【読書メモ】【3章】詳解 Terraform 第3版 ―Infrastructure as Codeを実現する

↓の本の「3章　Terraformステートを管理する」のメモを残します。

Amazon 楽天

前章のメモ

【読書メモ】【2章】詳解 Terraform 第3版 ―Infrastructure as Codeを実現する

↓の本の「2章　Terraformをはじめよう」のメモを残します。前章のメモ Terraformのインストール・公式ドキュメント・Ubuntuへの...

Terraform ステートとは
1. チームでステートファイルを使用する際の問題点
ステートファイルの共有ストレージ
1. Gitなどのバージョン管理システムの問題点
2. バックエンド
Terraformバックエンドの制限
1. バックエンドのS3やDynamoDBをいつ作るか
2. 変数や参照不可
ステートファイルの分離
1. ワークスペースによる分離
2. ファイルレイアウトによる分離
terraform_remote_stateデータソース
まとめ

Terraform ステートとは

Terraformステートファイル＝どのようなインフラリソースを構築したのかの情報を持っている

デフォルトでは、terraformコマンドを実行したディレクトリにterraform.tfstateが作成される

チームでステートファイルを使用する際の問題点

ステートファイルの共有
チーム全員がステートファイルにアクセスできる必要がある。
なので、S3など共有のストレージでファイルを管理する。
ステートファイルのロック
2人同時にTerraformを実行するとステートファイルの更新が競合する。
ステートファイルをロックする仕組みが必要
ステートファイルの分離
環境ごとにステートファイルを分けて管理したい。
⇒例えば、ステージ環境への変更が本番環境へ影響を及ぼすなどを防ぎたい

ステートファイルの共有ストレージ

Gitなどのバージョン管理システムの問題点

最新のステートファイルを常にpull/pushする必要がある
ステートファイルをロックする仕組みがない
機密情報の載ったステートファイルをGitで管理するのはセキュリティ上よろしくない

バックエンド

どのようにステート情報を扱うかを決める。

ローカルバックエンド：ローカル環境でステートファイルを管理。デフォルトはこっち。

リモートバックエンド：共有ストレージでステートファイルを管理。S3などを使う。

リモートバックエンド

メリット

常に最新のステートファイルを参照/更新できる
ほとんどはロックやファイルの暗号化をサポートしている

S3を使うことのメリット

高い耐久性と可用性
暗号化やDynamoDBを使ったロック、バージョニングをサポート

Terraformバックエンドの制限

バックエンドのS3やDynamoDBをいつ作るか

↓の順番でS3にステートファイルを保存します

S3とDynamoDBを作成。このときステートファイルはローカルにある
backend設定を追加し、terraform initでS3にステートファイルをあげる

※削除はこの逆のステップ

変数や参照不可

backendブロックでは変数や参照が不可

ステートファイルの分離

複数環境のステートを1つのファイルで管理していると、

ある環境の変更が他の環境へ影響を及ぼしてしまう可能性があります。

なので、環境ごとにステートファイルを分けて管理したい

ワークスペースによる分離

1つ目の方法はTerraformのワークスペースという機能を使用すること。

terraform workspaceコマンドを実行し、ワークスペースごとにステートを管理します。

Anacondaで仮想環境ごとにPythonのライブラリを管理するのと同じイメージなのか。。

デメリット

全ワークスペースのステートファイルが同じバックエンドに保存される
⇒どのワークスペースにも等しくアクセス権限が必要
各ワークスペースのインフラの状況を把握しづらい
ワークスペースの切り替え忘れなどミスが起きやすい

ファイルレイアウトによる分離

各環境ごとにフォルダを分けてTerraformファイルを作成し、バックエンドも分ける。

ステートファイルの責任範囲を小さくした方がトラブルの影響範囲も小さくなるので、

各環境内でもNetwork、Application、DataBaseなどでステートファイルを分けるといい。

メリット

コードと環境の対応箇所がわかりやすい
ステートファイルやバックエンドを完全に分離しているのでトラブル時の影響が小さくなる

デメリット

複数のフォルダ配下でterraformコマンドを使わなければならない
⇒Terragruntで解決可能
各環境ごとにフォルダやファイルがあるので重複するコードが多くなる
⇒moduleを活用しよう
フォルダが分かれているため、リソース間の参照が難しくなる
⇒Terragruntで解決可能

terraform_remote_stateデータソース

別のTerraformファイルが使用しているステートファイルを参照する仕組み。

※あくまで参照なので、書き込みや変更はしない。

// データソースとして参照する
// ここで参照した値を使うには、data.terraform_remote_state.<NAME>.outputs.<ATTRIBUTE>
data "terraform_remote_state" "<NAME>" {
  backend = "s3"

  config = {
    bucket = "<BUCKET_NAME>"
    key = "<BUCKET_PATH>"
    region = "<REGION>"
  }
}