Packer: --no-destroy-on-error wie Vagrant

Das klingt vernünftig. Ich denke, das -debug Flag ist in der Tat der richtige Ansatz, aber vielleicht sollte das -debug Flag Optionen erlauben wie:

• Schritt durch jeden Schritt
• Fahren Sie fort, bis ein Fehler auftritt
• Fahren Sie fort, bis die Bereinigungsschritte beginnen

Ich würde die Option, bis zu einem Fehler fortzufahren und die VM nicht zu zerstören, als äußerst nützlich empfinden

Wenn mir jemand einige Hinweise geben kann, wo ich anfangen soll, dies zu implementieren, kann ich möglicherweise etwas Zeit investieren, um dies als Option hinzuzufügen

Das wäre auch für mich sehr nützlich.

@timmow Möglicherweise müssen Sie den Bereinigungsschritt für die Instanzerstellung jedes Builders ändern, um nichts zu tun, wenn ein bestimmtes Flag gesetzt ist (z. B. https://github.com/mitchellh/packer/blob/master/builder/amazon/common/step_run_source_instance.go) # L122)

Es wäre ein gewisser Arbeitsaufwand, alle Schritte durchzukämmen und herauszufinden, wo es angebracht wäre, keine Maßnahmen zu ergreifen.

Eine Idee, die ich gerade hatte, wäre, ein Flag zu geben, das auf Benutzereingaben wartet, bevor ein Bereinigungsschritt verarbeitet wird. Auf diese Weise können Sie Ihr Debugging durchführen, beispielsweise die Eingabetaste drücken, und der Packer kümmert sich um die Bereinigung.

Fühlen Sie sich frei, mich hier anzupingen, wenn ich Ihnen helfen kann.

Zu Ihrer Information, dies geschieht auf FILO-Weise hier https://github.com/mitchellh/multistep/blob/master/basic_runner.go#L71

Möglicherweise müssen Sie den Basisläufer erweitern (debuggable_runner?)

Es wäre großartig, eine Art Schritt "Überspringen" -Funktionalität weiter unten hinzuzufügen, die im Grunde genommen Bereinigungsschritte für diese Konfiguration vom Typ --no-destroy-on-error überspringt. Es würde auch einige coole Sachen im -debug -Modus ermöglichen, wie das interaktive Drücken von s zum Überspringen.

Ähnlich wie beim Debuggen von "Pause" denke ich, dass eine Option wie -pause-on-error Vorteil wäre.

Hallo, ich sehe, dass dieses Problem durch dieses Commit https://github.com/mitchellh/packer/commit/2ed7c3f65cc2e0a14d39d8934ef1168f8192bb08 behoben wird, aber ich sehe die Änderung im HEAD des Hauptzweigs nicht. Wo und warum ist es verschwunden?

Das brauche ich auch wirklich.

Gibt es Hoffnung, diese Funktion zu haben? Was muss getan werden, um 2ed7c3f oder eine Variation davon zusammenzuführen?

Ja, ich könnte diese Option auch verwenden. Ich sehe, es wurde begangen, aber dann verschwunden.

Gibt es ein Update dazu?

Ich würde das auch wirklich lieben. Ich kann Ihnen nicht sagen, wie viel Zeit ich mit dem Debuggen von Problemen verschwendet habe und einen langen VM-Erstellungsprozess durchlaufen muss, um immer wieder auf den Fehler zuzugreifen. Die VM in der Nähe zu halten, wäre ein großer Gewinn.

Gibt es eine ETA, bei der diese (oder eine ähnliche) Funktionalität in main zusammengeführt wird? Ich habe versucht, mit Packer eine VM zu erstellen, auf der Visual Studio als Teil der Vagrant-Basisbox installiert ist, und ich brauche sie wirklich, um die VM nicht zu zerstören, bevor ich die Gelegenheit hatte, herauszufinden, warum die Schritte fehlschlagen. Es ist nicht akzeptabel, jeden Schritt über --debug bestätigen zu müssen.

Eine weitere Abstimmung für diese, da die Option -debug den Fehler unterdrückt, den ich zu analysieren versuche.

Es wird so viel Zeit aufgewendet, um den endgültigen Zustand des Computers zu debuggen, bevor er ausfällt. Der Schalter -debug schneidet es nicht ab - ich möchte, dass es den normalen Prozess durchläuft und den Arbeitsordner nach einem Fehler intakt bleibt, damit ich mit Protokollen und Status diagnostizieren kann. Ich freue mich wirklich auf eine Art Wechsel des Betriebszustands.

Ein weiteres +1 für diese Funktion wäre immens hilfreich.

+1 Es treten ähnliche Probleme auf, bei denen es hilfreich wäre, den endgültigen Status zu debuggen, einige Bereitstellungsskripte zu optimieren und den Build dann erneut auszuführen, um festzustellen, ob dies den Prozess behoben hat, anstatt bei jedem Debug-Schritt manuell die Eingabetaste zu drücken.

Ein weiteres + 1 für diese Funktion. Es wäre schön zu wissen, was damit passiert ist? Niemand aus dem Team antwortete. Gehen Sie voran auf den Teller, es tut nicht weh. LOL! Ich bin völlig neu bei Packer. Ich war am Ende eines ISO-Builds von 1,5 Stunden und dies geschah. Das Testen und Debuggen sollte von größter Bedeutung sein, um einen vollständig süßen Anwendungs-Stream zu erhalten.

+1 Auch hier erstellen wir unsere Bilder kopflos. Daher ist es nicht gut, wenn --debug ein manuelles Durchlaufen erfordert, aber es wäre großartig, das fehlerhafte Bild untersuchen zu können.

: +1: Ich möchte diese Funktion auch haben

+1 Diese Funktion wäre großartig!

Verwandt mit oder möglicherweise von # 1687 dupliziert

+1 Nur um die VM unverändert zu lassen, ohne

+1 dieser wird sehr nützlich sein

+1, um die Debug-Bereitstellung zu unterstützen, wenn nur mit Packer

+1 Ich bin im selben Boot. Ich habe unzählige Stunden damit verbracht, Windows-VMs neu zu erstellen, nur um einen Cheffehler im Bereitstellungsschritt zu haben, und keine Möglichkeit, die VM zu debuggen, wenn sie gelöscht wird. Bitte lassen Sie es eine Option geben, bei einem Fehler nicht alles zu löschen.

Nachdem ich gesehen habe, dass dieses Problem seit zwei Jahren besteht, habe ich keine Hoffnung, dass es behoben wird. Ich versuche wirklich, Packer zu mögen, aber am Ende verbringe ich mehr Zeit damit, auf den Build-Schritt zu warten, als die Ergebnisse tatsächlich zu verwenden.

Pleeeeeaseeeeeee +1

+1

+1

+1

Ich habe mich gefragt, was das Argument dafür war, und dieses Problem über Google gefunden. Ich wurde traurig, als es keine Funktion gab.

Hallo Entwickler, ich habe diesen Thread erneut besucht und kann mit Sicherheit sagen, dass dieser Fehler die Entwicklung unserer Systeme erheblich verlangsamt, obwohl ich es geschafft habe, Packer weiterhin effektiv zu nutzen. Wir können es schaffen, aber es wäre aufrichtig schön, wenn ein Mitarbeiter eine Anleitung zu diesem Thema @mitchellh geben könnte. Ich habe vielleicht sogar Zeit, eine Lösung beizutragen, wenn ich in die richtige Richtung weisen kann, aber ich werde hoffentlich auf Ihre Antwort oder jemanden in Ihrem Team warten. Vielen Dank für das tolle Tool. Ich möchte auf jeden Fall, dass Sie und Ihr Team wissen, wie großartig ich dieses Produkt finde.

Da ich alle +1 E-Mail-Benachrichtigungen für eine Funktion, die ich auch wollte, satt hatte ;-), begann ich mich in die Codebasis zu vertiefen und fügte eine erste Implementierung hinzu. HINWEIS - Dies ist noch nicht getestet ... und ich weiß nicht einmal, ob es richtig funktioniert. Wenn Sie versuchen, es aus dem Quellcode zu erstellen, stieß ich auf ein interessantes Problem, bei dem Packer sich selbst von Github aus selbst referenziert, was dazu führt, dass dieser Code nicht ordnungsgemäß erstellt wird. Sie müssen Ihren Packer-Quellordner in GoPath vorübergehend mit dem Ordner verknüpfen, in den Sie dieses Repo herunterladen (oder warten, bis ich eine Pull-Anfrage getestet und gesendet habe).

https://github.com/jcoutch/packer

Die Tatsache, dass dies nicht das Standardverhalten ist, wenn Sie mein Französisch verzeihen, ist völlig verrückt. Tippfehler in Ihrem Installationsskript gemacht? Lassen Sie uns einfach Ihre gesamte Arbeit zerstören und Ihnen diese Stunde Ihres Lebens niemals zurückgeben. Über. Und über. Nochmal._

Ich stelle mir vor, dass buchstäblich jede einzelne Person, die dieses Tool für etwas anderes als die einfachsten Beispiele verwendet, jedes Mal auf dieses Problem stößt, wenn sie es verwendet. Es besteht eindeutig eine massive Nachfrage nach dieser Funktion, und dennoch wird sie 2 Jahre später noch nicht implementiert.

Absolut umwerfend.

+1

Mann, das war ein bissiger Kommentar. Schlechte Laune gestern, aber all diese Zeitverschwendung kostet viel Zeit und Geld.

@jcoutch - hast du einen Build, den du teilen kannst?

Ich habe ein OSX-Build auf meinem Computer, hatte aber noch keine Gelegenheit, es zu testen
funktioniert noch. In meiner Freizeit daran zu arbeiten ... was ich nicht viel zu tun hatte
Ersatz in letzter Zeit. Ganz zu schweigen davon, dass dies meine erste Erfahrung mit Go ist (ganz
eine interessante Sprache.) Ich werde versuchen, sie bis Ende dieser Woche zu testen,
und wenn alles gut aussieht, werde ich eine Pull-Anfrage einreichen. Ich werde es auch versuchen
Post-OSX- und Windows-Builds, die andere testen können, sobald ich weiß, dass sie stabil sind.

Am Mittwoch, 23. September 2015, 17:14 Uhr schrieb Rich Jones [email protected] :

Mann, das war ein bissiger Kommentar. Schlechte Laune gestern, aber die ganze Zeit
Verschwendung kostet viel Zeit und Geld.

@jcouth - hast du einen Build, den du teilen kannst?

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/mitchellh/packer/issues/409#issuecomment -142730452.

Bitte !! :-D

Ich versuche es mit Ansible auszuführen, aber es funktioniert nicht und der KVM-Gast ist nach dem Fehler verschwunden. Es ist also nicht möglich, dorthin zu gehen, um zu sehen, was falsch ist ...

Prost!

Viel gebraucht. Vielen Dank.

Hier ist der @ jcoutch- Patch mit den richtigen Zeilenenden zur einfacheren Überprüfung: https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

Dieser Patch verhindert das Löschen nur, wenn Präprozessoren ausfallen. Er behält keine Artefakte bei, wenn ein Builder (mit seinen Provisionern) ausfällt.

EDIT: Das scheint die Absicht zu sein, aber eigentlich tut es nichts, obwohl es leicht repariert werden könnte, um es zu erfüllen.

Ja, ich hatte keine Gelegenheit gehabt, auf diesen Thread zu antworten. Ich habe es endlich versucht
meine Änderungen mit einem fallenden Provisioner aus ... es funktioniert nicht so wie ich
beabsichtigt. Wenn Sie sich den Code genauer ansehen, sieht es so aus, als würde der Builder damit umgehen
das Löschen von Artefakten bei einem Bereitstellungsfehler ... anstelle des Codes I.
geändert.

Am Samstag, 3. Oktober 2015, 09:37 Uhr schrieb Orivej Desh [email protected] :

Hier ist der @ jcoutch https://github.com/jcoutch Patch mit der richtigen Zeile
Endungen zur leichteren Überprüfung: orivej @ 23bbd4d
https://github.com/orivej/packer/commit/23bbd4d8fd2d3971eb40eb9348204e3c6c086cca

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/mitchellh/packer/issues/409#issuecomment -145249481.

Hier ist https://github.com/orivej/multistep/commit/e02bce9811c65138ea2e84c7162cd8769f35858f ein Proof-of-Concept, das --debug neu definiert, um nach dem ersten Fehler nur einmal anzuhalten. Https://github.com/mitchellh/multistep/pull/5 muss vor der ersten Bereinigung und nicht vor der zweiten Bereinigung angehalten werden. Dieses Verhalten wurde in # 1687 vorgeschlagen. (Dies ist kein Proof of Concept, sondern eine Lösung, wenn die in # 1687 vorgeschlagene Neudefinition von --debug in Ordnung ist.)

+1 zum Erhalt von Artefakten bei einem fehlgeschlagenen Build im -debug-Modus.

Ich habe Packer für eine Weile mit dem Patch ausgeführt und hatte nie einen Grund, ihn ohne -debug zu starten. Ich frage mich, ob ich Binärdateien für umfassendere Tests veröffentlichen sollte.

+1

Ich habe gerade bemerkt, dass der Link, den ich gepostet habe, ein Patch für mehrere Schritte war, nicht für Packer. Das Update, bei dem der Packer bei Ausführung mit -debug bei einem Fehler pausiert, befindet sich unter https://github.com/orivej/packer/tree/debug-on-error

@orivej Mit welchem ​​Patch soll ich beginnen, wenn ich Ihren No-Destroy-Verhaltenspatch testen möchte? https://github.com/orivej/packer/commit/a713a4698831a8dfcd48484dc4675631779b6840 ?

Ja, es gibt ein Commit, orivej @ a713a46. Es kann immer noch sauber auf den Master übertragen werden.
Sie benötigen außerdem einen Patch für github.com/mitchellh/multistep von https://github.com/mitchellh/multistep/pull/5 . Andernfalls wird der Packer angehalten, nachdem der letzte Schritt zerstört wurde.

@orivej hast du eine gepatchte Binärdatei für OSX? Das Neustarten des gesamten Erstellungsprozesses aufgrund eines kleinen Fehlers beim Erstellen einer Gentoo Linux-Box ist unglaublich schmerzhaft (zeitaufwändig). Die Möglichkeit, die Box nach dem Ausfall zu laden und herauszufinden, was falsch ist, ist für mich ein Muss.

Ich habe eine Option hinzugefügt, um den fehlgeschlagenen Schritt erneut zu versuchen, anstatt ihn abzubrechen. Selbst wenn dies erfolgreich ist, kann der Build insgesamt fehlschlagen. und wenn ich mich nicht geirrt habe, verarbeitet der Packer die Eingabe nicht zuverlässig, und der Benutzer muss möglicherweise mehrmals antworten.

Diese Änderung hängt nicht von gepatchten Mehrstufen ab und lebt in Branch , Commit .

Ich habe hier Binärdateien hochgeladen: https://orivej-packer.s3.amazonaws.com/index.html (Teilbaum debug-on-error-2 ).

Die Möglichkeit, die Box nach dem Ausfall zu laden und herauszufinden, was falsch ist, ist für mich ein Muss.

Mein Patch bewahrt nicht die Box, die geladen werden kann, sondern lässt die aktuelle Box am Leben, bis Sie den Build manuell beenden, damit Sie SSH in sie einbinden und das Debuggen durchführen können (wenn Sie packer mit -debug aufrufen

Danke für das Feedback, @orivej.

Mein Patch behält nicht die Box bei, die geladen werden kann, sondern lässt die aktuelle Box am Leben, bis Sie den Build manuell beenden, damit Sie SSH in sie einbinden und das Debuggen durchführen können (wenn Sie den Packer mit der Option -debug aufrufen).

Es wurde festgestellt, dass der Standard-Packer-Build mit --debug pausiert, bevor die Umgebung zerstört wird, sodass Sie die Möglichkeit haben, ihn wie beschrieben zu debuggen. Dazu benutze ich "headless": false . Wie unterschiedlich ist der Prozess mit Ihrem Patch?

• Der Packer wird erst angehalten, nachdem ein Schritt fehlgeschlagen ist, anstatt nach jedem Schritt anzuhalten.
• Es wird angehalten, bevor der Packer nach dem fehlgeschlagenen Schritt bereinigt. (Obwohl ich mich nicht erinnere, warum ich das gebraucht habe, da der problematischste Bereitstellungsschritt keine Bereinigung durchführt.)
• Die zweite Ausgabe des Patches ermöglicht es, den fehlgeschlagenen Schritt erneut zu versuchen. (Wenn die Bereitstellung fehlschlägt, werden alle Bereitsteller erneut ausgeführt.)

Ich habe gerade bemerkt, dass # 2608 eine unglückliche Entscheidung getroffen hat, Plugins von älteren Packer-Versionen auf neuere eingebaute Plugins zu priorisieren. Um also meinen Packer-Build (oder zukünftige Packer-Versionen, sofern die Autoren dieses Verhalten nicht überdenken) zu verwenden, müssen Sie alle entfernen Binärdateien, deren Namen mit packer- .

Die unzuverlässige Eingabebehandlung ist auch ein Artefakt von # 2608, ich werde sehen, ob ich es beheben kann.

Die unzuverlässige Eingabebehandlung wird durch die zusätzliche Initialisierung der integrierten Plugins verursacht, insbesondere durch setupStdin() in main.go . Da dieser Aufruf ohnehin nicht in der Lage zu sein scheint, seinen erklärten Zweck zu erfüllen, konnte ich ihn ohne Auswirkungen deaktivieren und meine Binärdateien neu erstellen.

Es wäre sehr nützlich, den Packer einfach beenden zu können, ohne die VM bei einem Fehler anzuhalten oder zu zerstören. Dies ist besonders wichtig bei Bereitstellungskomponenten, die normalerweise die benutzerdefinierteste Logik enthalten. Wenn Sie SSH in eine Box einbinden und das ursprüngliche Skript erneut ausführen oder ein modifiziertes Skript oder Rezept zum Testen ausprobieren können, erhalten Sie schnelle und wertvolle Einblicke in die tatsächlichen Ursachen des Fehlers und in die Fehlerbehebung. Das Erstellen eines ganzen Packers ist viel zu zeitaufwändig, um ihn selbst für die einfachste Fehlerbehebung zu benötigen.

Das Flag -debug ist nützlich, macht den Vorgang jedoch sehr manuell. Sehr oft ist es nützlich, einen unbeaufsichtigten Build auszuführen, ihn jedoch zu beenden, wenn ein Fehler auftritt, und das System in einem Zustand zu belassen, in dem die Ursache untersucht und behoben werden kann.

: +1: Unabhängig davon, ob -debug oder nicht, sollte es eine Option geben, die Instanz am Laufen zu halten, damit Sie Skripte / Debugging auf der Instanz usw. wiedergeben können, es sei denn, dies beeinträchtigt irgendwie die Erfassung des AMI-Images.

+1

+1 .. Ich bin überrascht, dass dies ungefähr 2,5 Jahre später sein würde, da es so nützlich wäre. Dies würde mir die Fehlerbehebung bei meinem Packer-Build erheblich erleichtern.

Ich konnte dies in AWS überwinden, indem ich den Kündigungsschutz für die Instanz verwendete, bevor der Chef-Client startet. Es ist keine anständige Option, aber hey, es funktioniert. Alle anderen Optionen :)

+500 - warum ist diese Funktion noch nicht verfügbar?

Vielleicht könnten wir als Entwickler versuchen, uns die Hände schmutzig zu machen, anstatt uns zu beschweren?

Die Funktionsanforderung könnte nicht einfacher sein.

• Lesen Sie eine neue Befehlszeilenoption ( --no-destroy-on-error )
• Fügen Sie an der richtigen Stelle ein bescheidenes if . Pseudocode:

unless no_destroy_on_error # add this conditional <<<<<<<<<
   perform_cleanup
end

Ich versuche es mal. Und wenn es funktioniert, werde ich es nicht teilen (hauptsächlich, um hypothetische Anfragen / Beschwerden zu vermeiden). Anstrengung ist eine gute Sache.

@vemv , ich habe dieses Problem bereits im Wesentlichen mit zwei Commits unter https://github.com/orivej/packer/commits/debug-on-error-2 gelöst

@orivej Das ist großartig! Ich habe geplant, ein --pause-on-error hinzuzufügen, was meiner Meinung nach der beste Weg ist (wenn ein Schritt fehlschlägt, warten Sie vor dem Bereinigen auf einen Tastendruck, damit sich der Benutzer anmelden und Fehler beheben kann).

Könnten Sie eine PR mit Ihrem Code öffnen und wir können die Details dort besprechen.
CC @cbednarski

@vemv Ich

@orivej und @ rickard-von-essen, alles, was Benutzereingaben erfordert, funktioniert bei mir nicht wirklich, da ich Packer nur in automatisierten Werkzeugen verwende (dh Jenkins oder TravisCI). Ich weiß, dass es auch viele andere Leute in meiner Position gibt. Ich denke, was ich wirklich möchte, ist etwas, das (1) möglicherweise die Ausführlichkeit der Ausgabe erhöht und (2) die Quellmaschine (ob EC2, VMWare, was auch immer) einfach laufen lässt, damit ein Mensch sie nach dem überprüfen kann Job ist fehlgeschlagen.

Derzeit wird das Debuggen zwischen den Schritten angehalten, sodass Sie die Eingabetaste drücken müssen, um fortzufahren. Solange Sie wissen, bei welchem ​​Schritt Sie fehlschlagen werden, können Sie die VM dort lediglich zu Debug-Zwecken "halten", aber das ist offensichtlich nicht so gut. Sie möchten wirklich, dass die Vorlage jeden Schritt durchläuft, damit Sie den vollständigen Fehlerstatus überprüfen können.

Füge einfach mein: +1: hinzu. Ich könnte diese Funktion wirklich nutzen.

@jantman Ich werde packer -debug bereinigen lassen, wenn der Prozess fehlschlägt und keine Eingabe erhalten kann (z. B. mit Eingabe von /dev/null ). Beachten Sie, dass die Packer-Laufsequenz auf der Idee basiert, dass jeder Schritt anschließend bereinigt werden kann und wird. Durch eine abrupte Beendigung bleibt das System in einem Zustand, den der Packer möglicherweise nicht alleine verarbeiten kann (z. B. beschwert er sich über dieses Ausgabeverzeichnis existiert bereits), daher sollten Sie damit rechnen müssen, herauszufinden, wie Sie Ihren Prozess wiederholbar machen können, aber dies ist wahrscheinlich einfach.

@ rickard-von-essen Ich werde meinen Patch aktualisieren (neue Anbieter hinzufügen) und später heute eine Pull-Anfrage stellen.

Von @DarwinJS unter https://github.com/mitchellh/packer/issues/3445#issue -148713866

Ich erstelle Windows-Boxen in AWS und habe das ebs-Volume "delete_on_termination" auf false gesetzt, damit ich nach einem fehlgeschlagenen Build [a] das Volume anhängen, [b] eine Instanz starten, [c] die Protokolle anzeigen, [d] Fahren Sie die Instanz herunter, [e] trennen Sie das Volume, [f] löschen Sie das Volume manuell.

Ich habe festgestellt, dass die c:\windows\temp<guid>.out -Dateien die Konsolenausgabe der von mir ausgeführten Powershell-Provisioner enthalten.

Das Abrufen dieser Ausgabe ist der einzige Grund, warum ich all diese zusätzlichen Schritte ausführen muss, um diese Informationen zu erhalten.

Wäre großartig, wenn Packer so etwas wie PACKER_CONSOLE_LOGS_COPY=$env:temp damit diese Protokolle immer zurückgebracht werden können (insbesondere das letzte, das fehlgeschlagen ist) und ich die zusätzlichen Schritte vermeiden könnte.

Für diejenigen, die mein Ziel teilen, die neueste Packer-Entwicklerversion zu kompilieren und gleichzeitig orivej frühere Korrekturen zu integrieren, die beim ersten Fehlschlagen der Packer-Erstellung pausieren, sind hier die Schritte, die ich unternommen habe, die für mich funktioniert haben.

Complete "Setting up Go to work on Parker" steps 1-4 . ( see https://github.com/mitchellh/packer/blob/master/CONTRIBUTING.md )
git checkout master
git remote add fork https://github.com/orivej/packer
git fetch fork
git checkout -b debug-on-error fork/debug-on-error
git merge debug-on-error
make
run ./bin/packer build -debug template.json

Ich kann bestätigen, dass dies bei mir funktioniert hat und die Bereitstellung nur dann unterbrochen wurde, wenn ein Fehler aufgetreten ist.

Ich konnte https://github.com/orivej/packer/tree/debug-on-error-2 nicht erfolgreich zusammenführen

Ich bin neugierig, ich bin ziemlich neu in Packer und Git und diesem Problem; Gibt es eine andere Art und Weise, wie Leute die Korrekturen von orivej implementiert haben, als ich es beschrieben habe? Möglicherweise fehlt mir etwas sehr Offensichtliches. Bitte geben Sie mir Bescheid, wenn dies der Fall ist.

Überprüfen Sie einfach den Status dieses Problems.

Ist es so, dass die Änderungen von @orivej dieses Problem

+1

es wäre wirklich nützlich, im Moment verwende ich eine Inline-Shell mit sleep 1800 , um die VM am Leben zu erhalten.
Bitte implementieren Sie so schnell wie möglich :)

Imho -debug macht das, was wir alle brauchen. Nach jedem Befehl müssen Sie die Eingabetaste drücken, um mit dem nächsten fortzufahren. Keine Eingabe = vm lebendig :)

@noose - Ich sitze nicht da und

IMHO ist der -bug völlig nutzlos. Ich verwende komplizierte Builds und habe wirklich keine Geduld, tausendmal die Eingabetaste zu drücken, bis ich zum Problem komme.
Ich verstehe wirklich nicht, warum eine solche einfache Funktion so schwer zu implementieren ist.

@ henris42 Während ich Ihnen in diesem Zusammenhang in Bezug auf die Nutzlosigkeit von -debug zustimme, warum versuchen Sie es nicht mit einer Pull-Anfrage, wenn es so ein Kinderspiel ist?

@noose , ich automatisiere den Packer-Build in einem Jenkins-Job (der von Git die config / scripts und Ansible-Playbooks abruft). Wenn Sie Packer auf diese Weise verwenden, ist ein interaktiver Modus nicht sinnvoll. Es ist viel nützlicher, eine Post-Failure-Analyse durchzuführen.
Ich denke, dies ist ein häufiges Szenario in der DevOps-Welt :)

Scheint, als ob jeder das braucht. Das Erstellen dieser AMIs ist fehleranfällig und diese Funktion würde die Fehlerbehebung weniger zeitaufwändig machen

Ich stimme @worstadmin zu. Beim Erstellen von Vagrant-Boxen können Sie das Problem aus verschiedenen Blickwinkeln lösen (z. B. die virtuelle Maschine in der Nähe halten, Dinge mit dem Null-Provisioner ausprobieren usw.), während Amazon-Images eine besondere Rasse darstellen und das Debuggen sehr lästig ist, wenn dies der Fall ist ein Problem.

In Kombination mit https://github.com/mitchellh/packer/issues/1687 wäre dies großartig.

Darüber hinaus ist es häufig hilfreich, Fehler der Bereitsteller zu ignorieren und fortzufahren, insbesondere in der frühen Phase der Entwicklung eines Images usw.

Fast 3 Jahre später ... und immer noch fast nichts. Ich habe die letzten Tage damit verbracht, meinen Kopf auf einer Tastatur zu zerschlagen und versucht, komplexe Windows-Builds zu erstellen, bei denen die Ausführung von Powershell-Skripten ohne Ausgabe willkürlich und zufällig fehlschlägt. Aufgrund der automatischen Bereinigung kann ich nicht auf die Instanz springen. Wenn ich mit aktiviertem -debug laufe, scheinen die zusätzlichen "Pausen", die durch die manuelle Eingabe entstehen, dazu zu führen, dass dieses Problem nicht auftritt. Was, Sie würden denken, das wäre sinnvoll, wenn ich meinen Powershell-Skripten einfach eine Menge Schlaf hinzufüge, um dies zu simulieren, und das hilft nicht.

Nicht einmal lügen, ich werde jemandem eine Prämie von 100 US-Dollar zahlen, wenn jemand so schnell wie möglich ernsthaft eine --no-destroy-on-error-Funktion erstellen und dafür den Ball ins Rollen bringen kann. Ich (und es scheint, als ob Hunderte von anderen) diese Funktion benötigen, insbesondere wenn man bedenkt, dass Packer normalerweise mit Blick auf die Automatisierung verwendet werden (über CI / CD / etc). Also hier ist meine lange +1 und Bitte.

Hey, es könnte eine Problemumgehung für einen Shell-Provisioner geben, ich habe jedoch keine Ahnung von anderen Provisionern. : cry_cat_face:

Ich hatte es heute fast funktioniert, aber als ich in Go lernte, wusste ich nicht, dass ich wieder in der Hölle der Metaprogrammierung landen werde, indem ich die Benutzeroberfläche durch mehrere Dateien jage, um die Implementierung zu finden :(

Schauen Sie sich meinen aktuellen Vorschlag unter # 3885 an, der für mich bereits gut aussieht!

@tmartinx :

Ich versuche es mit Ansible auszuführen, aber es funktioniert nicht und der KVM-Gast ist nach dem Fehler verschwunden. Es ist also nicht möglich, dorthin zu gehen, um zu sehen, was falsch ist ...

Um dieses Problem zu umgehen, bis es eine neue Packer-Version gibt, die # 3885 enthält:

    {
      "type": "shell",
      "inline": [
...
        "ansible-playbook ... || (echo \"*** FAILED WITH CODE $? *** Hit Ctrl-C to terminate\"; sleep 14400; exit 1)"
        ]
    }

Sie haben dann 4 Stunden Zeit, um in die noch laufende VM zu ssh und herumzustöbern.

Was zur Hölle geht hier vor?

• Packer hat einen VMware-Fehler "Unbekannter Fehler" festgestellt.
• _Packer_ sagte mir, ich solle die Protokolldatei von VMWare auf weitere Informationen überprüfen. Das Protokoll soll sich im Ausgabeverzeichnis befinden.
• Aber _Packer selbst_ löscht das Ausgabeverzeichnis, so dass ich das Protokoll nicht überprüfen kann. Haha! Gut, Packer, du Schlingel!
• Scheiße anderer Leute sind in eine ähnliche Situation geraten, wie sie es offensichtlich tun würden.
• Die Leute fordern seit Jahren eine scheinbar sehr einfache und unkomplizierte Lösung für dieses Problem.
• Einige von ihnen beschlossen sogar, dies selbst zu beheben. Es scheint, dass ihre Patches von HashiCorp abgelehnt wurden oder dass sie einfach nicht erfolgreich waren.
• In jedem Fall hat HashiCorp Funkstille bewahrt. Es sieht so aus, als würden sie das niemals beheben.

Sollen wir daraus schließen, dass die US-Regierung HashiCorp geknebelt und ihnen gesagt hat, sie sollen das nicht reparieren oder so?

Es fällt mir schwer, alternative Erklärungen zu finden.

Ich hatte den Eindruck, dass die Tools von HashiCorp insgesamt eine gute Wahl für DevOpsy-Produkte sind, aber jetzt habe ich Bedenken. Ernsthaft. Vermissen wir alle hier etwas Offensichtliches oder ist HashiCorp einfach nur super schattig?

Der Grund, warum dieses Ticket geschlossen ist, ist, dass das Problem bereits behoben wurde.

Fügen Sie der Befehlszeile das Flag -on-error=ask Wenn dann ein Fehler auftritt, werden Sie gefragt, ob Sie die Build-Artefakte löschen möchten oder nicht.

Bevor Sie diese Frage beantworten, können Sie in die VM ssh und herumstöbern.

@ peterlindstrom234 , dies wurde bereits implementiert. Sie können "-on-error = abort" verwenden und der Packer sollte keine Bereinigung durchführen, wenn ein Fehler auftritt.

Okay, mein schlechtes. Es hat allerdings seltsam lange gedauert.

@ Peterlindstrom234 Es hat lange