Packer: ansible 2.8 pauses packer ansible approvisionneur

Ran dans exactement le même problème - rétrogradé à ansible 2.7.10 et cela a parfaitement fonctionné

quelqu'un d'autre a-t-il pu le reprocher?

Pareil ici. J'ai dû déclasser.

Le mar 28 mai 2019 à 20 h 58, AndrewCi [email protected] a écrit:

quelqu'un d'autre a-t-il pu le reprocher?

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/hashicorp/packer/issues/7667?email_source=notifications&email_token=AAAAFFDXJF7SZ3RCR7ZC4XLPXV6GTA5CNFSM4HOEP2H2YY3PNVWWK3TUL52HS4VM4DFVWNHGH45WWWK3TUL52HS4VMVWNX63NVWWK3TUL52HS4VMVWNX63GWWWK3TUL52HS4DFVWNX63NVWWK3TUL52HS4VMVWNX63NVWWK3TUL52HS4DFVWNX63GWWWK3TUL52HS4VFVWNX63
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAAFFFYN7SKLPFDER6IOYDPXV6GTANCNFSM4HOEP2HQ
.

Je suis également en mesure de reproduire cela à l'aide du provisionneur Azure ARM

yup, également déclassé ansible

Je pense que nous atteignons cela sur ansible 2.6.2

@intinig Vers quelle version rétrogradez-vous?

Revenir à 2.7.10 l'a corrigé pour moi.

Très bien pour moi, j'ai contourné ce problème en supprimant l'option -vv . SAUVAGE!

2.7.10

Le jeudi 30 mai 2019 à 19:50, adamday2 [email protected] a écrit:

Revenir à 2.7.10 l'a corrigé pour moi.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/hashicorp/packer/issues/7667?email_source=notifications&email_token=AAAAFFDBJO4EIUY3O43JGOTPYAHWNA5CNFSM4HOEP2H2YY3PNVWWK3TUL52HS4VMFVomToken=AAAAFFDBJO4EIUY3O43JGOTPYAHWNA5CNFSM4HOEP2H2YY3PNVWWK3TUL52HS4VMFVomT20WWWK3TUL52HS4VMVFVom
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAAFFESVO36RH5QHKQV2F3PYAHWNANCNFSM4HOEP2HQ
.

Ceci est (au moins dans certains cas) lié à la découverte automatisée de l'interpréteur Python ajoutée à Ansible 2.8; le codage en dur /usr/bin/python corrigé les blocages que j'ai observés.

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

Hit this, mais vraiment besoin de 2.8 pour certains des modules améliorés vSphere qui ont été publiés.

Il suffit de noter ici car il s'agit d'un problème populaire - ce fournisseur est l'un de nos fournisseurs pris en charge par la communauté, ce qui signifie que les responsables de HashiCorp n'y passent pas beaucoup de temps d'ingénierie; cela signifie que la meilleure façon de voir votre suggestion faire partie de Packer est d'ouvrir un PR.

@flowerysong merci pour les conseils, ça marche! Le virtualenv fait de l'aide.

Une machine Windows avec la connexion Packer a le même problème, est-ce que quelqu'un a une solution de contournement?

Quelqu'un a-t-il au moins une cause fondamentale de ce qui cause ce blocage et un plan potentiel pour résoudre ce problème? Heureux d'aider où je peux, mais pas familier avec Go (pourrait être plus utile avec un point dans la bonne direction).

En outre, l'exécution de Packer à partir d'un autre système d'exploitation pourrait-elle faire une différence?

J'ai la même chose. Tentative avec packer 1.3.3, 1.3.4, 1.4.1, 1.4.2, les versions 2.7.10, 2.8.0 et 2.8.1 ansibles présentent toutes le même comportement. La définition de ANSIBLE_PYTHON_INTERPRETER env var a réussi.

J'ai jeté un coup d'œil à cela aujourd'hui; mon instinct basé sur vos découvertes ansible_python_interpreter est que l'avertissement généré lors de l'utilisation de la liste de secours provoque le blocage car nous ne traitons pas correctement stderr quelque part.

Dans une heure environ, j'ai bricolé j'avais du mal à reproduire une situation où je pouvais générer cet avertissement de secours pour tester cette théorie, cependant. Si l'un d'entre vous qui rencontre ce problème peut partager votre architecture de système d'exploitation invité et quelle version de python est installée (et où elle est installée), ce serait très utile afin que je ne passe pas beaucoup de temps à faire tourner les roues obtenir un cas de repro.

Pour l'instant, cela ressemble à la définition de ansible_python_interpreter qui fonctionne directement pour vous tous. Je serais curieux de savoir si le mettre à la valeur ansible_python_interpreter=auto_silent est suffisant pour résoudre ce problème; cela ajouterait du crédit à ma théorie selon laquelle Packer a mal géré le tuyau par lequel l'avertissement passe quelque part.

@SwampDragons C'est la même raison pour laquelle le pipelining provoque le blocage du provisionneur, dont je ne connais pas la cause exacte. La découverte d'interpréteur utilise toujours le pipelining, qu'elle soit activée ou non pour l'exécution du module.

Cela va potentiellement être résolu du côté d'Ansible en ajoutant un délai d'expiration à la découverte de l'interpréteur, mais il n'y a actuellement aucun calendrier pour ce correctif.

@flowerysong merci pour l'info. Avez-vous un lien vers un problème de GH ou quelque chose qui parle de la discussion sur le délai d'expiration que nous pouvons suivre ici?

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

SO @SwampDragons - par votre question, je peux confirmer qu'en utilisant:
"extra_arguments": [
"--extra-vars",
"ansible_python_interpreter = auto_silent"
]
Permet à une exécution Linux utilisant ansible-local de fonctionner sans problème en utilisant les éléments suivants:
Ansible 2.8.1
Emballeur 1.4.2
Version KVM de RHEL7

Cependant, ces mêmes arguments entraînent toujours une erreur lors de la tentative de provisionnement d'un hôte WINDOWS Server 2019 avec l'erreur suivante:

2019-07-15T14: 05: 46-04: 00: ==> qemu: Exécution d'Ansible: ansible-playbook --extra-vars packer_build_name = qemu packer_builder_type = qemu -o IdentitiesOnly = yes -i / tmp / packer-provisioner- 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_addracker = 10.0.2connection vars ansible_shell_type = powershell ansible_shell_executable = Aucun ansible_python_interpreter = auto_silent

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

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

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

2019-07-15T14: 05: 55-04: 00: qemu: TASK [Faits Gathering] * * * * * * * * * * * * * * * * * **

2019-07-15T14: 05: 56-04: 00: qemu: fatal: [par défaut]: ECHEC! => {"ansible_facts": {}, "changed": false, "msg": "Les modules suivants n'ont pas pu s'exécuter: setup \ n setup: MODULE FAILURE \ nVoir stdout / stderr pour l'erreur exacte \ n"}

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

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

2019-07-15T14: 05: 56-04: 00: qemu: par défaut: ok = 0 modifié = 0 inaccessible = 0 échoué = 1 ignoré = 0 sauvé = 0 ignoré = 0

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

2019-07-15T14: 05: 56-04: 00: ==> qemu: Suppression du répertoire de sortie ...

2019-07-15T14: 05: 56-04: 00: Erreur de construction 'qemu': Erreur lors de l'exécution d'Ansible: état de sortie différent de zéro: état de sortie 2

Donc, je pense que nous avons une solution de contournement valable pour "Linux" en attendant le pipeline "fix" dans un core ansible, mais "Windows" a encore besoin de quelque chose de plus pour lui permettre de fonctionner pour le moment?

Quelqu'un travaille actuellement sur ce sujet ou a des idées sur la façon d'aborder un correctif?

Pas que je sache.

Ma solution consistait à ajouter ceci: "extra_arguments": ["-e", "ansible_python_interpreter=/usr/bin/python", "-vv"]

Je ne peux toujours pas reproduire ce problème pour me sauver la vie, mais j'ai décidé d'aller de l'avant en essayant de créer une solution de contournement basée sur la théorie selon laquelle le problème sous-jacent est le proxy ssh de Packer qu'il crée pour transférer les appels Ansible.

J'ai créé un PR # 8625 à partir d'une branche qui supprime complètement ce proxy localhost et modifie l'approvisionneur pour utiliser à la place l'adresse IP de l'hôte dans le fichier d'inventaire. J'adorerais si certains d'entre vous tous affectés par le bogue pouvaient supprimer une version (disponible ici: https://circleci.com/gh/hashicorp/packer/29969#artifacts/containers/0) et me le faire savoir si cela résout le problème pour vous. Veuillez noter que dans l'état actuel des choses, cette branche rompt les versions de Docker. Je trouverai comment les annuler après avoir déterminé si cette décision résoudra réellement le problème.

Veuillez également me faire savoir si la suppression du proxy vous cause des problèmes; que PR est vraiment dans un état de travail en cours.

Des preneurs à tester le PR ci-dessus et à me faire savoir s'il résout l'incompatibilité ansible 2.8+? J'ai de nouvelles versions, disponibles ici: https://circleci.com/gh/hashicorp/packer/32248#artifacts/containers/0 , qui vous permettent d'utiliser ou non l'adaptateur proxy basé sur l'option booléenne "use_proxy" (actuellement la valeur par défaut est true, mais je changerai la valeur par défaut à l'avenir si cela semble utile)

@SwampDragons , merci d'avoir fourni ces nouvelles versions de packer (v 1.5.2).

J'ai essayé cette nouvelle version 1.5.2 à la fois sur macos (Python 3.7.3) et à partir d'un docker
conteneur (Python 3.6.9) mais la compilation du packer se bloque maintenant avant d'exécuter l'approvisionneur ansible:

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

... sur les deux architectures.

Si je reviens au packer 1.5.1, la connexion à WinRM réussit, PowerShell
les approvisionneurs s'exécutent avec succès, mais l'approvisionnement ansible échoue quoi qu'il arrive
une option ou des arguments supplémentaires sont donnés. La solution de contournement 'ansible_python_interpreter'
mentionné ci-dessus ne fonctionne pas pour moi malheureusement.

Les 2 environnements que j'ai essayé de construire:
1. macos [Darwin Kernel Version 19.3.0: root: xnu-6153.81.5 ~ 1 / RELEASE_X86_64 x86_64]
- emballeur 1.5.1
- constructeur: azure-arm
- os_type: Windows
- communicateur: winrm
- ansible 2.9.2
- Python 3.7.3

1. Docker / mcr.microsoft.com/azure- cli: dernier [Linux 1cba84bd80dd
   4.19.76-linuxkit # 1 SMP jeu 17 oct 19:31:58 UTC 2019 x86_64 Linux]
2. emballeur 1.5.1
   
   
   
   • constructeur: azure-arm
   
   
   • os_type: Windows
   
   
   • communicateur: 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

---------

Merci pour la mise à jour - j'ai poussé quelques correctifs et de nouveaux binaires peuvent être trouvés sur le PR. Cependant, je n'ai pas eu la chance de configurer l'option sans proxy pour winrm.

J'ai finalement pu reproduire le blocage et je peux confirmer que la désactivation du proxy, comme possible dans le Pr lié, résout le problème pour les versions SSH. Je n'ai pas encore eu l'occasion de rechercher et d'implémenter le correctif pour WinRM.

Les artefacts pour ceux d'entre vous sur SSH qui ont besoin de cette solution de contournement peuvent être trouvés ici: https://circleci.com/gh/hashicorp/packer/33086#artifacts/containers/0 .

Comme je ne l'ai pas fait pour Windows, cela ne fera probablement pas partie de la version 1.5.2, mais je vais le reprendre et continuer à travailler dessus dans quelques jours.

Merci @SwampDragons , c'est une excellente nouvelle! Dans l'attente d'obtenir les correctifs pour les versions de Windows lorsque vous pourrez continuer à travailler dessus.

Je peux confirmer que l'utilisation de la version ci-dessus résout le problème de connexion d'Ansible à l'instance Packer via SSH. 🚀

Je rencontre le même problème dans ansible 2.9 avec winrm. Ensuite, je rétrograde l'ansible à 2.7 après cela, il fonctionnait bien une fois. Mais maintenant, je rencontre également le même problème dans ansible 2.7.

ansible = 2,7,0
version python = 3.7.6
emballeur = 1,5,4

<127.0.0.1> (0, b '', b'OpenSSH_7.9p1, LibreSSL 2.7.3 \ r \ ndebug1: Lecture des données de configuration / etc / ssh / ssh_config \ r \ ndebug1: / etc / ssh / ssh_config ligne 48: Application des options pour * \ r \ ndebug2: resolution_canonicalize: hostname 127.0.0.1 est l'adresse \ r \ ndebug1: auto-mux: essai du maître existant \ r \ ndebug2: fd 3 paramètre O_NONBLOCK \ r \ ndebug2: mux_client_hello_exchange: master version 4 \ r \ ndebug3: mux_client_forwards: réexpéditions demande: 0 locale, 0 à distance \ r \ ndebug3: mux_client_request_session: entrer \ r \ ndebug3: mux_client_request_alive: entrer \ r \ ndebug3: mux_client_request_alive: fait pid = 14869 \ r \ ndebug3: mux_client_request_session: demande session envoyées \ r \ n # <CLIXML \ r \ nSystem.Management.Automation.PSCustomObjectSystem.Object1Préparation des modules pour la première utilisation.0-1-1Terminé-1 debug3: mux_client_read_packet: échec de la lecture de l'en-tête: pipe cassée \ r \ ndebug2: état de sortie reçu du maître 0 \ r \ n ')

@SwampDragons a de la chance avec la mise à jour de Windows

Pas encore - j'ai voyagé et je n'ai pas eu la main sur le clavier cette semaine. Je vais essayer de reprendre la tâche la semaine prochaine.

@SwampDragons y a-t-il un statut sur Windows? Je vous remercie!

Oui! Vendredi, j'ai reçu un POC pour les versions Windows sans proxy fonctionnant avec WinRM avec une authentification de base, mais je dois encore faire des tests pour m'assurer que cela fonctionne avec ssl.

Cela vit! Les binaires qui fonctionnent pour ansible avec winrm peuvent être téléchargés ici: https://circleci.com/gh/hashicorp/packer/42423#artifacts/containers/0

Voir les documents ajoutés dans le PR pour des instructions d'utilisation détaillées: https://github.com/hashicorp/packer/pull/8625

Salut @SwampDragons Merci pour tout votre travail (et aux autres sur les rapports)! :)
J'ai essayé la version nocturne indiquée ci-dessus, et cela échoue toujours pour moi. Je dois encore revenir à Ansible 2.7.10 pour que cela fonctionne pour moi.
[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]$
Cela provient d'un hôte Centos 7.7 utilisant vsphere-iso (super de le voir intégré maintenant!) Construisant une image minimale Centos 7.7.
Quelqu'un d'autre a-t-il trouvé d'autres problèmes?

@ChrisGWarp J'aurai besoin d'un cas de repro complet afin d'examiner plus en détail votre échec, car il fonctionne sur ma machine;)

packer_test.zip
Terminé!
Y compris le journal de l'échec, la rectification (rétrogradation ansible) et le succès.
J'espère que cela t'aides. :)

Donc, en regardant votre configuration:

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

Maintenant, je n'ai pas testé cela avec Galaxy, mais aussi dans votre configuration, il ne semble pas que vous ayez réellement désactivé le proxy.

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

Pouvez-vous essayer ce qui précède avec PACKER_DEBUG = 1 dans votre environnement pour obtenir des journaux détaillés? Et les lier dans un résumé?

Ok, j'ai réussi à aller plus loin, mais j'ai ensuite rencontré d'autres problèmes.
Voici ce que j'ai trouvé / observé:

Je n'étais pas sûr de use_proxy, s'il s'agissait d'un paramètre existant dont la valeur devait être modifiée ou s'il s'agissait d'un nouveau paramètre.

Packer 1.5.5 s'étouffe dessus, donc je suppose une nouvelle variable et donc pas rétrocompatible.

Packer 1.5.6-dev a fonctionné, car il ne s'est pas bloqué au stade de la collecte des faits (oui!), Mais il s'est ensuite étouffé sur le problème de la clé hôte. D'où charge-t-il ansible.cfg? Ou, la même question d'une autre manière, où (comme dans quel répertoire) est-ce que ansible-playbook est généré?

Il s'agit du fragment de fichier .json, les variables d'environnement ne semblaient pas modifier le comportement de la clé hôte.

"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" ] } ]

Voici la sortie du journal:

`[ 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] Version de Packer: 1.5.6-dev (d824b7e969d0d54ce23b42aa2a577a73a4780765) [go1.13.9 linux amd64]
2020/04/26 20:46:14 Vérification de 'PACKER_CONFIG' pour un chemin de fichier de configuration
2020/04/26 20:46:14 'PACKER_CONFIG' non défini; vérification du chemin du fichier de configuration par défaut
2020/04/26 20:46:14 Tentative d'ouverture du fichier de configuration: /home/dev-user/.packerconfig
2020/04/26 20:46:14 [WARN] Le fichier de configuration n'existe pas: /home/dev-user/.packerconfig
2020/04/26 20:46:14 Définition du répertoire de cache: / home / dev-user / eclipse-workspace / packer-test / packer_cache
2020/04/26 20:46:14 Création d'un client de plugin pour le chemin: / usr / bin / packer
2020/04/26 20:46:14 Démarrage du plugin: / usr / bin / packer [] string {"/ usr / bin / packer", "plugin", "packer-builder-vsphere-iso"}
2020/04/26 20:46:14 En attente de l'adresse RPC pour: / usr / bin / packer
2020/04/26 20:46:14 Adresse RPC unix reçue pour / usr / bin / packer: addr is / tmp / packer-plugin421608791
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: [INFO] Version Packer: 1.5.6-dev (d824b7e969d0d54ce23b42aa2a577a73a4780765) [go1.13.9 linux amd64]
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: Vérification de 'PACKER_CONFIG' pour un chemin de fichier de configuration
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: 'PACKER_CONFIG' non défini; vérification du chemin du fichier de configuration par défaut
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: tentative d'ouverture du fichier de configuration: /home/dev-user/.packerconfig
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: [WARN] Le fichier de configuration n'existe pas: /home/dev-user/.packerconfig
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: Définition du répertoire de cache: / home / dev-user / eclipse-workspace / packer-test / packer_cache
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: args: [] string {"packer-builder-vsphere-iso"}
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: Adresse du plugin: unix / tmp / packer-plugin421608791
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: En attente de connexion ...
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: Servir une connexion de plugin ...
2020/04/26 20:46:14 Création d'un client de plugin pour le chemin: / usr / bin / packer
2020/04/26 20:46:14 Démarrage du plugin: / usr / bin / packer [] string {"/ usr / bin / packer", "plugin", "packer-provisioner-ansible"}
2020/04/26 20:46:14 En attente de l'adresse RPC pour: / usr / bin / packer
2020/04/26 20:46:14 Adresse RPC unix reçue pour / usr / bin / packer: addr is / tmp / packer-plugin434205582
2020/04/26 20:46:14 plugin packer-provisioner-ansible: [INFO] Version Packer: 1.5.6-dev (d824b7e969d0d54ce23b42aa2a577a73a4780765) [go1.13.9 linux amd64]
2020/04/26 20:46:14 plugin packer-provisioner-ansible: Vérification de 'PACKER_CONFIG' pour un chemin de fichier de configuration
2020/04/26 20:46:14 plugin packer-provisioner-ansible: 'PACKER_CONFIG' non défini; vérification du chemin du fichier de configuration par défaut
2020/04/26 20:46:14 plugin packer-provisioner-ansible: tentative d'ouverture du fichier de configuration: /home/dev-user/.packerconfig
2020/04/26 20:46:14 plugin packer-provisioner-ansible: [WARN] Le fichier de configuration n'existe pas: /home/dev-user/.packerconfig
2020/04/26 20:46:14 plugin packer-provisioner-ansible: Définition du répertoire de cache: / home / dev-user / eclipse-workspace / packer-test / packer_cache
2020/04/26 20:46:14 plugin packer-provisioner-ansible: args: [] string {"packer-provisioner-ansible"}
2020/04/26 20:46:14 plugin packer-provisioner-ansible: Adresse du plugin: unix / tmp / packer-plugin434205582
2020/04/26 20:46:14 plugin packer-provisioner-ansible: En attente de connexion ...
2020/04/26 20:46:14 plugin packer-provisioner-ansible: Servir une connexion de plugin ...
vsphere-iso: la sortie sera dans cette couleur.

2020/04/26 20:46:14 Mode de débogage de construction: false
2020/04/26 20:46:14 Force build: vrai
2020/04/26 20:46:14 En cas d'erreur:
2020/04/26 20:46:14 Préparation de la compilation: vsphere-iso
2020/04/26 20:46:15 En attente des builds pour terminer ...
2020/04/26 20:46:15 Démarrage de la compilation: vsphere-iso
2020/04/26 20:46:15 Générateur en cours d'exécution: vsphere-iso
2020/04/26 20:46:15 [INFO] (télémétrie) Démarrage du constructeur vsphere-iso
2020/04/26 20:46:15 plug-in packer-provisioner-ansible: version du livre de jeu ansible: 2.9.6
==> vsphere-iso: Création de VM ...
==> vsphere-iso: Personnalisation du matériel ...
==> vsphere-iso: Montage d'images ISO ...
2020/04/26 20:46:17 plugin packer-builder-vsphere-iso: Création d'un CD-ROM sur le contrôleur '& {{{} 200 0xc00055e2a00} 0 []} 'avec iso' [ISO] CentOS / CentOS-7-x86_64-Minimal-1908.iso '
==> vsphere-iso: Création d'une disquette ...
vsphere-iso: copie de fichiers à plat depuis floppy_files
2020/04/26 20:46:18 plugin packer-builder-vsphere-iso: chemin de la disquette: / tmp / packer579447498
2020/04/26 20:46:18 plugin packer-builder-vsphere-iso: Initialisation du périphérique bloc sauvegardé par un fichier temporaire
2020/04/26 20:46:18 plugin packer-builder-vsphere-iso: Formatage du périphérique bloc avec un système de fichiers FAT ...
2020/04/26 20:46:18 plugin packer-builder-vsphere-iso: Initialisation du système de fichiers FAT sur un périphérique bloc
2020/04/26 20:46:18 plugin packer-builder-vsphere-iso: lecture du répertoire racine à partir du système de fichiers
vsphere-iso: Copie du fichier: http / ks-7.7-minimal-static.cfg
vsphere-iso: copie terminée des fichiers depuis floppy_files
vsphere-iso: collecte des chemins depuis floppy_dirs
vsphere-iso: chemins résultants de floppy_dirs: []
vsphere-iso: copie des chemins d'accès depuis floppy_dirs
==> vsphere-iso: Téléchargement d'une image de disquette créée
==> vsphere-iso: Ajout de la disquette générée ...
==> vsphere-iso: démarrage du serveur HTTP sur le port 8081
2020/04/26 20:46:19 plugin packer-builder-vsphere-iso: port disponible trouvé: 8081 sur IP: 0.0.0.0
==> vsphere-iso: Définit l'ordre de démarrage temporaire ...
==> vsphere-iso: Allumer la VM ...
==> vsphere-iso: Attente de 10 s pour le démarrage ...
==> vsphere-iso: le serveur HTTP fonctionne sur http: // ABCE: 8081 /
==> vsphere-iso: saisie de la commande de démarrage ...
2020/04/26 20:46:32 plugin packer-builder-vsphere-iso: code spécial ''trouvé, remplacé par: CodeTab
2020/04/26 20:46:40 plugin packer-builder-vsphere-iso: code spécial ''trouvé, remplacé par: CodeReturnEnter
2020/04/26 20:46:40 plugin packer-builder-vsphere-iso: Attente 1 seconde
==> vsphere-iso: En attente d'IP ...
2020/04/26 20:46:41 plugin packer-builder-vsphere-iso: [INFO] En attente d'IP, jusqu'à timeout total: 30m0s, timeout de règlement: 5s
2020/04/26 20:55:12 plugin packer-builder-vsphere-iso: VM IP acquise: ABCD
2020/04/26 20:55:12 plugin packer-builder-vsphere-iso: VM IP est toujours la même: ABCD
2020/04/26 20:55:13 plugin packer-builder-vsphere-iso: VM IP est toujours la même: ABCD
2020/04/26 20:55:14 plugin packer-builder-vsphere-iso: VM IP est toujours la même: ABCD
2020/04/26 20:55:15 plugin packer-builder-vsphere-iso: VM IP est toujours la même: ABCD
2020/04/26 20:55:16 plugin packer-builder-vsphere-iso: VM IP est toujours la même: ABCD
==> vsphere-iso: Adresse IP: ABCD
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: VM IP est toujours la même: ABCD
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: VM IP semble assez stable: ABCD
==> vsphere-iso: Utilisation du communicateur ssh pour se connecter: ABCD
==> vsphere-iso: En attente de disponibilité de SSH ...
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [INFO] En attente de SSH, jusqu'à timeout: 5m0s
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [INFO] Tentative de connexion SSH à ABCD: 22 ...
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [DEBUG] se reconnecter à la connexion TCP pour SSH
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [DEBUG] handshaking avec SSH
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [DEBUG] poignée de main terminée!
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [DEBUG] Ouverture d'une nouvelle session ssh
==> vsphere-iso: Connecté à SSH!
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: transfert de l'agent [INFO] activé
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: exécution du hook de provision
2020/04/26 20:55:17 [INFO] (télémétrie) Démarrage de l'approvisionnement ansible
==> vsphere-iso: approvisionnement avec Ansible ...
vsphere-iso: ne pas utiliser l'adaptateur proxy pour l'exécution d'Ansible:
vsphere-iso: Utilisation des clés ssh de Packer Communicator ...
vsphere-iso: Utilisation des clés ssh de Packer Communicator ...
2020/04/26 20:55:17 plugin packer-provisioner-ansible: Création d'un fichier d'inventaire pour l'exécution d'Ansible ...
vsphere-iso: Exécution d'Ansible Galaxy
vsphere-iso: [AVERTISSEMENT]: - dovry.ansible_role_sample (master) est déjà installé - utilisez
vsphere-iso: --force pour changer la version en non spécifié
2020/04/26 20:55:18 plugin packer-provisioner-ansible: Megan cmd est & exec.Cmd {Path: "/ usr / bin / ansible-playbook", Args: [] 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_addr : 8081 "," --ssh-extra-args "," -o IdentitiesOnly = yes "," -i "," / tmp / packer-provisioner-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), done: 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: Exécution d'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_htth_addr - 808 args -o IdentitiesOnly = yes -i / tmp / packer-provisioner-ansible807514096 /home/dev-user/eclipse-workspace/packer-test/ansible/packer-test.yml -vvsphere-iso: Utilisation de /etc/ansible/ansible.cfg comme fichier de configurationvsphere-iso:vsphere-iso: PLAY [Configurer la VM de base] * * * * * * * * * * * * * * *