この記事は「Ansible Advent Calendar 2019」24日目の記事です。
レッドハットでAnsibleのテクニカルサポートエンジニアをしている八木澤(ひよこ大佐)です。
我々テクニカルサポートエンジニアは、お客様からのお問い合わせに基づいて、提供いただいたAnsibleのログなどからおおよそのエラーの原因を推定し、調査を進めます。そういったトラブルシューティングの知識は、現場レベルで伝えられることはあっても、文章として伝えることは困難です。
しかし「Ansibleを使い始めてみたけれど、エラーがわかりにくくて何が問題なのかわからない！」という方にとっては、まさにトラブルシューティングのための情報こそが有用なのではないでしょうか。この記事では、そういった方々を対象に、日々Ansibleのテクニカルサポートをしている経験をもとに、Ansibleで確認するべきトラブルシューティングのファーストステップと、トラブルシューティングのエッセンスをご説明します。
また、これらの基本はAnsible Automationサブスクリプションをご利用のお客様で、「Red Hatサポートに問い合わせをしたいけれども、何の情報を収集すればよいのか」という指針にもなると思いますので、ぜひ参考にしていただければ幸いです。
基本的なトラブルシューティング
初回は、Ansibleのトラブルシューティングの基本からおさらいしましょう。Ansibleのトラブルシューティングは、通常のITインフラにおけるプロセスと大きな違いはありません。重要なのは、Ansibleがどのような方法でPlaybookを実行しており、どのプロセスでエラーが発生しているのか理解することです。
Ansibleのアーキテクチャを理解する
Ansibleはご存知の通り、コネクションプラグインを通じてターゲットノードに接続し、変更を実施します。Linuxノードであれば、接続後にターゲットノード上でPythonスクリプトを実行し、実行結果をコントロールノードへ返却します。
これらの動作は、対象となるターゲットノードの環境やコネクションプラグインによって異なることに注意してください。ネットワーク機器やWindowsではまた異なる手法(httpapiやwinrmなど)で接続するため、トラブルシューティングで確認するべきポイントも異なります。
Ansibleがどのようにターゲットノードに接続していて、どこで問題が発生したのか、頭の中でイメージを描いたり実際に図を描いて考えることが重要です。
トラブルシューティングのフロー
トラブルシューティングの基本的なフローは、以下の通りです。
- エラーメッセージの確認
- 事象の切り分け
- 情報収集
- 対処
エラーメッセージの確認
Ansibleで実行に失敗すると、何らかのエラーが出力されます。まず、出力されたエラーを確認します。多くの場合、エラーメッセージの中にトラブルシューティングに必要な情報が存在します。よくあるエラーメッセージとその対処法については、次回ご説明します。
また、Ansibleでは ansible-playbooks コマンド実行時に「-vvv」オプションを指定することで、より詳細な出力を確認することもできます。これらの情報をもとに、どのようなエラーが発生しているのかを把握します。
エラーメッセージを確認する際に重要なのは、「AnsibleがPlaybookを実行するプロセス」のどこで問題が発生しているのか確認することです。例えば、「UNREACHABLE」のエラーであれば、そもそもAnsibleがターゲットノードに接続することができていませんので、コントロールノードとターゲットノード間でSSH接続が可能か確認する必要があります。
Ansibleでは、さまざまな問題が発生する可能性があります。たとえばPythonのパスが通っていなかったり、パーミッションの問題、モジュールのバグ、Playbookの記述ミスなど、考え始めるとキリがありません。ですので、問題があると思われる要素を絞りこむ必要があります。
事象の切り分け
エラーメッセージを確認したら、具体的にどのような事象なのか切り分けを行います。切り分けを実施する際に確認するポイントはいくつかありますが、特に重要なのは以下のポイントです。
- 再現可能か、再現不可能か
- 環境の確認(Ansibleのバージョン、OSのバージョン、プロキシの有無等)
- 発生頻度(1度だけ発生する/たまに発生する/毎回発生)
- 発生する対象(1台だけ/すべて)
これはおそらくどのようなトラブルシューティングでも同様だと思われますが、これらの情報は問題のある箇所の特定にも役立ちます。例えばサポートに問い合わせをする際に、上記のような情報を添付すると、スムーズにトラブルシューティングを開始することが可能です。
情報収集
エラーメッセージや出力されたTracebackから、類似の事象や問題がないか確認します。単純にGoogleで検索してもいいですが、AnsibleのGitHubリポジトリのIssueを確認するのもよいでしょう。Ansibleユーザー会のコミュニティでは「qa」というSlackチャンネルがありますので、類似する問題が見つからなければそこで聞くのも手です。
Ansibleを使用しているユーザーは世界中にいますので、調べてみると同じような問題に遭遇しているユーザーがいたりします。それらの情報の内容と信憑性を確認しながら、検証を進めていきます。
検証を進めた結果、「これかもしれない」という情報が見つかる場合があります。その場合は、その裏付けとなる証拠を集める必要があります。例えば別の観点でログを確認したり、その情報とバージョンが同一であるか確認したり、場合によってはモジュールなどのコードを直接確認し、挙動を推察して仮説を立てます。そのロジックに抜け漏れがないか、仮説を補強する証拠がないか確認していきます。また、検証環境があれば実際に再現し、事象が改善するか確認します。
対処
もし原因と思わしき設定箇所や問題が判明し、「おそらくこれに間違いない」という確証を得た場合は、実際に対処します。ここで解決しなかった場合は、Ansibleの未知のバグである可能性も検討しつつ、また別の観点で仮説を立てたうえで、再度情報を収集し分析する必要があります。
これらのステップは、ドラマ・小説で刑事や探偵が事件を捜査する流れとよく似ています。証拠となるログやエラーメッセージをもとに仮説を立て、推理し、さまざまな可能性を検討しながら事件の真相解明と事件解決へと向かっていきます。しかし、仮説を立てるためにはAnsibleがどのように動作しているのか理解していなければ、そもそもの原因を推測することもできません。ですので、基本に立ち返ってAnsibleのしくみを学ぶことが何よりも大切です。
次回以降では、より具体的なAnsibleのトラブルシューティングや、トラブルシューティングに役立つ情報についてご紹介します。
