↓の本の「10章 チームでTerraformを使う」のメモを残します。
前章のメモ
チームでIaCを採用
IaCを採用するコスト
- スキルのギャップ
- エンジニアは手動でインフラを管理することに慣れている
- コードを書く時間が増えることに苦痛を感じる可能性あり
- 新しい人を採用する必要もあるかも
- 新しいツール
- ツールの学習に時間を要する
- マインドセットの変化
- いままで手動で変更をしていたものがコードになり、作業に時間がかかる
- 学び始めは効率よく扱えない
- 機会コスト
- IaCを導入することに時間をかけるため他のタスクができない。
- 他のプロジェクトとIaCを導入することはどちらが重要だろうか？
インフラコードのデプロイワークフロー
- バージョン管理
- モジュール用とインフラデプロイ用の２つのリポジトリが理想
- モジュール用リポジトリは0からインフラ構築するコストを減らせる
- 変更はTerraformのコードからのみ行う
- 先祖返りしないようにデプロイは特定の１つのブランチからのみ
- モジュール用とインフラデプロイ用の２つのリポジトリが理想
- コードをローカルで実行
- 実際にデプロイして確かめる必要あり
- 専用のサンドボックス環境があるのが望ましい
- コードに変更を加える
- 変更を加えたら再デプロイして確かめる
- 時間がかかるので、変更分のみデプロイできるように工夫する
- 変更に対するレビューを依頼
- バグだけでなく、チームのコーディングガイドラインに沿っているかもレビュー
- 自動テストの実行
- terraform plan を実行して結果を読むべき
- 変更をマージしてリリース
- デプロイ
- デプロイツール
- Atlantis
- Terraform Cloud, Terraform Enterprise
- Terragrunt
- スクリプト
- デプロイを実行するのはサーバから。
- デプロイ時の環境差異をなくすため
- GitHub ActionsやCircleCI, Jenkinsなど
- 環境間の昇格
- 開発⇒ステージング⇒本番 のようにデプロイする
- デプロイツール
コメント