Ansibleは非常に強力なツールであり、サーバー、クラウド、ネットワーク、コンテナーなど、さまざまなプラットフォームを自動化できます。
多くの場合、既存の役割とコレクションを再利用するだけで、必要なものを自動化できます。
また、プレイブックで使用できるモジュールはたくさんあります。
しかし、より複雑なプレイブックの開発とテストを開始すると、最終的にはいくつかのトラブルシューティング方法が必要になります。のようなもの：
- Ansibleタスクのフローを確認します。
- 変数のデータ型を確認します。
- 特定の時点で一時停止して、それらの値を検査することもできます。
この記事で説明するヒントの一部は、コマンドラインを介したAnsibleの実行にのみ適用されます。その他は、AnsibleTowerから実行する場合にも有効です。
1。 Ansibleの環境とパラメーター
プレイブックで期待どおりに動作しない理由を調査する必要がある場合は、通常、Ansible環境を確認することから始めることをお勧めします。
実行しているAnsibleバイナリとPythonのバージョンとパスはどれですか？
プレイブックに必要なOSパッケージまたはPythonモジュールを追加した場合、Ansibleインタープリターはそれらを「認識」していますか？
この基本情報は、さまざまな方法で取得できます。コマンドラインから、ansible --versionを実行します コマンド。
❯ ansible --version
ansible 2.9.10
config file = /etc/ansible/ansible.cfg
configured module search path = ['/home/admin/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python3.6/site-packages/ansible
executable location = /usr/bin/ansible
python version = 3.6.8 (default, Mar 18 2021, 08:58:41) [GCC 8.4.1 20200928 (Red Hat 8.4.1-1)]
ansible-playbookなどの他のAnsibleコマンドを実行しても、同じ情報を取得できます またはansible-config --versionを使用 オプション。
Ansible Towerでは、ジョブテンプレートがVERBOSITY 2（より詳細）以上で実行された場合にこの情報が表示されます。
AnsibleおよびPythonバイナリのバージョンと場所に加えて、実行でansible.cfg が使用されているかどうかなど、モジュールに使用されるパスを再確認することをお勧めします。 デフォルトではない（つまり、/etc/ansible/ansible.cfgではないファイル） 。
カスタムのansible.cfgからのオプションを調査する場合 ファイルの場合、コマンドラインから次のコマンドを実行できます。
❯ ansible-config dump --only-changed
DEFAULT_BECOME(/home/admin/ansible/ansible.cfg) = True
DEFAULT_BECOME_USER(/home/admin/ansible/ansible.cfg) = root
DEFAULT_FORKS(/home/admin/ansible/ansible.cfg) = 10
DEFAULT_HOST_LIST(/home/admin/ansible/ansible.cfg) = ['/home/admin/ansible/inventory']
DEFAULT_ROLES_PATH(/home/admin/ansible/ansible.cfg) = ['/home/admin/ansible/roles']
HOST_KEY_CHECKING(/home/admin/ansible/ansible.cfg) = False 名前が示すように、これは異なるパラメータを一覧表示します デフォルトのものから。
2。詳細モードでの実行
プレイブックをデバッグモードで実行することは、タスクと変数で何が起こっているかについての詳細を取得するための次のステップになる可能性があります。
コマンドラインから、-vを追加できます （または-vv 、-vvv 、-vvvv 、-vvvvv ）。最高の冗長性レベルは情報が多すぎる場合があるため、必要なものが得られるまで、複数回の実行で徐々に増やしていく方がよいでしょう。
レベル4は接続の問題のトラブルシューティングに役立ち、レベル5はWinRMの問題に役立ちます。
Towerから、 VERBOSITYを選択できます ジョブテンプレート定義からのレベル。
注 ：詳細情報はトラブルシューティングにのみ役立つため、状況を解決した後は、デバッグモードを無効にすることを忘れないでください。
また、デバッグモードでは、no_logを使用しない限り、特定の変数（パスワードなど）の値が表示されます。 タスクのオプションなので、完了したら出力を消去します。
3。デバッグを使用して変数を表示する
どこについて良いアイデアがある場合 問題は、より外科的なアプローチを使用できることです。表示する必要のある変数のみを表示します。
(...)
- name: Display the value of the counter
debug:
msg: "Counter={{ counter }} / Data type={{ counter | type_debug }}"
(...)
TASK [Display the value of the counter] ****************************************************************************
ok: [node1] => {
"msg": "Counter=42 / Data type=AnsibleUnicode"
}
これ カウンターをインクリメントできなかったのはそのためです。フィルタtype_debug データ型がテキストであることを示しています intではありません 思った通り。
[次のこともお勧めします：AnsibleforLinuxシステム管理者向けクイックスタートガイド]
4。 varsが正しいコンテンツとデータ型を持っていることを確認する
アサートを使用できます モジュールを使用して、変数に期待されるコンテンツ/タイプがあることを確認し、問題が発生した場合にタスクを失敗させます。
次のプレイブックはこれを示しています：
---
- name: Assert examples
hosts: node1
gather_facts: no
vars:
var01: 13
tasks:
- debug:
msg: "Parameter 01 is {{ (param01 | type_debug) }}"
- name: Make sure that we have the right type of content before proceeding
assert:
that:
- "var01 is defined"
- "(var01 | type_debug) == 'int' "
- "param01 is defined "
- "(param01 | type_debug) == 'int' " コマンドラインからプレイブックを実行する場合、なし 追加の変数を提供する：
❯ ansible-playbook xassert.yml
PLAY [Assert examples] ****************************************************************************
TASK [debug] ****************************************************************************
ok: [node1] => {
"msg": "Parameter 01 is AnsibleUndefined"
}
TASK [Make sure that we have the right type of content before proceeding] ****************************************************************************
fatal: [node1]: FAILED! => {
"assertion": "param01 is defined ",
"changed": false,
"evaluated_to": false,
"msg": "Assertion failed"
}
PLAY RECAP ****************************************************************************
node1 : ok=1 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 コマンドラインからプレイブックを実行する場合、 with extra-var：
❯ ansible-playbook xassert.yml -e "param01=99"
PLAY [Assert examples] ****************************************************************************
TASK [debug] ****************************************************************************
ok: [node1] => {
"msg": "Parameter 01 is str"
}
TASK [Make sure that we have the right type of content before proceeding] ****************************************************************************
fatal: [node1]: FAILED! => {
"assertion": "(param01 | type_debug) == 'int' ",
"changed": false,
"evaluated_to": false,
"msg": "Assertion failed"
}
PLAY RECAP ****************************************************************************
node1 : ok=1 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 データ型がstrとして表示されます 驚きましたが、ここに説明と解決策があります。
また、Towerから同じプレイブックを実行し、パラメーターをextra-varsとして渡すか、調査のフィールドとして渡す場合、パラメーターのデータ型は intになります。 。
はい、難しい場合があります...しかし、何を探すべきかを知っていれば、これらの「機能」は問題になりません。
5。ファクトと変数のリストを取得する
インベントリに変数を定義したか（ホストやグループ用）、プレイブックの実行中に追加の変数を作成して割り当てたかにかかわらず、ある時点でそれらの値を調べると役立つ場合があります。
---
- name: vars
hosts: node1,node2
tasks:
- name: Dump vars
copy:
content: "{{ hostvars[inventory_hostname] | to_nice_yaml }}"
dest: "/tmp/{{ inventory_hostname }}_vars.txt"
delegate_to: control
- name: Dump facts
copy:
content: "{{ ansible_facts | to_nice_yaml }}"
dest: "/tmp/{{ inventory_hostname }}_facts.txt"
delegate_to: control これにより、変数とファクト（ファクトを収集している場合）が個別のファイルに保存され、分析できるようになります。
コマンドラインを実行するために、タスクをコントロールホスト（localhost）に委任して、ファイルを各ノードに個別に保存するのではなく、ファイルをローカルに保存しました。 Towerから実行している場合は、1つも選択する必要があります。 ファイルを保存するサーバー（ターゲットノードが1つだけで、そこでファイルを分析してもかまわない場合を除く）。
6。コマンドラインからのトラブルシューティングのためのタスクデバッガーの使用
Ansibleデバッガーを使用して、プレイブックをステップバイステップモードで実行し、変数と引数の内容をインタラクティブに調べることもできます。
さらに、変数の値をオンザフライで変更して、実行を続行することもできます。
デバッガーは、次の例のように、タスクレベルまたは再生レベルで有効にできます。
---
- name: Example using debugger
hosts: localhost
gather_facts: no
vars:
radius: "5.3"
pi: "3.1415926535"
debugger: on_failed
tasks:
- name: Calculate the area of a circle
debug:
msg:
- "Radius.............: {{ radius }}"
- "pi................: {{ pi }}"
- "Area of the circle: {{ (pi * (radius * radius)) }}" ネタバレ注意：変数を文字列として定義しました。これにより、計算を実行しようとすると明らかにエラーが発生します。
❯ ansible-playbook xdebugger.yml
PLAY [Example using debugger] ****************************************************************************
TASK [Calculate the area of a circle] ****************************************************************************
fatal: [localhost]: FAILED! => {"msg": "Unexpected templating type error occurred on (Area of the circle: {{ (pi * (radius * radius)) }}): can't multiply sequence by non-int of type 'AnsibleUnicode'"}
[localhost] TASK: Calculate the area of a circle (debug)> p task_vars['pi']
'3.1415926535'
[localhost] TASK: Calculate the area of a circle (debug)> p task_vars['radius']
'5.3'
[localhost] TASK: Calculate the area of a circle (debug)> task_vars['pi']=3.1415926535
[localhost] TASK: Calculate the area of a circle (debug)> task_vars['radius']=5.3
[localhost] TASK: Calculate the area of a circle (debug)> p task_vars['radius']
5.3
[localhost] TASK: Calculate the area of a circle (debug)> task_vars['pi']=3.1415926535
[localhost] TASK: Calculate the area of a circle (debug)> redo
ok: [localhost] => {
"msg": [
"Radius............: 5.3",
"pi................: 3.1415926535",
"Area of the circle: 88.247337636815"
]
}
PLAY RECAP ****************************************************************************
localhost : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ここで何が起こったのか：
- 最初は、int以外の変数について不平を言って、タスクが失敗しました。
- デバッガーが呼び出されました。
- プリントを使用しました（ p ）変数の値を表示するコマンド。
- この場合、問題はデータ型にあることはわかっていましたが、値が正しいと考えることができました（値の前後の引用符に注意を払わない場合）。
- 後で、変数の内容を更新して、変数に番号を割り当てました。
- 次に、
redoを使用しました 新しい値でタスクを再実行するコマンドを実行すると、正常に終了しました。
誰もいないことがわかっているので、これは単純なシナリオでした。 円の面積を計算するために実際にAnsibleを使用します。しかし、より複雑な状況では、長いプレイブックの実行の途中で変数の内容を見つけて、最初からやり直すことなくその時点から続行できると便利な場合があります。
[この無料の電子書籍を入手する：ダミーのKubernetesクラスターを管理する。 ]
まとめ
トラブルシューティングオプションの優れた武器を組み込むと、Ansibleプレイブックの問題をより迅速に特定するのに役立ちます。調査の場所によっては、特定の方法がより適しています。
たとえば、何の感覚をつかもうとしているだけの場合 間違っている可能性があり、どこで 、デバッグレベルを徐々に上げることから始めたいと思うかもしれません。
問題の場所がよくわかったら、デバッグレベルを下げて（目の前の出力が少なくなるように）、分析しているタスクに固有のオプションを使用すると便利な場合があります。
Ansibleのトラブルシューティングは難しい場合がありますが、組み込みの問題解決ツールと組み合わせた系統的なアプローチを使用すると、自分ではるかに簡単にすることができます。 Ansible環境とタスクフローを確認してから、適切なデータタイプを探し、最後に各タスクの一時停止とステップ実行を検討してください。