Ansibleは事実の収集にこだわりました
私のansibleボックス（vagrant）でいくつかの奇妙な問題があります。
昨日すべてがうまくいき、私のプレイブックはうまくいきました。
今日、Ansibleは「事実の収集」にかかっていますか？
詳細な出力は次のとおりです。
<5.xxx.xxx.xxx> ESTABLISH CONNECTION FOR USER: deploy
<5.xxx.xxx.xxx> REMOTE_MODULE setup
<5.xxx.xxx.xxx> EXEC ['ssh', '-C', '-tt', '-vvv', '-o', 'ControlMaster=auto', '-
o', 'ControlPersist=60s', '-o', 'ControlPath=/home/vagrant/.ansible/cp/ansible-s
sh-%h-%p-%r', '-o', 'Port=2221', '-o', 'KbdInteractiveAuthentication=no', '-o',
'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o
', 'PasswordAuthentication=no', '-o', 'User=deploy', '-o', 'ConnectTimeout=10',
'5.xxx.xxx.xxx', "/bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1411372677
.18-251130781588968 && chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1411372677.18-2
51130781588968 && echo $HOME/.ansible/tmp/ansible-tmp-1411372677.18-251130781588
968'"]
私はVagrantでのAnsible pingで同様の問題を抱えていましたが、それは理由もなく突然停止しただけで、以前はまったく問題なく動作していました。 sshや接続問題のような他の問題とは異なり、タイムアウトなしで永遠に死にます。
この問題を解決するために私がしたことの1つは、~/.ansibleディレクトリをクリーンアップすることです。理由はわかりませんが、解決しました。
変更する場合は、Vagrantを更新する前に、~/.ansibleフォルダーをクリーンアップしてください。
私にとって、セットアップモジュールモジュールは、NFSマウントの停止状態でスタックしていました。
マシンで「df」を実行しても何も起こらない場合は、同じケースである可能性があります。
PS：NFS共有/マウントポイントをアンマウントできない場合は、不正な「umount -l」の使用を検討してください
Ansibleは、さまざまな理由でこのようにハングする可能性があります。通常、接続の問題またはセットアップモジュールがハングするためです。問題を絞り込み、解決できるようにする方法を次に示します。
Ansibleは宛先ホストに接続できません
ホストキー（known_hosts）の問題
1）Ansibleの古いバージョン（2.1以前）では、宛先のホストキーがソースに存在しない場合、または不一致がある場合、Ansibleは常に通知するとは限りません。
解決策：その宛先への同じパラメーターでSSH接続を開いてみてください。解決する必要のあるSSHエラーが見つかると、コマンドが機能します。
2）他のステータスの最中にAnsibleがSSH接続メッセージを表示して、Ansibleをそのタスクで「フリーズ」させることがあります。
Warning: the ECDSA Host key for 'myhost' differs from the key for the IP address '10.10.1.10'
Offending key for IP in /etc/ssh/ssh_known_hosts:246
Matching Host key in /etc/ssh/ssh_known_hosts:477
Are you sure you want to continue connecting (yes/no)?
この場合、尋ねられたSSHの質問に対して「yes」と入力するだけで、プレイを続行できます。その後、ルートのknown_hostsの問題を修正できます。
秘密鍵認証の問題
鍵ベースの認証とパスワードを使用する場合、他の問題には以下が含まれます。
- 秘密鍵が宛先で正しくセットアップされていない可能性があります
- 秘密鍵に誤った権限がローカルにある可能性があります（Ansibleジョブを実行しているユーザーのみが読み取ることができます）
解決策：問題のあるホストに対してansible -m ping <destination> -kを実行してみてください-それが機能しない場合は、上記のホストキーの問題解決策を試してください。
Ansibleはすぐに事実を収集できません
setupモジュール（ansible-playbook実行の開始時に自動的に実行される場合、またはansible -m setup <Host>として手動で実行される場合）は、ハードウェア情報を収集するときにハングすることがよくあります（ホストからディスク情報を取得する場合など） I/Oが高い、マウントエントリが悪いなど）。
解決策：ansible -m setup -a gather_subset=!all <destination>を実行してみてください。これが機能する場合、ansible.cfgでこの行を設定することを検討する必要があります。
gather_subset=!hardware
Ansibleがファクトの収集でハングする理由はたくさんありますが、先に進む前に、このような状況で最初に行うべきテストを次に示します。
ansible -m ping <hostname>
このテストはホストに接続し、次を返すのに十分なコードを実行します。
<hostname> | SUCCESS => {
"changed": false,
"ping": "pong"
}
これが機能する場合は、ターゲットのホスト名を解決し、接続を開き、認証し、リモートpython通訳。
さて、これが、プレイブックの冒頭で問題が発生する可能性のあるものの（完全ではない）リストです。
Ansibleによって実行されるコマンドは、インタラクティブな入力を待っています
これは、コマンドがSudoパスワード（-Kスイッチを忘れた場合）や、新しいsshホストフィンガープリントの受け入れなど、決して発生しないインタラクティブな入力を待つ古いansibleバージョンで発生したことを覚えています。 （新しいターゲットホストの場合）。
最近のバージョンのansibleはこれらの両方のケースを適切に処理し、通常のユースケースではすぐにエラーを発生させるので、sshやSudoを自分で呼び出すなどの操作を行わない限り、この種の問題は発生しません。そして、あなたがそうしたとしても、それは事実の収集後でしょう。
デッドsshマスター接続
Sshクライアントに渡されるいくつかの非常に興味深いオプションが、ここにあるデバッグログにあります。
ControlMaster=autoControlPersist=60sControlPath=/home/vagrant/.ansible/cp/ansible-ssh-%h-%p-%r
これらのオプションは man ssh_config に記載されています。
デフォルトでは、ansibleはssh接続の使用に関して賢く試みます。特定のホストの場合、プレイ内のすべてのタスクに対して新しい接続を作成する代わりに、ホストを1回開き、プレイブック全体（およびプレイブック全体）で開いたままにします。
新しい接続の確立は、既存の接続を使用するよりもはるかに遅く、計算集約的であるため、これは良いことです。
実際には、すべてのssh接続は~/.ansible/cp/some-Host-specific-pathでのソケットの存在をチェックします。最初の接続はそれを見つけることができないため、通常どおり接続してから作成します。その後のすべての接続は、このソケットを使用して、すでに確立されている接続を通過します。
確立された接続が十分な時間使用されなかった後に最終的にタイムアウトして閉じた場合でも、ソケットも閉じられ、元の接続に戻ります。
ここまでは順調ですね。
ただし、実際には接続が切断されても、sshクライアントはそれが確立されていると見なします。これは通常、ラップトップからプレイブックを実行し、WiFi接続が失われた場合（またはWiFiからイーサネットに切り替えた場合など）に発生します。
この最後の例はひどい状況です：デフォルトのssh構成でターゲットマシンにsshcanできますが、以前の接続がまだアクティブと見なされている限り、ansibleは新しいものを確立しようとさえしません。
この時点で、私たちはこの古いソケットを取り除きたいだけであり、それを行う最も簡単な方法はそれを削除することです：
# Delete all the current sockets (may disrupt currently running playbooks)
rm -r ~/.ansible/cp
# Delete only the affected socket (requires to know which one it is)
rm ~/.ansible/cp/<replace-by-your-socket>
これは1回限りの修正には最適ですが、頻繁に発生する場合は、より長期の修正を探す必要がある場合があります。この目標に向けて役立つ可能性があるいくつかの指針を次に示します。
- サーバーからプレイブックを起動します（ラップトップよりも安定したネットワーク接続で）
- ansible configuration を使用するか、直接 ssh client configuration を使用して接続共有を無効にします
- 同じリソースを使用しますが、タイムアウトを微調整して、マスター接続のクラッシュが実際により速くタイムアウトするようにします
執筆時点では、いくつかのオプションが変更されています（たとえば、私の最新の実行でControlPath=/home/toadjaune/.ansible/cp/871b533295が得られました）。ただし、一般的な考え方はまだ有効です。
事実の収集に実際に時間がかかりすぎる
すべてのプレイの最初に、ansibleはターゲットシステムに関する多くの情報を収集し、それを Facts に入れます。これらはプレイブックで使用できる変数であり、通常は非常に便利ですが、この情報の取得が非常に長くなることがあります（不良マウントポイント、高I/O、高負荷のディスクなど）。
これは言われていますが、厳密にはプレイブックを実行するためのファクトは必要ありませんが、ほとんどすべてのファクトはそうではないので、私たちがしないことを試して無効にしましょう必要ありません。そのためのいくつかのオプション：
- 完全に disable セットアップモジュール
- セットアップモジュール の構成を変更して、特定の部分のみを含めるようにします。
- コマンドライン引数を介して
- 経由 ansible設定ファイル
デバッグの目的で、コマンドラインから直接セットアップモジュールを呼び出すと非常に便利です。
ansible -m setup <hostname>
この最後のコマンドは、プレイブックと同様にハングし、最終的にタイムアウト（または成功）するはずです。次に、モジュールをもう一度実行して、可能な限りすべてを無効にします。
ansible -m setup -a gather_subset='!all' <hostname>
それでもハングする場合は、いつでもモジュールを完全に無効にしてプレイすることができますが、問題は別の場所にある可能性があります。
ただし、正常に（かつ迅速に）機能する場合は、 モジュールのドキュメント を参照してください。次の2つのオプションがあります。
- ファクトの収集をサブセットに限定し、不要なものを除外します（
gather_subsetの可能な値を参照） gather_timeoutは、より多くの時間を許可することで、問題の修正にも役立ちます（ただし、ハングではなく、タイムアウトエラーを修正することになります）。
その他の問題
明らかに、他のことがうまくいかない場合があります。デバッグに役立ついくつかのポインタ：
- 実行されたすべてのコマンドが表示されるため、ansible maximum verbosity level（
-vvvv）を使用します - 上記で説明したように、コマンドラインから直接
pingおよびsetupモジュールを使用します ansible -m pingが機能しない場合は、手動でsshを試行してください
Gathering Factsにぶら下がっているAnsibleでも同様の問題がありました。スクリプトをタスクやロールのないプロンプトに分解しましたが、それでもハングしました。
私のプロセスリストには、1日に蓄積された12のハングしたansibleプロセスが見つかりました。
/usr/bin/python /tmp/ansible_Jfv4PA/ansible_module_setup.py
/usr/bin/python /tmp/ansible_M2T10L/ansible_module_setup.py
それらを殺した後、それは再び働き始めました。
Dmytroは何かに取り組んでいます！
AnsibleはホストのFQDNを使用します。ホストがDNS解決可能ではなく、/etc/hostsにマッピングがない場合、ansibleはDNSがタイムアウトするまで待機します。
接続しているマシンのホストファイルに::1 <fqdn>を追加すると、AnsibleはDNSを経由せずにFQDNをすぐに取得します。
ホストは/etc/hostsからホストをルックアップする必要があることに注意してください。これは、すべてではないにしても、ほとんどのLinuxシステムのデフォルトですが、編集が/etc/nsswitch.confの場合も問題になる可能性があります。
同じ問題がありました。冗長モードでansibleを実行すると、有用な情報が得られませんでした。
プレイブックを実行する前にサーバーが再プロビジョニングされました。
既知のホストリストからサーバーを削除すると、以下のコマンドを使用してこれが修正されました。
$ ssh-keygen -f "~/.ssh/known_hosts" -R <hostname>
$ ssh-keygen -f "~/.ssh/known_hosts" -R <ip_address>
注：ホスト名とIPアドレスの両方を削除する必要があります
あなたがSudoプレイブックを使用しているかどうかはわかりませんが、私はそうでした、そしてそれはSudoパスワードにかかっていました。
ドキュメントから-あなたはそれを殺すことができ、次に-Kも使用できます。
幸運を。
サーバーOSを再インストールしたときなど、ターゲットシステムのフィンガープリントが変更された可能性があります。 known_hosts内のエントリを削除する必要があります。ansibleはnot信頼されていないエントリが問題であることを通知します。説明どおりにスタックします。
Ansibleは認証できないようです...したがって、-kを使用して、以下に示すように、ansibleにサーバーのパスワードを要求させます....
ansible-playbook -K -i hosts playbook.yml -vvvv
私の場合、ansibleはタスクの途中で動作を停止しました。その理由は、私のssh-agentが機能しなくなったためです（ssh-add -lは何も返しませんでした）。私はすべてを再起動し、それは再び働いた。 ssh-agentが正しく動作しているかどうかを確認してください（ssh-add -lスタックしないでください）。
~/.ansibleだけを削除しても、私にはできませんでした。したがって、そのディレクトリの内容を確認するために、ctrl-z（プロセスをスリープ状態にする）を実行して確認し、fgを介してansibleプロセスを続行しました。その場合、私は何も削除しませんでした。しかし、それが続いただけです。だから私はctrl-z-> fgだけを試してみましたが、それもうまくいきました。レインダンスのような感じですが、行き詰まっている方も是非お試しください。
FQDNとホスト名の不一致もansible hangoutを引き起こす可能性があります。ホスト名ドメインとは異なるドメインでFQDNを使用しました。 両方を等しくするの後、ansibleは完全に機能します。おそらくansibleは、リモートホストでタスクを実行する前にFQDNとホスト名を比較します。それが役に立てば幸い！
Ansible-playbookが「Gathering facts」でハングするのはなぜですか？ ブログ投稿のアドバイスに従って、この問題の原因を修正しました。
次のように簡略化できます。
コマンドを保存して
DEFAULT_KEEP_REMOTE_FILES=yesを有効にするには、-vvvvを設定しますハンドブックをもう一度実行します。
プレイがスタックしたときに、最後に印刷されたシェルコマンドをコピーします（
/bin/sh -cの後の部分）。ssh経由でサーバーにログオンします。straceを使用して、プレイの最後のステップを再生します。 stepコマンドは-vvv出力からコピーされます。例：strace -f /bin/sh -c "echo BECOME-SUCCESS-ltxvshvezrnmumzdprccoiekhjheuwxt; /usr/bin/python /home/user/.ansible/tmp/ansible-tmp-1527099315.31-224479822965785/setup.py"「straced」ステップが立ち往生している呼び出しを確認し、修正します:)
私の場合、それはアクセスできないネットワークドライブでした...
私は迷惑な箱をリセットすることによってこの問題を解決しました
vagrant destroy
vagrant up