リメディエーションを扱う

Terraform PR エージェントを接続すると、エージェントはアクション可能な DoiT シグナルに応じて pull request を作成します。リメディエーションの pull request は DoiT コンソールではなく、GitHub で作成およびレビューされます。

(推奨) Terraform 依存関係ロックファイルをコミットする

エージェントは、リポジトリ内のプロバイダバージョンに応じてリメディエーションを調整するために、Terraform 依存関係ロックファイル (.terraform.lock.hcl) と、required_providers のバージョン制約を使用します。これにより、サポートされているリソースフィールドを選択したり、バージョン固有のバグや注意点に対する既知のワークアラウンドを適用したりできます。

エージェントがプロバイダの正確なバージョンを解決し、より正確な変更を生成できるように、.terraform.lock.hcl をリポジトリにコミットしてください。

エージェントをトリガーする

早期アクセス期間中、DoiT はアクション可能な Composer Insight を選択し、DoiT の Trigger automated IaC remediation for an insight アクションを呼び出す CloudFlow を提供します。エージェントは、スケジュール実行や Integrations カタログからのオンデマンド実行には対応していません。CloudFlow を使用しない第一級の Insights トリガーは、今後のリリースで提供予定です。

代表的な提供フローは次のとおりです。

1. 開始する (例: Manually start トリガーで開始)。

2. List insights を実行し、その後に Filter on List insights を実行して、どの Insight をリメディエートするかを選択。

3. List resource results for an insight を実行して、影響を受けるクラウドリソース ID を収集。

4. LLM ノードを使用して、エージェント向けのリメディエーションガイダンスを整形。

5. DoiT ノード 上で Trigger automated IaC remediation for an insight を呼び出し、エージェントを開始。

この最後のアクションには、トリガー元 (CloudFlow と Insight) と、クラウドプロバイダー、Insight のピラー (例: コストまたはセキュリティ)、影響を受けるリソース ID、リメディエーションテキスト、およびオプションでリソースごとの推定コスト削減額を含むシグナルペイロードが必要です。提供されるフローでは、これらの値は上流のノードから渡されます。

エージェントが、対象リソースを接続済み GitHub リポジトリ内の Terraform コードにマッピングできない場合、そのリソースはスキップされます。対象リソースを 1 つもマッピングできない場合、pull request は作成されません。

エンドツーエンドのフロー

1. シグナル検出: 影響を受けるクラウドリソースを含む Insight が CloudFlow を通じてエージェントに渡されます。

2. リソースマッピング: エージェントは、接続済みの Terraform (HCL) コードベースを検索し、これらのリソースが定義されている場所を特定します。

3. コード生成: エージェントは、推奨されるリメディエーションを実装するための最小限の Terraform 変更を生成し、既存のコードスタイルおよび設定済みのガードレールを尊重します。

4. ローカル検証: pull request を作成する前に、エージェントは提案された変更に対してローカルチェックを実行します。リポジトリ内に Checkov の設定が存在する場合、terraform fmt、tflint、trivy、checkov を含みます。

5. pull request の作成: エージェントは、対象リポジトリ内の専用ブランチ上に pull request を作成します (同じ Insight に対する既存のリメディエーションブランチがすでに存在する場合は、そのブランチを更新します)。リメディエーションが複数のリポジトリにまたがる場合、エージェントはリポジトリごとに 1 つの pull request を作成します。これらのリポジトリ間に Terraform モジュール依存関係が存在する場合、エージェントは依存関係の順序に従って pull request を作成します。まずプロバイダリポジトリ、その後それらのモジュールを利用するリポジトリの順で作成し、各 PR にマージ順序に関するメモを含めます。

6. レビューとマージ: チームは GitHub 上で pull request をレビューし、通常の変更管理プロセスに従ってマージします。マージ後は、通常のデプロイパイプラインが Terraform の変更を適用します。

リメディエーションの pull request を探す

次の条件に当てはまる pull request を探してください。

• リポジトリのデフォルトブランチをターゲットにしている
• doit/iac-remediation/ ブランチから作成されている
• タイトルが [IaC] で始まっている

pull request をレビューする

各リメディエーションの pull request には、レビューに役立つコンテキストが含まれています。

セクション	確認内容
根拠 ("Why")	シグナルの内容を説明し、なぜこれらの変更がシグナルに対処するのかを説明します。
提案された変更 ("What changed")	エージェントが行った HCL コードの変更点を要約します。複数リポジトリにまたがるリメディエーションの場合、各 pull request には、バッチ全体の概要ではなく、そのリポジトリの変更範囲に限定された AI 生成のサマリーが含まれます。
実装の正当性 ("Why this way")	なぜエージェントが別の実装方法ではなく、この方法を選択したかを説明します。PR レビュー担当者のための情報です。
マージ順序	同じリメディエーション内でリポジトリ間に Terraform モジュール依存関係が存在する場合、この pull request が推奨されるマージ順序の中でどの位置にあるかを示します。依存関係が検出された複数リポジトリのリメディエーションにのみ表示されます。
対象リソース ("Scope")	PR によって変更されるリソースを参照します。
兄弟 PR ("Part of remediation")	同一のリメディエーションバッチに含まれる他の pull request をリンク付きで一覧表示し、リポジトリをまたいだ変更全体をたどれるようにします。複数リポジトリのリメディエーションにのみ表示されます。
コストコンテキストとリスク評価 ("Tradeoffs and impact")	依存関係への影響や潜在的なダウンタイムを強調します。コスト削減データが利用可能な場合は、リメディエーションによる推定コスト削減額の合計を表示します。トリガーにリソースごとの推定コスト削減額が含まれている場合、この pull request が対象とする削減額および最も影響の大きいリソース (最大 5 件) のリソースごとの内訳も表示します。複数リポジトリのリメディエーションでは、各 pull request は自分が対象とするリソースと削減額のみを表示します。

注意

リメディエーションコードは AI によって生成されます。マージする前に、提案された変更が環境にとって正しく安全であることを必ず確認してください。

エージェントがリメディエーションの pull request を作成した後、@doit を含むレビューコメントを残すことで、後続のイテレーションをガイドできます。@doit を含まないコメントは取得されません。

エージェントが同じリメディエーションブランチ上で再実行されると、@doit コメントを収集し、自動ボットメッセージや短いリアクションを除外したうえで、残りのフィードバックをリメディエーションプランに反映します。特定の環境のみに変更を限定するといった調整を依頼したり、確認の質問をしたり、提案された変更に関する問題を指摘したりできます。

承認、マージ、または却下する

リメディエーションの pull request は、リポジトリで設定されている必須承認やステータスチェックを含め、標準的な GitHub レビュープロセスを通じてマージしてください。エージェントが自動的に pull request をマージすることはありません。

• Merged: 通常のデプロイパイプラインが、マージ後に Terraform の変更を適用します。エージェントはロールバックを管理しません。

• Closed without merge: インフラストラクチャには変更が適用されません。元の Insight は DoiT 上に残り、チームが調査したり、他の手段で対処したりできます。

リメディエーションがモジュール依存関係を持つ複数のリポジトリにまたがる場合は、コンシューマー側のリポジトリよりも先に、プロバイダ側リポジトリの pull request をマージしてください。各 pull request 内のマージ順序メモが、推奨されるシーケンスを示します。

エージェントが行わないこと

• クラウド環境へアクセスしたり、terraform apply を実行したりすること。

• Terraform state バックエンドを読み書きすること。

• 強制プッシュやブランチ保護ルールの回避を行うこと。

• 同じ Insight とリソースに対して、既にオープンなリメディエーションブランチが存在する場合に、重複する pull request を作成すること (既存ブランチが更新されます)。

• 接続済みリポジトリ内で Terraform によって管理されていないリソースをリメディエートすること。