紹介
構成管理システムは、管理者や運用チームが多数のサーバーを制御するプロセスを効率化するために設計されています。これらのシステムは、1つの中央の場所から自動化された方法で多くの異なるシステムを制御できるようにします。
Linuxシステム向けには、ChefやPuppetなどの人気のある構成管理ツールがたくさんありますが、これらは多くの人々が望むまたは必要とするよりも複雑な場合があります。Ansibleは、ノードに特別なソフトウェアのインストールを必要としないアーキテクチャを提供するため、これらの選択肢の優れた代替手段です。自動化タスクを実行するためにSSHを使用し、プロビジョニングの詳細を定義するためにYAMLファイルを使用します。
このガイドでは、Ubuntu 20.04サーバーにAnsibleをインストールし、このソフトウェアの使用方法の基本について説明します。構成管理ツールとしてのAnsibleの高レベルな概要については、Ansibleを使用した構成管理の紹介を参照してください。
前提条件
このチュートリアルに従うには、以下が必要です：
-
1つのAnsibleコントロールノード: Ansibleコントロールノードは、SSH経由でAnsibleホストに接続して制御するために使用するマシンです。Ansibleコントロールノードは、ローカルマシンまたはAnsibleを実行するために専用のサーバーであることがありますが、このガイドではコントロールノードがUbuntu 20.04システムであることを前提としています。コントロールノードには次のものがあることを確認してください:
-
1つ以上のAnsibleホスト：Ansibleホストは、Ansibleコントロールノードが自動化される構成にされた任意のマシンです。このガイドでは、AnsibleホストがリモートのUbuntu 20.04サーバーであることを前提としています。各Ansibleホストには、次のものがあることを確認してください：
- AnsibleコントロールノードのSSH公開キーが、システムユーザーの
authorized_keysに追加されていること。このユーザーは、rootまたはsudo特権を持つ通常のユーザーであることができます。これを設定するには、Ubuntu 20.04でSSHキーを設定する方法のステップ2に従うことができます。
- AnsibleコントロールノードのSSH公開キーが、システムユーザーの
ステップ1 — Ansibleのインストール
サーバーインフラストラクチャを管理する手段としてAnsibleを使用するには、AnsibleソフトウェアをAnsibleコントロールノードとして機能するマシンにインストールする必要があります。
コントロールノードから、次のコマンドを実行して公式プロジェクトのPPA（個人パッケージアーカイブ）をシステムのソースリストに含めます：
- sudo apt-add-repository ppa:ansible/ansible
PPAの追加を受け入れるようにプロンプトが表示されたら、ENTERを押してください。
次に、新しく含まれたPPAに利用可能なパッケージをシステムのパッケージインデックスが認識するように、システムのパッケージインデックスを更新します：
- sudo apt update
この更新後、以下のコマンドでAnsibleソフトウェアをインストールできます：
- sudo apt install ansible
Ansibleコントロールノードには、ホストを管理するために必要なすべてのソフトウェアが含まれています。次に、ホストをコントロールノードのインベントリファイルに追加して、それらを制御できるようにする方法について説明します。
ステップ2 — インベントリファイルの設定
インベントリファイルには、Ansibleで管理するホストに関する情報が含まれています。インベントリファイルには、1つから数百のサーバーを含めることができ、ホストはグループやサブグループに整理することができます。インベントリファイルは、特定のホストやグループにのみ有効な変数を設定するためにもよく使用されます。これらの変数は、プレイブックやテンプレート内で使用されます。また、一部の変数はプレイブックの実行方法に影響を与える場合もあります。たとえば、すぐに見るansible_python_interpreter変数のようにです。
デフォルトのAnsibleインベントリの内容を編集するには、お好みのテキストエディタを使用して、Ansibleコントロールノードの/etc/ansible/hostsファイルを開きます:
- sudo nano /etc/ansible/hosts
注意: Ansibleは通常、etc/ansible/hostsにデフォルトのインベントリファイルを作成しますが、必要に応じて任意の場所にインベントリファイルを作成することができます。この場合、Ansibleコマンドやプレイブックを実行する際に、-iパラメータでカスタムインベントリファイルのパスを指定する必要があります。プロジェクトごとにインベントリファイルを使用することは、誤ってサーバーグループでプレイブックを実行するリスクを最小限に抑えるための良い方法です。
Ansibleインストールに含まれるデフォルトのインベントリファイルには、インベントリの設定に関する参考例がいくつか含まれています。次の例では、[servers]という名前のグループが定義されており、それぞれカスタムエイリアスで識別される異なる3つのサーバーが含まれています: server1, server2, および server3。IPアドレスは、AnsibleホストのIPアドレスに置き換えてください。
[servers]
server1 ansible_host=203.0.113.111
server2 ansible_host=203.0.113.112
server3 ansible_host=203.0.113.113
[all:vars]
ansible_python_interpreter=/usr/bin/python3
all:vars サブグループは、このインベントリに含まれるすべてのホストに対して有効になる ansible_python_interpreter ホストパラメータを設定します。 このパラメータは、リモートサーバーが /usr/bin/python（Python 2.7）ではなく、/usr/bin/python3 Python 3 実行可能ファイルを使用することを保証します。これは最近のUbuntuバージョンには存在しないためです。
作業が完了したら、CTRL+Xを押してファイルを保存して閉じ、変更を確認するためにYとENTERを押します。
インベントリを確認する場合はいつでも、次のコマンドを実行できます：
- ansible-inventory --list -y
出力は次のようになりますが、それぞれのサーバーインフラストラクチャはインベントリファイルで定義されたものに置き換えられます：
Outputall:
children:
servers:
hosts:
server1:
ansible_host: 203.0.113.111
ansible_python_interpreter: /usr/bin/python3
server2:
ansible_host: 203.0.113.112
ansible_python_interpreter: /usr/bin/python3
server3:
ansible_host: 203.0.113.113
ansible_python_interpreter: /usr/bin/python3
ungrouped: {}
インベントリファイルの設定が完了したので、Ansibleホストへの接続をテストするために必要なすべての準備が整いました。
ステップ 3 — 接続のテスト
サーバーを含めたインベントリファイルを設定した後、Ansibleがこれらのサーバーに接続してSSH経由でコマンドを実行できるかどうかを確認する時が来ました。
このガイドでは、通常、新しく作成されたサーバーにはデフォルトで root アカウントしかないため、Ubuntu を使用します。既存のAnsibleホストにすでに通常のsudoユーザーが作成されている場合は、代わりにそのアカウントを使用することをお勧めします。
-u引数を使用してリモートシステムのユーザーを指定できます。指定しない場合、Ansibleは制御ノード上の現在のシステムユーザーとして接続しようとします。
ローカルマシンまたはAnsible制御ノードから、次のコマンドを実行します：
- ansible all -m ping -u root
このコマンドは、デフォルトのインベントリからすべてのノードに対して、rootとして接続し、Ansibleの組み込みのpingモジュールを使用して接続テストを実行します。 pingモジュールは以下をテストします：
- ホストがアクセス可能かどうか；
- 有効なSSH認証情報を持っているかどうか；
- ホストがPythonを使用してAnsibleモジュールを実行できるかどうか。
次のような出力が表示されるはずです：
Outputserver1 | SUCCESS => {
"changed": false,
"ping": "pong"
}
server2 | SUCCESS => {
"changed": false,
"ping": "pong"
}
server3 | SUCCESS => {
"changed": false,
"ping": "pong"
}
これが最初にこれらのサーバーにSSH経由で接続する場合、Ansibleを介して接続するホストの信頼性を確認するよう求められます。プロンプトが表示されたら、yesと入力してENTERキーを押して確認してください。
ホストから"pong"の応答を受け取ると、そのサーバーでAnsibleコマンドとプレイブックを実行する準備ができたことを意味します。
注意: サーバーから正常なレスポンスを受け取れない場合は、異なる接続オプションでAnsibleコマンドを実行する方法についての詳細については、Ansibleチートシートガイドを参照してください。
ステップ4 — アドホックコマンドの実行（オプション）
Ansibleコントロールノードがホストと通信できることを確認した後、サーバー上でアドホックコマンドとPlaybookを実行できます。
SSH経由でリモートサーバーで通常実行するコマンドは、インベントリファイルで指定したサーバーでAnsibleで実行できます。たとえば、次のようにすべてのサーバーのディスク使用状況を確認できます：
- ansible all -a "df -h" -u root
Output
server1 | CHANGED | rc=0 >>
Filesystem Size Used Avail Use% Mounted on
udev 3.9G 0 3.9G 0% /dev
tmpfs 798M 624K 798M 1% /run
/dev/vda1 155G 2.3G 153G 2% /
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/vda15 105M 3.6M 101M 4% /boot/efi
tmpfs 798M 0 798M 0% /run/user/0
server2 | CHANGED | rc=0 >>
Filesystem Size Used Avail Use% Mounted on
udev 2.0G 0 2.0G 0% /dev
tmpfs 395M 608K 394M 1% /run
/dev/vda1 78G 2.2G 76G 3% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
/dev/vda15 105M 3.6M 101M 4% /boot/efi
tmpfs 395M 0 395M 0% /run/user/0
...
ハイライトされたコマンドdf -hは、任意のコマンドで置き換えることができます。
また、アドホックコマンドを介してAnsibleモジュールを実行することもできます。接続をテストするためにpingモジュールで行ったのと同様に、最新バージョンのvimをインストールするためにaptモジュールをすべてのサーバーに使用する方法を示します：
- ansible all -m apt -a "name=vim state=latest" -u root
Ansibleコマンドを実行する際に、個々のホスト、グループ、およびサブグループをターゲットにすることもできます。たとえば、serversグループ内のすべてのホストのuptimeを確認する方法は次のとおりです：
- ansible servers -a "uptime" -u root
複数のホストをコロンで区切って指定できます。
- ansible server1:server2 -m ping -u root
Ansibleリファレンスガイドを確認して、サーバーセットアップを自動化する際のAnsibleの使用方法について詳細を知ることができます。
結論
このガイドでは、Ansibleをインストールし、Ansibleコントロールノードからのアドホックコマンドを実行するためのインベントリファイルを設定しました。
インフラストラクチャを中央のAnsibleコントローラーマシンから接続および制御できることを確認したら、これらのホスト上で任意のコマンドやプレイブックを実行できます。
Ansibleの使用方法に関する詳細は、Ansibleチートシートガイドを参照してください。