メインコンテンツへスキップ

修復の操作

Terraform PR エージェントを接続すると、このエージェントは対応可能な DoiT シグナルに応じて pull request を作成します。修復用 pull request は DoiT コンソールではなく、GitHub 上で作成およびレビューされます。

エージェントは、リポジトリ内のプロバイダーバージョンに合わせて修復を行うために、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 を実行して、修復対象とする Insights を選択します。

  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 に対する修復ブランチがすでに存在する場合は、その既存ブランチを更新します）。

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

修復用 pull request を探す​

次の条件を満たす pull request を探してください。

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

pull request をレビューする​

各修復用 pull request には、レビューを支援するためのコンテキストが含まれます。

セクション確認内容
Rationale ("Why")シグナルの説明、およびなぜこれらの変更がシグナルへの対応となるのかを説明します。
Proposed changes ("What changed")エージェントが変更した HCL コード変更の概要を示します。
Implementation justification ("Why this way")エージェントが他の実装方法ではなく、この方法を選択した理由を説明します。PR レビュアーを支援するための情報です。
Target resources ("Scope")PR によって変更されたリソースを参照します。
Cost context & risk assessment ("Tradeoffs and impact")依存関係への影響や発生しうるダウンタイムを強調し、利用可能な場合は元のシグナルから推定されるコスト削減額またはコストへの影響も示します。
注意

修復コードは AI によって生成されます。マージする前に、提案された変更がご利用の環境にとって正しく安全であることを必ず確認してください。

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

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

承認、マージ、却下​

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

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

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

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

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

  • Terraform state backend の読み書きを行うこと。

  • 強制 push を行ったり、ブランチ保護ルールを迂回したりすること。

  • 同じ Insight と同じリソースに対して、既にオープンな修復ブランチが存在する場合に、重複する pull request を作成すること（既存ブランチが代わりに更新されます）。

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

に最終更新