構成管理ツール
サーバーなどの対象機器が、最終的なあるべき姿の状態にするツールです。そのため構成管理ツールでは、まず構成を管理する機器（対象機器）のあるべき姿を定義します。次に対象機器を確認し、あるべき姿と異なっている場合は定義にもとづいてあるべき姿に変更します。あるべき姿と同じ場合は何もしません。例えば、サーバーのあるべき姿が次のように定義されていたとします。- open-vm-tools がインストールされていること
- インストール済みのすべてのパッケージが最新の状態であること
Ansible
まず現時点の Ansible の実行要件などです。CentOS7 では Minimal インストールでも下記条件を満たすため、特に意識をする必要はないと思います。- Ansible を実行する機器を Control Machine 、対象機器を Managed Node と呼ぶ
- Control Machine に Python 2.7 または 3.5 以上が必要
- Managed Node に Python 2.6 以上または 3.5 以上が必要
- Control Machine と Managed Node 間は ssh で通信する
- あるべき姿は playbook ファイルに記述する
- 対象機器（Managed Node）の情報は inventory ファイルに記述する
- playbook ファイルと inventory ファイルは YAML を使用してを記述する（ inventory ファイルは ini 形式でも記述が可能です）
- Ansible には用途ごとに多数のモジュールが用意されており、このモジュールを使って playbook ファイルにあるべき姿を定義する
できること ＆ 得意なこと、不得意なこと
Ansible ができること ＆ 得意なことのまとめです。- サーバー構築や更新の自動化ができる
- 対象機器（サーバー）が playbook ファイルに書かれたあるべき姿に更新される
- 対象機器に特別なツールやプログラムのインストールが不要
- python や ssh 通信できる必要があるが、これらは最小インストールでもインストールされる（ことが多い）
- 冪等性を保っている
- 何回実行しても同じ結果（状態）になるため、失敗しても途中からするのではなく、最初からやり直すことができる
- 気楽にサーバーの構築／破壊ができる
- 壊しても playbook ファイルを使ってすぐに構築できる
- システム構築と同じ手法が使える = Infrastructure as Code（IaC）
- YAML で playbook / inventory ファイルをコーディング → コードレビュー → テスト環境で検証 → 実環境に適用
- 対象機器が 1 台でも 100 台でも手間はさほど変わらない
- inventory ファイルに記述する対象機器の増減で対処ができる
- playbook ファイルを残しておけば再利用ができる
- 過去に実行実績があるコードを部品として再利用することで、コード全体の信頼性が向上する
- 1 回だけの作業には向かない
- 1 回だけの作業であれば YAML でコードを書くよりも直接コマンドを打ったほうが圧倒的に早い
- 版（バージョン）管理が必要である
- きちんとコードの版（バージョン）管理をしておかないと、古いコードを実行してしまうことがある（ Git などで管理するのが望ましい）
- 適切なコードを書いているかチェックが必要である
- コードを複数人にさらす（レビューされる）機会がないと、独りよがりのコードになりやすい
変更履歴
2019/02/20 「できること ＆ 得意なこと、不得意なこと」を追記した2019/02/25 「構成管理ツール」の例示を変更した