Packer: ansible2.8はpackeransibleプロビジョナーを壊します

作成日 2019年05月20日  ·  45コメント  ·  ソース: hashicorp/packer

ansible 2.8の最近のリリース(ansible 2.7.10からのアップグレード)は、packeransibleプロビジョナーを壊しているようです。 同じパッカーテンプレートとプレイブックを実行しています。 ansible 2.8を使用して実行すると、プロビジョナーはファクトの収集タスクにハングアップし、通過しません。 ansibleを直接(プロビジョナーなしで)実行すると正しく機能することを確認しました。 すべてがansible2.7.10で正しく機能します。

テンプレートスニペット:

{ "type": "ansible", "playbook_file": "/home/ubuntu/", "command": "ansible-playbook" }

パッカー–バージョン1.4.1EC2インスタンスでAWSEBSビルダーを使用(詳細は以下)

オペレーティングシステムの詳細:
NAME = "Ubuntu"
VERSION = "18.04.2 LTS(バイオニックビーバー)"
ID = ubuntu
ID_LIKE = debian
PRETTY_NAME = "Ubuntu 18.04.2 LTS"
VERSION_ID = "18.04"
HOME_URL = " https://www.ubuntu.com/ "
SUPPORT_URL = " https://help.ubuntu.com/ "
BUG_REPORT_URL = " https://bugs.launchpad.net/ubuntu/ "
PRIVACY_POLICY_URL = " https://www.ubuntu.com/legal/terms-and-policies/privacy-policy "
VERSION_CODENAME = bionic
UBUNTU_CODENAME = bionic

bug community-supported plugin need-repro provisioneansible-remote

最も参考になるコメント

まったく同じ問題に遭遇しました-ansible2.7.10にダウングレードされ、完全に機能しました

全てのコメント45件

まったく同じ問題に遭遇しました-ansible2.7.10にダウングレードされ、完全に機能しました

他の誰かがこれを再現することができましたか?

こっちも一緒。 ダウングレードする必要がありました。

20時58時火曜2019年5月28日には、AndrewCi [email protected]書きました:

他の誰かがこれを再現することができましたか?


このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/hashicorp/packer/issues/7667?email_source=notifications&email_token=AAAAFFDXJF7SZ3RCR7ZC4XLPXV6GTA5CNFSM4HOEP2H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAAFFFYN7SKLPFDER6IOYDPXV6GTANCNFSM4HOEP2HQ

AzureARMプロビジョナーを使用してこれを再現することもできます

うん、またダウングレードされたansible

私たちはこれをansible2.6.2でヒットしていると思います

@intinigどのバージョンにダウングレードしますか?

2.7.10にロールバックすると、修正されました。

申し分なく、 -vvオプションを削除することでこれを回避しました。 野生!

2.7.10

19時50分に2019年5月30日(木)には、adamday2 [email protected]書きました:

2.7.10にロールバックすると、修正されました。


あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/hashicorp/packer/issues/7667?email_source=notifications&email_token=AAAAFFDBJO4EIUY3O43JGOTPYAHWNA5CNFSM4HOEP2H2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAAFFESVO36RH5QHKQV2F3PYAHWNANCNFSM4HOEP2HQ

これは(少なくともいくつかのケースでは)Ansible2.8に追加された自動化されたPythonインタープリター検出に関連しています。 /usr/bin/pythonハードコーディングすると、私が観察したハングが修正されました。

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

これに当てはまりますが、リリースされたvSphere拡張モジュールの一部には2.8が本当に必要です。

これは人気のある問題であるため、ここでメモしてください。このプロビジョナーは、コミュニティがサポートするプロビジョナーの1つです。つまり、HashiCorpのメンテナーはエンジニアリングにあまり時間をかけません。 これは、あなたの提案がPackerに反映されるのを確認する最良の方法は、PRを開くことであることを意味します。

@flowerysongヒントをありがとう、それは動作します! virtualenvが役に立ちます。

パッカー接続のWindowsマシンにも同じ問題がありますが、回避策はありますか?

少なくとも、このハングの原因の根本原因と、これを修正するための潜在的な計画を持っている人はいますか? 私ができるところを喜んで助けますが、Goに精通していません(正しい方向のポイントでもっと役立つかもしれません)。

また、別のOSからpackerを実行すると、違いが生じる可能性がありますか?

同じようになりました。 パッカー1.3.3、1.3.4、1.4.1、1.4.2で試行しましたが、ansibleバージョン2.7.10、2.8.0、および2.8.1はすべて同じ動作を示します。 ANSIBLE_PYTHON_INTERPRETER envvarの設定に成功しました。

今日はこれをざっと見てみました。 あなたのansible_python_interpreterの発見に基づく私の本能は、フォールバックリストを使用するときに生成される警告が、どこかでstderrを適切に処理していないため、ハングを引き起こしているということです。

しかし、1時間ほどで、その理論をテストするためにこのフォールバック警告を生成できる状況を再現するのに苦労しました。 この問題に遭遇した人がゲストOSのアーチとインストールされているPythonのバージョン(およびインストールされている場所)を共有できる場合、それは非常に役立つので、ホイールを回転させようとして多くの時間を費やすことはありません再現ケースを取得します。

今のところ、ansible_python_interpreterを設定することはあなた全員のために直接働くように聞こえます。 これを解決するには、値ansible_python_interpreter=auto_silent設定するだけで十分かどうかを知りたいと思います。 それは、パッカーがどこかで警告が来ているというパイプの取り扱いを誤っているという私の理論にいくらかの信憑性を追加するでしょう。

@SwampDragonsパイプライン処理によって

これは、インタープリターディスカバリーにタイムアウトを追加することで、Ansible側で対処される可能性がありますが、現在、その修正のタイムラインはありません。

@flowerysong情報をありがとう。 ここで追跡できるタイムアウトの議論について話しているGHの問題または何かへのリンクがありますか?

SO @ SwampDragons-あなたの質問によると、私はそれを使用して確認することができます:
"extra_arguments":[
"--extra-vars"、
"ansible_python_interpreter = auto_silent"
]
以下を使用して、ansible-localを使用したLinuxの実行を問題なく機能させることができます。
Ansible 2.8.1
パッカー1.4.2
RHEL7のKVMビルド

ただし、これらの同じ引数により、WINDOWS Server 2019ホストをプロビジョニングしようとすると、次のエラーでエラーが発生します。

2019-07-15T14:05:46-04:00:==> qemu:Executing 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_addr = 10.0.2.2:8084 --connection packer --extra- 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 [all] * * * * * * * * * * * * * * * * * * * * * **

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:致命的:[デフォルト]:失敗しました! => {"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:PLAY 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

したがって、ansibleコアでパイプラインの「修正」を待つ間は「Linux」の有効な回避策があると思いますが、「Windows」は当分の間機能するためにさらに何かが必要ですか?

現在これに取り組んでいる人、または修正に取り組む方法について何かアイデアがありますか?

私が知っていることではありません。

私の修正はこれを追加することでした: "extra_arguments": ["-e", "ansible_python_interpreter=/usr/bin/python", "-vv"]

命を救うためにこの問題を再現することはまだできませんが、根本的な問題はAnsible呼び出しを転送するために作成するPackerのsshプロキシであるという理論に基づいて、回避策を作成することにしました。

このlocalhostプロキシを完全に削除し、代わりにインベントリファイルのホストIPを使用するようにプロビジョナーを変更する、ブランチからPR#8625を作成しました。 バグの影響を受けたすべての人がビルドをプルダウンできれば(https://circleci.com/gh/hashicorp/packer/29969#artifacts/containers/0)、私に知らせてください。それはあなたのために問題を解決します。 現在のところ、そのブランチはDockerビルドを破壊することに注意してください。 この動きが実際に問題を解決するかどうかを理解した後、それらを壊さない方法を理解します。

プロキシの削除によって問題が発生するかどうかもお知らせください。 そのPRは非常に進行中の状態にあります。

上記のPRをテストし、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)とdockerの両方で試しました
コンテナ(Python 3.6.9)ですが、パッカービルドはansibleプロビジョナーを実行する前にストールするようになりました。

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

...両方のアーキテクチャで。

パッカー1.5.1に戻すと、WinRMへの接続は成功します。powershell
プロビジョナーは正常に実行されますが、ansibleプロビジョナーは何があっても失敗します
オプションまたは追加の引数が指定されます。 'ansible_python_interpreter'の回避策
残念ながら、上記は私にはうまくいきません。

私が構築しようとした2つの環境:
1. macos [Darwinカーネルバージョン19.3.0: root:xnu-6153.81.5〜1 / RELEASE_X86_64 x86_64]
-パッカー1.5.1
-ビルダー:紺碧の腕
--os_type:Windows
-コミュニケーター:winrm
--ansible 2.9.2
-Python 3.7.3

  1. Docker / mcr.microsoft.com/azure- cli:latest [Linux 1cba84bd80dd
    4.19.76-linuxkit#1 SMP Thu Oct 17 19:31:58 UTC 2019 x86_64 Linux]
  2. パッカー1.5.1

    • ビルダー:紺碧の腕

    • os_type:Windows

    • コミュニケーター: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

---------

更新してくれてありがとう-私はいくつかの修正をプッシュしました、そして新しいバイナリはPRで見つけることができます。 ただし、winrmのプロキシなしオプションを設定する機会はありませんでした。

私はついにハングを再現することができ、リンクされたPrで可能な限りプロキシを無効にすると、SSHビルドの問題が修正されることを確認できました。 WinRMの修正を調査して実装する機会はまだありません。

この回避策が必要なSSHのユーザー向けのアーティファクトは、 https

私はこれをWindowsで実行していないので、おそらく1.5.2リリースにはなりませんが、これを取り戻して、数日以内に作業を続けます。

@SwampDragonsに感謝し

上記

winrmを使用したansible2.9でも同じ問題が発生しています。 次に、ansibleを2.7にダウングレードし、その後、一度は正常に動作しました。 しかし今、私はansible2.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:hostname127.0.0.1はaddress \ r \ ndebug1:auto-mux:既存のマスターを試しています\ r \ ndebug2:fd3設定O_NONBLOCK \ r \ ndebug2:mux_client_hello_exchange:マスターバージョン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:完了pid = 14869 \ r \ ndebug3:mux_client_request_session:セッション要求が送信されました\ r \ n#<CLIXML \ r \ nSystem.Management.Automation.PSCustomObjectSystem.Object1初めて使用するためのモジュールの準備。0-1-1完了-1 debug3:mux_client_read_packet:ヘッダーの読み取りに失敗しました:パイプが壊れています\ r \ ndebug2:マスター0から終了ステータスを受け取りました\ r \ n ')

@SwampDragonsWindowsUpdateで運が

まだです-私は旅行をしていて、今週はキーボードを持っていません。 でも来週はタスクを取り戻そうとします。

@SwampDragons Windowsにステータスはありますか? ありがとうございました!

はい! 金曜日に、基本認証でWinRMを使用して動作するプロキシレスWindowsビルドのPOCを取得しましたが、それでもsslで動作することを確認するためにテストを行う必要があります。

生きている! winrmでansibleで機能するバイナリは、 https ://circleci.com/gh/hashicorp/packer/42423#artifacts/containers/0からダウンロードできます。

詳細な使用手順については、PRに追加されたドキュメントを参照してください: https

こんにちは@SwampDragonsすべての作業(およびレポートに関する他の人)に感謝します! :)
上記のナイトリービルドを試しましたが、それでも失敗します。 それが私のために働くために、私はまだAnsible2.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]$
これは、vsphere-isoを使用してCentos 7.7ホストからのものです(これが組み込まれているのを見るのは素晴らしいです!)Centos7.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ファイルフラグメントであり、envvarsはホストキーの動作を変更していないようです。

"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 [情報]パッカーバージョン:1.5.6-dev(d824b7e969d0d54ce23b42aa2a577a73a4780765)[go1.13.9 linux amd64]
2020/04/2620: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 [警告]構成ファイルが存在しません:/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 / usr / bin / packerのunixRPCアドレスを受信しました:addrは/ tmp / packer-plugin421608791です
2020/04/26 20:46:14 packer-builder-vsphere-isoプラグイン:[情報]パッカーバージョン:1.5.6-dev(d824b7e969d0d54ce23b42aa2a577a73a4780765)[go1.13.9 linux amd64]
2020/04/26 20:46:14 packer-builder-vsphere-isoプラグイン:「PACKER_CONFIG」で構成ファイルのパスを確認しています
2020/04/26 20:46:14 packer-builder-vsphere-isoプラグイン:「PACKER_CONFIG」が設定されていません。 デフォルトの設定ファイルパスを確認する
2020/04/26 20:46:14 packer-builder-vsphere-isoプラグイン:構成ファイルを開こうとしています:/home/dev-user/.packerconfig
2020/04/26 20:46:14 packer-builder-vsphere-isoプラグイン:[警告]構成ファイルが存在しません:/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プラグイン:プラグインアドレス:unix / tmp / packer-plugin421608791
2020/04/26 20:46:14 packer-builder-vsphere-isoプラグイン:接続を待機しています...
2020/04/26 20:46:14 packer-builder-vsphere-isoプラグイン:プラグイン接続を提供しています...
2020/04/26 20:46:14パスのプラグインクライアントを作成しています:/ usr / bin / packer
2020/04/26 20:46:14プラグインの開始:/ usr / bin / packer [] string {"/ usr / bin / packer"、 "plugin"、 "packer-provisioner-ansible"}
2020/04/26 20:46:14次のRPCアドレスを待機中:/ usr / bin / packer
2020/04/26 20:46:14 / usr / bin / packerのunixRPCアドレスを受信しました:アドレスは/ tmp / packer-plugin434205582です
2020/04/26 20:46:14 packer-provisioner-ansibleプラグイン:[情報]パッカーバージョン: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プラグイン:[警告]構成ファイルが存在しません:/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プラグイン:プラグイン接続を提供しています...
vsphere-iso:出力はこの色になります。

2020/04/26 20:46:14ビルドデバッグモード:false
2020/04/26 20:46:14強制ビルド:true
2020/04/26 20:46:14エラー時:
2020/04/26 20:46:14ビルドの準備:vsphere-iso
2020/04/2620:46:15ビルドが完了するのを待っています...
2020/04/26 20:46:15ビルド実行の開始:vsphere-iso
2020/04/26 20:46:15実行中のビルダー:vsphere-iso
2020/04/26 20:46:15 [情報](テレメトリ)ビルダーvsphere-isoを開始しています
2020/04/26 20:46:15 packer-provisioner-ansibleプラグイン:ansible-playbookバージョン:2.9.6
==> vsphere-iso:VMの作成...
==> vsphere-iso:ハードウェアのカスタマイズ...
==> vsphere-iso:ISOイメージのマウント...
2020/04/26 20:46:17 packer-builder-vsphere-isoプラグイン:コントローラーでのCD-ROMの作成 '&{{{} 200 0xc00055e2a00} 0 []} 'with iso' [ISOs] 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プラグイン:一時ファイルにバックアップされたブロックデバイスを初期化しています
2020/04/26 20:46:18 packer-builder-vsphere-isoプラグイン:FATファイルシステムを使用してブロックデバイスをフォーマットしています...
2020/04/26 20:46:18 packer-builder-vsphere-isoプラグイン:ブロックデバイスでFATファイルシステムを初期化しています
2020/04/26 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:ポート8081でHTTPサーバーを起動しています
2020/04/26 20:46:19 packer-builder-vsphere-isoプラグイン:使用可能なポートが見つかりました:IPで8081:0.0.0.0
==> vsphere-iso:起動順序を一時的に設定します。
==> vsphere-iso:VMの電源をオンにします。
==> vsphere-iso:起動を10秒待っています...
==> vsphere-iso:HTTPサーバーはhttp:// ABCE:8081 /で動作しています
==> vsphere-iso:ブートコマンドを入力しています...
2020/04/26 20:46:32 packer-builder-vsphere-isoプラグイン:特別なコード ''が見つかりました。次のように置き換えます:CodeTab
2020/04/26 20:46:40 packer-builder-vsphere-isoプラグイン:特別なコード ''が見つかり、次のように置き換えます:CodeReturnEnter
2020/04/26 20:46:40 packer-builder-vsphere-isoプラグイン:1秒待機
==> vsphere-iso:IPを待機しています...
2020/04/26 20:46:41 packer-builder-vsphere-isoプラグイン:[情報] IPを待機中、最大タイムアウト:30分0秒、決済タイムアウト:5秒
2020/04/26 20:55:12 packer-builder-vsphere-isoプラグイン:取得したVM IP:ABCD
2020/04/26 20:55:12 packer-builder-vsphere-isoプラグイン:VM IPは同じです:ABCD
2020/04/26 20:55:13 packer-builder-vsphere-isoプラグイン:VM IPは同じです:ABCD
2020/04/26 20:55:14 packer-builder-vsphere-isoプラグイン:VM IPは同じです:ABCD
2020/04/26 20:55:15 packer-builder-vsphere-isoプラグイン:VM IPは同じです:ABCD
2020/04/26 20:55:16 packer-builder-vsphere-isoプラグイン:VM IPは同じです:ABCD
==> vsphere-iso:IPアドレス:ABCD
2020/04/26 20:55:17 packer-builder-vsphere-isoプラグイン:VM IPは同じです:ABCD
2020/04/26 20:55:17 packer-builder-vsphere-isoプラグイン:VM IPは十分に安定しているようです:ABCD
==> vsphere-iso:sshコミュニケーターを使用した接続:ABCD
==> vsphere-iso:SSHが利用可能になるのを待っています...
2020/04/26 20:55:17 packer-builder-vsphere-isoプラグイン:[情報] SSHを待機中、タイムアウトまで:5m0s
2020/04/26 20:55:17 packer-builder-vsphere-isoプラグイン:[情報] ABCD:22へのSSH接続を試行しています...
2020/04/26 20:55:17 packer-builder-vsphere-isoプラグイン:[DEBUG] SSHのTCP接続に再接続しています
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プラグイン:[デバッグ]新しいsshセッションを開く
==> vsphere-iso:SSHに接続しました!
2020/04/26 20:55:17 packer-builder-vsphere-isoプラグイン:[情報]エージェント転送が有効
2020/04/26 20:55:17 packer-builder-vsphere-isoプラグイン:プロビジョニングフックの実行
2020/04/26 20:55:17 [情報](テレメトリ)プロビジョナーを開始します
==> vsphere-iso:Ansibleを使用したプロビジョニング..
vsphere-iso:Ansibleの実行にプロキシアダプターを使用していません:
vsphere-iso:Packerコミュニケーターのsshキーを使用しています...
vsphere-iso:Packerコミュニケーターのsshキーを使用しています...
2020/04/26 20:55:17 packer-provisioner-ansibleプラグイン:Ansible実行用のインベントリファイルを作成しています...
vsphere-iso:AnsibleGalaxyの実行
vsphere-iso:[警告]:-dovry.ansible_role_sample(マスター)は既にインストールされています-使用
vsphere-iso:-forceでバージョンを指定なしに変更
2020/04/26 20:55:18 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(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 = ABCE:8081 --ssh-extra- 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 [ベースVMの構成] * * * * * * * * * * * * * * *


vsphere-iso:
vsphere-iso:TASK [事実の収集] * * * * * * * * * * * * * * * * *
キー '/ tmp / ansible-key848613781'のパスフレーズを入力します。
vsphere-iso:致命的:[デフォルト]:到達不能! => {"changed":false、 "msg": "ssh経由でホストに接続できませんでした:警告:既知のホストのリストに「ABCD」(ECDSA)が恒久的に追加されました。\ r \ n許可が拒否されました(publickey、gssapi- keyex、gssapi-with-mic、password)。 "、" unreachable ":true}
vsphere-iso:
vsphere-iso:PLAY RECAP * * * * * * * * * * * * * * * * * * * * * *
vsphere-iso:デフォルト:ok = 0変更= 0到達不能= 1失敗= 0スキップ= 0レスキュー= 0無視= 0
vsphere-iso:
2020/04/26 20:55:50 [情報](テレメトリ)終了ansible
==> vsphere-iso:プロビジョニング手順でエラーが発生しました:クリーンアッププロビジョナーが存在する場合は実行しています...
==> vsphere-iso:起動順序をクリアします。..
==> vsphere-iso:VMの電源をオフにします。
==> vsphere-iso:フロッピーイメージの削除..。
==> vsphere-iso:VMを破棄しています...
2020/04/26 20:55:51 packer-builder-vsphere-isoプラグイン:フロッピーディスクの削除:/ tmp / packer579447498
ビルド 'vsphere-iso'エラー:実行エラーAnsible:ゼロ以外の終了ステータス:終了ステータス4

==>一部のビルドが正常に完了せず、エラーが発生しました:
-> vsphere-iso:実行中にエラーが発生しましたAnsible:ゼロ以外の終了ステータス:終了ステータス4

==>ビルドは終了しましたが、アーティファクトは作成されませんでした。
2020/04/26 20:55:52 [情報](テレメトリ)vSphere-isoの終了
2020/04/26 20:55:52機械可読:エラーカウント[] string {"1"}
==>一部のビルドが正常に完了せず、エラーが発生しました:
2020/04/26 20:55:52機械可読:vsphere-iso、error [] string {"Ansibleの実行中にエラーが発生しました:ゼロ以外の終了ステータス:終了ステータス4"}
==>ビルドは終了しましたが、アーティファクトは作成されませんでした。
2020/04/26 20:55:52 [情報](テレメトリ)ファイナライズ。
2020/04/2620:55:53すべてのプラグインプロセスが完了するのを待っています...
2020/04/26 20:55:53 / usr / bin / packer:プラグインプロセスが終了しました
2020/04/26 20:55:53 / usr / bin / packer:プラグインプロセスが終了しました
[ dev-user @ centos-7-dev packer-test] $
`

Packer 1.5.5がチョークするので、新しい変数を想定しているため、下位互換性はありません。

正しい。 新機能のドキュメントは、リンクされたPRにあります。

Packer 1.5.6-devは、事実の収集段階でハングしなかったため(はい!)機能しましたが、ホストキーの問題で窒息しました。 どこからansible.cfgをロードしますか? または、同じ質問を別の方法で、ansible-playbookはどこから(どのディレクトリにあるように)生成されますか?

ansible-playbookは、Packerを実行しているのと同じディレクトリから生成されます。

この問題は_ 30日間_⏳クローズされているため、ロックします。 これは、メンテナがアクティブな問題を見つけて集中するのに役立ちます。

これに似た問題を見つけた場合は、新しい問題を開いて問題テンプレートに記入してください。さらに調査するために必要なすべての詳細を取得できます。

このページは役に立ちましたか?
0 / 5 - 0 評価
bleepcoder.com は、世界中の開発者にソリューションを提供するために、公にライセンスされた GitHub の情報を使用しています。弊社は、GitHub, Inc.をはじめ、GitHubを利用した開発者のプロジェクトとは提携しておりません。私たちは、私たちのサーバー上のビデオや画像をホストしていません。すべての権利はそれぞれの所有者に帰属します。
このページのソース: ソース

人気のあるプログラミング言語
GitHub の人気プロジェクト
その他の GitHub プロジェクト

© 2024 bleepcoder.com - Contact
Made with in the Dominican Republic.
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.