クラウドの普及とともにインフラストラクチャ、なかでもサーバーではクラウド以前と比べて要求される構築期間が大幅に短くなっている。
サーバー構築の高速化が求められるなか、それを手助けする構成管理ツールは大きな関心を集めている。そのなかでAnsibleは今、最も利用されているインフラ構成管理ツールの１つである。
本稿では、Ansibleを基本から知りたいという読者向けに、Ansibleの概要や利用方法、他の構成管理ツールとの比較、利用事例などをコンパクトにまとめて紹介する。
Ansibleとは何か
Ansibleはオープンソースの構成管理とOSやソフトウェアなどの設定作業を自動化するツールであり、主にLinuxやWindowsなどの管理に利用されている。
クラウド環境やコンテナ環境でも管理可能なモジュールは提供されているが、Ansibleは基本的には管理者が手動で実行・管理していたOSコマンドやOS上の設定ファイルを自動で管理する。本稿ではこの機能を中心に説明していく。
Ansibleとは、OSのターミナルから実行するコマンドのことであり（以下、「Ansibleコマンド」と呼ぶ）、Ansibleコマンドが導入されているサーバーを本稿では「Ansibleサーバー」と呼ぶ。
AnsibleサーバーでAnsibleコマンドを実行すると、Ansibleサーバーから被管理サーバーへアクセスして各種設定を行う。
被管理サーバーへのアクセスと設定の反映には、対象がLinuxサーバーの場合はSSHプロトコルとPythonを、Windowsの場合はWinRM（Windows Remote Manager：Windowsリモート管理）プロトコルを使用する。被管理サーバー側に、Ansibleのクライアントを導入する必要はない（図表１）。
このクライアントの導入不要という点はAnsibleの大きなメリットの１つであり、そのため被管理サーバーを作成してから直ちにAnsibleでのセットアップが可能となる。
Ansibleにはいくつかコマンドが存在するが、Ansibleによる構成管理というと、ansible-playbookコマンドを実行する形が一般的である。
ansible-playbookコマンドを実行する際には、PlaybookファイルとInventoryファイルが必要である。Playbookファイルは、被管理サーバーに対して設定する内容を記述したテキストファイル（YAMLフォーマット）で、パッケージ管理、ユーザー管理、ファイルやディレクトリ操作、サービス操作など、さまざまな設定が可能である。
一方、Inventoryファイルは被管理サーバーの接続情報を定義するテキストファイルで、主に被管理サーバーのホスト名やIPアドレスのリストを記載するほか、被管理サーバーにアクセスする際に使用するユーザーID、パスワードやSSH鍵、被管理サーバーに導入されているPythonのパス、といった情報を記載することもある。
Ansibleコマンドの実行イメージは、以下のとおりである。
$ ansible-playbook␣-i␣Inventoryファイルパス␣Playbookファイルパス
デフォルトでは、ansible-playbookコマンドを実行したユーザーIDとSSH鍵で被管理サーバーにSSH接続して、Playbookを実行する。
異なるユーザーIDとSSH鍵でSSH接続する場合は、-uや–private-keyオプションなどを使用し、被管理サーバーがWindowsである場合はInventoryファイルにユーザーIDやパスワードを記述する（後述）。
Playbookの記述例は、以下のとおりである。
PlaybookはYAMLフォーマットで記述する。Playbookは大きく分けて、2～5行目のようにPlaybookの基本設定を記述する部分と、6行目以降のように被管理サーバーに適用する構成管理の内容を記述する部分に分かれる。
構成内容を記述する部分はさらに実行するモジュールごとに別れ、上記の例ではyumモジュールに関する設定が7～11行目に、userモジュールに関する設定が13～16行目に記述されている。
Ansibleにはさまざまなモジュールがあり、上記以外にも、たとえばディレクリやファイルを作成するモジュール、サービスを起動・停止するモジュール、Windows Updateを行うモジュールなど多数存在する。
次に、記述例の各項目の説明を以下に記す。
続いて、Inventoryファイルの記述例を以下に示す。
Inventoryファイルは、[]でグループを作成し（1行目、8行目）、その後にホスト名もしくはIPアドレスを記述する（2～6行目、9行目）。
被管理サーバーごとにパラメータを設定でき、4行目ではnode03.jp-ise.comという被管理サーバーへアクセスする際に用いるユーザーIDをadmin02と指定している。
なおここで指定したユーザーIDは、ansible-playbookコマンドの実行ユーザーIDやPlaybookのremote_userで指定したユーザーIDよりも優先され、被管理サーバーごとに異なる設定が必要な場合はInventoryファイルに記述する。
また11～16行目のように、グループに対してパラメータを設定できる。上記の例では、[ansible4win]というグループに対して、WindowsサーバーにPlaybookを適用するのに必要なパラメータを設定している。
Ansibleを利用するには何が必要か
Ansibleサーバーの要件は、Linux、mac OSが導入されているサーバー、もしくはPCが１台必要で、Python 2.7もしくはPython 3.5以上が導入されている必要がある（ただしPython 2のサポートは2020年４月に終了しているため、Python 3の使用を推奨）。
ハードウェアのスペックの要件はとくになく、低いスペックでも十分に動作可能である。Windowsはサポート対象外であるが、たとえばWSL（Windows Subsystem for Linux）を使用すれば、Windows環境上でもAnsibleを動作させられる。
なおAnsibleを導入する際には、インターネット接続環境であることが望ましい。インターネット接続環境であれば導入は非常に容易である（インストール手順は公式ドキュメントを参照）。
これに対して非接続環境の場合、PythonやAnsible、その導入前提となるパッケージをすべてダウンロードし、ローカル・リポジトリを作成する必要があるので、準備に手間がかかる。
一方、被管理サーバーの要件は、Linuxの場合はPython 2.6以上、もしくはPython 3.5以上（前述のとおりPython 3の使用を推奨）と、SSH接続が可能であることの2つである。
SSH接続については、Ansibleサーバーの鍵が登録されていることが望ましい。パスワードを使用した接続も可能であるが、実行に手間がかかったり、管理が煩雑になったりするので極力避けたいところである。
Windowsの場合はWinRMにより、リモート接続可能であることが前提条件になる。ただし通常、WinRMは有効化されていないので、Ansibleを利用する前にセットアップする必要がある。セットアップを実行するスクリプトが提供されているので、詳細は以下の公式ドキュメントを参照してほしい。
構成管理ツールか、それとも自動化ツールか
本稿ではAnsibleは構成管理ツールであると紹介したが、Ansibleの動作の概要から考えると、自動化（自動構成）ツールではないかと疑問に思う読者もいるだろう。
実際、Ansibleは自動化ツールとしての側面も備えている。Ansibleが単なる自動化ツールではなく、構成管理ツールである理由として冪等性（べきとうせい）を担保していることが挙げられる。
冪等性とは、ある操作を何度繰り返しても結果が同じであるという概念である。
Ansibleの場合は、ansible-playbookコマンドでPlaybookを適用した被管理サーバーに再び同じPlaybookを適用しても、設定内容に違いが生じないことを意味している。
たとえば、2重のパラメータ設定や2重のファイル生成などを行わず、すでに求められた設定や操作が行われているのであれば、その設定や操作を行わずにスキップする。
そのためサーバーごとにPlaybookが適用済みであるかどうかを確認する必要はなく、適用済みであろうと、未適用であろうと、まとめて同じPlaybookを適用すればよい。
このように、Ansibleは対象サーバーの構成内容に応じてPlaybookの内容を反映することから、単なる自動化ツールではなく構成管理ツールであるとされている。
ただしPlaybookでOSコマンドを実行する際など、冪等性が担保されない場合もある。その場合は、Ansibleの利用者自身が冪等性を担保するようPlaybookを記述する必要があるので注意したい。
他の構成管理ツールとの違いは何か
Ansibleのほかにも、ChefやPuppetといった構成管理ツールが広く普及している。これらの構成管理ツールもAnsibleと同等の機能を備えている。それぞれのメリットを以下に挙げる。
Ansible、Chef、Puppetの間にはツール間の優劣はない。あるのは、それぞれのツールがもつコンセプトの違いである。
Ansibleはクライアントが不要であることと記述のシンプルさから、多数のサーバーに画一的な（標準化された）設定を適用するのに向いている。
一方、ChefやPuppetは複雑な処理の記述を得意としていることから、少数のサーバーに対して、サーバーごとにカスタマイズされた設定を適用するのに向いている。
ツールがもつ、このような向き・不向きを考慮に入れず、あらゆる処理をAnsibleで実現させようとした結果、ロジックが複雑で、設定内容が分かりづらく、メンテナンス性の悪いPlaybookが出来上がってしまった例が存在する。
こうした事態を避けるためにも、場面や用途に応じて構成管理ツールを適切に選択することが重要である。
GUIでAnsibleを利用できないのか
Ansibleは、コマンドラインインターフェースからの操作が必要である。これに対してRed Hat社から提供されているAnsible Towerであれば、WebブラウザベースのGUIからAnsibleと同等の機能を利用できる（図表2）。
Ansible Towerを利用するメリットとして、GUIでのPlaybookの実行や各種設定の管理が可能であることのほか、ansible-playbookコマンドの実行ログの自動保管、認証情報のセキュアな管理、Ansible Towerユーザーの権限管理、REST APIによる他システム連携、ジョブスケジューリングなどが挙げられる。
本稿の目的はAnsibleの解説なので、これ以上の説明は省略するが、詳細は公式ドキュメントを参照してほしい。
またAnsible Towerだけでなく、Ansible Tower相当の機能を利用できるAWXもある。AWXはAnsible Towerの派生元であり、無償で利用可能である。
ただしAWXは開発ブランチであることから頻繁に変更され、テストも最低限しか行われないので注意が必要である。
Ansible TowerとAWXは、GUIコンソールの外観も含めほぼ同等の機能を備えるが、Ansible Towerは１台もしくは複数台のOS上で動作するのに対して、AWXはコンテナとして動作するという違いがある。
Ansibleによる運用自動化の例
以下に、日本アイ・ビー・エム システムズ・エンジニアリング内で使用する検証用仮想サーバーをクラウド環境に構築して、払い出しをするまでの手順を示す。
まずクラウドベンダーのポータルサイトにログインし、申請内容に応じたスペックの仮想サーバーをオーダーする。
デプロイが完了したら、仮想サーバーにログインしてパッケージのアップデート、利用者ごとのOSユーザーの作成、セキュリティの設定を行い、最後に利用者に仮想サーバーのIPアドレス、ユーザーID、パスワードや秘密鍵をメールで送付する。
当初はこれらを手作業で行っていたが、利用申請数や規模（仮想サーバー数や利用者数）が増加傾向であったため、青枠の作業をPlaybook化してAnsibleにより自動化した。
たとえば自動化以前の申請で、16台の仮想サーバーを11人の利用者で使用するケースでは、仮想サーバーを払い出しするまで、4人がかりで1週間ほどの時間を要していた。
これを自動化したところ、同等規模の申請でも担当者1名が半日程度で払い出せるようになった。
このようにAnsibleを活用することで、構築や運用のオペレーションを大幅に短縮することが可能である。
以上、Ansibleはセットアップする際に役立つ、非常に便利な構成管理かつ自動化のツールであり、他の構成管理ツールと比較して、クライアントが不要で、設定内容をシンプルに記述できる点が特徴であると紹介した。
Ansibleを利用することで、これまで何時間もかかっていた設定作業を短時間で完了できる。Ansibleで自動化できる作業は、さまざまな業務に存在しているはずである。
とても簡単に利用できるツールなので、まずは何か１つの作業をAnsibleで自動化することをぜひ試してほしい。
著者
細野晴海
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
クラウド・ソリューション
クラウド・イノベーション
ITスペシャリスト
2002年に日本アイ・ビー・エム システムズ・エンジニアリング株式会社に入社。主にIBMのシステム管理製品を担当してきた。ここ最近では、IBM CloudやAWS、AzureなどのクラウドインフラをAnsible、Terraform、Elasticsearchといったツールで構築・管理することに携わっている。
