【付録】Ansible現場の知恵袋：トラブルシューティング集＆AWX入門〜自動化のその先へ〜

「動かない！」と叫ぶ前に。プロが教える転ばぬ先の杖。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
全8回の「Ansible中級者講座」、お疲れ様でした！
皆さんはもう、変数やロールを駆使して、複雑な構成管理を自動化できるスキルを身につけました。

しかし、実際の現場に出ると、教科書通りにはいかない事態に必ず直面します。

• 「SSHがつながらなくて、そもそもPlaybookが始まらない」
• 「サーバーが100台を超えたら、実行完了まで1時間かかるようになった」
• 「自分以外のメンバーがPlaybookを実行できなくて、結局属人化している」

今回は「番外編」として、こうした現場のリアルな悩みを解決するための「トラブルシューティング集」と「パフォーマンス・チューニング」、そしてGUIでAnsibleを管理する「AWX」について解説します。

本記事は、これまでの連載を補完し、より実践的な運用を可能にするための「虎の巻」です。

---

1. トラブルシューティング逆引き辞典

Ansibleを使っていて遭遇するエラーの9割は、実は同じ原因です。
ここでは、頻出エラーとその解決策をパターン別に紹介します。

Case 1: SSH接続エラー (Permission denied)

エラーメッセージ：

fatal: [server1]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password)."}

原因：
SSHの鍵認証に失敗しています。公開鍵がサーバー側に登録されていないか、秘密鍵のパスが間違っています。

解決策：

1. 手動でSSHできるか確認する。
   ssh user@server1 -i ~/.ssh/id_rsa
2. Ansibleコマンドで鍵を指定してみる。
   ansible all -m ping --private-key=~/.ssh/id_rsa
3. inventory.ini や ansible.cfg に正しい秘密鍵のパスを記述する。

Case 2: ホストキー検証エラー (Host key verification failed)

エラーメッセージ：

fatal: [server1]: UNREACHABLE! => {"changed": false, "msg": "Host key verification failed."}

原因：
初めて接続するサーバーか、サーバーのOSを入れ直して指紋（Fingerprint）が変わった場合に発生します。SSHのセキュリティ機能による遮断です。

解決策：

開発環境や、頻繁に作り直すクラウド環境では、このチェックを無効化するのが一般的です。
ansible.cfg に以下を追記します。

[defaults]
host_key_checking = False

Case 3: 権限昇格エラー (Missing sudo password)

エラーメッセージ：

fatal: [server1]: FAILED! => {"msg": "Missing sudo password"}

原因：
become: true を指定しているのに、sudo実行時にパスワードを求められています。
（パスワードなしsudoが許可されていない環境）

解決策：

1. 実行時に --ask-become-pass (または -K) オプションを付けて、パスワードを入力する。
2. サーバー側の visudo 設定で、ansible実行ユーザーに対して NOPASSWD: ALL を設定する（推奨）。

Case 4: Pythonが見つからない (Discover failed)

エラーメッセージ：

fatal: [server1]: FAILED! => {"msg": "/usr/bin/python: not found"}

原因：
ターゲットサーバーにPythonがインストールされていないか、パスが特殊な場所（Python 3しか入っていない環境でPython 2を探しているなど）にあります。

解決策：

インベントリファイルで、使用するPythonインタープリタを明示的に指定します。

[webservers]
server1 ansible_python_interpreter=/usr/bin/python3

Case 5: YAMLの構文エラー (Syntax Error)

エラーメッセージ：

ERROR! We were unable to read either as JSON nor YAML...

原因：
インデント（スペースの数）がずれているか、コロン : の後にスペースがない場合がほとんどです。

解決策：

VS Codeなどのエディタに「YAML」や「Ansible」の拡張機能を入れましょう。
保存時に自動で構文チェックをしてくれるため、この種のエラーで悩む時間をゼロにできます。

---

2. 実行速度を爆速化するパフォーマンス・チューニング

サーバー台数が数十台を超えてくると、Ansibleの実行時間が目に見えて遅くなってきます。
デフォルト設定は「安全重視」のため、少しチューニングするだけで劇的に速くなります。

2-1. 並列実行数 (forks) を増やす

Ansibleはデフォルトで「5台ずつ」並列処理します（forks=5）。
サーバーが100台あると、20回に分けて実行されるため時間がかかります。

マシンスペックにもよりますが、これを増やすだけで単純に処理速度が上がります。
ansible.cfg を編集します。

[defaults]
# デフォルトの5から増やす（CPUコア数やメモリに応じて調整）
forks = 20

2-2. SSHのパイプライン化 (pipelining)

Ansibleは通常、1つのタスクを実行するのに「ファイルを転送→実行→削除」という手順で複数回SSH接続を行います。
pipelining = True にすると、SSHセッションを維持したまま処理を流し込むため、接続オーバーヘッドが激減します。

ansible.cfg に以下を追記します。

[ssh_connection]
pipelining = True

2-3. Facts収集の無効化 (gather_facts)

第1回で解説したFacts（OS情報などの収集）は便利ですが、毎回全サーバーに対して実行されるため時間がかかります。
Facts変数を使っていないPlaybookであれば、これをスキップすることで数秒〜数十秒の短縮になります。

Playbookの冒頭に記述します。

- name: 高速化設定の例
  hosts: all
  gather_facts: false  # これを追加
  tasks:
    ...

---

3. チーム運用の切り札「Ansible AWX」入門

「コマンドライン(CUI)は難しい」「誰がいつ実行したか履歴を残したい」「定期的に自動実行したい」。
こうしたチーム運用の課題を解決するのが、Red Hat社が提供する「Ansible Automation Platform」のアップストリーム版（OSS版）である「AWX」です。

AWXでできること

• Web GUIでの操作： ブラウザからボタン一つでPlaybookを実行できます。非エンジニアでも操作可能です。
• 権限管理： 「Aさんは閲覧のみ」「Bさんは実行可能」といった細かい権限設定ができます。
• 履歴管理： 「誰が、いつ、どのPlaybookを実行し、結果はどうだったか」が全てログに残ります。
• スケジュール実行： 「毎晩深夜2時にパッチ適用のPlaybookを流す」といったジョブ管理が可能です。
• シークレット管理： 秘密鍵やパスワードをAWX内部に保存し、ユーザーに見せずに利用させることができます。

Ansible Tower と AWX の違い

• AWX: 無償のオープンソース版。最新機能がいち早く入るが、サポートはない。更新頻度が高い。
• Ansible Automation Platform (旧 Tower): 有償の商用製品版。動作が安定しており、Red Hat社のサポートが受けられる。

まずはAWXで使い勝手を試し、企業での本格導入なら有償版を検討するのが良いでしょう。

---

4. AWXの簡易構築（Docker版）

かつてAWXの構築は非常に困難でしたが、現在はKubernetes上での動作が標準となっています。
しかし、学習用としては少々ハードルが高いため、ここでは有志が開発しているDocker Compose版の簡易構築ツールを紹介します。

※あくまで検証用として利用してください。

4-1. 必要要件

• メモリ: 4GB以上（推奨8GB）
• CPU: 2コア以上
• Docker および Docker Compose がインストールされていること

4-2. 構築手順

GitHubから構築用リポジトリをクローンして起動します。

# リポジトリのクローン
git clone https://github.com/ansible/awx.git
cd awx

# 以前はDocker Composeでの直接起動が公式サポートされていましたが、
# 現在は「AWX Operator」を使ったKubernetes展開が標準です。
# 簡易的に試すなら「minikube」等を使うのが近道です。

…と、以前は簡単に docker-compose up できたのですが、現在のAWX（バージョン18以降）はKubernetesネイティブなアーキテクチャに変更されました。
そのため、「とりあえず試す」ハードルが少し上がっています。

そこでおすすめなのが、「AWX Operator」を使ったMinikube上へのデプロイです。
詳細は公式ドキュメントを参照していただきたいですが、大まかな流れは以下の通りです。

1. Linuxマシンに minikube をインストールする。
2. minikube start でローカルKubernetesクラスタを起動する。
3. AWX Operator（インストーラーのようなもの）を適用する。
4. AWX本体の定義ファイル（YAML）を適用する。

起動すると、ブラウザからAWXのログイン画面にアクセスできるようになります。

[ログイン画面のイメージ]
ユーザー名: admin
パスワード: (インストール時に設定したもの)

ログイン後は、「インベントリ」を登録し、「プロジェクト（Gitリポジトリ）」を連携し、「ジョブテンプレート（実行設定）」を作成すれば、すぐにGUIからの自動化ライフが始まります。

---

5. さらなる高みへ：おすすめ学習リソース

Ansibleの世界はまだまだ奥が深いです。
さらにスキルアップするためのリソースを紹介します。

公式ドキュメント（英語/日本語）

Ansibleのドキュメントは非常に充実しています。
特に「Module Index」は必読です。「こんなモジュールないかな？」と思ったらまずここを探しましょう。
Googleで「ansible [やりたいこと]」と検索するよりも、「ansible [モジュール名]」で公式を読むほうが確実です。

Ansible Galaxy

第5回でも紹介しましたが、世界中のエンジニアが作ったロールが公開されています。
自分で書く前に、「Nginx role」などで検索してみましょう。
「★（スター）」が多いロールのソースコードを読むことは、最高の勉強になります。

Molecule（分子）

Playbookの「テスト」を自動化するフレームワークです。
「Dockerコンテナを立ち上げ、Playbookを実行し、正しく設定されたかテストし、コンテナを破棄する」という一連の流れを自動化できます。
CI/CDパイプラインにAnsibleを組み込むなら必須のスキルです。

---

総まとめ：自動化の旅は終わらない

今回の付録記事も含め、全9回の長きにわたりお付き合いいただきありがとうございました。

皆さんは、「変数」や「ロール」といった概念を理解し、「Ansible Vault」でセキュリティを守り、「デバッグ」で問題を解決し、さらには「AWX」という運用の出口まで知ることができました。
これはもう、立派な「自動化エンジニア」のスキルセットです。

しかし、技術は日々進化します。
コンテナオーケストレーションの「Kubernetes」、クラウド構築の「Terraform」、監視の「Prometheus」など、Ansibleと組み合わせることでさらに強力になるツールは山ほどあります。

この連載が、皆さんのエンジニアライフにおける「自動化への入り口」となり、よりクリエイティブで楽しい仕事ができるようになることを心から願っています。

それでは、また新しい技術の講座でお会いしましょう！
LINUX工房の「リナックス先生」でした。