オーケストレーションツールと構成管理ツール
システムの実行を支えるインフラ。サーバ、OS、ミドルウェアに加えてストレージやネットワークなどがある。そのインフラの管理をあわよくばシステム開発者に押し付けようというのがInfrastructure as Code（IaC）だ。
IaCではインフラの構成を機械処理可能な定義ファイルに記述してプロビジョニングを自動化する。定義ファイルはGit等でバージョン管理する。定義は手続き的ではなく宣言的に行えた方が好ましい。
そんなIaCを支えるのはオーケストレーションツールや構成管理ツールだ。
オーケストレーションツール
AWS、GCP、Azure、物理サーバなどをプロビジョンしてOSやアプリケーションを実行する基盤環境を構築・管理するツールだ。
AWS Cloudformation、Azure Resource Manager、Terraformなどがある。
構成管理ツール
OSやアプリケーションを展開・設定するツールだ。
Ansible、Puppet、Chefなどがある。
連携
オーケストレーションツールと構成管理ツールの境界は曖昧で、オーケストレーションツールで構成管理することもできるし、逆に構成管理ツールでオーケストレーションすることもできる。
しかし得手不得手はあるので複数のツールを組み合わせてそのツールが得意な場所を任せるのがIaCでは一般的だ。
例えばTerraformでクラウド上に基盤を構築して、その基盤上で動作するアプリケーションをAnsbileで展開・設定する、と言った流れだ。
このためIaCでは色々なツールを目にすることになる。ある程度、ツールの名前と特徴を抑えておくとよいだろう。
以下に有名なツールをいくつか紹介する。
Chef
Puppet
- 構成管理ツール。
- エージェントが必要。
- プル型。
- Manifestに宣言する。
- 独自言語で定義ファイルを記述。
- 宣言型。
Ansible
- 構成管理ツール。
- エージェントレス。
- プッシュ型。
- YAMLで定義ファイルを記述。
- inventoryに対象デバイスを記述してplaybookに処理を記述する。
- 本質的には手続き型だが条件によっては宣言的に動作する。
SaltStack
- 構成管理ツール。
- エージェント（Minion）が必要。
- プル型。
- YAMLで定義ファイルを記述。
- AWS、Azure、VMware、Openstackなどの仮想環境にも強い
- 宣言型、手続き型の両方をサポート。
Terraform
- オーケストレーションツール。
- エージェントレス。
- クラウド環境の構築、管理に強い。
- 独自言語（HCL）で.tfファイルに記述。
- 宣言型。
エージェント型とエージェントレス型
エージェント型のエージェントレス型のメリット、デメリットが考えてみよう。
エージェント型
- 大量の装置を効率的に処理できる
- エージェントをインストールする手間がある
- エージェントをインストールできない装置は制御できない
エージェントレス型
- エージェントをインストールする手間がない
- エージェント型より多くの種類の装置に対応できる
- 大量の装置を処理するときの効率はエージェント型より劣る
宣言型と手続き型
続いて宣言的と手続き的の違いについて見てみよう。 IaCでは宣言型の方が好まれている。
なおAnsibleが宣言型か手続き型かについてはこちらで議論しているので興味があれば参照して欲しい。
宣言型
- システムの望む状態を定義するとツールがその状態に変更する。
- 既に望む状態にある場合はなにも実施しない。
- 望む状態に変更する具体的な手順はツールが判断する。
手続き型
- システムを望む状態に変更するための手順を定義する
- ツールは定義された手順をそのまま実行する
設定自動化の適用領域が広がっている中、IaCを実現するツールには対応する装置やクラウドの豊富さ求められている。こうした要望に答えられるのがTerraformやAnsibleだ。今後、これらのツールを見る機会は増えるだろう。
