State Management & Team Workflows - Terraform Tutorial Part 9.
Posted on :: 1496 Words :: Tags: terraform, state-management, devops, collaboration

目次

State Management & Team Workflows

すべてのインフラエンジニアが少なくとも一度は経験する恐怖の物語:

Terraformでデータベースを立ち上げます。ステートがあなたのラップトップで更新されます。昼食に行きます。チームメイトのSarahが最新のコードをpullし、古いステートファイルでterraform applyを実行します。Terraformはデータベースが存在しないと考えます。再作成しようとします。本番環境が壊れます。Slackが爆発します。

聞き覚えがありますか？

Terraformの基礎を征服し、再利用可能なモジュールを構築し、マルチクラウドインフラをデプロイしました。しかし、回避してきた大きな問題が1つあります: ローカルステートファイルは1人を超えてスケールしません。

単独作業？ローカルステートで問題ありません。2人目の開発者を追加？インフラストラクチャでロシアンルーレットをプレイしています。

これから学ぶこと:

  • なぜローカルステートがチームにとって時限爆弾なのか
  • リモートバックエンドの設定方法（S3、GCS、Azure Blob）
  • 災害を実際に防ぐステートロック
  • 本番環境を誤って破壊しない環境分離
  • 何も壊さずに安全にステートを移行
  • ステートがおかしくなったとき（もしではなく）の回復方法

最後には、2人から200人の開発者にスケールする本番グレードのステート管理ができます。

📦 Code Examples

Repository: terraform-hcl-tutorial-series This Part: Part 9 - State Management

動作するサンプルを取得:

git clone https://github.com/khuongdo/terraform-hcl-tutorial-series.git
cd terraform-hcl-tutorial-series
git checkout part-09
cd examples/part-09-state-management/

# リモートステートバックエンドを設定
terraform init
terraform plan

ローカルステートの問題: チームが衝突するとき

なぜローカルステートファイルがインフラストラクチャの時限爆弾なのかを分析しましょう:

ローカルステートがチームを破壊する5つの方法

1. 単一の真実の源がない すべての開発者が独自のステートファイルを持っています。あなたのはデータベースが存在すると言います。Sarahのは言いません。誰が正しい？最後にterraform applyを実行した人が勝ちます。ネタバレ: 全員が負けます。

2. 並行アクセス保護がゼロ あなたがterraform applyを実行します。Sarahが同時にterraform applyを実行します。両方のプロセスが同じインフラを変更しようとします。ステートファイルが破損します。インフラが未定義の状態になります。復旧頑張ってください。

3. ラップトップはバックアップ戦略ではない MacBookにコーヒーをこぼす？ステートファイルを失う？インフラはまだクラウドに存在しますが、Terraformは何を作成したか分かりません。変更できません。きれいに破棄できません。何百ものリソースを手動でインポートする必要があります。

4. 機密データ、暗号化ゼロ ステートファイルにはすべてが含まれています: データベースパスワード、APIキー、プライベートIP。ラップトップに暗号化されずに座っています。コーヒーショップでロック解除されたマシンを誰かが掴む準備ができています。

5. 監査証跡なし 誰が何を変更した？いつ？なぜ？分かりません。ステートファイルは履歴を追跡しません。午前2時に本番が壊れたとき、フォレンジックはゼロです。

解決策？ラップトップにステートを保存するのをやめる。チームがアクセスできる場所に置く。

リモートステートバックエンド: すべてを統治する1つのステートファイル

リモートステートバックエンドはシンプルです: ステートファイルをみんながアクセスできる場所に置く。

terraform.tfstateがラップトップにある代わりに、S3、Google Cloud Storage、またはAzure Blob Storageにあります。terraform applyを実行すると、クラウドから最新のステートをpullし、変更を加え、更新されたステートをpushします。

リモートステートの設定: ステップバイステップ

クラウドプロバイダーに合ったバックエンドを選択。これらの1つだけを設定する必要があります。

オプション1: DynamoDBロック付きAWS S3バックエンド

S3がステートファイルを保存。DynamoDBがロックを提供し、2人が同時にterraform applyを実行できないようにします。

# backend-resources.tf（別のディレクトリで最初に実行）

provider "aws" {
  region = "us-west-2"
}

# ステート保存用のS3バケット
resource "aws_s3_bucket" "terraform_state" {
  bucket = "my-company-terraform-state"  # グローバルに一意である必要があります

  lifecycle {
    prevent_destroy = true  # 安全: 誤ってステートを削除しない
  }
}

# ステートファイル復旧のためのバージョニングを有効化
resource "aws_s3_bucket_versioning" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id

  versioning_configuration {
    status = "Enabled"
  }
}

# サーバー側暗号化を有効化
resource "aws_s3_bucket_server_side_encryption_configuration" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

# ステートロック用のDynamoDBテーブル
resource "aws_dynamodb_table" "terraform_locks" {
  name         = "terraform-state-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

チェックポイント: これらに答えられますか？

Part 10に進む前に、理解していることを確認:

  1. なぜローカルステートはチームに失敗するのか? 単一の真実の源がない、並行アクセス保護がゼロ、ディザスタリカバリがない、機密データが暗号化されずに保存、誰が何を変更したかの監査証跡がない

  2. 3つの本番グレードリモートバックエンドは? AWS S3（ロック用DynamoDB）、Google Cloud Storage（組み込みロック）、Azure Blob Storage（組み込みロック）

  3. ステートロックは何を防ぐ? 2人（またはCI/CDジョブ）が同時にterraform applyを実行するのを防ぐ。ロックがないと、同時applyがステートファイルを破損

  4. ワークスペース vs ディレクトリ分離: 本番環境にはどちらを使うべき? ディレクトリベース分離。ワークスペースは便利だが環境を間違えやすい。別ディレクトリは物理的にdevとprodを混同不可能にする

  5. インフラを壊さずにローカルステートからリモートステートに移行するには? main.tfでバックエンド設定を更新、terraform initを実行、ステートをコピーするようプロンプトされたら"yes"、terraform planで確認、ローカルステートファイルを削除

連載ナビゲーション:

この記事は「Terraform from Fundamentals to Production」シリーズの一部です。Infrastructure as Codeをマスターする12分の9地点です。