Ansibleの「No inventory was parsed」エラーの解決方法

beginner🔧 Ansible2026-04-11| Ansible 2.9+, Linux (Ubuntu, CentOS, Debian), macOS, WSL2

Error Message

[WARNING]: No inventory was parsed, only implicit localhost is available [WARNING]: Could not match supplied host pattern
#ansible#インベントリ#devops#トラブルシューティング

何が起きているのか?

1時間かけてプレイブックを微調整したとします。Enterキーを押し、Webサーバーが更新されるのを期待しましたが、実行は1秒足らずで終了してしまいます。緑色の「ok」ステータスが流れる代わりに、ターミナルは黄色の警告で埋め尽くされます。Ansibleはホストが見つからないと主張し、デフォルトの localhost を使用します。そして、[webservers] のようなホストパターンが実質的に認識されないため、すべてのタスクがスキップされます。

この警告は、Ansibleが管理対象ノードのリストを探したものの、何も見つからなかった場合に表示されます。インベントリファイルが見つからないか、見つかったファイルが読み取れない、あるいは空であるかのいずれかです。障害を知らせる具体的な出力は以下の通りです:

[WARNING]: No inventory was parsed, only implicit localhost is available
[WARNING]: Could not match supplied host pattern: webservers

検索順序:Ansibleが探す場所

Ansibleはホストの場所を推測しません。厳格にハードコードされた階層に従います。ファイルを明示的に指定しない場合、以下の場所をこの順番で確認します:

  • コマンドラインで使用される -i フラグ。
  • ANSIBLE_INVENTORY 環境変数。
  • カレントディレクトリにある ansible.cfg ファイル内の inventory 設定。
  • ~/.ansible.cfg (ホームディレクトリ)内の inventory 設定。
  • /etc/ansible/hosts にあるグローバルデフォルト。

これらすべてのチェックで何も見つからない場合、Ansibleはリモートインフラストラクチャを諦め、デフォルトでローカルマシンを対象にします。

クイックフィックス:インベントリフラグを使用する

軌道に乗せるための最も早い方法は、Ansibleに使用するファイルを正確に伝えることです。-i (inventory)フラグを使ってパスを指定します。例えば、ファイル名が production.ini の場合、次のようにプレイブックを実行します:

ansible-playbook -i production.ini site.yml

これはアドホックコマンドでも機能します。12台のサーバーの接続を一度にテストするには、次のように実行します:

ansible all -i production.ini -m ping

恒久的な対策:プロジェクトレベルの設定

手動でのフラグ指定は面倒で、タイポ(打ち間違い)の原因にもなります。長期的に解決するには、プロジェクトのルートフォルダ(プレイブックと同じ場所)に ansible.cfg ファイルを作成します。これにより、Ansibleは常に最初にローカルフォルダを探すようになります。

ansible.cfg に以下の行を追加してください:

[defaults]
inventory = ./hosts.ini
host_key_checking = False

これで、単に ansible-playbook site.yml を実行するだけで、余計な入力なしに自動的に hosts.ini が読み込まれるようになります。

隠れた問題のトラブルシューティング

パスを正しく設定してもエラーが続く場合は、次の3つの問題のいずれかが原因である可能性があります:

1. YAMLフォーマットの罠

YAMLは非常に厳格なことで知られています。2つのスペースの代わりにタブ文字が1つあるだけで、hosts.yaml ファイルは壊れてしまいます。興味深いことに、Ansibleは常に「Syntax Error」を表示するとは限りません。ファイルのパースに失敗し、黙って無視することもあります。

構造を変換して確認してみてください。私はよく YAML ↔ JSON コンバーター を使って、構造が正しくマッピングされているか確認します。JSON出力が入れ子になっていたり壊れていたりする場合、YAMLのインデントが間違っています。

2. グループ名の不一致

Ansibleがファイルを読み込めても、指定された特定のグループが見つからないことがあります。インベントリ内のグループ名が、プレイブックの hosts: 行と一致しているか確認してください。標準的な hosts.ini は以下のようになります:

[webservers]
192.168.1.10
192.168.1.11

[dbservers]
10.0.0.5

3. Linuxの権限

Ansibleがファイルを使用するには、そのファイルを読み取る必要があります。ファイルを root として作成し、プレイブックを標準ユーザーとして実行している場合、Ansibleがブロックされる可能性があります。ls -l hosts.ini を実行して確認してください。権限が -rw------- のようになっており、自分が所有者でない場合は、chmod 644 hosts.ini を実行して読み取り可能にする必要があります。

検証:動作確認の方法

接続テストのためだけに大規模なプレイブックを実行して時間を無駄にしないでください。ansible-inventory ツールを使用して、Ansibleが内部で何を認識しているかを正確に確認しましょう。

生のリストを表示するには、次を実行します:

ansible-inventory --list -y

より分かりやすいツリー形式で表示するには、次を使用します:

ansible-inventory --graph

出力にホスト名やIPアドレスが表示されれば、準備完了です。@all@ungrouped だけが表示され、その下にデータがない場合は、Ansibleはまだファイルを無視しています。

まとめチェックリスト

  • ファイル名: hosts.inihosts.yml、あるいは単に hosts ですか?設定を実際の名前と一致させてください。
  • パス指定: -i 経由でパスを指定しましたか?それとも ansible.cfg で定義しましたか?
  • グループ名: [group_name] はプレイブックの hosts: 行と一致していますか?
  • 構文: YAMLを使用している場合、隠れたタブ文字やインデントのエラーはありませんか?

Related Error Notes