2019」24日目の記事です。レッドハットでAnsibleのテクニカルサポートエンジニアをしている八木澤(ひよこ大佐)です。我々テクニカルサポートエンジニアは、お客様からのお問い合わせに基づいて、提供いただいたAnsibleのログなどからおおよそのエラーの原因を推定し、調査を進めます。いったトラブルシューティングの知識は、現場レベルで伝えられることはあっても、文章として伝えることは困難です。「Ansibleを使い始めてみたけれど、エラーがわかりにくくて何が問題なのかわからない!」という方にとっては、まさにトラブルシューティングのための情報こそが有用なのではないでしょうか。この記事では、そういった方々を対象に、日々Ansibleのテクニカルサポートをしている経験をもとに、Ansibleで確認するべきトラブルシューティングのファーストステップと、トラブルシューティングのエッセンスをご説明します。Hatサポートに問い合わせをしたいけれども、何の情報を収集すればよいのか」という指針にもなると思いますので、ぜひ参考にしていただければ幸いです。基本的なトラブルシューティング初回は、Ansibleのトラブルシューティングの基本からおさらいしましょう。Ansibleのトラブルシューティングは、通常のITインフラにおけるプロセスと大きな違いはありません。重要なのは、Ansibleがどのような方法でPlaybookを実行しており、どのプロセスでエラーが発生しているのか理解することです。Ansibleのアーキテクチャを理解するAnsibleはご存知の通り、コネクションプラグインを通じてターゲットノードに接続し、変更を実施します。Linuxノードであれば、接続後にターゲットノード上でPythonスクリプトを実行し、実行結果をコントロールノードへ返却します。これらの動作は、対象となるターゲットノードの環境やコネクションプラグインによって異なることに注意してください。ネットワーク機器やWindowsではまた異なる手法(httpapiやwinrmなど)で接続するため、トラブルシューティングで確認するべきポイントも異なります。Ansibleがどのようにターゲットノードに接続していて、どこで問題が発生したのか、頭の中でイメージを描いたり実際に図を描いて考えることが重要です。トラブルシューティングのフロートラブルシューティングの基本的なフローは、以下の通りです。対処エラーメッセージの確認Ansibleで実行に失敗すると、何らかのエラーが出力されます。出力されたエラーを確認します。多くの場合、エラーメッセージの中にトラブルシューティングに必要な情報が存在します。あるエラーメッセージとその対処法については、次回ご説明します。コマンド実行時に「-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のトラブルシューティングや、トラブルシューティングに役立つ情報についてご紹介します。Hatのさいとうです。HatでOpenShiftのサポートをしているid:nekopです。各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。