Packer: ansible 2.8 quebra o provisionador ansible do packer

Encontrou exatamente o mesmo problema - rebaixado para ansible 2.7.10 e funcionou perfeitamente

mais alguém foi capaz de reproduzir isso?

O mesmo aqui. Eu tive que fazer o downgrade.

Na terça - feira, 28 de maio de 2019 às 20:58, AndrewCi

mais alguém foi capaz de reproduzir isso?

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/hashicorp/packer/issues/7667?email_source=notifications&email_token=AAAAFFDXJF7SZ3RCR7ZC4XLPXV6GTA5CNFSM4HOEP2H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWNDJDY#issuecomment-496645263 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAAAFFFYN7SKLPFDER6IOYDPXV6GTANCNFSM4HOEP2HQ
.

Também consigo reproduzir isso usando o provisionador ARM do Azure

sim, ansible também rebaixado

Acho que estamos atingindo isso no ansible 2.6.2

@intinig Para qual versão você faz downgrade?

Reverter para 2.7.10 corrigiu para mim.

Tudo bem para mim, resolvi isso removendo a opção -vv . SELVAGEM!

2.7.10

Na quinta-feira, 30 de maio de 2019 às 19:50, adamday2 [email protected] escreveu:

Reverter para 2.7.10 corrigiu para mim.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/hashicorp/packer/issues/7667?email_source=notifications&email_token=AAAAFFDBJO4EIUY3O43JGOTPYAHWNA5CNFSM4HOEP2H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWTASNA#issuecomment-497420596 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAAAFFESVO36RH5QHKQV2F3PYAHWNANCNFSM4HOEP2HQ
.

Isso está (pelo menos em alguns casos) relacionado à descoberta do interpretador Python automatizado adicionado ao Ansible 2.8; a codificação permanente /usr/bin/python corrigiu as travas que observei.

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

Faça isso, mas realmente preciso do 2.8 para alguns dos módulos aprimorados do vSphere que foram lançados.

Apenas fazendo uma observação aqui, já que este é um problema popular - este provisionador é um de nossos provisionadores suportados pela comunidade, o que significa que os mantenedores do HashiCorp não gastam muito tempo de engenharia nele; isso significa que a melhor maneira de ver sua sugestão chegar ao Packer é abrir um PR.

@flowerysong obrigado pelas dicas, funciona! O virtualenv ajuda.

Uma máquina Windows com a conexão de empacotador tem o mesmo problema, alguém tem uma solução alternativa?

Alguém pelo menos tem uma causa raiz para o que está causando esse travamento e um plano potencial para consertar isso? Fico feliz em ajudar onde posso, mas não estou familiarizado com Go (pode ser mais útil com um ponto na direção certa).

Além disso, executar o packer em um sistema operacional diferente pode fazer diferença?

Tenho o mesmo. Tentativa com empacotador 1.3.3, 1.3.4, 1.4.1, 1.4.2, ansible versões 2.7.10, 2.8.0 e 2.8.1, todos exibindo o mesmo comportamento. A configuração de ANSIBLE_PYTHON_INTERPRETER env var foi bem-sucedida.

Dei uma olhada rápida nisso hoje; meu instinto baseado em suas descobertas ansible_python_interpreter é que o aviso que está sendo gerado ao usar a lista de fallback está causando o travamento porque não estamos processando stderr corretamente em algum lugar.

No entanto, na hora em que comecei a consertar, tive problemas para reproduzir uma situação em que pudesse gerar esse aviso de fallback para testar essa teoria. Se qualquer um de vocês que está se deparando com este problema puder compartilhar seu sistema operacional convidado e qual versão do python está instalada (e onde está instalada), isso seria muito útil, então eu não gastei muito tempo tentando obter um caso de reprodução.

Por enquanto, parece que definir o ansible_python_interpreter funciona diretamente para todos vocês. Eu ficaria curioso para saber se defini-lo com o valor ansible_python_interpreter=auto_silent é suficiente para resolver isso; isso acrescentaria algum crédito à minha teoria de que Packer está lidando mal com o cano de que o aviso está chegando em algum lugar.

@SwampDragons É o mesmo motivo pelo qual o pipelining faz com que o provisionador trave, e não sei a causa raiz precisa. A descoberta de intérprete sempre usa pipelining, independentemente de estar habilitado para execução do módulo.

Isso provavelmente será resolvido no lado do Ansible, adicionando um tempo limite à descoberta do intérprete, mas atualmente não há nenhum cronograma para essa correção.

@flowerysong, obrigado pela informação. Você tem um link para um problema de GH ou algo que fale sobre a discussão de tempo limite que possamos acompanhar aqui?

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

SO @SwampDragons - de acordo com sua pergunta, posso confirmar isso usando:
"extra_arguments": [
"--extra-vars",
"ansible_python_interpreter = auto_silent"
]
Permite que uma execução Linux usando ansible-local funcione sem problemas usando o seguinte:
Ansible 2.8.1
Packer 1.4.2
Versão KVM do RHEL7

No entanto, esses mesmos argumentos ainda resultam em um erro ao tentar provisionar um host WINDOWS Server 2019 com o seguinte erro:

2019-07-15T14: 05: 46-04: 00: ==> qemu: Executando 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.2 packer_http_addrer = 10connection.2: --extra-vars.2 packer_http_addrer = 10conex. vars ansible_shell_type = powershell ansible_shell_executable = Nenhum ansible_python_interpreter = auto_silent

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

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

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

2019-07-15T14: 05: 55-04: 00: qemu: TASK [Coleta de fatos] * * * * * * * * * * * * * * * * * **

2019-07-15T14: 05: 56-04: 00: qemu: fatal: [padrão]: FALHOU! => {"ansible_facts": {}, "changed": false, "msg": "Os seguintes módulos falharam ao executar: setup \ n setup: MODULE FAILURE \ nVeja stdout / stderr para o erro exato \ n"}

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

2019-07-15T14: 05: 56-04: 00: qemu: REPRODUÇÃO * * * * * * * * * * * * * * * * * * * * * **

2019-07-15T14: 05: 56-04: 00: qemu: padrão: ok = 0 alterado = 0 inacessível = 0 com falha = 1 ignorado = 0 resgatado = 0 ignorado = 0

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

2019-07-15T14: 05: 56-04: 00: ==> qemu: Excluindo diretório de saída ...

2019-07-15T14: 05: 56-04: 00: Build 'qemu' com erro: Erro ao executar Ansible: Status de saída diferente de zero: status de saída 2

Portanto, acho que temos uma solução válida para o "Linux" enquanto aguardamos a "correção" do pipeline no núcleo ansible, mas o "Windows" ainda precisa de algo mais para permitir que funcione por enquanto?

Alguém atualmente trabalhando nisso ou tem alguma ideia sobre como abordar uma correção?

Não que eu saiba.

Minha solução foi adicionar este: "extra_arguments": ["-e", "ansible_python_interpreter=/usr/bin/python", "-vv"]

Ainda não consigo reproduzir esse problema para salvar minha vida, mas decidi seguir em frente tentando criar uma solução alternativa com base na teoria de que o problema subjacente é o proxy ssh do Packer que ele cria para encaminhar chamadas Ansible.

Criei um PR # 8625 de uma filial que remove esse proxy localhost completamente e modifica o provisionador para usar o IP do host no arquivo de inventário. Adoraria se alguns de vocês afetados pelo bug pudessem baixar uma compilação (disponível aqui: https://circleci.com/gh/hashicorp/packer/29969#artifacts/containers/0) e me avisassem se isso resolve o problema para você. Observe que, do jeito que está agora, esse branch quebra as compilações do Docker. Vou descobrir como desembrulhá-los depois de descobrir se essa mudança vai realmente resolver o problema.

Informe-me também se a remoção do proxy causar problemas para você; que PR está em um estado de Trabalho em Andamento.

Algum comprador testando o PR acima e me informando se ele resolve a incompatibilidade do ansible 2.8+? Tenho novas compilações, disponíveis aqui: https://circleci.com/gh/hashicorp/packer/32248#artifacts/containers/0 , que permitem que você use ou não o adaptador proxy com base na opção booleana "use_proxy" (atualmente o padrão é verdadeiro, mas vou alterar o padrão no futuro se achar que vale a pena)

@SwampDragons , obrigado por fornecer essas novas compilações de empacotador (v 1.5.2).

Eu tentei esta nova compilação 1.5.2 em macos (Python 3.7.3) e em um docker
contêiner (Python 3.6.9), mas a compilação do empacotador agora trava antes de executar o provisionador ansible:

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

... em ambas as arquiteturas.

Se eu reverter para o packer 1.5.1, a conexão com WinRM é bem-sucedida, PowerShell
provisionadores são executados com sucesso, mas o provisionador ansible falha, não importa o que
opção ou argumentos extras são fornecidos. A solução alternativa 'ansible_python_interpreter'
mencionado acima não funciona para mim, infelizmente.

Os 2 ambientes que tentei construir:
1. macos [Darwin Kernel Versão 19.3.0: root: xnu-6153.81.5 ~ 1 / RELEASE_X86_64 x86_64]
- packer 1.5.1
- construtor: azure-arm
- os_type: Windows
- comunicador: winrm
- ansible 2.9.2
- Python 3.7.3

1. Docker / mcr.microsoft.com/azurecli : mais recente [Linux 1cba84bd80dd
   4.19.76-linuxkit # 1 SMP quinta-feira, 17 de outubro 19:31:58 UTC 2019 x86_64 Linux]
2. packer 1.5.1
   
   
   
   • construtor: azure-arm
   
   
   • 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

---------

Obrigado pela atualização - enviei algumas correções e novos binários podem ser encontrados no PR. Eu não tive a chance de configurar a opção no-proxy para winrm, no entanto.

Finalmente consegui reproduzir o travamento e posso confirmar que a desativação do proxy, conforme possível no Pr vinculado, corrige o problema para compilações SSH. Ainda não tive a chance de pesquisar e implementar a correção para WinRM.

Os artefatos para aqueles de vocês no SSH que precisam dessa solução alternativa podem ser encontrados aqui: https://circleci.com/gh/hashicorp/packer/33086#artifacts/containers/0 .

Como ainda não fiz isso para o Windows, provavelmente não chegará à versão 1.5.2, mas pegarei de volta e continuarei a trabalhar em alguns dias.

Obrigado @SwampDragons , essa é uma ótima notícia! Ansioso para obter as correções para as compilações do Windows quando você puder continuar a trabalhar nelas.

Posso confirmar que o uso da compilação acima corrige o problema com o Ansible se conectando à instância do Packer via SSH. 🚀

Estou tendo o mesmo problema no ansible 2.9 com winrm. Então eu rebaixei o ansible para 2.7 depois que funcionou bem uma vez. Mas agora estou tendo o mesmo problema no ansible 2.7 também.

ansible = 2.7.0
versão python = 3.7.6
packer = 1.5.4

<127.0.0.1> (0, b '', b'OpenSSH_7.9p1, LibreSSL 2.7.3 \ r \ ndebug1: Lendo dados de configuração / etc / ssh / ssh_config \ r \ ndebug1: / etc / ssh / ssh_config linha 48: Aplicando opções para * \ r \ ndebug2: resolve_canonicalize: hostname 127.0.0.1 é endereço \ r \ ndebug1: auto-mux: Tentando master existente \ r \ ndebug2: configuração fd 3 O_NONBLOCK \ r \ ndebug2: mux_client_hello_exchange: master versão 4 \ r \ ndebug3: mux_client_forwards: encaminhamentos de solicitação: 0 local, 0 remoto \ r \ ndebug3: mux_client_request_session: entrando \ r \ ndebug3: mux_client_request_alive: entrando \ r \ ndebug3: mux_client_request_debug3 solicitação de sessão \ ndebug3: feito pid = 148 \ r \ n # <CLIXML \ r \ nSystem.Management.Automation.PSCustomObjectSystem.Object1Preparando módulos para o primeiro uso.0-1-1Concluído-1 debug3: mux_client_read_packet: falha na leitura do cabeçalho: pipe quebrado \ r \ ndebug2: Status de saída recebido do mestre 0 \ r \ n ')

@SwampDragons alguma sorte com o Windows Update

Ainda não - tenho viajado e não tive as mãos no teclado esta semana. Vou tentar retomar a tarefa na próxima semana.

@SwampDragons existe um status no Windows? Obrigado!

Sim! Na sexta-feira, recebi um POC para compilações do Windows sem proxy que funcionam usando WinRM com autenticação básica, mas ainda preciso fazer testes para ter certeza de que funciona com SSL.

Ele vive! Binários que funcionam para ansible com winrm podem ser baixados aqui: https://circleci.com/gh/hashicorp/packer/42423#artifacts/containers/0

Consulte os documentos adicionados no PR para obter instruções de uso detalhadas: https://github.com/hashicorp/packer/pull/8625

Olá @SwampDragons. Obrigado por todo o seu trabalho (e a outros em reportagem)! :)
Eu tentei a compilação noturna listada acima, e ainda falha para mim. Ainda preciso reverter para o Ansible 2.7.10 para que funcione para mim.
[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]$
Isto é de um host Centos 7.7 usando o vsphere-iso (ótimo ver que foi construído agora!) Construindo uma imagem mínima do Centos 7.7.
Alguém mais encontrou algum outro problema?

@ChrisGWarp Vou precisar de um caso de reprodução completo para examinar mais a sua falha, já que funciona na minha máquina;)

packer_test.zip
Feito!
Incluindo log de falha, retificação (ansible de downgrade) e sucesso.
Espero que isto ajude. :)

Então, olhando para sua configuração:

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

Bem, eu não testei isso com o Galaxy, mas também na sua configuração não parece que você realmente desligou o proxy.

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

Você pode tentar o procedimento acima com PACKER_DEBUG = 1 em seu ambiente para obter logs detalhados? E vinculá-los em uma essência?

Ok, consegui ir mais longe, mas depois encontrei outros problemas.
Isso é o que eu encontrei / observei:

Não tinha certeza sobre o use_proxy, se era um parâmetro existente cujo valor precisava ser alterado, ou se era um novo.

O Packer 1.5.5 engasga com ele, então estou assumindo uma nova variável e, portanto, não compatível com versões anteriores.

O Packer 1.5.6-dev funcionou, pois não travou no estágio de coleta de fatos (yey!), Mas então travou no problema chave do host. De onde ele carrega ansible.cfg? Ou, a mesma pergunta de outra forma, de onde (como em qual diretório) o ansible-playbook é gerado?

Este é o fragmento do arquivo .json, o env vars não pareceu alterar o comportamento da chave do 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" ] } ]

Aqui está a saída do log:

`[ 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] Versão do packer: 1.5.6-dev (d824b7e969d0d54ce23b42aa2a577a73a4780765) [go1.13.9 linux amd64]
2020/04/26 20:46:14 Verificando 'PACKER_CONFIG' para um caminho de arquivo de configuração
2020/04/26 20:46:14 'PACKER_CONFIG' não definido; verificar o caminho do arquivo de configuração padrão
2020/04/26 20:46:14 Tentando abrir o arquivo de configuração: /home/dev-user/.packerconfig
2020/04/26 20:46:14 [WARN] O arquivo de configuração não existe: /home/dev-user/.packerconfig
2020/04/26 20:46:14 Configurando o diretório do cache: / home / dev-user / eclipse-workspace / packer-test / packer_cache
2020/04/26 20:46:14 Criando cliente de plug-in para o caminho: / usr / bin / packer
2020/04/26 20:46:14 Iniciando plugin: / usr / bin / packer [] string {"/ usr / bin / packer", "plugin", "packer-builder-vsphere-iso"}
2020/04/26 20:46:14 Aguardando endereço RPC para: / usr / bin / packer
2020/04/26 20:46:14 Endereço RPC unix recebido para / usr / bin / packer: addr é / tmp / packer-plugin421608791
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: [INFO] Versão do 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 um caminho de arquivo de configuração
2020/04/26 20:46:14 Plug-in packer-builder-vsphere-iso: 'PACKER_CONFIG' não definido; verificar o caminho do arquivo de configuração padrão
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: Tentativa de abrir o arquivo de configuração: /home/dev-user/.packerconfig
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: [WARN] O arquivo de configuração não existe: /home/dev-user/.packerconfig
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: Configuração do diretório 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: endereço do plugin: unix / tmp / packer-plugin421608791
2020/04/26 20:46:14 plugin packer-builder-vsphere-iso: Aguardando conexão ...
2020/04/26 20:46:14 Plug-in packer-builder-vsphere-iso: Servindo uma conexão de plug-in ...
2020/04/26 20:46:14 Criando cliente de plug-in para o caminho: / usr / bin / packer
2020/04/26 20:46:14 Iniciando plugin: / usr / bin / packer [] string {"/ usr / bin / packer", "plugin", "packer-provisioner-ansible"}
2020/04/26 20:46:14 Aguardando endereço RPC para: / usr / bin / packer
2020/04/26 20:46:14 Endereço RPC unix recebido para / usr / bin / packer: addr é / tmp / packer-plugin434205582
2020/04/26 20:46:14 plugin packer-provisioner-ansible: [INFO] Versão do 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 um caminho de arquivo de configuração
2020/04/26 20:46:14 plug-in packer-provisioner-ansible: 'PACKER_CONFIG' não definido; verificar o caminho do arquivo de configuração padrão
2020/04/26 20:46:14 plugin packer-provisioner-ansible: Tentativa de abrir o arquivo de configuração: /home/dev-user/.packerconfig
2020/04/26 20:46:14 plugin packer-provisioner-ansible: [WARN] O arquivo de configuração não existe: /home/dev-user/.packerconfig
2020/04/26 20:46:14 plugin packer-provisioner-ansible: Definir o diretório 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: endereço do plugin: unix / tmp / packer-plugin434205582
2020/04/26 20:46:14 plugin packer-provisioner-ansible: Aguardando conexão ...
2020/04/26 20:46:14 Plug-in packer-provisioner-ansible: Servindo uma conexão de plug-in ...
vsphere-iso: a saída será nesta cor.

2020/04/26 20:46:14 Modo de depuração de compilação: falso
2020/04/26 20:46:14 Criar força: verdadeiro
2020/04/26 20:46:14 Em caso de erro:
2020/04/26 20:46:14 Preparando a construção: vsphere-iso
2020/04/26 20:46:15 Esperando que as compilações sejam concluídas ...
2020/04/26 20:46:15 Iniciando execução de compilação: vsphere-iso
2020/04/26 20:46:15 Construtor em execução: vsphere-iso
2020/04/26 20:46:15 [INFO] (telemetria) Iniciando builder vsphere-iso
2020/04/26 20:46:15 Plug-in packer-provisioner-ansible: ansible-playbook versão: 2.9.6
==> vsphere-iso: Criando VM ...
==> vsphere-iso: Personalizando hardware ...
==> vsphere-iso: Montando imagens ISO ...
2020/04/26 20:46:17 plugin packer-builder-vsphere-iso: Criando CD-ROM no controlador '& {{{} 200 0xc00055e2a00} 0 []} 'com iso' [ISOs] CentOS / CentOS-7-x86_64-Minimal-1908.iso '
==> vsphere-iso: Criando disquete ...
vsphere-iso: Copiar arquivos de forma plana de floppy_files
2020/04/26 20:46:18 plugin packer-builder-vsphere-iso: Caminho do disquete: / tmp / packer579447498
2020/04/26 20:46:18 plugin packer-builder-vsphere-iso: Inicializando o dispositivo de bloco apoiado por um arquivo temporário
2020/04/26 20:46:18 plugin packer-builder-vsphere-iso: formatando o dispositivo de bloco com um sistema de arquivos FAT ...
2020/04/26 20:46:18 plugin packer-builder-vsphere-iso: inicializando o sistema de arquivos FAT no dispositivo de bloco
2020/04/26 20:46:18 plugin packer-builder-vsphere-iso: Lendo o diretório raiz do sistema de arquivos
vsphere-iso: Copiando arquivo: http / ks-7.7-minimal-static.cfg
vsphere-iso: Terminada a cópia de arquivos de floppy_files
vsphere-iso: Coletando caminhos de floppy_dirs
vsphere-iso: Caminhos resultantes de floppy_dirs: []
vsphere-iso: Concluída a cópia de caminhos de floppy_dirs
==> vsphere-iso: Carregando a imagem de disquete criada
==> vsphere-iso: Adicionando disquete gerado ...
==> vsphere-iso: Iniciando servidor HTTP na porta 8081
2020/04/26 20:46:19 Plug-in packer-builder-vsphere-iso: Porta disponível encontrada: 8081 no IP: 0.0.0.0
==> vsphere-iso: Definir ordem de inicialização temporária ...
==> vsphere-iso: Ligue a VM ...
==> vsphere-iso: Esperando 10 segundos para inicializar ...
==> vsphere-iso: o servidor HTTP está funcionando em http: // ABCE: 8081 /
==> vsphere-iso: Digitando o comando de inicialização ...
2020/04/26 20:46:32 plugin packer-builder-vsphere-iso: código especial ''encontrado, substituindo por: CodeTab
2020/04/26 20:46:40 plugin packer-builder-vsphere-iso: código especial ''encontrado, substituindo por: CodeReturnEnter
2020/04/26 20:46:40 plugin packer-builder-vsphere-iso: Aguardando 1 segundo
==> vsphere-iso: Aguardando IP ...
2020/04/26 20:46:41 plugin packer-builder-vsphere-iso: [INFO] Aguardando IP, até o tempo limite total: 30m0s, tempo limite de liquidação: 5s
2020/04/26 20:55:12 plugin packer-builder-vsphere-iso: VM IP adquirido: ABCD
2020/04/26 20:55:12 plugin packer-builder-vsphere-iso: VM IP ainda é o mesmo: ABCD
2020/04/26 20:55:13 plugin packer-builder-vsphere-iso: VM IP ainda é o mesmo: ABCD
2020/04/26 20:55:14 plugin packer-builder-vsphere-iso: VM IP ainda é o mesmo: ABCD
2020/04/26 20:55:15 plugin packer-builder-vsphere-iso: VM IP ainda é o mesmo: ABCD
2020/04/26 20:55:16 plugin packer-builder-vsphere-iso: VM IP ainda é o mesmo: ABCD
==> vsphere-iso: endereço IP: ABCD
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: VM IP ainda é o mesmo: ABCD
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: VM IP parece estável o suficiente: ABCD
==> vsphere-iso: Usando o comunicador ssh para conectar: ​​ABCD
==> vsphere-iso: Aguardando SSH ficar disponível ...
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [INFO] Aguardando SSH, até o tempo limite: 5m0s
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [INFO] Tentando conexão SSH com ABCD: 22 ...
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [DEBUG] reconectando à conexão TCP para SSH
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [DEBUG] handshaking com SSH
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [DEBUG] handshake concluído!
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [DEBUG] Abrindo nova sessão ssh
==> vsphere-iso: conectado ao SSH!
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: [INFO] encaminhamento de agente ativado
2020/04/26 20:55:17 plugin packer-builder-vsphere-iso: executando o gancho de provisionamento
2020/04/26 20:55:17 [INFO] (telemetria) Iniciando o provisionador ansible
==> vsphere-iso: Provisionando com Ansible ...
vsphere-iso: Não usando adaptador Proxy para execução de Ansible:
vsphere-iso: Usando chaves ssh do Packer comunicador ...
vsphere-iso: Usando chaves ssh do Packer comunicador ...
2020/04/26 20:55:17 plugin packer-provisioner-ansible: Criando arquivo de inventário para execução de Ansible ...
vsphere-iso: Executando o Ansible Galaxy
vsphere-iso: [AVISO]: - dovry.ansible_role_sample (master) já está instalado - use
vsphere-iso: --force para alterar a versão para não especificada
2020/04/26 20:55:18 plugin packer-provisioner-ansible: Megan cmd é & 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 = 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 (nulo), Dir:" ", Stdin: io.Reader (nulo), Stdout: io.Writer (nulo) , Stderr: io.Writer (nulo), ExtraFiles: [] os.File (nulo), SysProcAttr :( syscall.SysProcAttr) (nulo), Processo :( os.Process) (nulo), ProcessState :( os.ProcessState) (nil), ctx: context.Context (nil), lookPathErr: erro (nil), concluído: falso, 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: Executando 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 = ABsCE 81 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 arquivo de configuraçãovsphere-iso:vsphere-iso: PLAY [Configurar a VM de base] * * * * * * * * * * * * * * * *