複数の Ansible インベントリを管理する

AnsibleAnsibleBeginner
今すぐ練習

💡 このチュートリアルは英語版からAIによって翻訳されています。原文を確認するには、 ここをクリックしてください

はじめに

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


Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL ansible(("Ansible")) -.-> ansible/AnsibleSetupandConfigurationGroup(["Ansible Setup and Configuration"]) ansible(("Ansible")) -.-> ansible/ModuleOperationsGroup(["Module Operations"]) ansible(("Ansible")) -.-> ansible/InventoryManagementGroup(["Inventory Management"]) ansible(("Ansible")) -.-> ansible/PlaybookEssentialsGroup(["Playbook Essentials"]) ansible/AnsibleSetupandConfigurationGroup -.-> ansible/install("Ansible Setup") ansible/ModuleOperationsGroup -.-> ansible/debug("Test Output") ansible/InventoryManagementGroup -.-> ansible/groups_inventory("Define Inventory Groups") ansible/InventoryManagementGroup -.-> ansible/mutil_inventory("Multiple Inventory Sources") ansible/PlaybookEssentialsGroup -.-> ansible/playbook("Execute Playbook") subgraph Lab Skills ansible/install -.-> lab-290193{{"複数の Ansible インベントリを管理する"}} ansible/debug -.-> lab-290193{{"複数の Ansible インベントリを管理する"}} ansible/groups_inventory -.-> lab-290193{{"複数の Ansible インベントリを管理する"}} ansible/mutil_inventory -.-> lab-290193{{"複数の Ansible インベントリを管理する"}} ansible/playbook -.-> lab-290193{{"複数の Ansible インベントリを管理する"}} end

インベントリディレクトリとファイルの作成

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

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

mkdir -p /home/labex/project/inventory

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

次に、inventory ディレクトリ内に2つのインベントリファイル dev_inventory.iniprod_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 を保存して終了します。

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

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

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

  1. プレイブックは開発環境で正常に実行されました。
  2. ホストが開発環境に属していることを正しく識別しました。
  3. ホスト名を正常に取得して表示しました。
  4. 「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

両方のインベントリを含めても、プレイブックが1回だけ実行されたことに気付くかもしれません。これは、両方のインベントリが同じlocalhostを参照しており、Ansibleは既定でホストを重複排除するためです。各インベントリに異なるホストがある場合、Ansibleは各ユニークなホストに対してプレイブックを実行します。

環境は「production」と識別されます。なぜなら、本番インベントリファイルがコマンドの最後に指定されているからです。Ansibleは、グループ所属と変数値を決定する際にホストの最後の出現を使用します。-iオプションの順序を逆にすると、出力には「development」が表示されます。

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

まとめ

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

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

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

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