Terraform vs Ansible vs Pulumi: どのIaCを選ぶ?
TerraformはstateとともにHCLで宣言的にインフラをプロビジョニングし、Ansibleは手続き的に構成とオーケストレーションを行い、Pulumiは実際の言語でIaCを書きます。
TerraformはHCLで望ましいインフラを宣言し、多数のproviderにわたってstate fileを介して調整し、プロビジョニングで力を発揮します。AnsibleはSSH上で順序付けされたタスクを実行(エージェントレス)してサーバーを構成し変更をオーケストレーションし、構成管理とアプリのデプロイで力を発揮します。PulumiはインフラをTypeScript、Python、Goで表現し、ループ、関数、テストをIaCにもたらします。両者は重なりますが、異なるレイヤーを重視します。
| Terraform | Ansible | Pulumi | |
|---|---|---|---|
| モデル | 宣言的(HCL) | 手続き的(YAMLタスク) | 宣言的(実際のコード) |
| 強み | プロビジョニング | 構成管理 | プロビジョニング + ロジック |
| State | state file | ステートレス(ほぼ) | state(バックエンド) |
| 言語 | HCL | YAML | TS/Python/Go |
| 最適な用途 | クラウドのプロビジョニング | サーバー構成、オーケストレーション | コード駆動のIaC |
役割と重なり
Terraformはクラウドリソースを宣言的にプロビジョニングする一般的な選択肢です。Ansibleはそれらのリソースの構成、ソフトウェアのインストール、stateを管理せずに複数ステップの変更をオーケストレーションすることに強みがあります。Pulumiは、IaCに完全なプログラミング言語の力、抽象化、ユニットテストを望むチームに適しています。多くの現場はTerraform(プロビジョニング)とAnsible(構成)を組み合わせるか、すべてを1つの言語に保つためPulumiを選びます。
CIにおいて
PRでplan/previewを実行し、applyはreviewの後ろにgateし、クラウドの認証情報はCIのsecret storeに可能な限りOIDCを使って保存してください。3つともマネージドrunnerで動作し、より高速なrunnerはplan、preview、applyのステップを短縮します。
結論
宣言的なマルチクラウドのプロビジョニングには、Terraformです。サーバー構成と手続き的なオーケストレーションには、Ansibleです。ロジックとテストを備えた実際のプログラミング言語によるIaCには、Pulumiです。古典的な組み合わせはTerraformとAnsibleで、チームが汎用言語を好む場合はPulumiがHCLレイヤーを置き換えます。