Packer: ansible 2.8 Pausen Packer ansible Provisioner

Bin auf genau das gleiche Problem gestoßen - auf ansible 2.7.10 herabgestuft und es hat perfekt funktioniert

konnte das noch jemand tadeln?

Hier gilt das gleiche. Ich musste ein Downgrade durchführen.

Am Dienstag, den 28. Mai 2019 um 20:58 Uhr schrieb AndrewCi [email protected] :

konnte das noch jemand tadeln?

- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/hashicorp/packer/issues/7667?
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAAAFFFYN7SKLPFDER6IOYDPXV6GTANCNFSM4HOEP2HQ
.

Ich kann dies auch mit dem Azure ARM-Provisioner reproduzieren

yup, auch herabgestuft ansible

Ich denke, wir treffen dies auf ansible 2.6.2

@intinig Auf welche Version führen Sie ein Downgrade durch?

Das Zurücksetzen auf 2.7.10 hat es für mich behoben.

Okay für mich, ich habe das umgangen, indem ich die Option -vv . WILD!

2.7.10

Am 30. Mai 2019 um 19:50 schrieb adamday2 [email protected] :

Das Zurücksetzen auf 2.7.10 hat es für mich behoben.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/hashicorp/packer/issues/7667?
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAAAFFESVO36RH5QHKQV2F3PYAHWNANCNFSM4HOEP2HQ
.

Dies hängt (zumindest in einigen Fällen) mit der automatisierten Python-Interpreter-Erkennung zusammen, die Ansible 2.8 hinzugefügt wurde. Das Hardcodieren von /usr/bin/python die von mir beobachteten

      "extra_arguments": [
        "--extra-vars",
        "ansible_python_interpreter=/usr/bin/python"
      ],

Treffen Sie dies, benötigen Sie jedoch wirklich 2.8 für einige der erweiterten vSphere-erweiterten Module, die veröffentlicht wurden.

Machen Sie sich hier nur eine Notiz, da dies ein beliebtes Problem ist. Dieser Provisioner ist einer unserer von der Community unterstützten Provisioner. Dies bedeutet, dass die HashiCorp-Betreuer nicht viel technische Zeit damit verbringen. Dies bedeutet, dass der beste Weg, um zu sehen, wie Ihr Vorschlag in Packer aufgenommen wird, darin besteht, eine PR zu öffnen.

@ Flowerysong danke für die Tipps, es funktioniert! Das virtualenv macht die Hilfe.

Ein Windows-Computer mit Packer-Verbindung hat das gleiche Problem. Hat jemand eine Problemumgehung?

Hat jemand zumindest eine Grundursache dafür, was diesen Hang verursacht, und einen möglichen Plan, um dies zu beheben? Gerne helfe ich, wo ich kann, bin aber nicht mit Go vertraut (könnte mit einem Punkt in die richtige Richtung sinnvoller sein).

Könnte es auch einen Unterschied machen, Packer von einem anderen Betriebssystem aus auszuführen?

Habe das gleiche. Mit Packer 1.3.3, 1.3.4, 1.4.1, 1.4.2 versucht, zeigen die Ansible-Versionen 2.7.10, 2.8.0 und 2.8.1 alle dasselbe Verhalten. Das Festlegen von ANSIBLE_PYTHON_INTERPRETER env var war erfolgreich.

Ich habe mir das heute kurz angesehen. Mein Bauchgefühl basiert auf Ihren ansible_python_interpreter-Erkenntnissen, dass die Warnung, die bei Verwendung der Fallback-Liste generiert wird, den Hang verursacht, weil wir stderr irgendwo nicht richtig verarbeiten.

In ungefähr einer Stunde hatte ich Probleme, eine Situation zu reproduzieren, in der ich diese Fallback-Warnung generieren konnte, um diese Theorie zu testen. Wenn einer von Ihnen, der auf dieses Problem stößt, Ihren Gastbetriebssystem-Arch und die installierte Python-Version (und den Installationsort) freigeben kann, wäre dies sehr hilfreich, damit ich nicht viel Zeit damit verbringe, meine Räder zu drehen Holen Sie sich einen Repro-Fall.

Im Moment klingt es so, als würde das Festlegen des ansible_python_interpreter direkt für Sie alle funktionieren. Ich wäre gespannt, ob es ausreicht, den Wert ansible_python_interpreter=auto_silent festzulegen, um dies zu lösen. Das würde meiner Theorie, dass Packer die Leitung, durch die die Warnung irgendwo durchkommt, falsch gehandhabt wird, etwas Glaubwürdiges hinzufügen.

@ SwampDragons Es ist der gleiche Grund, warum Pipelining dazu führt, dass der Provisioner hängen

Dies wird möglicherweise auf der Ansible-Seite behoben, indem der Interpreter-Erkennung ein Timeout hinzugefügt wird. Derzeit gibt es jedoch keinen Zeitplan für dieses Update.

@ Flowerysong danke für die Info. Haben Sie einen Link zu einem GH-Problem oder etwas, das über die Timeout-Diskussion spricht, die wir hier verfolgen können?

https://github.com/ansible/ansible/issues/57542

SO @SwampDragons - gemäß Ihrer Frage kann ich dies mit folgenden
"extra_arguments": [
"--extra-vars",
"ansible_python_interpreter = auto_silent"
]]
Ermöglicht eine Linux-Ausführung mit ansible-local ohne Probleme mit den folgenden Funktionen:
Ansible 2.8.1
Packer 1.4.2
KVM Build von RHEL7

Dieselben Argumente führen jedoch immer noch zu einem Fehler, wenn versucht wird, einen WINDOWS Server 2019-Host mit dem folgenden Fehler bereitzustellen:

2019-07-15T14: 05: 46-04: 00: ==> qemu: Ausführen von Ansible: ansible-playbook --extra-vars packer_build_name = qemu packer_builder_type = qemu -o IdentitiesOnly = yes -i / tmp / packer-provisor- ansible556061269 /opt/jenkins/workspace/-templates_2019_imagebuild_PR-10/windows/ansible/initial_config.yaml -e ansible_ssh_private_key_file = / tmp / ansible-key458833230 --extra-vars packer_http_adra - 10.xt - vars ansible_shell_type = Powershell ansible_shell_executable = Keine ansible_python_interpreter = auto_silent

2019-07-15T14: 05: 55-04: 00: qemu:

2019-07-15T14: 05: 55-04: 00: qemu: PLAY [all] * * * * * * * * * * * * * * * * * * * * * * **

2019-07-15T14: 05: 55-04: 00: qemu:

2019-07-15T14: 05: 55-04: 00: qemu: AUFGABE [Fakten sammeln] * * * * * * * * * * * * * * * * * * **

2019-07-15T14: 05: 56-04: 00: qemu: fatal: [Standard]: FEHLGESCHLAGEN! => {"ansible_facts": {}, "geändert": false, "msg": "Die folgenden Module konnten nicht ausgeführt werden: setup \ n setup: MODULFEHLER \ nSuchen Sie stdout / stderr für den genauen Fehler \ n"}

2019-07-15T14: 05: 56-04: 00: qemu:

2019-07-15T14: 05: 56-04: 00: qemu: PLAY RECAP * * * * * * * * * * * * * * * * * * * * * * **

2019-07-15T14: 05: 56-04: 00: qemu: Standard: ok = 0 geändert = 0 nicht erreichbar = 0 fehlgeschlagen = 1 übersprungen = 0 gerettet = 0 ignoriert = 0

2019-07-15T14: 05: 56-04: 00: qemu:

2019-07-15T14: 05: 56-04: 00: ==> qemu: Ausgabeverzeichnis löschen ...

2019-07-15T14: 05: 56-04: 00: Build 'qemu' fehlerhaft: Fehler beim Ausführen Ansible: Exit-Status ungleich Null: Exit-Status 2

Ich denke also, wir haben eine gültige Problemumgehung für "Linux", während wir auf die Pipeline "Fix" im Ansible Core warten, aber "Windows" braucht noch etwas mehr, damit es vorerst funktioniert?

Hat jemand gerade daran gearbeitet oder Ideen, wie man sich einem Fix nähert?

Nicht dass ich wüsste.

Mein Fix war, folgendes hinzuzufügen: "extra_arguments": ["-e", "ansible_python_interpreter=/usr/bin/python", "-vv"]

Ich kann dieses Problem immer noch nicht reproduzieren, um mein Leben zu retten, aber ich habe beschlossen, weiter zu versuchen, eine Problemumgehung zu erstellen, die auf der Theorie basiert, dass das zugrunde liegende Problem der Packer-SSH-Proxy ist, der zum Weiterleiten von Ansible-Anrufen erstellt wird.

Ich habe eine PR # 8625 aus einem Zweig erstellt, der diesen Localhost-Proxy vollständig entfernt und den Provisioner so ändert, dass stattdessen die Host-IP in der Inventardatei verwendet wird. Ich würde mich freuen, wenn einige von Ihnen, die von dem Fehler betroffen sind, einen Build herunterladen könnten (hier verfügbar: https://circleci.com/gh/hashicorp/packer/29969#artifacts/containers/0) und mich wissen lassen, ob es löst das Problem für Sie. Bitte beachten Sie, dass dieser Zweig derzeit Docker-Builds bricht. Ich werde herausfinden, wie ich sie lösen kann, nachdem wir herausgefunden haben, ob dieser Schritt das Problem tatsächlich lösen wird.

Bitte lassen Sie mich auch wissen, ob das Entfernen des Proxys Probleme für Sie verursacht. Diese PR befindet sich in einem sehr unfertigen Zustand.

Gibt es Abnehmer, die die oben genannte PR testen und mich wissen lassen, ob sie die ansible 2.8+ Inkompatibilität behebt? Ich habe neue Builds, die hier verfügbar sind: https://circleci.com/gh/hashicorp/packer/32248#artifacts/containers/0 , mit denen Sie den Proxy-Adapter basierend auf der booleschen Option "use_proxy" verwenden oder nicht verwenden können. (Derzeit ist der Standardwert true, aber ich werde den Standardwert in Zukunft ändern, wenn er sich lohnt.)

@ SwampDragons ,

Ich habe versucht, diese neue Version 1.5.2 sowohl auf Macos (Python 3.7.3) als auch von einem Docker aus zu erstellen
Container (Python 3.6.9), aber der Packer-Build bleibt jetzt stehen, bevor der ansible Provisioner ausgeführt wird:

==> azure-arm: Waiting for WinRM to become available...
==> azure-arm: Timeout waiting for WinRM.

... auf beiden Architekturen.

Wenn ich zu Packer 1.5.1 zurückkehre, ist die Verbindung zu WinRM erfolgreich, Powershell
Provisioner werden erfolgreich ausgeführt, aber der ansible Provisioner schlägt fehl, egal was passiert
Option oder zusätzliche Argumente werden angegeben. Die Problemumgehung 'ansible_python_interpreter'
oben erwähnt funktioniert bei mir leider nicht.

Die 2 Umgebungen, die ich versucht habe zu erstellen:
1. macos [Darwin Kernel Version 19.3.0: root: xnu-6153.81.5 ~ 1 / RELEASE_X86_64 x86_64]
- Packer 1.5.1
- Erbauer: Azurblauer Arm
- os_type: Windows
- Kommunikator: winrm
- ansible 2.9.2
- Python 3.7.3

1. Docker / mcr.microsoft.com/azure-cli : neueste [Linux 1cba84bd80dd
   4.19.76-linuxkit # 1 SMP Do 17.10. 19:31:58 UTC 2019 x86_64 Linux]
2. Packer 1.5.1
   
   
   
   • Erbauer: Azurblauer Arm
   
   
   • os_type: Windows
   
   
   • Kommunikator: winrm
   
   
3. ansible 2.9.4
4. Python 3.6.9

debug logs:

---------
    azure-arm: [azure-arm]
    azure-arm: XX.XXX.142.52
==> azure-arm: Provisioning with Ansible...
==> azure-arm: Executing Ansible: ansible-playbook --extra-vars packer_build_name=azure-arm packer_builder_type=azure-arm -o IdentitiesOnly=yes -i /var/folders/08/_km87dpn38zf4c0yr8lnq8880000gp/T/packer-provisioner-ansible557376101 /Users/Laurent/work/ansible/win-playboom.yml -e ansible_ssh_private_key_file=/var/folders/08/_km87dpn38zf4c0yr8lnq8880000gp/T/ansible-key717334430 -vvvv --connection packer --inventory-file=../ansible/inventory/inventory_azure_rm.yml --extra-vars ansible_python_interpreter=/Users/Laurent/.pyenv/shims/python ansible_shell_type=powershell ansible_shell_executable=None
    azure-arm: ansible-playbook 2.9.2
    azure-arm: <XX.XXX.142.52> ESTABLISH WINRM CONNECTION FOR USER: packer on PORT 5986 TO XX.XXX.142.52
    azure-arm: fatal: [pkrvmnzc8laeuz0_3a38]: UNREACHABLE! => {
    azure-arm:     "changed": false,
    azure-arm:     "msg": "ssl: the specified credentials were rejected by the server",
    azure-arm:     "unreachable": true
    azure-arm: }
...
    azure-arm: fatal: [default]: FAILED! => {
    azure-arm:     "ansible_facts": {},
    azure-arm:     "changed": false,
    azure-arm:     "failed_modules": {
    azure-arm:         "setup": {
    azure-arm:             "failed": true,
    azure-arm:             "module_stderr": "OpenSSH_7.9p1, LibreSSL 2.7.3\r\ndebug1:
    ...
    ...
        azure-arm:             "module_stdout": "",
    azure-arm:             "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error",
    azure-arm:             "rc": 1
    azure-arm:         }
    azure-arm:     },
    azure-arm:     "msg": "The following modules failed to execute: setup\n"
    azure-arm: }
    azure-arm:
    azure-arm: PLAY RECAP *********************************************************************
    azure-arm: default                    : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0
    azure-arm: pkrvmnzc8laeuz0_3a38       : ok=0    changed=0    unreachable=1    failed=0    skipped=0    rescued=0    ignored=0

---------

Vielen Dank für das Update - ich habe ein paar Korrekturen vorgenommen und neue Binärdateien finden Sie auf der PR. Ich hatte jedoch keine Gelegenheit, die No-Proxy-Option für winrm einzurichten.

Ich konnte endlich den Hang reproduzieren und bestätigen, dass das Deaktivieren des Proxys, wie im verknüpften Pr möglich, das Problem für SSH-Builds behebt. Ich hatte noch keine Gelegenheit, das Update für WinRM zu recherchieren und zu implementieren.

Artefakte für diejenigen unter Ihnen auf SSH, die diese Problemumgehung benötigen, finden Sie hier: https://circleci.com/gh/hashicorp/packer/33086#artifacts/containers/0 .

Da ich dies für Windows noch nicht in Gang gebracht habe, wird es wahrscheinlich nicht in die Version 1.5.2 kommen, aber ich werde es wieder aufnehmen und in ein paar Tagen weiter daran arbeiten.

Danke @SwampDragons , das sind großartige Neuigkeiten! Wir freuen uns darauf, die Korrekturen für Windows-Builds zu erhalten, wenn Sie weiter daran arbeiten können.

Ich kann bestätigen, dass die Verwendung des obigen Builds das Problem behebt, dass Ansible über SSH eine Verbindung zur Packer-Instanz herstellt. 🚀

Ich habe das gleiche Problem in Ansible 2.9 mit WinRM. Dann habe ich das Ansible auf 2.7 herabgestuft, danach hat es einmal gut funktioniert. Aber jetzt habe ich das gleiche Problem auch in Ansible 2.7.

ansible = 2.7.0
Python-Version = 3.7.6
Packer = 1.5.4

<127.0.0.1> (0, b '', b'OpenSSH_7.9p1, LibreSSL 2.7.3 \ r \ ndebug1: Konfigurationsdaten lesen / etc / ssh / ssh_config \ r \ ndebug1: / etc / ssh / ssh_config Zeile 48: Anwenden von Optionen für * \ r \ ndebug2: resolve_canonicalize: hostname 127.0.0.1 ist die Adresse \ r \ ndebug1: auto-mux: Versuch, einen vorhandenen Master zu verwenden \ r \ ndebug2: fd 3 Einstellung O_NONBLOCK \ r \ ndebug2: mux_client_hello_exchange: master version 4 \ r \ ndebug3: mux_client_forwards: Anforderungsweiterleitungen: 0 lokal, 0 remote \ r \ ndebug3: mux_client_request_session: Eingabe von \ r \ ndebug3: mux_client_request_alive: Eingabe von \ r \ ndebug3: mux_client_request_alive: erledigt pid = n \ r \ n # <CLIXML \ r \ nSystem.Management.Automation.PSCustomObjectSystem.Object1Module für den ersten Gebrauch vorbereiten.0-1-1Abgeschlossen-1 debug3: mux_client_read_packet: Header lesen fehlgeschlagen: Pipe defekt \ r \ ndebug2: Exit-Status von Master 0 erhalten \ r \ n ')

@ SwampDragons kein Glück mit Windows Update

Noch nicht - ich war auf Reisen und hatte diese Woche keine Hände auf der Tastatur. Ich werde versuchen, die Aufgabe nächste Woche wieder aufzunehmen.

@ SwampDragons Gibt es einen Status unter Windows? Vielen Dank!

Ja! Am Freitag habe ich einen POC für Windows-Builds ohne Proxy erhalten, die mit WinRM mit grundlegender Authentifizierung arbeiten, aber ich muss noch Tests durchführen, um sicherzustellen, dass es mit SSL funktioniert.

Es lebt! Binärdateien, die für ansible mit winrm funktionieren, können hier heruntergeladen werden: https://circleci.com/gh/hashicorp/packer/42423#artifacts/containers/0

Ausführliche Anweisungen zur Verwendung finden Sie in den in der PR hinzugefügten Dokumenten: https://github.com/hashicorp/packer/pull/8625

Hi @SwampDragons Vielen Dank für all Ihre Arbeit (und an andere bei der Berichterstattung)! :) :)
Ich habe den oben aufgeführten nächtlichen Build ausprobiert und er schlägt für mich immer noch fehl. Ich muss immer noch auf Ansible 2.7.10 zurücksetzen, damit es für mich funktioniert.
[dev-user@centos-7-dev Downloads]$ ansible --version ansible 2.9.6 config file = /etc/ansible/ansible.cfg configured module search path = [u'/home/dev-user/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules'] ansible python module location = /usr/lib/python2.7/site-packages/ansible executable location = /usr/bin/ansible python version = 2.7.5 (default, Aug 7 2019, 00:51:29) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] [dev-user@centos-7-dev Downloads]$ packer --version 1.5.6 [dev-user@centos-7-dev Downloads]$
Dies ist von einem Centos 7.7-Host, der die vsphere-iso verwendet (großartig zu sehen, dass sie jetzt eingebaut ist!), Die ein minimales Centos 7.7-Image erstellt.
Hat noch jemand andere Probleme gefunden?

@ChrisGWarp Ich benötige einen vollständigen Repro-Fall, um mehr über Ihren Fehler zu Computer funktioniert;)

packer_test.zip
Getan!
Einschließlich Fehlerprotokoll, Korrektur (Herabstufung ansible) und Erfolg.
Hoffe das hilft. :) :)

Schauen Sie sich also Ihre Konfiguration an:

        {
            "type":            "ansible",
            "playbook_file":   "./ansible/packer-test.yml",
            "galaxy_file":     "./ansible/requirements.yml",
            "user":            "root",
            "extra_arguments": [ "-v" ]
        }

Jetzt habe ich dies nicht mit Galaxy getestet, aber auch in Ihrer Konfiguration scheint es nicht so, als hätten Sie den Proxy tatsächlich ausgeschaltet.

        {
            "type":            "ansible",
            "playbook_file":   "./ansible/packer-test.yml",
            "galaxy_file":     "./ansible/requirements.yml",
            "user":            "root",
            "use_proxy": false,
            "extra_arguments": [ "-v" ]
        }

Können Sie das oben genannte mit PACKER_DEBUG = 1 in Ihrer Umgebung versuchen, um ausführliche Protokolle zu erhalten? Und diese in einem Kern verknüpfen?

Ok, ich habe es geschafft, weiter zu kommen, bin dann aber auf andere Probleme gestoßen.
Folgendes habe ich gefunden / beobachtet:

Ich war mir über den use_proxy nicht sicher, ob es sich um einen vorhandenen Parameter handelte, dessen Wert geändert werden musste, oder ob es sich um einen neuen handelte.

Packer 1.5.5 drosselt daran, daher gehe ich von einer neuen Variablen aus und bin daher nicht abwärtskompatibel.

Packer 1.5.6-dev hat funktioniert, da es nicht in der Phase des Sammelns von Fakten hing (yey!), Aber dann erstickte es an der Host-Schlüsselfrage. Woher lädt es ansible.cfg? Oder die gleiche Frage auf andere Weise, woher (wie in welchem ​​Verzeichnis) kommt ansible-playbook?

Dies ist das .json-Dateifragment. Die env-Variablen schienen das Verhalten des Hostschlüssels nicht zu ändern.

"provisioners": [ { "type": "ansible", "playbook_file": "./ansible/packer-test.yml", "galaxy_file": "./ansible/requirements.yml", "user": "root", "use_proxy": false, "ansible_env_vars": [ "ANSIBLE_HOST_KEY_CHECKING=False", "ANSIBLE_NOCOLOR=True" ], "extra_arguments": [ "-v" ] } ]

Hier ist die Protokollausgabe:

`[ dev-user @ centos-7-dev packer- test] $ PACKER_LOG = 1 Packer-Build -force vsphere-packer-test-x86_64.json
2020/04/26 20:46:14 [INFO] Packer-Version: 1.5.6-dev (d824b7e969d0d54ce23b42aa2a577a73a4780765) [go1.13.9 linux amd64]
2020/04/26 20:46:14 Überprüfen von 'PACKER_CONFIG' auf einen Konfigurationsdateipfad
2020/04/26 20:46:14 'PACKER_CONFIG' nicht gesetzt; Überprüfen des Standardpfads für die Konfigurationsdatei
2020/04/26 20:46:14 Versuch, die Konfigurationsdatei zu öffnen: /home/dev-user/.packerconfig
2020/04/26 20:46:14 [WARN] Konfigurationsdatei existiert nicht: /home/dev-user/.packerconfig
2020/04/26 20:46:14 Festlegen des Cache-Verzeichnisses: / home / dev-user / eclipse-workspace / packer-test / packer_cache
2020/04/26 20:46:14 Plugin-Client für Pfad erstellen: / usr / bin / packer
2020/04/26 20:46:14 Plugin starten: / usr / bin / packer [] string {"/ usr / bin / packer", "Plugin", "packer-builder-vsphere-iso"}
2020/04/26 20:46:14 Warten auf RPC-Adresse für: / usr / bin / packer
2020/04/26 20:46:14 Unix-RPC-Adresse für / usr / bin / packer empfangen: addr ist / tmp / packer-plugin421608791
2020/04/26 20:46:14 packer-builder-vsphere-iso plugin: [INFO] Packer-Version: 1.5.6-dev (d824b7e969d0d54ce23b42aa2a577a73a4780765) [go1.13.9 linux amd64]
2020/04/26 20:46:14 packer-builder-vsphere-iso plugin: Überprüfen Sie 'PACKER_CONFIG' auf einen Konfigurationsdateipfad
2020/04/26 20:46:14 packer-builder-vsphere-iso plugin: 'PACKER_CONFIG' nicht gesetzt; Überprüfen des Standardpfads für die Konfigurationsdatei
2020/04/26 20:46:14 packer-builder-vsphere-iso plugin: Versuch, die Konfigurationsdatei zu öffnen: /home/dev-user/.packerconfig
2020/04/26 20:46:14 packer-builder-vsphere-iso plugin: [WARN] Konfigurationsdatei existiert nicht: /home/dev-user/.packerconfig
2020/04/26 20:46:14 packer-builder-vsphere-iso-Plugin: Festlegen des Cache-Verzeichnisses: / home / dev-user / eclipse-workspace / packer-test / packer_cache
2020/04/26 20:46:14 packer-builder-vsphere-iso plugin: args: [] string {"packer-builder-vsphere-iso"}
2020/04/26 20:46:14 packer-builder-vsphere-iso plugin: Plugin-Adresse: unix / tmp / packer-plugin421608791
2020/04/26 20:46:14 packer-builder-vsphere-iso plugin: Warten auf Verbindung ...
2020/04/26 20:46:14 packer-builder-vsphere-iso plugin: Plugin-Verbindung bedienen ...
2020/04/26 20:46:14 Plugin-Client für Pfad erstellen: / usr / bin / packer
2020/04/26 20:46:14 Plugin starten: / usr / bin / packer [] string {"/ usr / bin / packer", "plugin", "packer-providerer-ansible"}
2020/04/26 20:46:14 Warten auf RPC-Adresse für: / usr / bin / packer
2020/04/26 20:46:14 Unix-RPC-Adresse für / usr / bin / packer empfangen: addr ist / tmp / packer-plugin434205582
2020/04/26 20:46:14 Packer-Provisioner-Ansible-Plugin: [INFO] Packer-Version: 1.5.6-dev (d824b7e969d0d54ce23b42aa2a577a73a4780765) [go1.13.9 linux amd64]
2020/04/26 20:46:14 Packer-Provisioner-Ansible-Plugin: Überprüfen Sie 'PACKER_CONFIG' auf einen Konfigurationsdateipfad
2020/04/26 20:46:14 Packer-Provisioner-Ansible-Plugin: 'PACKER_CONFIG' nicht gesetzt; Überprüfen des Standardpfads für die Konfigurationsdatei
2020/04/26 20:46:14 Packer-Provisioner-Ansible-Plugin: Versuch, die Konfigurationsdatei zu öffnen: /home/dev-user/.packerconfig
2020/04/26 20:46:14 Packer-Provisioner-Ansible-Plugin: [WARN] Konfigurationsdatei existiert nicht: /home/dev-user/.packerconfig
2020/04/26 20:46:14 Packer-Provisioner-ansible-Plugin: Festlegen des Cache-Verzeichnisses: / home / dev-user / eclipse-workspace / packer-test / packer_cache
2020/04/26 20:46:14 Packer-Provisioner-Ansible-Plugin: Argumente: [] Zeichenfolge {"Packer-Provisioner-Ansible"}
2020/04/26 20:46:14 Packer-Provisioner-Ansible-Plugin: Plugin-Adresse: Unix / tmp / Packer-Plugin434205582
2020/04/26 20:46:14 Packer-Provisioner-Ansible-Plugin: Warten auf Verbindung ...
2020/04/26 20:46:14 Packer-Provisioner-Ansible-Plugin: Eine Plugin-Verbindung bedienen ...
vsphere-iso: Die Ausgabe erfolgt in dieser Farbe.

2020/04/26 20:46:14 Build-Debug-Modus: false
2020/04/26 20:46:14 Force Build: wahr
2020/04/26 20:46:14 Bei Fehler:
2020/04/26 20:46:14 Build vorbereiten: vsphere-iso
2020/04/26 20:46:15 Warten auf Builds abgeschlossen ...
2020/04/26 20:46:15 Build-Lauf starten: vsphere-iso
2020/04/26 20:46:15 Laufender Builder: vsphere-iso
2020/04/26 20:46:15 [INFO] (Telemetrie) Builder vsphere-iso wird gestartet
2020/04/26 20:46:15 Packer-Provisioner-Ansible-Plugin: Ansible-Playbook-Version: 2.9.6
==> vsphere-iso: VM erstellen ...
==> vsphere-iso: Hardware anpassen ...
==> vsphere-iso: ISO-Images mounten ...
2020/04/26 20:46:17 packer-builder-vsphere-iso plugin: CD-ROM auf Controller erstellen '& {{{} 200 0xc00055e2a00} 0 []} 'mit ISO' [ISOs] CentOS / CentOS-7-x86_64-Minimal-1908.iso '
==> vsphere-iso: Diskette erstellen ...
vsphere-iso: Dateien einfach aus floppy_files kopieren
2020/04/26 20:46:18 packer-builder-vsphere-iso plugin: Diskettenpfad: / tmp / packer579447498
2020/04/26 20:46:18 packer-builder-vsphere-iso plugin: Initialisierung des Blockgeräts, das von einer temporären Datei unterstützt wird
2020/04/26 20:46:18 packer-builder-vsphere-iso plugin: Formatieren des Blockgeräts mit einem FAT-Dateisystem ...
2020/04/26 20:46:18 packer-builder-vsphere-iso plugin: Initialisierung des FAT-Dateisystems auf dem Blockgerät
2020/04/26 20:46:18 packer-builder-vsphere-iso plugin: Lesen des Stammverzeichnisses aus dem Dateisystem
vsphere-iso: Kopieren der Datei: http / ks-7.7-minimal-static.cfg
vsphere-iso: Kopieren von Dateien aus floppy_files abgeschlossen
vsphere-iso: Sammeln von Pfaden von floppy_dirs
vsphere-iso: Resultierende Pfade von floppy_dirs: []
vsphere-iso: Kopierpfade von floppy_dirs fertig
==> vsphere-iso: Hochgeladenes erstelltes Diskettenbild
==> vsphere-iso: Generierte Diskette hinzufügen ...
==> vsphere-iso: Starten des HTTP-Servers auf Port 8081
2020/04/26 20:46:19 packer-builder-vsphere-iso plugin: Verfügbarer Port gefunden: 8081 auf IP: 0.0.0.0
==> vsphere-iso: Startreihenfolge vorübergehend einstellen ...
==> vsphere-iso: VM einschalten ...
==> vsphere-iso: 10s auf Boot warten ...
==> vsphere-iso: HTTP-Server arbeitet unter http: // ABCE: 8081 /
==> vsphere-iso: Boot-Befehl eingeben ...
2020/04/26 20:46:32 packer-builder-vsphere-iso plugin: Spezieller Code ''gefunden, ersetzt durch: CodeTab
2020/04/26 20:46:40 packer-builder-vsphere-iso plugin: Spezieller Code ''gefunden, ersetzt durch: CodeReturnEnter
2020/04/26 20:46:40 packer-builder-vsphere-iso plugin: Warte 1 Sekunde
==> vsphere-iso: Warten auf IP ...
2020/04/26 20:46:41 packer-builder-vsphere-iso plugin: [INFO] Warten auf IP, bis zur Gesamtzeitüberschreitung: 30m0s, Abrechnungszeitüberschreitung: 5s
2020/04/26 20:55:12 Packer-Builder-Vsphere-ISO-Plugin: VM IP erworben: ABCD
2020/04/26 20:55:12 packer-builder-vsphere-iso plugin: VM IP ist immer noch dieselbe: ABCD
2020/04/26 20:55:13 packer-builder-vsphere-iso plugin: VM IP ist immer noch dieselbe: ABCD
2020/04/26 20:55:14 packer-builder-vsphere-iso plugin: VM IP ist immer noch dieselbe: ABCD
2020/04/26 20:55:15 packer-builder-vsphere-iso plugin: VM IP ist immer noch dieselbe: ABCD
2020/04/26 20:55:16 packer-builder-vsphere-iso plugin: VM IP ist immer noch dieselbe: ABCD
==> vsphere-iso: IP-Adresse: ABCD
2020/04/26 20:55:17 packer-builder-vsphere-iso plugin: VM IP ist immer noch dieselbe: ABCD
2020/04/26 20:55:17 packer-builder-vsphere-iso plugin: VM IP scheint stabil genug zu sein: ABCD
==> vsphere-iso: Verbindung mit ssh communicator herstellen: ABCD
==> vsphere-iso: Warten auf die Verfügbarkeit von SSH ...
2020/04/26 20:55:17 packer-builder-vsphere-iso plugin: [INFO] Warten auf SSH, bis Timeout: 5m0s
2020/04/26 20:55:17 packer-builder-vsphere-iso plugin: [INFO] Versuch einer SSH-Verbindung zu ABCD: 22 ...
2020/04/26 20:55:17 packer-builder-vsphere-iso plugin: [DEBUG] stellt erneut eine Verbindung zur TCP-Verbindung für SSH her
2020/04/26 20:55:17 packer-builder-vsphere-iso plugin: [DEBUG] Handshake mit SSH
2020/04/26 20:55:17 packer-builder-vsphere-iso plugin: [DEBUG] Handshake abgeschlossen!
2020/04/26 20:55:17 packer-builder-vsphere-iso plugin: [DEBUG] Neue ssh-Sitzung eröffnen
==> vsphere-iso: Verbunden mit SSH!
2020/04/26 20:55:17 packer-builder-vsphere-iso plugin: [INFO] Agentenweiterleitung aktiviert
2020/04/26 20:55:17 packer-builder-vsphere-iso-Plugin: Ausführen des Bereitstellungs-Hooks
2020/04/26 20:55:17 [INFO] (Telemetrie) Starten des Provisioners ansible
==> vsphere-iso: Bereitstellung mit Ansible ...
vsphere-iso: Kein Proxy-Adapter für Ansible-Ausführung:
vsphere-iso: Verwenden von SSH-Schlüsseln aus dem Packer Communicator ...
vsphere-iso: Verwenden von SSH-Schlüsseln von Packer Communicator ...
2020/04/26 20:55:17 Packer-Provisioner-Ansible-Plugin: Erstellen einer Inventardatei für Ansible Run ...
vsphere-iso: Ausführen von Ansible Galaxy
vsphere-iso: [WARNUNG]: - dovry.ansible_role_sample (master) ist bereits installiert - use
vsphere-iso: --force, um die Version in nicht angegeben zu ändern
2020/04/26 20:55:18 Packer-Provisioner-Ansible-Plugin: Megan cmd ist & exec.Cmd {Pfad: "/ usr / bin / ansible-playbook", Argumente: [] string {"ansible-playbook", " -e "," packer_build_name = vsphere-iso "," -e "," packer_builder_type = vsphere-iso "," -e "," ansible_ssh_private_key_file = / tmp / ansible-key848613781 "," -e "," packer_http_dr = : 8081 "," --ssh-extra-args "," -o IdentitiesOnly = yes "," -i "," / tmp / packer-providerer-ansible807514096 "," / home / dev-user / eclipse-workspace / packer-test / ansible / packer-test.yml "," -v "}, Env: [] string (nil), Dir:" ", Stdin: io.Reader (nil), Stdout: io.Writer (nil) , Stderr: io.Writer (nil), ExtraFiles: [] os.File (nil), SysProcAttr :( syscall.SysProcAttr) (nil), Process :( os.Process) (nil), ProcessState :( os.ProcessState) (nil), ctx: context.Context (nil), lookPathErr: error (nil), beendet: false, childFiles: [] os.File (nil), closeAfterStart: [] io.Closer (nil), closeAfterWait: [] io.Closer (nil), goroutine: [] func () error (nil), errch: (chan error) (nil), waitDone: (chan struct {}) (nil)}==> vsphere-iso: Ausführen von Ansible: ansible-playbook -e packer_build_name = vsphere-iso -e packer_builder_type = vsphere-iso -e ansible_ssh_private_key_file = / tmp / ansible-key848613781 -e packer_http_addr: args -o IdentitiesOnly = yes -i / tmp / packer-provisor-ansible807514096 /home/dev-user/eclipse-workspace/packer-test/ansible/packer-test.yml -vvsphere-iso: Verwenden von /etc/ansible/ansible.cfg als Konfigurationsdateivsphere-iso:vsphere-iso: PLAY [Konfigurieren Sie die Basis-VM] * * * * * * * * * * * * * * * * *