Packer: ansible 2.8 ломает упаковщик ansible Provider

Возникла точно такая же проблема - была понижена до версии 2.7.10, и она отлично работала

Кто-нибудь еще мог воспроизвести это?

Тоже самое. Мне пришлось понизить рейтинг.

Во вторник, 28 мая 2019 года, в 20:58, AndrewCi [email protected] написал:

Кто-нибудь еще мог воспроизвести это?

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/hashicorp/packer/issues/7667?email_source=notifications&email_token=AAAAFFDXJF7SZ3RCR7ZC4XLPXV6GTA5CNFSM4HOEP2H2YY3PNVWWK3TUL52HSG63DFMVRE45
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAAAFFFYN7SKLPFDER6IOYDPXV6GTANCNFSM4HOEP2HQ
.

Я также могу воспроизвести это с помощью средства подготовки Azure ARM.

да, также пониженный анзибль

Я думаю, что мы достигаем этого в версии 2.6.2.

@intinig До какой версии вы

Откат на 2.7.10 исправил эту проблему.

Хорошо для меня, я обошел это, удалив опцию -vv . ДИКИЙ!

2.7.10

30 мая 2019 года в 19:50 adamday2 [email protected] написал:

Откат на 2.7.10 исправил эту проблему.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/hashicorp/packer/issues/7667?email_source=notifications&email_token=AAAAFFDBJO4EIUY3O43JGOTPYAHWNA5CNFSM4HOEP2H2YY3PNVWWK3TUL52HS443DFMVREXXWWK3TUL52HS443DFVREXW08C02H2H2WWGWWG0B0B0B2H0B0B0B0B0B0B0B2
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAAAFFESVO36RH5QHKQV2F3PYAHWNANCNFSM4HOEP2HQ
.

Это (по крайней мере, в некоторых случаях) связано с автоматическим обнаружением интерпретатора Python, добавленным в Ansible 2.8; жесткое кодирование /usr/bin/python исправило наблюдаемые мной зависания.

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

Ударьте, но для некоторых выпущенных расширенных модулей vSphere действительно требуется 2.8.

Просто сделайте здесь примечание, поскольку это популярная проблема - этот провайдер является одним из наших провайдеров, поддерживаемых сообществом, а это означает, что сопровождающие HashiCorp не тратят на него много времени на разработку; это означает, что лучший способ увидеть, как ваше предложение попадет в Packer, - это открыть PR.

@flowerysong спасибо за подсказки, работает! Virtualenv помогает.

У машины Windows с подключением упаковщика такая же проблема, есть ли у кого-нибудь обходной путь?

Есть ли у кого-нибудь хотя бы основная причина этого зависания и потенциальный план по ее устранению? Рад помочь, где могу, но не знаком с Go (может быть, больше пользы, если указать в правильном направлении).

Кроме того, может ли иметь значение запуск упаковщика из другой ОС?

Получил то же самое. Попытка использовать упаковщик 1.3.3, 1.3.4, 1.4.1, 1.4.2, доступные версии 2.7.10, 2.8.0 и 2.8.1 демонстрируют одинаковое поведение. Установка ANSIBLE_PYTHON_INTERPRETER env var выполнена успешно.

Я взглянул на это сегодня; мой инстинкт, основанный на ваших открытиях ansible_python_interpreter, заключается в том, что предупреждение, генерируемое при использовании резервного списка, вызывает зависание, потому что мы где-то неправильно обрабатываем stderr.

Через час или около того я возился, но у меня возникли проблемы с воспроизведением ситуации, когда я мог бы сгенерировать это резервное предупреждение для проверки этой теории. Если кто-либо из вас, столкнувшихся с этой проблемой, может поделиться своей архитектурой гостевой ОС и узнать, какая версия python установлена ​​(и где она установлена), это было бы очень полезно, поэтому я не тратил кучу времени, крутясь на колесах, пытаясь получить репродукционный футляр.

На данный момент похоже, что настройка ansible_python_interpreter работает для всех вас напрямую. Мне было бы любопытно узнать, достаточно ли установки значения ansible_python_interpreter=auto_silent для решения этой проблемы; Это добавило бы некоторой достоверности моей теории о том, что Пакер неправильно обращается с трубкой, через которую откуда-то приходит предупреждение.

@SwampDragons Это та же самая причина, по которой конвейерная обработка приводит к зависанию

Это потенциально может быть решено на стороне Ansible путем добавления тайм-аута для обнаружения интерпретатора, но в настоящее время нет графика для этого исправления.

@flowerysong спасибо за информацию. У вас есть ссылка на проблему с GH или что-то, в котором говорится об обсуждении тайм-аута, которое мы можем отследить здесь?

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

SO @SwampDragons - на ваш вопрос я могу подтвердить это, используя:
"extra_arguments": [
"--extra-vars",
"ansible_python_interpreter = auto_silent"
]
Позволяет без проблем работать с linux с использованием ansible-local, используя следующее:
Ansible 2.8.1
Пакер 1.4.2
KVM Сборка RHEL7

Однако те же самые аргументы приводят к ошибке при попытке подготовить хост WINDOWS Server 2019 со следующей ошибкой:

2019-07-15T14: 05: 46-04: 00: ==> qemu: Выполнение 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_adder = 10.0-ddr: vars ansible_shell_type = powershell ansible_shell_executable = Нет ansible_python_interpreter = auto_silent

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

2019-07-15T14: 05: 55-04: 00: QEMU: PLAY [все] * * * * * * * * * * * * * * * * * * * * * **

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

2019-07-15T14: 05: 55-04: 00: qemu: TASK [Сбор фактов] * * * * * * * * * * * * * * * * * **

2019-07-15T14: 05: 56-04: 00: qemu: fatal: [по умолчанию]: НЕ ВЫПОЛНЕНО! => {"ansible_facts": {}, "changed": false, "msg": "Не удалось выполнить следующие модули: setup \ n setup: MODULE FAILURE \ nСм. stdout / stderr для точной ошибки \ n"}

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

2019-07-15T14: 05: 56-04: 00: QEMU: ВОСПРОИЗВЕДЕНИЕ RECAP * * * * * * * * * * * * * * * * * * * * * **

2019-07-15T14: 05: 56-04: 00: qemu: по умолчанию: ok = 0 изменено = 0 недоступно = 0 не удалось = 1 пропущено = 0 спасено = 0 игнорируется = 0

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

2019-07-15T14: 05: 56-04: 00: ==> qemu: Удаление каталога вывода ...

2019-07-15T14: 05: 56-04: 00: Сборка qemu с ошибкой: ошибка выполнения Ansible: ненулевой статус выхода: статус выхода 2

Итак, я думаю, что у нас есть допустимый обходной путь для «Linux», пока мы ждем «исправления» конвейера в недоступном ядре, но «Windows» все еще нужно что-то еще, чтобы позволить ему работать на данный момент?

Кто-нибудь в настоящее время работает над этим или есть идеи о том, как подойти к исправлению?

Не то, чтобы я в курсе.

Мое исправление было добавить следующее: "extra_arguments": ["-e", "ansible_python_interpreter=/usr/bin/python", "-vv"]

Я до сих пор не могу воспроизвести эту проблему, чтобы спасти свою жизнь, но я решил продвинуться вперед и попытаться создать обходной путь, основанный на теории, что основная проблема заключается в прокси-сервере Packer ssh, который он создает для пересылки вызовов Ansible.

Я создал PR # 8625 из ветки, которая полностью удаляет этот прокси localhost и модифицирует провайдер, чтобы вместо этого использовать IP-адрес хоста в файле инвентаризации. Мне бы хотелось, чтобы кто-нибудь из вас, затронутых этой ошибкой, снял сборку (доступен здесь: https://circleci.com/gh/hashicorp/packer/29969#artifacts/containers/0) и дайте мне знать, если это решает проблему за вас. Обратите внимание, что на данный момент эта ветка нарушает сборки Docker. Я выясню, как их восстановить после того, как мы выясним, действительно ли этот ход решит проблему.

Пожалуйста, дайте мне знать, если удаление прокси вызывает у вас проблемы; этот PR находится в состоянии «незавершенная работа».

Любые желающие протестировать вышеупомянутый PR и сообщить мне, решает ли он несовместимость ansible 2.8+? У меня есть новые сборки, доступные здесь: https://circleci.com/gh/hashicorp/packer/32248#artifacts/containers/0 , которые позволяют использовать или не использовать адаптер прокси на основе логического параметра use_proxy. (в настоящее время по умолчанию установлено значение true, но я изменю значение по умолчанию в будущем, если это будет целесообразно)

@SwampDragons , спасибо за предоставление этих новых сборок упаковщика (v 1.5.2).

Я пробовал эту новую сборку 1.5.2 как на macos (Python 3.7.3), так и в докере.
контейнер (Python 3.6.9), но сборка упаковщика теперь останавливается перед запуском ansible Provider:

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

... на обеих архитектурах.

Если я вернусь к упаковщику 1.5.1, соединение с WinRM будет успешным, powershell
провайдеры работают успешно, но доступный провайдер не работает, несмотря ни на что
приводятся опции или дополнительные аргументы. Обходной путь 'ansible_python_interpreter'
упомянутое выше не работает для меня, к сожалению.

Две среды, которые я пытался создать:
1. macos [ядро Дарвина версии 19.3.0: root: xnu-6153.81.5 ~ 1 / RELEASE_X86_64 x86_64]
- пакер 1.5.1
- строитель: лазоревка
- os_type: Windows
- коммуникатор: winrm
- анзибль 2.9.2
- Python 3.7.3

1. Docker / mcr.microsoft.com/azure- cli : последняя версия [Linux 1cba84bd80dd
   4.19.76-linuxkit # 1 SMP Чт 17 октября 19:31:58 UTC 2019 x86_64 Linux]
2. пакер 1.5.1
   
   
   
   • строитель: лазоревка
   
   
   • os_type: Windows
   
   
   • коммуникатор: winrm
   
   
3. недостоверный 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

---------

Спасибо за обновление - я внес несколько исправлений, и новые двоичные файлы можно найти в PR. Однако у меня не было возможности настроить опцию без прокси для WinRM.

Я наконец смог воспроизвести зависание и могу подтвердить, что отключение прокси, насколько это возможно в связанной Pr, устраняет проблему для сборок SSH. У меня еще не было возможности изучить и внедрить исправление для WinRM.

Артефакты для тех из вас, кто пользуется SSH и кому нужен этот обходной путь, можно найти здесь: https://circleci.com/gh/hashicorp/packer/33086#artifacts/containers/0 .

Поскольку у меня этого не было для Windows, это, вероятно, не войдет в выпуск 1.5.2, но я возьму это резервную копию и продолжу работу над ней через пару дней.

Спасибо, @SwampDragons , отличные новости! Будем рады получить исправления для сборок Windows, когда вы сможете продолжить работу над ними.

Я могу подтвердить, что использование приведенной выше сборки устраняет проблему с подключением Ansible к экземпляру Packer через SSH. 🚀

У меня такая же проблема в ansible 2.9 с winrm. Затем я понизил анзибль до 2.7, после этого он работал нормально. Но теперь я испытываю ту же проблему и в ansible 2.7.

ansible = 2.7.0
версия python = 3.7.6
пакер = 1.5.4

<127.0.0.1> (0, b '', b'OpenSSH_7.9p1, LibreSSL 2.7.3 \ r \ ndebug1: чтение данных конфигурации / etc / ssh / ssh_config \ r \ ndebug1: / etc / ssh / ssh_config строка 48: Применение параметров для * \ r \ ndebug2: resolve_canonicalize: hostname 127.0.0.1 is address \ r \ ndebug1: auto-mux: Попытка существующего мастера \ r \ ndebug2: установка fd 3 O_NONBLOCK \ r \ ndebug2: mux_client_hello_exchange: master version 4 \ r \ ndebug3: mux_client_forwards: переадресация запросов: 0 локальных, 0 удаленных \ r \ ndebug3: mux_client_request_session: ввод \ r \ ndebug3: mux_client_request_alive: ввод \ r \ ndebug3: mux_client_request_alive_alive_request_alive 14: выполнено rid_client_request_alive_alive14 \ r \ n # <CLIXML \ r \ nSystem.Management.Automation.PSCustomObjectSystem.Object1Подготовка модулей к первому использованию.0-1-1Завершено-1 debug3: mux_client_read_packet: ошибка чтения заголовка: сломанный канал \ r \ ndebug2: получен статус выхода от мастера 0 \ r \ n ')

@SwampDragons удачи с обновлением Windows

Еще нет - я путешествовал и на этой неделе не играл на клавиатуре. Но я постараюсь вернуться к задаче на следующей неделе.

@SwampDragons есть ли статус в Windows? Спасибо!

Да! В пятницу я получил POC для сборок Windows без прокси, работающих с использованием WinRM с базовой аутентификацией, но мне все еще нужно провести тестирование, чтобы убедиться, что он работает с ssl.

Оно живет! Бинарные файлы, которые работают для ansible с winrm, можно скачать здесь: https://circleci.com/gh/hashicorp/packer/42423#artifacts/containers/0

См. Подробные инструкции по использованию в документации, добавленной в PR: https://github.com/hashicorp/packer/pull/8625

Привет, @SwampDragons Спасибо за всю вашу работу (и всем, кто
Я пробовал вышеперечисленную ночную сборку, но у меня все еще не получилось. Мне все еще нужно откатиться на Ansible 2.7.10, чтобы он работал у меня.
[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]$
Это с хоста Centos 7.7, использующего vsphere-iso (здорово, что он встроен сейчас!), Создающий минимальный образ Centos 7.7.
Кто-нибудь еще обнаружил другие проблемы?

@ChrisGWarp Мне понадобится полный репро-кейс, чтобы больше

packer_test.zip
Готово!
Включая журнал сбоев, исправлений (возможность перехода на более раннюю версию) и успехов.
Надеюсь это поможет. :)

Итак, глядя на ваш конфиг:

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

Я не тестировал это с Galaxy, но также в вашей конфигурации не похоже, что вы действительно отключили прокси.

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

Можете ли вы попробовать описанное выше с PACKER_DEBUG = 1 в своей среде, чтобы получить подробные журналы? И связать их в сущности?

Хорошо, мне удалось пройти дальше, но затем возникли другие проблемы.
Вот что я нашел / заметил:

Я не был уверен в использовании use_proxy, если это существующий параметр, значение которого нужно изменить, или новое.

Packer 1.5.5 подавляется этим, поэтому я предполагаю новую переменную и, следовательно, не имеющую обратной совместимости.

Packer 1.5.6-dev действительно работал, так как он не зависал на этапе сбора фактов (да!), Но затем он подавился проблемой ключа хоста. Откуда загружается ansible.cfg? Или, тот же вопрос по-другому, откуда (как в каком каталоге) создается ansible-playbook?

Это фрагмент файла .json, env vars, похоже, не изменили поведение ключа хоста.

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

Вот результат журнала:

`[ 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] Версия упаковщика: 1.5.6-dev (d824b7e969d0d54ce23b42aa2a577a73a4780765) [go1.13.9 linux amd64]
2020/04/26 20:46:14 Проверка пути к файлу конфигурации в 'PACKER_CONFIG'
2020/04/26 20:46:14 'PACKER_CONFIG' не установлен; проверка пути к файлу конфигурации по умолчанию
2020/04/26 20:46:14 Попытка открыть файл конфигурации: /home/dev-user/.packerconfig
2020/04/26 20:46:14 [WARN] Файл конфигурации не существует: /home/dev-user/.packerconfig
2020/04/26 20:46:14 Установка каталога кеша: / home / dev-user / eclipse-workspace / packer-test / packer_cache
2020/04/26 20:46:14 Создание клиента плагина для пути: / usr / bin / packer
2020/04/26 20:46:14 Стартовый плагин: / usr / bin / packer [] string {"/ usr / bin / packer", "plugin", "packer-builder-vsphere-iso"}
2020/04/26 20:46:14 Ожидание адреса RPC для: / usr / bin / packer
2020/04/26 20:46:14 Получен unix-адрес RPC для / usr / bin / packer: addr is / tmp / packer-plugin421608791
2020/04/26 20:46:14 packer-builder-vsphere-iso plugin: [INFO] Версия упаковщика: 1.5.6-dev (d824b7e969d0d54ce23b42aa2a577a73a4780765) [go1.13.9 linux amd64]
2020/04/26 20:46:14 packer-builder-vsphere-iso plugin: проверка пути к файлу конфигурации в 'PACKER_CONFIG'
2020/04/26 20:46:14 Плагин packer-builder-vsphere-iso: 'PACKER_CONFIG' не установлен; проверка пути к файлу конфигурации по умолчанию
26.04.2020 20:46:14 Плагин packer-builder-vsphere-iso: попытка открыть файл конфигурации: /home/dev-user/.packerconfig
2020/04/26 20:46:14 Плагин packer-builder-vsphere-iso: [WARN] Файл конфигурации не существует: /home/dev-user/.packerconfig
2020/04/26 20:46:14 Плагин packer-builder-vsphere-iso: Установка каталога кеша: / home / dev-user / eclipse-workspace / packer-test / packer_cache
2020/04/26 20:46:14 плагин packer-builder-vsphere-iso: args: [] string {"packer-builder-vsphere-iso"}
2020/04/26 20:46:14 packer-builder-vsphere-iso plugin: Адрес плагина: unix / tmp / packer-plugin421608791
26.04.2020 20:46:14 Плагин packer-builder-vsphere-iso: Ожидание подключения ...
2020/04/26 20:46:14 packer-builder-vsphere-iso plugin: обслуживание подключения к плагину ...
2020/04/26 20:46:14 Создание клиента плагина для пути: / usr / bin / packer
2020/04/26 20:46:14 Стартовый плагин: / usr / bin / packer [] строка {"/ usr / bin / packer", "plugin", "packer-provisioner-ansible"}
2020/04/26 20:46:14 Ожидание адреса RPC для: / usr / bin / packer
2020/04/26 20:46:14 Получен unix-адрес RPC для / usr / bin / packer: addr is / tmp / packer-plugin434205582
2020/04/26 20:46:14 подключаемый модуль packer-provisioner-ansible: [INFO] Версия упаковщика: 1.5.6-dev (d824b7e969d0d54ce23b42aa2a577a73a4780765) [go1.13.9 linux amd64]
2020/04/26 20:46:14 Плагин packer-provisioner-ansible: проверка пути к файлу конфигурации в 'PACKER_CONFIG'
2020/04/26 20:46:14 подключаемый модуль packer-provisioner-ansible: 'PACKER_CONFIG' не установлен; проверка пути к файлу конфигурации по умолчанию
2020/04/26 20:46:14 Плагин packer-provisioner-ansible: Попытка открыть файл конфигурации: /home/dev-user/.packerconfig
2020/04/26 20:46:14 Плагин packer-provisioner-ansible: [WARN] Файл конфигурации не существует: /home/dev-user/.packerconfig
2020/04/26 20:46:14 Плагин packer-provisioner-ansible: Установка каталога кеша: / home / dev-user / eclipse-workspace / packer-test / packer_cache
2020/04/26 20:46:14 Плагин packer-provisioner-ansible: args: [] string {"packer-provisioner-ansible"}
2020/04/26 20:46:14 Плагин packer-provisioner-ansible: Адрес плагина: unix / tmp / packer-plugin434205582
2020/04/26 20:46:14 Плагин packer-provisioner-ansible: Ожидание подключения ...
2020/04/26 20:46:14 packer-provisioner-ansible plugin: обслуживание подключения к плагину ...
vsphere-iso: вывод будет в этом цвете.

2020/04/26 20:46:14 Режим отладки сборки: false
2020/04/26 20:46:14 Форс-билд: правда
2020/04/26 20:46:14 При ошибке:
2020.04.26 20:46:14 Готовим сборку: vsphere-iso
2020/04/26 20:46:15 Ожидание завершения сборки ...
2020/04/26 20:46:15 Запуск сборки: vsphere-iso
2020.04.26 20:46:15 Запуск билдера: vsphere-iso
2020.04.26 20:46:15 [INFO] (телеметрия) Запускаем билдер vsphere-iso
2020/04/26 20:46:15 плагин packer-provisioner-ansible: версия ansible-playbook: 2.9.6
==> vsphere-iso: Создание ВМ ...
==> vsphere-iso: Настройка оборудования ...
==> vsphere-iso: Монтирование образов ISO ...
2020/04/26 20:46:17 Плагин packer-builder-vsphere-iso: Создание CD-ROM на контроллере '& {{{} 200 0xc00055e2a00} 0 []} 'с iso' [ISO] CentOS / CentOS-7-x86_64-Minimal-1908.iso '
==> vsphere-iso: Создание дискеты ...
vsphere-iso: прямое копирование файлов с floppy_files
2020/04/26 20:46:18 Плагин packer-builder-vsphere-iso: Путь к дискете: / tmp / packer579447498
2020/04/26 20:46:18 packer-builder-vsphere-iso plugin: Инициализация блочного устройства, поддерживаемого временным файлом
26.04.2020 20:46:18 Плагин packer-builder-vsphere-iso: Форматирование блочного устройства с файловой системой FAT ...
2020/04/26 20:46:18 packer-builder-vsphere-iso plugin: Инициализация файловой системы FAT на блочном устройстве
26.04.2020 20:46:18 Плагин packer-builder-vsphere-iso: чтение корневого каталога из файловой системы
vsphere-iso: Копирование файла: http / ks-7.7-minimal-static.cfg
vsphere-iso: Копирование файлов с floppy_files завершено
vsphere-iso: Сбор путей из floppy_dirs
vsphere-iso: Полученные пути из floppy_dirs: []
vsphere-iso: Копирование путей из floppy_dirs выполнено
==> vsphere-iso: загрузка созданного образа дискеты
==> vsphere-iso: Добавление созданной дискеты ...
==> vsphere-iso: запуск HTTP-сервера на порту 8081
2020/04/26 20:46:19 Плагин packer-builder-vsphere-iso: Найден доступный порт: 8081 на IP: 0.0.0.0
==> vsphere-iso: установить временный порядок загрузки ...
==> vsphere-iso: Включите ВМ ...
==> vsphere-iso: 10 секунд ожидания загрузки ...
==> vsphere-iso: HTTP-сервер работает по адресу http: // ABCE: 8081 /
==> vsphere-iso: Ввод команды загрузки ...
2020/04/26 20:46:32 packer-builder-vsphere-iso plugin: специальный код ''найдено, заменив на: CodeTab
2020/04/26 20:46:40 packer-builder-vsphere-iso plugin: специальный код ''найдено, заменив на: CodeReturnEnter
2020/04/26 20:46:40 packer-builder-vsphere-iso plugin: ожидание 1 секунда
==> vsphere-iso: Ожидание IP ...
2020/04/26 20:46:41 Плагин packer-builder-vsphere-iso: [ИНФОРМАЦИЯ] Ожидание IP, до общего тайм-аута: 30 мин. С, расчетное время ожидания: 5 с.
2020/04/26 20:55:12 Плагин packer-builder-vsphere-iso: Получен IP-адрес виртуальной машины: ABCD
26.04.2020 20:55:12 Плагин packer-builder-vsphere-iso: IP-адрес виртуальной машины все тот же: ABCD
26.04.2020 20:55:13 Плагин packer-builder-vsphere-iso: IP-адрес ВМ все тот же: ABCD
26.04.2020 20:55:14 Плагин packer-builder-vsphere-iso: IP-адрес ВМ все тот же: ABCD
26.04.2020 20:55:15 Плагин packer-builder-vsphere-iso: IP-адрес виртуальной машины все тот же: ABCD
26.04.2020 20:55:16 Плагин packer-builder-vsphere-iso: IP-адрес виртуальной машины все тот же: ABCD
==> vsphere-iso: IP-адрес: ABCD
26.04.2020 20:55:17 Плагин packer-builder-vsphere-iso: IP-адрес виртуальной машины все тот же: ABCD
2020/04/26 20:55:17 Плагин packer-builder-vsphere-iso: IP ВМ кажется достаточно стабильным: ABCD
==> vsphere-iso: Использование ssh-коммуникатора для подключения: ABCD
==> vsphere-iso: Ожидание доступности SSH ...
2020/04/26 20:55:17 packer-builder-vsphere-iso plugin: [INFO] Ожидание SSH до таймаута: 5 мин.
2020/04/26 20:55:17 packer-builder-vsphere-iso plugin: [INFO] Попытка SSH-подключения к ABCD: 22 ...
2020/04/26 20:55:17 плагин packer-builder-vsphere-iso: [DEBUG] переподключение к TCP-соединению для SSH
2020/04/26 20:55:17 Плагин packer-builder-vsphere-iso: подтверждение установления связи [DEBUG] с помощью SSH
2020/04/26 20:55:17 плагин packer-builder-vsphere-iso: рукопожатие [DEBUG] завершено!
2020/04/26 20:55:17 packer-builder-vsphere-iso plugin: [DEBUG] Открытие нового сеанса ssh
==> vsphere-iso: подключен к SSH!
2020/04/26 20:55:17 packer-builder-vsphere-iso plugin: [INFO] пересылка агента включена
2020/04/26 20:55:17 Плагин packer-builder-vsphere-iso: Запуск обработчика Provision Hook
2020/04/26 20:55:17 [INFO] (телеметрия) Запуск провайдера недоступен
==> vsphere-iso: подготовка с помощью Ansible ...
vsphere-iso: прокси-адаптер не используется для запуска Ansible:
vsphere-iso: Использование ssh-ключей коммуникатора Packer ...
vsphere-iso: Использование ssh-ключей коммуникатора Packer ...
2020/04/26 20:55:17 Плагин packer-provisioner-ansible: Создание файла инвентаризации для запуска Ansible ...
vsphere-iso: выполнение Ansible Galaxy
vsphere-iso: [ВНИМАНИЕ]: - dovry.ansible_role_sample (master) уже установлен - используйте
vsphere-iso: - принудительно изменить версию на неопределенную
2020/04/26 20:55:18 packer-provisioner-ansible plugin: Megan cmd is & exec.Cmd {Путь: "/ 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 = AB : 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: [] строка (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), finished: 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: Выполнение 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 - ABBYY: extra_addr - args -o IdentitiesOnly = yes -i / tmp / packer-provisioner-ansible807514096 /home/dev-user/eclipse-workspace/packer-test/ansible/packer-test.yml -vvsphere-iso: использование /etc/ansible/ansible.cfg в качестве файла конфигурацииvsphere-iso:vsphere-iso: PLAY [Настроить базовую ВМ] * * * * * * * * * * * * * * *