Terraform vs. Ansible: どちらが本当に必要か

Infrastructure as Code の初心者は、通常この質問を2つの方法で尋ねます。「最初に学ぶべきツールはどれか」または「なぜチームは両方を使うのか」。短い答えは、Terraform と Ansible は異なる問題を解決し、本番環境のほとんどのセットアップはどちらか一方を選ぶのではなく、両方を一緒に使うということです。

Terraform が実際にしていること

Terraform はプロビジョニングツールです。存在するべきインフラストラクチャを宣言します。VPC、3つの EC2 インスタンス、RDS データベース、特定のポリシー付き S3 バケット。HCL で最終状態を記述し、terraform plan を実行して何が変わるかを確認してから、terraform apply を実行して実行します。Terraform は状態ファイル（ローカルまたは DynamoDB ロック機能を持つ S3 バケットのようなバックエンドに）を保持し、設定をクラウドプロバイダーの実際のリソース ID にマッピングします。

ここでの強みは、プロバイダー全体での依存関係解決です。Terraform にセキュリティグループを作成して EC2 インスタンスにアタッチするよう指示すると、自動的に順序を判断します。また AWS、Azure、GCP、Cloudflare、Datadog および数十の他のプロバイダーで同じワークフローを通じて機能し、インフラストラクチャが複数のベンダーにまたがると重要になります。

Terraform が得意でないのは、マシンが存在した後にマシン内で発生することです。パッケージのインストール、設定ファイルの編集、継続的な方法でのサービスの再起動を行いません。remote-exec のようなプロビジョナーは存在しますが、HashiCorp 自体はブートストラッピング以上のものには使用しないことを推奨しています。

Ansible が実際にしていること

Ansible は設定管理ツールです。SSH（Windows の場合は WinRM）を介して接続し、既に存在するマシンに対してタスクを実行します。nginx のインストール、設定ファイルのテンプレート化、ユーザーの作成、サービスの再起動、cron ジョブが存在することを強制します。Playbook は YAML で、モジュールは設計上べき等なため、同じ playbook を2回実行してもシステムが既に望ましい状態と一致していれば、2回目は何も変わりません。

Ansible はターゲットホストにエージェントをインストールする必要がなく、Python と SSH アクセスだけで済みます。これにより既存インフラストラクチャに簡単に追加できます。また、厳密には「プロビジョニング」ではないオーケストレーションタスク（フリート全体のローリング再起動、ブルーグリーンデプロイステップ、1つのホストでのデータベースマイグレーション実行とロードバランサーの更新）にも適しています。

重複する部分と混乱する理由

両方のツールは技術的には互いの仕事の一部を実行できます。Ansible にはクラウドモジュール（amazon.aws.ec2_instance、azure.azcollection.azure_rm_virtualmachine）があり、インフラストラクチャを起動できます。Terraform にはプロビジョナーがあり、新しいインスタンスでシェルコマンドを実行できます。ただし、プロビジョニングに Ansible を使用することは Terraform の状態追跡と plan/diff ワークフローを放棄することを意味し、設定に Terraform プロビジョナーを使用することはべき等で反復可能な設定管理を放棄することを意味します。

ほとんどのチームが採用する実践的な分割：

• Terraform がインフラストラクチャを構築します。ネットワーク、コンピュートインスタンス、ロードバランサー、マネージドデータベース、IAM ロール。
• Ansible が上にあるものを設定します。ソフトウェアインストール、ユーザー、設定ファイル、サービス状態、アプリケーションデプロイステップ。

引き継ぎの具体例

AWS でロードバランサーの背後に3つのウェブサーバーを立ち上げるとします。

resource "aws_instance" "web" {
  count         = 3
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  tags = { Name = "web-${count.index}" }
}

output "web_ips" {
  value = aws_instance.web[*].public_ip
}

Terraform がインスタンスを作成して IP を出力します。その出力をダイナミック Ansible インベントリに供給できます（amazon.aws.aws_ec2 インベントリプラグインは EC2 タグを直接読み取り、手動コピペは不要です）。そして実行します：

ansible-playbook -i aws_ec2.yml site.yml

site.yml は nginx をインストールし、アプリ設定を配置し、サービスを開始します。Terraform は nginx に触れません。Ansible は VPC に触れません。各ツールは独自のレーンに留まり、各ツールは互いと矛盾しない独自の状態/べき等モデルを持っています。

避ける価値がある一般的な間違い

Terraform 状態を git に格納することは最も一般的な初期段階の間違いです。状態ファイルにはプレーンテキストのシークレットが含まれ、インフラストラクチャモデルを破損するマージ競合を引き起こします。初日からリモートバックエンドを使用してください。

Ansible では、playbook が実際にはべき等でない、実際のモジュール（ansible.builtin.apt、ansible.builtin.copy、ansible.builtin.systemd）を持つものに対して shell または command モジュールを使用するという誤りです。チェック後処理ロジックを正しく既に処理しています。

最初に学ぶべきものを決めている場合：クラウドプロビジョニングとマルチ環境セットアップを行っている場合は Terraform を学び、既に持っているサーバーの設定ドリフトを管理している場合は Ansible を学びます。ほとんどの DevOps ロールは最初の1年以内に両方に精通することが期待されます。

状態管理、ダイナミックインベントリ、これらのツールの周辺の完全な CI/CD パイプラインの構築の詳細については、Korra Studio の関連 DevOps および Cloud セグメントを確認してください。