コードとしてのインフラストラクチャ：Terraform、 Ansible

コードとしてのインフラストラクチャ： Terraform、 Ansible

1） IaCとツールの違い

Terraform-宣言的オーケストレーター-IaC：プロバイダを通じてクラウドインフラストラクチャ（VPC、 K8s、 LB、 DB、 IAM）を作成/修正します。リソースライフサイクルを管理し、状態を保存します。
Ansible-プロシージャコンフィグ-IaCおよび構成管理：ホスト/ソフトウェア（パッケージ、ファイル、サービス）を構成し、アプリケーション、テンプレート、ステップのオーケストレーションを提供する方法を知っています。エージェント（SSH/WinRM）がなくても、タスクの権限はありません。

組み合わせ：Terraform-「プラットフォームが何で作られているか」、Ansible-「どのように設定され、起動されているか」。

2）リポジトリとレイヤーの構造

1.基盤（ランディングゾーン）：ネットワーク、IAM、 KMS、ベースログ/監視。

2.プラットフォーム：Kubernetesクラスタ、データベース、キュー、オブザビリティスタック。

3.ワークロード：スペース/名前空間、サービスアカウント、ポリシー、構成。

• 'iac/terraform/'-モジュールと環境（'modules/'、 'envs/'）。
• 'iac/ansible/'-ロール（'roles/'）、プレイブック（'playbooks/'）、インベントリ（'inventions/'）。
• 'policies/'-OPA/Conftestルール。
• 'pipelines/'-CI/CDスクリプト（lint/plan/apply/test）。

3）テラフォーム： モジュール、状態、環境

3.1モジュール

小さく、再利用：'vpc'、 'eks'、 'rds'、 'redis'、 'alb'、 'iam-role'。
入力→'変数。tf'、出力→'出力。tf'、バージョン-modules/git-tagsのレジストリを介して。

hcl module "vpc" {
source = "git::ssh://git@repo/iac. git//modules/vpc? ref=v1. 6. 0"
name  = "prod-core"
cidr  = "10. 0. 0. 0/16"
azs  = ["eu-central-1a","eu-central-1b"]
}

3.2ステート

リモートバックエンド（S3/GCS+DynamoDB/LockTable）+ロック。
環境による分離：'prod。tfstate'、ステージング。tfstate'。
ステートドリフト：予定通りCIの「テラフォームプラン」；漂流するとき警戒しなさい。

hcl terraform {
backend "s3" {
bucket     = "iac-state"
key      = "prod/network/terraform. tfstate"
region     = "eu-central-1"
dynamodb_table = "iac-locks"
encrypt    = true
}
}

3.3ワークスペース/エンブ

• ディレクトリ'envs/prod'、' envs/stage'（ビジュアル）を分離します。
• 明るいバリエーションのワークスペースですが、シークレットの混在は避けてください。
• 'tfvars'：' prodを介したパラメータ。tfvars、ステージ。TFVARSの'.

4） Ansible： 役割、在庫、Idempotence

4.1役割とプレイブック

roles/
nginx/
tasks/main. yml templates/.j2 handlers/main. yml defaults/main. yml playbooks/
site. yml

yaml
- hosts: web become: true roles:
- role: nginx vars:
nginx_listen_port: 8080

4.2インベントリとダイナミクス

'inventories/prod/hosts。yml'+変数'group_vars/host_vars'。

動的インベントリ： 'aws_ec2'、 'gcp_compute'、 'kubernetes。「コア」

4.3 Idempotency

可能な限りモジュール（'shell'ではない）を使用します。
'changed_when'/'check_mode'を実行します。
ハンドラは変更のみを反映します。

5）秘密と構成

Terraform： 'sensitive=true'による値の分泌；秘密自体は状態にありません（AWS Secrets Manager/HashiCorp Vault/KMSに保存し、データソースを参照してください）。
Ansible：可変暗号化のためのVault （'ansible-vault encrypt'）、 HashiCorp Vault/KMSとの統合。
GitOps：別のリポジトリ/ストレージ内の秘密、最小権限によるアクセス。

6）コードとしてのポリシー

OPA/Conftest for Terraformプラン：パブリックS 3の禁止、オープンSG、タグ付けされていないリソース（タグ）。
Terraform Cloud/Enterprise-代替としてのセンチネル。
Ansible Lint：スタイルとセキュリティ（'sudo： yes'なし、raw-shellなし）。

rego package terraform. security

deny[msg] {
input. resource_type == "aws_security_group_rule"
input. values. cidr_blocks[_] == "0. 0. 0. 0/0"
input. values. from_port == 22 msg:= "SSH from 0. 0. 0. 0/0 is forbidden"
}

7） IaCのテスト

Terraform： 'tflint'、 'tfsec'/'checkov'、統合チェックのためのTerratest （Go）。
Ansible： 'ansible-lint'、役割をテストする分子（+Docker/Podman/EC2）。
適用の後の煙テスト：HTTPの調査、港/プロセス、権利。

8） CI・CD・GitOps

1.Lint/Sec： tflint、 tfsec/checkov、 ansible-lint。

2.プラン：アーティファクト（MRコメント）を掲載した「テラフォームプラン」。

3.ポリシーゲート：Conftest/Sentinel。

4.適用（手動/承認）：アーティファクトの署名があるメインのみ。

5.Ansible deploy： '--check'をステージに、'--diff'をprodに配置します。

6.ポストチェック：合成/プローブ、リリースアノテーションダッシュボード。

• 真理の源としてマニフェストを保つ。Argo CD/Flux for Kubernetes、しかしTerraformを介した基本的なクラスタ/プリミティブ。

9） Kubernetes、ネットワーク、データベースのパターン

9.1 Kubernetes

テラフォーム：EKS/GKE/AKSクラスタ、ノード、IAM、 StorageClass、 LB。
Ansible： AMI/bastionの準備、イメージアセンブリ/リポジトリ、ポストインストール（ロガー/エージェント/OTel）。

9.2ネットワークと境界

テラフォーム：VPC/サブネット/NAT/トランジットゲートウェイ/WAF、ルート。
Ansible： NGINX/Envoy/HAProxy設定、TLS、 WAFルール設定。

9.3ベース/キャッシュ/キュー

Terraform： RDS/CloudSQLグループパラメータ、Redis/ElastiCache、 Kafka/MSK。
Ansible：キャッシュのウォームアップ、移行ジョブ、バックアップ/エージェントの設定。

10） configsの例

10.1 Terraform-RDS PostgreSQL+SG

hcl module "db" {
source        = "terraform-aws-modules/rds/aws"
engine        = "postgres"
engine_version    = "15. 4"
instance_class    = "db. m6g. large"
allocated_storage  = 100 name         = "core"
username       = var. db_user password       = var. db_password # см. secret data source vpc_security_group_ids = [module. db_sg. security_group_id]
multi_az       = true backup_retention   = 7
}

module "db_sg" {
source = "terraform-aws-modules/security-group/aws"
name  = "db-core"
vpc_id = module. vpc. vpc_id ingress_cidr_blocks = ["10. 0. 0. 0/8"]
ingress_rules    = ["postgresql-tcp"]
}

10.2テラフォーム-秘密のデータソース

hcl data "aws_secretsmanager_secret_version" "db" {
secret_id = "prod/db/core"
}
variable "db_password" {
type   = string sensitive = true default  = jsondecode(data. aws_secretsmanager_secret_version. db. secret_string). password
}

10.3 Ansible-postgresql-clientロール（フラグメント）

yaml
- name: Install packages apt:
name: [ "postgresql-client-15" ]
state: present update_cache: yes

- name: Create. pgpass copy:
dest: /home/deploy/.pgpass mode: '0600'
content: "{{ db_host }}:5432:core:{{ db_user }}:{{ db_password }}"
no_log: true

- name: Smoke query shell: psql -h {{ db_host }} -U {{ db_user }} -d core -c "select 1"
register: psql_out changed_when: false

10.4 Ansible-テンプレート付きNGINX

yaml
- name: Deploy nginx. conf template:
src: templates/nginx. conf. j2 dest: /etc/nginx/nginx. conf notify: Restart nginx

- name: Ensure nginx running service:
name: nginx state: started enabled: true

handlers:
- name: Restart nginx service: { name: nginx, state: restarted }

11）ドリフトおよびコンプライアンス管理

読み取り専用キーで定期的な「テラフォームプラン」；矛盾がある場合にチケットを作成します。
Ansible --checkは重要なロールにスケジュールされています（監査モード）。
レポート：失敗したOPA/Conftestポリシー、タグ付けされていない/バックアップ/監視リソース。

12）可視性と監査

'terraform apply'のログとプランアーティファクト-オブジェクトストレージに保存。
Ansible： 'callback_plugins' （json）→central log/ELK；ジョブID、 commit SHA、 trace_idを含む。
メトリクス：プラン/プレイブックの実行時間、変更頻度、テストカバレッジ。

13）安全性

モジュール/ロール署名または固定タグ/ハッシュ。
最小IAMの権利（'plan' ≠ 'apply'）、 CIとヒューマンアプリの役割を分離します。
状態/ログの暗号化、モジュール/ロールのプライベートレジスタ。
ポリシー「no plaintext secrets in VCS」、シークレットスキャナ（gitleaks/trufflehog）。

14）アンチパターン

1つのテラフォームモンスターモジュール「すべてのために」；モジュールバージョンがありません。
ローカルテラフォーム。tfstateとロックなし。
IaC→永遠のドリフト上のクラウドで手動編集。
モジュールの代わりにansible 'shell'/'command' （idempotencyを破る）。
Inventory 「in one file」 groups/variablesなしでprod/stageをミックスします。
vars/repositoriesの秘密、Vault/KMSの不在。
プランなし、ピアレビューなしで申し込む。

15）実装チェックリスト（0-45日）

0-10日

リモートバックエンド/ロックを構成し、Terraformモジュールを展開します。
tflint/tfsec/checkov、 ansible-lintを有効にします。リソースタグ/ラベルをネゴシエートします。
NGINX/エージェント/ロガーのAnsibleロールを作成します。在庫を整理します。

11-25日

重要なモジュール/役割のConftest/OPA、 Terratest、 Moleculeを追加します。
CI： MRの「計画」、アーティファクトの計画、承認された手動適用；Ansible '--check'がステージ。
Secret Storage （Vault/KMS/Secrets Manager）を統合します。

26-45日

ドリフト検出のための自動スケジュール、ポリシーレポート。
バージョン管理を行うモジュール/ロールのディレクトリ;'README。それぞれにMD。
GitOps：リリースの注釈、モニタリングとアラートゲートの組み合わせ。

16）成熟度の指標

リモート状態とロックを持つ環境の％=100％

テスト（テラテスト/分子）によるモジュール/役割のシェア≥ 70％です。
MRから適用（prod）への平均時間は数時間ではなく、日です。
ゼロ「手動ドリフト」（すべての変更はMRを通過します）。
クリティカルリソースの100％はPolicy as Code（タグ、暗号化、バックアップ）でカバーされています。

17）結論

Terraformは予測可能で繰り返し可能なインフラストラクチャベースを指定します。Ansibleは、ホストとサービスを希望の状態にもたらします。Add Policy as Code、 remote state with location、 tests、 secret management and CI/CD with plan→review→apply-そして、IaCループは管理しやすく、安全で高速になり、リリースは原子的で可逆的になります。