※『Ansible徹底入門 クラウド時代の新しい構成管理の実現』より一部を抜粋（記事掲載に合わせ改変）。
前書き
2013年の春先、私は悩んでいました。その当時、開発を進めていたコンテナ型PaaSにある新機能を追加しなければならなかったからです。その新機能は大まかにまとめると「コンテナ内に存在するWebアプリケーションを外部の環境に『そのまま元と同じように動く状態で』エクスポート可能にする」といったものでした。
はじめのうちは、そこまでハードルは高くないだろうと踏んでいたのですが、PaaS内での自動セットアップは種々の特別な前提の元に成り立っており、外部環境でそのまま再現できるものではありませんでした。さらに仮にそれができたとしても、利用ユーザーによって環境が書き換えられていた場合「環境をそのまま」エクスポートすることはできません。
また、必要に応じてユーザーが自分でエクスポート用スクリプトに手を加えられるような仕組みも必要になりますが、既存のスクリプトはPythonとシェルスクリプトが複雑に絡みあっており、とても「見てもらえれば分かりますよ」といえる代物ではありません。
結局のところ当初の目論見に反し、一から新しい自動環境セットアップ用の仕組みを用意する必要が出てきたのです。
2013年当時、環境セットアップの自動化といえばChefかPuppetといった空気で、このエクスポート機能も最初はこのどちらかを採用するつもりでいました。しかし「操作対象へのエージェントインストールが必須」、「プログラミング言語に慣ている人でないと手が出しづらい」といった点がネックとなり、ほかによい選択肢がないものかと探していて見つかったのが、まだ登場して間もないころのAnsibleです。
Ansibleはネットワーク経由でアクセスさえできればエージェントは不要であり、YAML形式で書かれたコード（Playbook）はプログラマーでない人でも読み書きが簡単です。「これぞ探し求めていたものだ！」とすぐさまAnsibleを使っての実装を進め、無事エクスポート機能を完成させることができました。それからは自分で環境のデプロイを行う際にもAnsibleは手放せないものになっています。
あれから数年がたち、クラウドコンピューティングがITインフラの基本となり、IT活用に要求されるスピード感もどんどん加速する今日、Ansibleのような構成管理技術はシステムの開発と運用に携わるすべての人たちに欠かせないものになってきています。
そこで本書では、初めてAnsibleに触れる人たちに向けた解説とチュートリアルに加え、特に実用上の参考になるであろう各クラウド基盤（OpenStack/AWS/Azure）への活用ノウハウ、最新機能でありながら大きな注目を集めるDockerコンテナとの連携など、これからAnsibleを使っていくにあたり重要になるであろう内容を1冊にまとめました。本書が読書の皆様のAnsible活用の助けとなることを願っております。
最後に、本書の執筆にご尽力いただきましたエキスパート執筆陣の皆さん、出版に携わった関係各位に感謝いたします。
2017年1月 廣川英寿
※『Ansible徹底入門 クラウド時代の新しい構成管理の実現』より一部を抜粋（記事掲載に合わせ改変）。
1 クラウド時代のインフラとAnsibleの基礎
1.3 Ansible の歴史
Ansibleは米国Red Hat社が提供し、オープンソースコミュニティによって開発が進められているPython で記述された「あらゆる人のための自動化（Automation for Everyone）」を志向する構成管理ツールです（図1.3）。
Ansibleは、もともとAnsible社によって2012年から提供され始めた、構成管理ツールの中でも後発のソフトウェアです。若いソフトウェアではあるものの、非常にアクティブに開発が続けられており、早い段階からほかの構成管理ソフトウェアと比べても遜色のないクオリティに達し、2013年2月にバージョン1の正式版がリリースされてからは、NASA（米国航空宇宙局）のような大規模組織でも導入されるようになるなど、急速に広まっていきました。
2015年10月にAnsible社がRed Hat社に買収されたことも、Ansibleの実用性と注目度の高さを表しているといってよいでしょう。買収後の2016年1月には、表面的な利用感はそのままに裏側のコア部分を書き直したバージョン2が正式リリースされ、ネットワーク機器への対応などの新たな機能拡充と既存機能の改善が続けられています。
1.5 Ansibleの特徴
最後に、構成管理ツールとしてのAnsibleが持つ特徴をいくつか挙げて、代表的な類似ツールであるPuppetおよびChefとの比較を見ていきましょう。
なお、PuppetとChefはともにRubyで記述された構成管理ツールで、どちらもAnsible登場以前から普及しているものです。Puppetは2005年に登場した最古参で、Infrastructure as Codeという言葉の祖ともなるツールです。Puppet Languageという独自言語でコード（Manifest）を記述します。
一方のChefはPuppetなどの影響下で2009年に登場したツールで、Rubyそのものでコード（Recipe）を記述できるという特徴があります。Webアプリの分野で広く使われているRubyがそのまま使えるというエンジニアフレンドリーさと、最近のDevOps 隆盛に伴って広く普及しました。
1.5.1 エージェントレス
AnsibleがPuppetやChefなどほかの主要な構成管理ツールと根本的に異なる点は、エージェントレスで動くという点です。エージェントレスの特徴を知るために、まずはエージェントを用いた構成管理ツールの動きを確認しておきましょう。
Puppet/Chefを含むエージェント型の構成管理ツールでは、操作対象マシンの中で起動する専用エージェントが、中央サーバーにアクセスしてコードを取得し、エージェント自らがマシン内の設定をあるべき状態に更新します。中央サーバーから設定を取ってくるということで「プル型」とも呼ばれるアーキテクチャです（図1.4）。
エージェント型のメリットとしては、
- 中央サーバーは各マシンへのアクセス情報を知らなくてよい（1 箇所にアクセス情報が集中しない）
- マシン立ち上げ時にエージェントを自動起動するようにしておけば勝手に設定処理を行ってくれる
といった点がありますが、次のような制約もあります。
- 操作対象に専用のエージェントをインストールする必要がある（操作対象の環境への副作用を伴う）
-
エージェントを入れるための方法を用意する必要がある
- エージェントが入った設定済みのOS イメージ
- IaaS によってはChef/Puppet 設定済みイメージなどが用意されている場合もある
- VM 作成とマシン内設定を組み合わせる場合などは工程が複数段階に分離してしまい、やや複雑
やはり、あらかじめエージェントのセットアップが必要となるのがネックになりやすいポイントでしょう。
一方、Ansibleが採用するエージェントレスモデルでは、Ansibleがインストールされた中央マシンが各操作対象にログインして直接操作を実行する「プッシュ型」のアーキテクチャを採用しています。そのため、Ansible からネットワーク経由でマシンに繋がるかぎり、何の事前準備もなくAnsibleから対象マシンを操作できるのです（図1.5）。
ネットワーク接続に関しても、特別な専用プロトコルは一切使わず、通常のSSH接続を用いて対象マシンにログインします（Windowsの場合はWinRM、Dockerコンテナにはdocker-exec経由で接続）。つまり、Ansibleは人がログインするときとまったく同じように操作対象にログインします。また、Ansibleが対象マシンの中で操作を実行する際には、必要なファイルを対象に転送してから実行しますが、このファイルも操作終了時に削除してくれるため、操作対象の中に恒久的に残る副作用が生じません。この点で、人手による作業と非常に近い工程を実行しているといえます。
また、中央にいるAnsibleが操作の起点になるという一方向性が常に保たれるため、たとえば「IaaS上に複数VMを立ち上げ、ネットワークを設定し、各VM内のセットアップまで実施する」ような工程をまたぐ操作であっても、Playbook内の操作として一貫で実行できます。操作対象レイヤーの異なる処理をシームレスに繋げるという点で、作業フローの繋ぎこみツールとして活用できることは、ほかの構成管理ツールと異なるAnsibleの利点といえるでしょう。
1.5.2 冪等性
あまり耳馴染みのない単語かもしれませんが、Infrastructure as Codeを語る際には冪（べき）等性というキーワードが頻出します。これはAnsible固有の特徴というわけではないのですが、AnsibleのモジュールとPlaybookを取り扱うにあたって重要な概念ですので、紹介しておきます。
冪等性とは「ある操作を何度実行しても常に結果が同じになる」性質のことです。Ansible においては、各モジュールの内部で、何を実行するかを「手続き的」に扱うのではなく、最終的なあるべき姿を「宣言的」に取り扱うことによって冪等性が担保されるようになっています。
より具体的に、「あるファイルAを配置する」処理を例にとって冪等性の有無による動きの違いを見てみましょう。
-
冪等性を考慮しない場合
「ファイルAをどこどこにコピーする」という手順それ自体が定義されており、操作実行前のファイル設置状況は考慮しない。すでにファイルが置かれている場合でも再コピーしてしまったり、逆に書き換えるべきものがそのままになってしまったりと、操作対象の状態次第で無駄な処理が実行されたり望ましくない結果となる恐れがある -
冪等性が担保されている場合
「ファイルAがどこどこに存在する」という最終的な状態が定義されており、まずはファイルの設置状況の確認処理が実行される。すでに同じファイルが置かれていれば定義された状態を満たしているので、変更を伴う処理は実行されない。未設置時や異なる内容のファイルが置かれている場合にかぎり、ファイルをコピーする
このように、事前の状態に関わらず最終的な結果を望ましい状態にするのがAnsibleにおける冪等性です。
なお、ここでいう冪等性とは操作対象の状態が常に同じになることを指しているわけではありません。たとえば「パッケージを最新版に保つ」というような定義の場合は、そのパッケージの最新版が何かという外部要因によって実際の結果は変わります。あくまでも、Playbookに記述されている目的ベースで捉えたときに結果が一定になるという点に注意してください。
また、Ansibleのモジュールがすべて冪等性を保っているというわけでもなく、任意のコマンドを実行するcommandモジュールなど、望ましい結果をモジュール側から自動で判定できないために、Playbookに冪等性を保つための条件を記述する場合もあります。このあたりの詳細については、第3章を参照してください。
1.5.3 再利用性
Ansibleを長く使い続けるにあたって、気になるのが再利用性の高さです。「再利用性が高い」つまり汎用性を高く保てるのであれば、Ansibleを使い続けるにつれ実装などにかかる手間は減っていくはずです。何度も似た内容を実装しなければならないのは辛いものがあります。
典型的な操作を実装しているモジュールのほかに、Playbookの側にも再利用のための仕組みが備わっていますので紹介しましょう。
まずひとつ目は、すでにすこし出てきた変数を使った値の抽象化です。操作対象となるマシンごとに個別の値を設定したり、Playbook実行のたびに異なる値を与えたりできますので、値の差し替えが想定される箇所を変数化してしまえば、部分的に異なるPlaybookの亜種が発生するような事態を防げます。
もうひとつ、Playbookそれ自体をRoleという単位で部品化して使い回すことも可能です。RoleはPlaybookを各システムで共通して使う単位で切り分けたもので、「MySQLセットアップ」のようにミドルウェアのセットアップ単位にRoleが作られるのが一般的です。RoleはAnsibleであらかじめ決められた単位の部品化であり、ディレクトリ構造などにルールがあり（詳細は第4章で取り扱います）、どこの誰が実装したRoleであってもPlaybookから使うことができます。Ansible GalaxyというRoleの公開／共有のプラットフォームも用意されており、世界中の人が作ったRole資産を活用できるようになっているのです。
上記のとおり、Ansibleでの再利用の単位は変数やRoleといった単位に限られており、「○○クラスから△△メソッドだけ持ってくる」というような使い回しができるPuppetやChefには柔軟さの点で劣ります。これは、YAMLの説明で挙げた「誰からでも使いやすい」というAnsibleの理念による部分で、再利用の方法や構造を決め打ちして自由度を下げているぶん、可読性やメンテナンス性を高く保てるようになっています。
この「皆が継続的に使い続けられるように」という視点は、具体的な機能差以上にほかのツールとAnsibleとを分ける個性になっているといえるでしょう。
さて、以上でAnsibleの概要とその前提となるInfrastructure as Codeについての説明は終わりです。次章からは実際にAnsible のインストールとPlaybook作成のチュートリアルに進んでいきます。
