Contents
Consul の基本機能と Terraform の IaC 基本概念
Consul は分散型キー・バリューストア兼サービスカタログとして、マイクロサービス環境の 登録／検索 と ヘルスチェック を提供します。一方 Terraform はインフラ構成をコードで管理し、状態管理 と プラン/適用 のプロセスを標準化します。両者を組み合わせることで、サービス変化とインフラ変更を同期させた自動運用が実現できます。
サービスディスカバリとヘルスチェック
Consul エージェントは各ノード上で常駐し、ローカルのサービス情報とヘルス状態を Consul サーバーへリアルタイムにレプリケートします。
- 登録方式：service {} ブロックまたは API 呼び出しで名前・アドレス・ポートを登録。
- ヘルスチェック種別：HTTP、GRPC、TCP、Script（シェル/PowerShell）など多様なチェックが利用可能。
- 状態伝搬：エージェントは 1 秒単位の間隔でサーバーへハートビートを送信し、失敗時は「critical」フラグを付与してカタログから除外します。
ポイント：Consul の DNS インターフェース（
consul.ドメイン）や HTTP API は常に最新の健康状態を返すため、ロードバランサやサービスメッシュと組み合わせた高可用構成が容易です。
Terraform の提供形態と主要コンポーネント
Terraform には OSS（ローカル実行） と Terraform Cloud/Enterprise（SaaS） の二つの配布形態があります。どちらも HCL（HashiCorp Configuration Language）で記述し、同一プロバイダーを利用できますが、状態管理とチームコラボレーションの方式が異なります。
| 項目 | OSS 版 | Cloud/Enterprise 版 |
|---|---|---|
| 実行環境 | ローカルマシン／CI ランナー | HashiCorp が提供するリモートバックエンド |
| 状態管理 | terraform.tfstate をローカルまたはリモート（例：S3）に保存 |
組み込みのリモートステートとロック機構を自動利用 |
| チーム機能 | Git でコード管理、手動ロックが必要 | ワークスペース、プラン承認、Sentinel ポリシー等の統合機能 |
| シークレット管理 | -var-file や環境変数で外部から供給 |
Vault 連携や Terraform Cloud のシークレットストアが標準装備 |
参考：公式ガイドは「OSS は自己責任で状態を保管、Cloud はマネージドバックエンド」と明記しています【1】。
Consul Terraform Sync (CTS) の概要とアーキテクチャ
CTS は Consul カタログの変化 → Terraform 実行 → インフラ状態更新 というサイクルを自動化するコンポーネントです。以下では役割、内部構成、そして運用上の制約やセキュリティ留意点をまとめます。
CTS が果たす役割と典型的な連携フロー
- Watch / Event：Consul の
watch設定またはeventAPI でサービス追加・更新・削除を検知。 - トリガー評価：
cts.hclに記述された条件（例：特定タグの有無）と照合し、対象か判定。 - Terraform 実行：対象があれば事前に用意した Terraform モジュールを
plan→apply。 - 結果フィードバック：実行ログとプラン結果を Consul の KV（例：
cts/status）へ書き込み、監査情報として残す。
注意点：CTS は単一プロセスで動作するため、同時に多数の Watch が走る環境では CPU とメモリ使用量が増大 します。公式ドキュメントは「1 CPU・2 GiB RAM を最低構成」としています【2】。
トリガーメカニズムと設定例
CTS は以下の三種のトリガーをサポートします。
| 種類 | 説明 | 主な利用シーン |
|---|---|---|
| Event | Consul の event API で任意文字列を送信 → 即時実行 |
デプロイパイプラインからの手動トリガー |
| Watch | サービス・キー・セッションの変更をリアルタイム監視 | 常駐サービスの自動同期 |
| Schedule | Cron 形式で定期的にプラン生成 → 差分があれば適用 | 夜間バッチやリコンシリエーション |
cts.hcl の最小構成例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
consul { address = "127.0.0.1:8500" } terraform { source = "./modules/security-group" variables = { env = "staging" } } trigger "service" { name = "db-service" type = "service" events = ["create", "update"] } |
address：Consul エージェントの API エンドポイント。source：Terraform モジュールへの相対パス（ローカルまたは Git）。events：対象とする Consul イベント種別。
ベストプラクティス：本番環境では必ず
log_level = "INFO"に加えて、デバッグ時にだけDEBUGに切り替えるよう環境変数CTS_LOG_LEVELを利用してください。
CTS の制限事項とセキュリティ留意点
| 項目 | 内容 |
|---|---|
| 同時実行数 | デフォルトでは 1 つの Watch あたり最大 5 件の Terraform 実行を許容。上限は max_concurrent パラメータで変更可能だが、過剰に増やすと API レートリミットに抵触する恐れあり【2】 |
| 権限 | CTS エージェントは Consul の read/write KV と service watch 権限が必要。最小特権の ACL ポリシーを作成し、cts-agent ロールに割り当てることが推奨される |
| ネットワーク要件 | CTS は Consul エージェントと Terraform プロバイダー（例：AWS）双方へ接続できなければならない。VPC 内で動作させる場合は、エージェントの http ポート 8500 と Terraform が利用する各クラウド API のアウトバウンドが許可されていることを確認 |
| Vault 連携 | 環境変数や平文ファイルにシークレットを書かない。Terraform 側で vault_generic_secret データソースまたは vault_aws_auth_backend を利用し、CTS の実行時に動的クレデンシャルを取得する【3】 |
| 障害復旧 | 失敗した適用は自動ロールバックされない。手順としては terraform state pull → plan -refresh=false → 必要に応じて apply -target=... を実行し、CTS の設定を修正後に再度走らせる |
2026 年版 CTS インストール・設定手順
以下の手順は Ubuntu 22.04 環境でのインストール例です。公式ガイド（2026‑06‑05）を基に、バージョン確認からテスト実行までの流れを示します。
1. 必要バージョンの確認
|
1 2 3 4 |
# Consul と Terraform の最低推奨バージョンは以下（公式ドキュメント参照） consul version # >= 1.14 terraform version # >= 1.5 |
実務上の注意：
asdf,tfenv等でバージョンを統一すると、将来のアップグレード時に依存関係が衝突しにくくなります。
2. CTS バイナリの取得と配置
|
1 2 3 4 5 6 |
curl -L -o cts.zip \ https://releases.hashicorp.com/consul-terraform-sync/0.7.3/consul-terraform-sync_0.7.3_linux_amd64.zip unzip cts.zip -d /usr/local/bin chmod +x /usr/local/bin/consul-terraform-sync consul-terraform-sync version # => 0.7.3 |
最新版は https://releases.hashicorp.com/consul-terraform-sync/ のディレクトリ一覧から確認してください。
3. 設定ファイル (cts.hcl) の作成
先述の最小構成をベースに、ACL ポリシー と Vault シークレット取得 を追加した例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
consul { address = "127.0.0.1:8500" token = "{{ env \"CONSUL_HTTP_TOKEN\" }}" } terraform { source = "./modules/security-group" variables = { aws_region = "ap-northeast-1" # Vault から動的に取得したクレデンシャル aws_access_key = vault_generic_secret("aws/creds/cts").data["access_key"] aws_secret_key = vault_generic_secret("aws/creds/cts").data["secret_key"] } } trigger "service" { name = "db-service" type = "service" events = ["create", "update"] } |
ポイント：
vault_generic_secretは Terraform のvaultプロバイダーが提供するデータソースです。Vault 側でcts-agentロールに対しread権限のみ付与すると、最小特権の原則を満たせます【3】。
4. Dry‑run（シミュレーション）で検証
|
1 2 3 4 |
CONSUL_HTTP_TOKEN=$(cat /etc/consul/token) \ CTS_LOG_LEVEL=DEBUG \ consul-terraform-sync run -config ./cts.hcl -dry-run |
- 構文エラー：
-dry-runでは HCL のパースと Watch 設定だけが検証されます。 - プラン確認：期待通りの
terraform planが出力されたら、本番適用へ進めます。
5. 本番実行と監視
|
1 2 3 |
systemd-run --unit=cts.service \ /usr/local/bin/consul-terraform-sync run -config /etc/cts/cts.hcl |
- ログ出力：
journalctl -u cts.service -fでリアルタイムに確認。 - 障害時のロールバック：失敗した場合は
terraform state listとstate pullを利用し、前回の状態へ手動復元します（上記「障害復旧」参照）。
連携パターン比較と選択ガイド
組織規模や運用ポリシーに応じて、主に 3 つ のアプローチが考えられます。以下ではそれぞれの特徴を整理し、導入判断材料を提供します。
1. 手動 Terraform 実行
- 適用タイミング：人為的な承認フローが必要なケース（例：規制対象リソース）。
- メリット：最小構成で始めやすく、権限管理もシンプル。
- デメリット：サービス増加に比例して作業負荷が膨らむ。リアルタイム性は低い。
2. CTS による自動適用
| 項目 | 内容 |
|---|---|
| リアルタイム性 | Consul の Watch が検知次第、数秒以内に Terraform が実行される。 |
| 運用負荷 | 初期設定以降はエージェントが自律的に処理。 |
| スケーラビリティ | エージェントを横展開すれば大規模環境でも対応可能。ただし同時実行数の上限に注意。 |
| 障害復旧 | Terraform の Plan が保存されるため、手動で apply -target できる。 |
3. Terraform Cloud + Consul Provider
- 構成：CI/CD パイプライン（例：GitHub Actions）で
terraform plan→ Cloud ワークスペースの承認 →apply。Consul Provider がプラン時点で最新カタログを取得。 - メリット：ロック・履歴管理が SaaS に委託でき、ガバナンス（Sentinel）やチームコラボが標準装備。Vault 連携も Cloud のシークレットストアで完結。
- デメリット：CTS のような「サービス変化即時適用」ではなく、プラン実行のタイミングに依存する（※定期的に
terraform plan -refresh=trueを走らせる必要あり）。
選択指針
- リアルタイム性が最優先 → CTS。
- ガバナンスと監査が必須 → Terraform Cloud + Consul Provider。
- コスト・運用リソースが限られる小規模環境 → 手動実行か、最小構成の CTS（単一エージェント）で様子を見る。
ベストプラクティスと実務ユースケース
1. Vault と組み合わせたシークレット管理
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
provider "vault" { address = "https://vault.example.com" } data "vault_generic_secret" "aws_cts" { path = "aws/creds/cts" } variable "aws_access_key" { default = data.vault_generic_secret.aws_cts.data["access_key"] } variable "aws_secret_key" { default = data.vault_generic_secret.aws_cts.data["secret_key"] } |
- 最小特権：Vault ポリシーで
cts-agentに読み取り専用 (read) のみ付与。 - 動的クレデンシャル：TTL が短いトークンを利用すれば、漏洩リスクが低減。
2. State バックエンドの選択とロールバック戦略
| バックエンド | 特徴 |
|---|---|
| Terraform Cloud | ロック・履歴管理が自動。UI/CLI で過去バージョンにワンクリック復元可能。 |
| Consul KV | CTS と同一クラスタ内に保持でき、ネットワーク遅延が最小。ただしロックは外部ツール（例：DynamoDB）と組み合わせが推奨される。 |
ロールバック手順（Cloud 使用時）
1. ワークスペースの「State Versions」から対象リビジョンを選択。
2. 「Rollback」ボタンで前回安定版へ復元。
3. CTS の設定変更後、再度runコマンドで適用。
3. 代表的ユースケース
| ユースケース | 目的 | CTS が果たす役割 |
|---|---|---|
| ネットワーク機器自動設定 | スイッチの VLAN 変更を即時反映 | Consul に登録されたポート情報 → CTS が network_device モジュールを呼び出し、Cisco IOS のコンフィグを書き換える |
| クラウド SG 同期 | タグベースで Security Group を管理 | サービスタグが更新されると CTS が対象 SG のインバウンドルールを自動修正 |
| マイクロサービス版 App Mesh | バージョンごとのトラフィック分離 | Service に付与した version タグ変更 → CTS が aws_appmesh_virtual_node を更新し、Blue/Green デプロイを自動化 |
これらはすべて 「サービス変化 ⇒ インフラ変更」 というパターンで、CTS の存在意義が最も顕在化するシナリオです。
まとめ
- Consul と Terraform はそれぞれサービスディスカバリと IaC の基盤 であり、相互に補完し合うことで「コード＝真実」の自動運用が可能になる。
- CTS は Consul カタログの変化をトリガーに Terraform を走らせる橋渡しコンポーネントで、リアルタイム同期と状態管理の両方を担う。
- 運用上は バージョン要件・ACL ポリシー・ネットワークアクセス を公式ドキュメントで再確認し、最小特権かつスケールアウト可能な構成を設計することが必須。
- Vault 連携やリモートステート と合わせて導入すれば、シークレット漏洩リスクと状態破損リスクの両方を低減できる。
- 組織の要件（リアルタイム性・ガバナンス・コスト）に応じて 手動 / CTS 自動化 / Terraform Cloud のいずれか、またはハイブリッドな運用モデルを選択すべきである。
参考文献
- HashiCorp Documentation – Terraform Overview (2026‑06‑05). https://developer.hashicorp.com/terraform/docs
- HashiCorp Documentation – Consul Terraform Sync (CTS) Requirements (2026‑06‑05). https://developer.hashicorp.com/consul/tutorials/terraform-sync/install
- HashiCorp Documentation – Vault Provider for Terraform (2026‑06‑05). https://registry.terraform.io/providers/hashicorp/vault/latest/docs