Packer: ansible 2.8 rompe empaquetador ansible provisioner

Me encontré exactamente con el mismo problema: degradado a ansible 2.7.10 y funcionó perfectamente

¿Alguien más pudo reprochar esto?

Igual que aquí. Tuve que degradar.

El martes 28 de mayo de 2019 a las 20:58, AndrewCi [email protected] escribió:

¿Alguien más pudo reprochar esto?

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/hashicorp/packer/issues/7667?email_source=notifications&email_token=AAAAFFDXJF7SZ3RCR7ZC4XLPXV6GTA5CNFSM4HOEP2H2YY3PNVWWK3TUL52HS4DFVDVDXHJWKNM49-4DFVDVDXWJWKNM49 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAAFFFYN7SKLPFDER6IOYDPXV6GTANCNFSM4HOEP2HQ
.

También puedo reproducir esto usando el aprovisionador Azure ARM

sí, también degradado ansible

Creo que estamos golpeando esto en ansible 2.6.2

@intinig ¿ cambiaste ?

Regresar a 2.7.10 lo arregló para mí.

Muy bien para mí, solucioné esto eliminando la opción -vv . ¡SALVAJE!

2.7.10

El jueves 30 de mayo de 2019 a las 19:50, adamday2 [email protected] escribió:

Regresar a 2.7.10 lo arregló para mí.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/hashicorp/packer/issues/7667?email_source=notifications&email_token=AAAAFFDBJO4EIUY3O43JGOTPYAHWNA5CNFSM4HOEP2H2YY3PNVWWK3TUL52HS4DFVREXWHG43WNAVMV ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAAFFESVO36RH5QHKQV2F3PYAHWNANCNFSM4HOEP2HQ
.

Esto está (al menos en algunos casos) relacionado con el descubrimiento automatizado del intérprete de Python agregado a Ansible 2.8; la codificación rígida /usr/bin/python solucionó los bloqueos que observé.

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

Haga esto, pero realmente necesita 2.8 para algunos de los módulos mejorados de vSphere que se han lanzado.

Solo hago una nota aquí, ya que este es un problema popular: este aprovisionador es uno de nuestros aprovisionadores respaldados por la comunidad, lo que significa que los encargados de mantenimiento de HashiCorp no dedican mucho tiempo a la ingeniería; esto significa que la mejor manera de ver su sugerencia en Packer es abrir un PR.

@flowerysong gracias por los consejos, ¡funciona! El virtualenv hace la ayuda.

Una máquina con Windows con la conexión del empaquetador tiene el mismo problema, ¿alguien tiene una solución?

¿Alguien tiene al menos una causa raíz de lo que está causando este bloqueo y un plan potencial para solucionarlo? Feliz de ayudar en lo que puedo, pero no familiarizado con Go (podría ser más útil con un punto en la dirección correcta).

Además, ¿podría hacer una diferencia ejecutar el empaquetador desde un sistema operativo diferente?

Tengo lo mismo. Intenté con packer 1.3.3, 1.3.4, 1.4.1, 1.4.2, versiones ansible 2.7.10, 2.8.0 y 2.8.1, todas exhibiendo el mismo comportamiento. La configuración de ANSIBLE_PYTHON_INTERPRETER env var se realizó correctamente.

Hoy eché un vistazo rápido a esto; mi instinto basado en sus descubrimientos de ansible_python_interpreter es que la advertencia que se genera cuando se usa la lista de respaldo está causando el bloqueo porque no estamos procesando stderr correctamente en alguna parte.

Sin embargo, en la hora que jugué, tuve problemas para reproducir una situación en la que podría generar esta advertencia de respaldo para probar esa teoría. Si alguno de ustedes que se encuentra con este problema puede compartir el arco de su sistema operativo invitado y qué versión de Python está instalada (y dónde está instalada), sería muy útil para no perder mucho tiempo haciendo girar mis ruedas tratando de conseguir un estuche de reproducción.

Por ahora, parece que configurar ansible_python_interpreter funciona directamente para todos ustedes. Tendría curiosidad por saber si establecerlo en el valor ansible_python_interpreter=auto_silent es suficiente para resolver esto; eso agregaría algo de credibilidad a mi teoría de que Packer está manejando mal la tubería por la que la advertencia llega por alguna parte.

@SwampDragons Es la misma razón por la que la canalización hace que el aprovisionador se cuelgue, y no conozco la causa raíz precisa. El descubrimiento de intérpretes siempre usa canalización, independientemente de si está habilitado para la ejecución del módulo.

Esto potencialmente se abordará en el lado de Ansible agregando un tiempo de espera al descubrimiento del intérprete, pero actualmente no hay un cronograma para esa solución.

@flowerysong gracias por la información. ¿Tiene un enlace a un problema de GH o algo que hable sobre la discusión del tiempo de espera que podamos rastrear aquí?

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

SO @SwampDragons : según su pregunta, puedo confirmar que usando:
"extra_arguments": [
"--extra-vars",
"ansible_python_interpreter = auto_silent"
]
Permite que una ejecución de Linux usando ansible-local funcione sin problemas usando lo siguiente:
Ansible 2.8.1
Empaquetador 1.4.2
Compilación KVM de RHEL7

Sin embargo, esos mismos argumentos dan como resultado un error aún al intentar aprovisionar un host de WINDOWS Server 2019 con el siguiente error:

2019-07-15T14: 05: 46-04: 00: ==> qemu: Ejecutando 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 empaquetador_http_adr_paquete 2: 80er = 10.0.2 vars ansible_shell_type = powershell ansible_shell_executable = Ninguno ansible_python_interpreter = auto_silent

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

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

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

2019-07-15T14: 05: 55-04: 00: qemu: TAREA [Datos Gathering] * * * * * * * * * * * * * * * * * **

2019-07-15T14: 05: 56-04: 00: qemu: fatal: [predeterminado]: FAILED! => {"ansible_facts": {}, "cambiado": falso, "msg": "Los siguientes módulos no se pudieron ejecutar: setup \ n setup: MODULE FAILURE \ nVer stdout / stderr para el error exacto \ n"}

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

2019-07-15T14: 05: 56-04: 00: qemu: RESUMEN DEL JUEGO * * * * * * * * * * * * * * * * * * * * * **

2019-07-15T14: 05: 56-04: 00: qemu: predeterminado: ok = 0 cambiado = 0 inaccesible = 0 fallido = 1 omitido = 0 rescatado = 0 ignorado = 0

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

2019-07-15T14: 05: 56-04: 00: ==> qemu: Eliminando directorio de salida ...

2019-07-15T14: 05: 56-04: 00: Compilación 'qemu' con error: Error al ejecutar Ansible: Estado de salida distinto de cero: estado de salida 2

Así que creo que tenemos una solución alternativa válida para "Linux" mientras esperamos la "solución" de la tubería en el núcleo ansible, pero "Windows" todavía necesita algo más para permitir que funcione por el momento.

¿Alguien está trabajando actualmente en esto o tiene alguna idea sobre cómo abordar una solución?

No que yo supiese.

Mi solución fue agregar esto: "extra_arguments": ["-e", "ansible_python_interpreter=/usr/bin/python", "-vv"]

Todavía no puedo reproducir este problema para salvar mi vida, pero he decidido seguir adelante para intentar crear una solución alternativa basada en la teoría de que el problema subyacente es el proxy ssh de Packer que crea para reenviar llamadas de Ansible.

Creé un PR # 8625 a partir de una rama que elimina este proxy de host local por completo y modifica el aprovisionador para usar en su lugar la IP del host en el archivo de inventario. Me encantaría si algunos de ustedes afectados por el error pudieran eliminar una compilación (disponible aquí: https://circleci.com/gh/hashicorp/packer/29969#artifacts/containers/0) y avíseme si resuelve el problema por ti. Tenga en cuenta que, tal como está ahora, esa rama rompe las compilaciones de Docker. Descubriré cómo deshacerlos después de que averigüemos si este movimiento realmente resolverá el problema.

Por favor, avíseme también si la eliminación del proxy le causa problemas; que PR se encuentra en un estado de trabajo en progreso.

¿Alguno de los interesados ​​en probar el PR anterior y dejarme saber si resuelve la incompatibilidad ansible 2.8+? Tengo nuevas compilaciones, disponibles aquí: https://circleci.com/gh/hashicorp/packer/32248#artifacts/containers/0 , que le permiten usar o no el adaptador de proxy basado en la opción booleana "use_proxy" (actualmente el valor predeterminado es verdadero, pero cambiaré el valor predeterminado en el futuro si parece que vale la pena)

@SwampDragons , gracias por proporcionar estas nuevas compilaciones de empaquetadores (v 1.5.2).

Probé esta nueva compilación 1.5.2 tanto en macos (Python 3.7.3) como desde una ventana acoplable
container (Python 3.6.9) pero la compilación del empaquetador ahora se detiene antes de ejecutar el aprovisionador ansible:

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

... en ambas arquitecturas.

Si vuelvo al packer 1.5.1, la conexión a WinRM se realiza correctamente, powershell
Los aprovisionadores se ejecutan correctamente, pero el aprovisionador ansible falla sin importar qué
se dan la opción o argumentos adicionales. La solución alternativa 'ansible_python_interpreter'
Lamentablemente, lo mencionado anteriormente no me funciona.

Los 2 entornos que he intentado construir:
1. macos [Darwin Kernel Version 19.3.0: root: xnu-6153.81.5 ~ 1 / RELEASE_X86_64 x86_64]
- empaquetador 1.5.1
- constructor: brazo azul
- os_type: Windows
- comunicador: winrm
- ansible 2.9.2
- Python 3.7.3

1. Docker / mcr.microsoft.com/azure- cli: último [Linux 1cba84bd80dd
   4.19.76-linuxkit # 1 SMP Jue 17 Oct 19:31:58 UTC 2019 x86_64 Linux]
2. empaquetador 1.5.1
   
   
   
   • constructor: brazo azul
   
   
   • os_type: Windows
   
   
   • comunicador: 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

---------

Gracias por la actualización, presioné algunas correcciones y se pueden encontrar nuevos binarios en el PR. Sin embargo, no he tenido la oportunidad de configurar la opción sin proxy para winrm.

Finalmente pude reproducir el bloqueo y puedo confirmar que deshabilitar el proxy, como sea posible en el Pr vinculado, soluciona el problema de las compilaciones SSH. Todavía no he tenido la oportunidad de investigar e implementar la solución para WinRM.

Los artefactos para aquellos de ustedes en SSH que necesitan esta solución se pueden encontrar aquí: https://circleci.com/gh/hashicorp/packer/33086#artifacts/containers/0 .

Debido a que no lo he puesto en marcha para Windows, es probable que no llegue a la versión 1.5.2, pero lo retomaré y continuaré trabajando en él en un par de días.

Gracias @SwampDragons , ¡son buenas noticias! Esperamos obtener las correcciones para las compilaciones de Windows cuando pueda continuar trabajando en ellas.

Puedo confirmar que el uso de la compilación anterior soluciona el problema con Ansible que se conecta a la instancia de Packer a través de SSH. 🚀

Estoy experimentando el mismo problema en ansible 2.9 con winrm. Luego bajé el ansible a 2.7 y luego funcionó bien una vez. Pero ahora también estoy experimentando el mismo problema en ansible 2.7.

ansible = 2.7.0
versión de python = 3.7.6
empaquetador = 1.5.4

<127.0.0.1> (0, b '', b'OpenSSH_7.9p1, LibreSSL 2.7.3 \ r \ ndebug1: lectura de datos de configuración / etc / ssh / ssh_config \ r \ ndebug1: / etc / ssh / ssh_config línea 48: Aplicando opciones para * \ r \ ndebug2: resolve_canonicalize: hostname 127.0.0.1 es address \ r \ ndebug1: auto-mux: probando el maestro existente \ r \ ndebug2: fd 3 configuración O_NONBLOCK \ r \ ndebug2: mux_client_hello_exchange: versión maestra 4 \ r \ ndebug3: mux_client_forwards: reenvíos de solicitudes: 0 locales, 0 remotos \ r \ ndebug3: mux_client_request_session: ingresando \ r \ ndebug3: mux_client_request_alive: ingresando \ r \ ndebug3: mux_client_request_alsionive: \ nxdebses3_solicitud: r_quest_solicitud sentida: \ r \ n # <CLIXML \ r \ nSystem.Management.Automation.PSCustomObjectSystem.Object1Preparación de módulos para el primer uso.0-1-1Terminado-1 debug3: mux_client_read_packet: error de lectura del encabezado: tubería rota \ r \ ndebug2: estado de salida recibido del maestro 0 \ r \ n ')

@SwampDragons suerte con la actualización de Windows

Todavía no, he estado viajando y no he tenido las manos en el teclado esta semana. Sin embargo, intentaré retomar la tarea la próxima semana.

@SwampDragons ¿hay algún estado en Windows? ¡Gracias!

¡Si! El viernes obtuve un POC para compilaciones de Windows sin proxy que funcionan con WinRM con autenticación básica, pero todavía necesito hacer pruebas para asegurarme de que funciona con ssl.

¡Vive! Los binarios que funcionan para ansible con winrm se pueden descargar aquí: https://circleci.com/gh/hashicorp/packer/42423#artifacts/containers/0

Consulte los documentos agregados en el PR para obtener instrucciones de uso detalladas: https://github.com/hashicorp/packer/pull/8625

Hola @SwampDragons ¡ Gracias por todo tu trabajo (y a otros en reportar)! :)
Probé la compilación nocturna mencionada anteriormente y todavía me falla. Todavía tengo que volver a Ansible 2.7.10 para que funcione para mí.
[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]$
Esto es de un host Centos 7.7 que usa vsphere-iso (¡es genial verlo integrado ahora!) Construyendo una imagen mínima de Centos 7.7.
¿Alguien más encontró otros problemas?

@ChrisGWarp Necesitaré un caso de reproducción completo para ver más su falla, ya que funciona en mi máquina;)

packer_test.zip
¡Hecho!
Incluyendo registro de falla, rectificación (downgrade ansible) y éxito.
Espero que esto ayude. :)

Entonces, mirando tu configuración:

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

Ahora no probé esto con Galaxy, pero también en su configuración no parece que haya apagado el proxy.

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

¿Puede probar lo anterior con PACKER_DEBUG = 1 en su entorno para obtener registros detallados? Y vincularlos en una esencia?

Ok, logré llegar más lejos, pero luego encontré otros problemas.
Esto es lo que encontré / observé:

No estaba seguro sobre use_proxy, si era un parámetro existente cuyo valor necesitaba cambiarse, o si era uno nuevo.

Packer 1.5.5 se ahoga con él, por lo que estoy asumiendo una nueva variable y, por lo tanto, no es compatible con versiones anteriores.

Packer 1.5.6-dev funcionó, ya que no se bloqueó en la etapa de recopilación de datos (¡sí!), Pero luego se ahogó con el problema de la clave del host. ¿Desde dónde carga ansible.cfg? O, la misma pregunta de otra manera, ¿de dónde (como en qué directorio) se genera ansible-playbook?

Este es el fragmento de archivo .json, las variables de entorno no parecen cambiar el comportamiento de la clave del host.

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

Aquí está la salida del registro:

`[ dev-user @ centos-7-dev packer-test] $ PACKER_LOG = 1 compilación de empaquetador -force vsphere-packer-test-x86_64.json
2020/04/26 20:46:14 [INFO] Versión de Packer: 1.5.6-dev (d824b7e969d0d54ce23b42aa2a577a73a4780765) [go1.13.9 linux amd64]
2020/04/26 20:46:14 Verificando 'PACKER_CONFIG' para una ruta de archivo de configuración
2020/04/26 20:46:14 'PACKER_CONFIG' no establecido; comprobar la ruta del archivo de configuración predeterminada
2020/04/26 20:46:14 Intentando abrir el archivo de configuración: /home/dev-user/.packerconfig
2020/04/26 20:46:14 [WARN] El archivo de configuración no existe: /home/dev-user/.packerconfig
2020/04/26 20:46:14 Configuración del directorio de caché: / home / dev-user / eclipse-workspace / packer-test / packer_cache
2020/04/26 20:46:14 Creación de un cliente de complemento para la ruta: / usr / bin / packer
2020/04/26 20:46:14 Complemento de inicio: / usr / bin / packer [] string {"/ usr / bin / packer", "plugin", "packer-builder-vsphere-iso"}
2020/04/26 20:46:14 Esperando dirección RPC para: / usr / bin / packer
2020/04/26 20:46:14 Se recibió la dirección RPC de Unix para / usr / bin / packer: addr is / tmp / packer-plugin421608791
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: [INFO] Versión de Packer: 1.5.6-dev (d824b7e969d0d54ce23b42aa2a577a73a4780765) [go1.13.9 linux amd64]
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: Verificando 'PACKER_CONFIG' para una ruta de archivo de configuración
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: 'PACKER_CONFIG' no establecido; comprobar la ruta del archivo de configuración predeterminada
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: Intentando abrir el archivo de configuración: /home/dev-user/.packerconfig
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: [WARN] El archivo de configuración no existe: /home/dev-user/.packerconfig
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: Configuración del directorio de caché: / 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: Dirección del plugin: unix / tmp / packer-plugin421608791
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: Esperando conexión ...
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: Sirviendo una conexión de plugin ...
2020/04/26 20:46:14 Creación de un cliente de complemento para la ruta: / usr / bin / packer
2020/04/26 20:46:14 Complemento de inicio: / usr / bin / packer [] string {"/ usr / bin / packer", "plugin", "packer-provisioner-ansible"}
2020/04/26 20:46:14 Esperando dirección RPC para: / usr / bin / packer
2020/04/26 20:46:14 Se recibió la dirección RPC de Unix para / usr / bin / packer: addr is / tmp / packer-plugin434205582
2020/04/26 20:46:14 plugin packer-provisioner-ansible: [INFO] Versión de Packer: 1.5.6-dev (d824b7e969d0d54ce23b42aa2a577a73a4780765) [go1.13.9 linux amd64]
2020/04/26 20:46:14 plugin packer-provisioner-ansible: Verificando 'PACKER_CONFIG' para una ruta de archivo de configuración
2020/04/26 20:46:14 plugin packer-provisioner-ansible: 'PACKER_CONFIG' no establecido; comprobar la ruta del archivo de configuración predeterminada
2020/04/26 20:46:14 plugin packer-provisioner-ansible: Intentando abrir el archivo de configuración: /home/dev-user/.packerconfig
2020/04/26 20:46:14 plugin packer-provisioner-ansible: [WARN] El archivo de configuración no existe: /home/dev-user/.packerconfig
2020/04/26 20:46:14 plugin packer-provisioner-ansible: Configuración del directorio de caché: / 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: dirección del plugin: unix / tmp / packer-plugin434205582
2020/04/26 20:46:14 plugin packer-provisioner-ansible: Esperando conexión ...
2020/04/26 20:46:14 plugin packer-provisioner-ansible: Sirviendo una conexión de plugin ...
vsphere-iso: la salida será en este color.

2020/04/26 20:46:14 Modo de depuración de compilación: falso
2020/04/26 20:46:14 Forzar compilación: verdadero
2020/04/26 20:46:14 Por error:
2020/04/26 20:46:14 Preparando compilación: vsphere-iso
2020/04/26 20:46:15 Esperando que se completen las compilaciones ...
2020/04/26 20:46:15 Inicio de ejecución de compilación: vsphere-iso
2020/04/26 20:46:15 Generador en ejecución: vsphere-iso
2020/04/26 20:46:15 [INFO] (telemetría) Constructor inicial vsphere-iso
2020/04/26 20:46:15 plugin packer-provisioner-ansible: ansible-playbook versión: 2.9.6
==> vsphere-iso: Creando VM ...
==> vsphere-iso: Personalizando hardware ...
==> vsphere-iso: Montaje de imágenes ISO ...
2020/04/26 20:46:17 plugin packer-builder-vsphere-iso: Creación de CD-ROM en el controlador '& {{{} 200 0xc00055e2a00} 0 []} 'con iso' [ISO] CentOS / CentOS-7-x86_64-Minimal-1908.iso '
==> vsphere-iso: Creando disquete ...
vsphere-iso: copiar archivos de forma plana desde floppy_files
2020/04/26 20:46:18 plugin packer-builder-vsphere-iso: Ruta de disquete: / tmp / packer579447498
2020/04/26 20:46:18 plugin packer-builder-vsphere-iso: Inicializando dispositivo de bloque respaldado por archivo temporal
2020/04/26 20:46:18 plugin packer-builder-vsphere-iso: formateo del dispositivo de bloque con un sistema de archivos FAT ...
2020/04/26 20:46:18 plugin packer-builder-vsphere-iso: Inicializando el sistema de archivos FAT en el dispositivo de bloque
2020/04/26 20:46:18 plugin packer-builder-vsphere-iso: lectura del directorio raíz desde el sistema de archivos
vsphere-iso: Copiando archivo: http / ks-7.7-minimal-static.cfg
vsphere-iso: Terminado de copiar archivos de floppy_files
vsphere-iso: Recopilación de rutas de floppy_dirs
vsphere-iso: Rutas resultantes de floppy_dirs: []
vsphere-iso: Terminado de copiar rutas de floppy_dirs
==> vsphere-iso: cargando la imagen de disquete creada
==> vsphere-iso: Añadiendo un disquete generado ...
==> vsphere-iso: iniciando el servidor HTTP en el puerto 8081
2020/04/26 20:46:19 plugin packer-builder-vsphere-iso: puerto disponible encontrado: 8081 en IP: 0.0.0.0
==> vsphere-iso: Establecer orden de arranque temporal ...
==> vsphere-iso: Encienda la VM ...
==> vsphere-iso: Esperando 10 segundos para el arranque ...
==> vsphere-iso: el servidor HTTP está funcionando en http: // ABCE: 8081 /
==> vsphere-iso: Escribiendo comando de arranque ...
2020/04/26 20:46:32 plugin packer-builder-vsphere-iso: Código especial ''encontrado, reemplazando con: CodeTab
2020/04/26 20:46:40 plugin packer-builder-vsphere-iso: Código especial ''encontrado, reemplazando con: CodeReturnEnter
2020/04/26 20:46:40 plugin packer-builder-vsphere-iso: esperando 1 segundo
==> vsphere-iso: Esperando IP ...
2020/04/26 20:46:41 plugin packer-builder-vsphere-iso: [INFO] Esperando IP, hasta el tiempo de espera total: 30m0s, tiempo de espera establecido: 5s
2020/04/26 20:55:12 plugin packer-builder-vsphere-iso: VM IP adquirida: ABCD
2020/04/26 20:55:12 plugin packer-builder-vsphere-iso: VM IP sigue siendo la misma: ABCD
2020/04/26 20:55:13 plugin packer-builder-vsphere-iso: VM IP sigue siendo la misma: ABCD
2020/04/26 20:55:14 plugin packer-builder-vsphere-iso: VM IP sigue siendo la misma: ABCD
2020/04/26 20:55:15 plugin packer-builder-vsphere-iso: VM IP sigue siendo la misma: ABCD
2020/04/26 20:55:16 plugin packer-builder-vsphere-iso: VM IP sigue siendo la misma: ABCD
==> vsphere-iso: dirección IP: ABCD
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: VM IP sigue siendo la misma: ABCD
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: VM IP parece lo suficientemente estable: ABCD
==> vsphere-iso: usando el comunicador ssh para conectarse: ABCD
==> vsphere-iso: Esperando que SSH esté disponible ...
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [INFO] Esperando SSH, hasta el tiempo de espera: 5m0s
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [INFO] Intentando conexión SSH a ABCD: 22 ...
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [DEBUG] reconectando a la conexión TCP para SSH
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: protocolo de enlace [DEBUG] con SSH
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [DEBUG] ¡apretón de manos completo!
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [DEBUG] Apertura de una nueva sesión ssh
==> vsphere-iso: ¡Conectado a SSH!
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [INFO] reenvío de agentes habilitado
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: Ejecución del enlace de provisión
2020/04/26 20:55:17 [INFO] (telemetría) Provisionador de inicio ansible
==> vsphere-iso: Aprovisionamiento con Ansible ...
vsphere-iso: No se usa el adaptador de proxy para ejecutar Ansible:
vsphere-iso: Usando claves ssh del comunicador de Packer ...
vsphere-iso: Usando claves ssh del comunicador de Packer ...
2020/04/26 20:55:17 plugin packer-provisioner-ansible: Creación de un archivo de inventario para la ejecución de Ansible ...
vsphere-iso: Ejecución de Ansible Galaxy
vsphere-iso: [ADVERTENCIA]: - dovry.ansible_role_sample (master) ya está instalado - use
vsphere-iso: --force para cambiar la versión a no especificada
2020/04/26 20:55:18 plugin packer-provisioner-ansible: Megan cmd es & exec.Cmd {Ruta: "/ 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 = ABCE : 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), finish: 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: Ejecutando 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_adss = ABhCE-extra: 8081 args -o IdentitiesOnly = yes -i / tmp / packer-provisioner-ansible807514096 /home/dev-user/eclipse-workspace/packer-test/ansible/packer-test.yml -vvsphere-iso: usando /etc/ansible/ansible.cfg como archivo de configuraciónvsphere-iso:vsphere-iso: PLAY [Configurar la VM base] * * * * * * * * * * * * * * *