本章では、Infrastructure as Code（IaC）の考え方を中心に、インフラを「手作業で構築する」のではなく、「コードで管理・自動化する」ための設計思想を学びます。
現在のクラウド環境では、AWS・Azure・Google Cloud・KubernetesなどをGUIから操作するケースは減少し、TerraformやGitを利用したコードベースのインフラ管理が主流となっています。
本章ではTerraform・GitOps・Policy as Code・Secret Managementなど、企業で利用されている最新のインフラ運用技術を体系的に学習します。
1. Infrastructure as Code（IaC）とは
Infrastructure as Code（IaC）は、サーバ・ネットワーク・データベース・ロードバランサ・DNSなどのインフラ構成をコードとして管理する考え方です。
従来の運用
管理者
↓
AWS Console
↓
クリック
↓
サーバ作成
IaC
Git
↓
Terraform
↓
AWS API
↓
Infrastructure
GUI操作ではなくコードを実行することで、誰が実行しても同じ環境を再現できます。
2. IaCのメリット
- 環境を完全に再現できる
- ヒューマンエラーを削減できる
- Gitで変更履歴を管理できる
- レビュー・承認フローを導入できる
- 複数環境（開発・検証・本番）の構築が容易
- 自動化との相性が良い
3. Terraformとは
TerraformはHashiCorp社が開発したIaCツールであり、多くのクラウドサービスに対応しています。
Terraform
│
├── AWS
├── Azure
├── Google Cloud
├── Kubernetes
├── Cloudflare
└── GitHub
TerraformではHCL（HashiCorp Configuration Language）を使用してインフラを定義します。
4. Terraformの基本構造
resource "aws_instance" "web" {
ami = "ami-xxxx"
instance_type = "t3.micro"
}
Terraformでは「どのリソースを」「どの設定で」作成するかを宣言します。
5. Terraform Workflow
terraform init
↓
terraform plan
↓
terraform apply
↓
Infrastructure
- init：初期化
- plan：変更内容確認
- apply：反映
6. Terraform State
TerraformはStateファイルを利用して現在のインフラ状態を管理しています。
Terraform
│
terraform.tfstate
│
現在のAWS構成
Stateが存在することでTerraformは変更差分のみを適用できます。
7. Providerとは
Providerとはクラウドサービスとの橋渡しを行うプラグインです。
Terraform
│
AWS Provider
│
AWS API
AWSだけでなく多数のProviderが存在します。
8. Module設計
TerraformではModuleによってコードを部品化できます。
Root Module
├── VPC Module
├── EC2 Module
├── RDS Module
└── ALB Module
大規模案件ではModule設計が保守性を大きく左右します。
9. Drift Detection
GUIから設定変更するとTerraformのコードと実際の環境が一致しなくなります。
Terraform
↓
EC2
↓
AWS Consoleで変更
↓
差分発生
この状態をConfiguration Driftと呼びます。
10. Immutable Infrastructure
従来はサーバへSSH接続して直接修正していました。
Immutable Infrastructureではサーバを修正せず、新しいサーバへ置き換えます。
Old Server
↓
New Server
↓
Switch
環境差異を減らし品質を向上できます。
11. GitOpsとは
Gitを唯一の正しい状態（Single Source of Truth）として運用する考え方です。
Developer
↓
Git
↓
ArgoCD
↓
Kubernetes
Gitへマージされると自動でクラスタへ反映されます。
12. ArgoCD
ArgoCDはGitOpsを実現する代表的なツールです。
- Gitとの差分監視
- 自動同期
- Rollback
- 可視化
13. Flux
FluxもGitOpsツールとして広く利用されています。
ArgoCDと同様にGitを監視し、クラスタを自動同期します。
14. Secret Management
パスワードやAPIキーをGitへ直接保存してはいけません。
代表例
- HashiCorp Vault
- AWS Secrets Manager
- Azure Key Vault
- External Secrets Operator
15. Policy as Code
インフラにもポリシーをコードとして定義できます。
開発者
↓
Terraform
↓
Policy Check
↓
Apply
誤った設定を事前に防止できます。
16. OPA（Open Policy Agent）
OPAはPolicy as Codeを実現する代表的なOSSです。
例えば以下のようなルールを強制できます。
- S3をPublic禁止
- 暗号化必須
- タグ必須
- 最小権限IAM
17. CI/CDとの統合
Git Push
↓
GitHub Actions
↓
Terraform Plan
↓
Review
↓
Terraform Apply
人手を介さず安全にInfrastructureを更新できます。
18. Blue/Green Deployment
Blue Environment
Green Environment
↓
Switch
障害時には即座に旧環境へ戻せます。
19. Canary Deployment
100%
↓
95% Old
5% New
↓
50%
↓
100%
段階的にユーザーへ公開することでリスクを抑えます。
20. Progressive Delivery
Blue/GreenやCanaryを組み合わせながら、安全に本番リリースする考え方です。
21. Terraformベストプラクティス
- Moduleを活用する
- Stateを共有ストレージで管理する
- Backendを利用する
- 環境ごとにWorkspaceを分離する
- Secretsをコードへ書かない
- 変数を利用する
- レビュー必須にする
- Git管理する
22. よくある失敗例
- AWS Consoleで直接変更する
- StateをGitへコミットする
- Moduleを使わない
- Secretsを平文保存する
- Terraform Applyを本番へ直接実行する
- レビューなしでマージする
まとめ
Infrastructure as Codeは、単なる自動化ツールではありません。
インフラを「コード」として管理し、Git・レビュー・CI/CD・Policy・GitOpsを組み合わせることで、高品質かつ再現性の高いインフラ運用を実現します。
現代のクラウドエンジニアには、Terraformを書く能力だけでなく、IaC全体の設計思想を理解することが求められます。
本章のゴール
- Infrastructure as Codeの考え方を理解する
- Terraformの基本構造を理解する
- State・Provider・Moduleの役割を説明できる
- GitOpsの仕組みを理解する
- ArgoCD・Fluxの役割を理解する
- Policy as Codeを説明できる
- Secret Managementの重要性を理解する
- Blue/Green・Canary Deploymentを設計できる
- CI/CDとIaCを統合できる
- 企業レベルのIaC運用を理解する
