インフラ
Terraformを部分導入した後は？チーム運用へ移るための確認項目
Terraformコードはあるものの、ローカルapplyやState共有、レビューが未整備なチームへ。現状の棚卸し、段階的な移行、役割分担、運用開始の確認項目を整理します。
公開：
- AWS
- Terraform
- IaC
- 変更管理
この記事の目次
Terraformで一部のAWSリソースを管理できていても、実行方法を知る担当者だけがローカルでapplyしているなら、次の課題はチームで変更を扱う仕組みです。
この記事では、既存コードがあるチームが、State・認証・レビュー・本番承認をつなぎ、別の担当者も変更できる状態へ進むための確認項目を整理します。個別の移行コマンドや、全環境の一括改修は扱いません。以下の進め方は検討用の例であり、顧客の導入実績ではありません。
まだTerraformの導入自体を判断している場合は、導入時期を扱う記事から確認できます。
まず、現在の変更方法を棚卸しする
「コードがあるか」だけでなく、直近の変更を誰がどの手順で適用したかを確認します。分からない欄は未確認として残し、確認する担当者を決めます。
| 観点 | 確認すること | 残す情報 |
|---|---|---|
| コードと管理範囲 | どのリポジトリ・ディレクトリが、どのAWSリソースを管理するか | 対象・対象外、依存関係、Terraform・Providerのバージョン |
| State | 保存先、参照するState、アクセス権限、ロック対応、復旧方法は何か | 保存先と管理者、バックアップ・復旧手順 |
| 実行者 | ローカルとCIのどちらから、誰がplan・applyするか | 実行経路、対象アカウント・リージョン |
| 認証 | 個人とCIが何の認証・権限を使っているか | 認証方式、権限の管理者。秘密値自体は記載しない |
| レビュー | PRとplanを誰が、何の観点で確認するか | レビュアー、変更理由、影響確認の記録 |
| 本番承認 | 誰が適用を承認し、実行できるか | 承認者、変更可能時間、適用条件 |
| 緊急変更 | コンソール変更やapply失敗をどう扱うか | 連絡先、記録、コードとの整合を戻す手順 |
管理範囲が重なる別のTerraformコードやCloudFormationなどがあれば、先に管理主体を確認します。既存Stateの移動や再取り込みを、確認なしで進めないようにします。
小さな対象で、順番に運用を移す
1. 最初に試す変更と担当を決める
影響範囲を説明でき、検証と復旧方針を確認できる対象を選びます。変更頻度だけで選ばず、共有リソースや別システムへの依存も確認します。
コード作成、レビュー、本番承認、実行、導入後運用の役割を決めます。兼任する場合も、誰が何を確認するかを省略しません。
2. Stateと実行経路を揃える
チームが同じ対象のStateを参照できる保存・アクセス方法を決めます。バックエンドを変更する場合は、バックアップ、移行手順、切り戻し方針を確認して別作業として扱います。
Stateロックはバックエンドの対応に依存します。共有先へ置くだけで同時実行の問題が解消するとは限りません。CIの実行制御に加え、ローカルからの実行も含めて同じStateへの書き込みを競合させないルールを決めます。ロック解除は、実行中の作業がないことを確認し、手順に従って判断します。
3. PRでplanを確認し、承認後のapplyにつなぐ
コード差分に加え、対象アカウント・State・変数と、planの作成・更新・削除・置き換えを確認します。planは適用予定を示すもので、業務影響やアプリケーションの正常動作を保証しません。
承認したコードと適用するコード、planの対応を追えるようにします。保存したplanを適用する方式なら、その成果物の権限・保持期間・対象コミットを確認します。コードや実環境の変更により確認済みの計画が使えなくなった場合は、再計画・再確認します。
PRの承認と、本番applyを許可する制御は別々に確認します。GitHubのEnvironmentによる承認等を使う場合も、契約プラン・リポジトリの公開範囲・組織ポリシーによって利用可能な機能が異なります。利用できる前提で進めず、本番承認をどこで強制するかを決めます。
参考：HashiCorp：terraform plan、GitHub：Deployments and environments
4. 別担当者が操作してから範囲を広げる
手順書だけを渡して終わりにせず、普段applyしていない担当者が、小さな変更のPR作成から結果確認まで実施します。検証環境等で試し、本番に適用する場合は合意した承認・変更時間に従います。詰まった箇所を手順に反映してから次の対象へ広げます。
PRから適用までの役割例
以下は架空の運用例です。チーム人数や顧客の実態を示すものではなく、役割は自社の体制に合わせて決めます。
| 工程 | 担当する役割 | 残す確認・記録 |
|---|---|---|
| PR作成 | 変更担当 | 変更理由、対象、検証・復旧方針 |
| plan生成 | CIの実行主体 | コミット、対象State、実行結果。閲覧範囲を制限 |
| レビュー | レビュアー | コード・plan・依存関係と影響の確認 |
| 本番承認 | 本番承認者 | 適用する変更、実行可能時間の承認 |
| apply | 制限された実行主体 | 承認条件を満たした変更の適用と結果 |
| 結果確認 | 運用担当 | サービスの状態、変更記録、異常時の連絡 |
CI設定を変更できる人が、承認や認証条件も変更できないかを確認します。通常のTerraformコードだけでなく、ワークフローの変更権限・レビュー条件も運用設計の対象です。
State・planと実行権限を確認する
Stateや保存したplanには機密情報が含まれる場合があります。sensitive指定で画面上の表示を伏せても、Stateやplanへの保存を防ぐものではありません。Gitへのコミットや、公開PRコメントへのplan全文の貼り付けを避け、保存先の閲覧権限と保持・削除方法を決めます。
参考：HashiCorp：Manage sensitive data
GitHub ActionsからAWSを操作する場合は、OIDCで短期の認証情報を使う方法が候補になります。長期キーを保存しない構成でも、信頼ポリシーで許可するリポジトリ・ブランチ・Environment等を絞り、ロールの操作権限も必要な範囲に制限します。OIDCの採用だけで承認や最小権限が完成するわけではありません。
参考：GitHub：OIDC in AWS、AWS：IAM OIDC identity provider
チーム運用を始める前の完了確認
次の項目は運用開始を判断するための例です。全部を機械的に満たせば安全という基準ではなく、自社の対象と影響に合わせて受入条件を決めます。
- コード・State・実リソースの管理範囲と、対象外・依存関係を説明できる
- 別担当者が手順を使い、PR作成とplanの確認を実施できる
- 本番applyに承認が必要で、未承認の実行経路を制限している
- 適用するコミット・planと承認の対応を追える
- State・plan・CIログの閲覧範囲と、認証情報の管理者が決まっている
- 同時実行、ロック、失敗時に、止めて確認する手順と連絡先がある
- 緊急の手動変更を記録し、コードと実環境の差分を確認して整合を戻せる
- 適用後の動作確認、復旧判断、手順更新を担当する人がいる
緊急変更後は、コードに反映するのか、実環境を戻すのかを判断します。差分を確認せず通常のapplyを実行すると、必要な緊急変更を取り消す可能性があるため、影響を確認してから進めます。
未決事項を、次の作業に変える
棚卸しで残った項目に「確認担当」「次に確認すること」「確認する時期」を付けます。最初から全環境を改修する計画にせず、次の1変更をチームで扱うために必要な作業を選びます。
自社で進められる場合は、この表と完了確認を打ち合わせやPRの確認観点として利用できます。
部分導入済みの構成を含め、外部支援の対応範囲を確認したい方は、Linkupのサービス内容をご覧ください。既存コード・State・依存関係を確認したうえで対応可否と範囲を相談します。全環境の改修を標準に含めるものではありません。
方針や設計について助言が必要な場合は、スポット相談も選べます。パッケージへの問い合わせの前提ではありません。