複数の Ansible インベントリをマスターする

はじめに

この実験では、Ansible で複数のインベントリを扱う方法を学びます。複数のインベントリを管理することは、異なるホストグループや別個の環境がある複雑な環境で一般的なシナリオです。複数のインベントリを定義および整理する方法、異なるインベントリからホストにアクセスする方法、および複数のインベントリ間で操作を実行する方法を学びます。

インベントリディレクトリとファイルを作成する

まず、インベントリファイルを保存するディレクトリを作成し、その後、開発環境と本番環境用の 2 つの個別のインベントリファイルを作成しましょう。

まず、/home/labex/project パスに inventory という新しいディレクトリを作成します。

mkdir -p /home/labex/project/inventory

このコマンドは、inventory という新しいディレクトリを作成します。-p オプションは、親ディレクトリが存在しない場合にも作成することを確実にします。

次に、inventory ディレクトリ内に 2 つのインベントリファイル dev_inventory.ini と prod_inventory.ini を作成します。

touch /home/labex/project/inventory/dev_inventory.ini
touch /home/labex/project/inventory/prod_inventory.ini

touch コマンドは、ファイルが存在しない場合は空のファイルを作成し、存在する場合は変更日時を更新します。

次に、これらのインベントリファイルにコンテンツを追加します。テキストエディタ（nano や好きな他のテキストエディタを使用できます）で dev_inventory.ini を開きます。

nano /home/labex/project/inventory/dev_inventory.ini

以下のコンテンツを追加します。

[dev]
localhost ansible_connection=local

ファイルを保存してエディタを終了します（nano では、Ctrl+X、次に Y、そして Enter を押すことで行えます）。

次に、prod_inventory.ini を開きます。

nano /home/labex/project/inventory/prod_inventory.ini

以下のコンテンツを追加します。

[prod]
localhost ansible_connection=local

保存してエディタを終了します。

これらのインベントリファイルでは：

[dev] と [prod] はグループ名です。これらは、論理的なグループにホストを整理するのに役立ちます。
localhost はホスト名です。同じマシン上の異なる環境をシミュレートするために localhost を使用しています。
ansible_connection=local は、Ansible に対してコマンドをローカルで実行するように指示し、マシンに SSH 接続しようとしないようにします。これは、Ansible をインストールされている同じマシンに対して実行する際に便利です。

実際のシナリオでは、通常、開発サーバーと本番サーバーには異なる IP アドレスやホスト名があり、両方とも localhost を使用するわけではありません。

複数のインベントリ用のプレイブックを作成する

このステップでは、開発インベントリと本番インベントリの両方で動作するプレイブックを作成します。Ansible では、プレイブックは、ホストに実行する一連のタスクを定義する YAML ファイルです。

まず、/home/labex/project ディレクトリに multi_env_playbook.yaml という新しいファイルを作成します。

touch /home/labex/project/multi_env_playbook.yaml

次に、multi_env_playbook.yaml ファイルをテキストエディタで開きます。シンプルなコマンドラインテキストエディタである nano を使用します。

nano /home/labex/project/multi_env_playbook.yaml

以下のコンテンツをファイルにコピーして貼り付けます。

---
- name: Demonstrate multi-environment playbook
  hosts: all
  gather_facts: no
  tasks:
    - name: Print environment type
      debug:
        msg: "This host belongs to the {{ 'production' if 'prod' in group_names else 'development' }} environment"

    - name: Show hostname
      command: hostname
      register: hostname_output

    - name: Display hostname
      debug:
        msg: "The hostname is: {{ hostname_output.stdout }}"

貼り付けた後、Ctrl + X を押してから Y を押し、最後に Enter を押して nano を保存して終了します。

このプレイブックを分解して各部分を理解しましょう。

ファイルの先頭の --- は、YAML ドキュメントの開始を示します。
name: Demonstrate multi-environment playbook は、このプレイの説明的な名前です。
hosts: all は、このプレイブックがインベントリ内のすべてのホストで実行されることを意味します。
gather_facts: no は、実行速度を上げるために事実収集フェーズをスキップします。事実収集とは、Ansible が対象ホストに関する情報を収集することです。
tasks: は、実行するタスクのリストの始まりを示します。
最初のタスクは、debug モジュールを使用してメッセージを表示します。これは、条件文を使用してホストが本番環境または開発環境に属しているかどうかを判断します。
- group_names は、現在のホストが所属するすべてのグループのリストを含む特殊な変数です。
- group_names リストに 'prod' が含まれている場合、「production」を表示し、そうでない場合は「development」を表示します。
2 番目のタスクは、hostname コマンドを実行し、その出力を hostname_output という変数に保存します。
3 番目のタスクは、debug モジュールを使用してホスト名を表示します。保存された出力には hostname_output.stdout を使用します。

開発用インベントリでプレイブックを実行する

プレイブックとインベントリを設定したので、開発インベントリを使用してプレイブックを実行しましょう。

ターミナルで以下のコマンドを実行します。

ansible-playbook -i /home/labex/project/inventory/dev_inventory.ini /home/labex/project/multi_env_playbook.yaml

このコマンドを分解しましょう。

ansible-playbook は、Ansible のプレイブックを実行するコマンドです。
-i /home/labex/project/inventory/dev_inventory.ini は、使用するインベントリファイルを指定します。-i オプションは「インベントリ」を意味します。
/home/labex/project/multi_env_playbook.yaml は、プレイブックファイルのパスです。

このコマンドは、Ansible に対して dev_inventory.ini ファイルを使用して multi_env_playbook.yaml プレイブックを実行するように指示します。

以下のような出力が表示されるはずです。

PLAY [Demonstrate multi-environment playbook] *******************************************

TASK [Print environment type] *********************************************************
ok: [localhost] => {
    "msg": "This host belongs to the development environment"
}

TASK [Show hostname] ******************************************************************
changed: [localhost]

TASK [Display hostname] ***************************************************************
ok: [localhost] => {
    "msg": "The hostname is: 66d80191e483433f91fbdca9"
}

PLAY RECAP ****************************************************************************
localhost                  : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

この出力は、以下のことを示しています。

プレイブックは開発環境で正常に実行されました。
ホストが開発環境に属していることを正しく識別しました。
ホスト名を正常に取得して表示しました。
「PLAY RECAP」は、プレイブックの実行の概要を示しています。ここで、「ok=3」は 3 つのタスクが正常に実行されたことを意味し、「changed=1」は 1 つのタスクがシステムに変更を加えたこと（hostname コマンドを実行したこと）を意味します。

本番用インベントリでプレイブックを実行する

次に、同じプレイブックを本番インベントリを使用して実行し、どのように異なる動作をするか見てみましょう。

ターミナルで以下のコマンドを実行します。

ansible-playbook -i /home/labex/project/inventory/prod_inventory.ini /home/labex/project/multi_env_playbook.yaml

このコマンドは前のコマンドと似ていますが、dev_inventory.ini の代わりに prod_inventory.ini ファイルを使用しています。

以下のような出力が表示されるはずです。

PLAY [Demonstrate multi-environment playbook] *********************************

TASK [Print environment type] *************************************************
ok: [localhost] => {
    "msg": "This host belongs to the production environment"
}

TASK [Show hostname] **********************************************************
changed: [localhost]

TASK [Display hostname] *******************************************************
ok: [localhost] => {
    "msg": "The hostname is: labex-instance"
}

PLAY RECAP ********************************************************************
localhost                  : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

今回は、プレイブックが本番環境で実行されていることを正しく識別していることに注意してください。これは、[prod] グループの下にホストを定義している本番インベントリファイルを使用しているためです。

出力の残りは、開発インベントリで見たものと似ており、同じローカルマシン上で実行しているため予想されるものです。

両方のインベントリを使用してプレイブックを実行する

最後に、両方のインベントリを同時に使用してプレイブックを実行しましょう。これにより、Ansible が複数のインベントリを同時に処理する方法を示すことができます。

ターミナルで次のコマンドを実行してください。

ansible-playbook -i /home/labex/project/inventory/dev_inventory.ini -i /home/labex/project/inventory/prod_inventory.ini /home/labex/project/multi_env_playbook.yaml

このコマンドは、複数の -i オプションを使用して両方のインベントリファイルを含んでいます。Ansible はプレイブックを実行する際にこれらのインベントリを結合します。

以下のような出力が表示されるはずです。

PLAY [Demonstrate multi-environment playbook] *******************************************************************************************************************************************************************************************************************************************

TASK [Print environment type] ***********************************************************************************************************************************************************************************************************************************************************
ok: [localhost] => {
    "msg": "This host belongs to the production environment"
}

TASK [Show hostname] ********************************************************************************************************************************************************************************************************************************************************************
changed: [localhost]

TASK [Display hostname] *****************************************************************************************************************************************************************************************************************************************************************
ok: [localhost] => {
    "msg": "The hostname is: 66d80191e483433f91fbdca9"
}

PLAY RECAP ******************************************************************************************************************************************************************************************************************************************************************************
localhost                  : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

両方のインベントリを含めたにもかかわらず、プレイブックが一度しか実行されなかったことに気づくかもしれません。これは、両方のインベントリが同じ localhost を参照しており、Ansible はデフォルトでホストを重複排除するためです。各インベントリに異なるホストが含まれていた場合、Ansible は各ユニークなホストに対してプレイブックを実行します。

環境が「production」として識別されるのは、同じホストが異なるグループを持つ複数のインベントリに表示される場合、Ansible はそのホストを所属する すべての グループに追加するためです。localhost は [dev] と [prod] の両方のグループで定義されているため、group_names 変数には 'dev' と 'prod' の両方が含まれます。プレイブックのロジックは、'prod' が group_names に含まれているかどうかを確認します。この場合、常に true になるため、インベントリの順序に関係なく「production」が表示されます。

この複数のインベントリを使用するアプローチは、環境間で共通のホストがある場合や、異なるインベントリファイルからのホストの組み合わせに対してプレイブックを実行したい場合に、実際のシナリオで非常に役立ちます。

まとめ

この実験では、複数の Ansible インベントリを管理する方法を学びました。開発環境と本番環境用に個別のインベントリファイルを作成し、両方の環境で動作するプレイブックを書き、異なるインベントリ構成を使用してプレイブックを実行しました。

この実験からの主な学びは以下の通りです。

複数のインベントリファイルの作成と整理：異なる環境用に個別のインベントリファイルを作成する方法を学びました。これは、ホストの整理と管理に役立ちます。
異なる環境に適応できるプレイブックの作成：実行環境を確認し、それに応じて動作を調整するプレイブックを作成しました。
単一および複数のインベントリを使用したプレイブックの実行：プレイブックを実行する際に 1 つまたは複数のインベントリファイルを指定する方法を学びました。これにより、ホストの柔軟なターゲティングが可能になります。
複数のインベントリに登場するホストを Ansible がどのように扱うかを理解する：Ansible がホストを重複排除し、グループ所属を決定する際にホストの最後の出現を使用することがわかりました。

これらのスキルは、異なる環境を持つ複雑なインフラストラクチャを管理する際に重要です。複数のインベントリを活用することで、異なるホストセットや環境にわたる Ansible 自動化をより良く整理し、コントロールすることができます。