バージョン管理に関するベスト プラクティス

このドキュメントでは、Terraform for Google Cloud を使用する際に検討すべきバージョン管理のベスト プラクティスについて説明します。

他の形式のコードと同様に、インフラストラクチャ コードをバージョン管理に保存することで、履歴を保持し、ロールバックを容易に行うことができます。

このガイドでは Terraform の概要は説明しません。Google Cloud で Terraform を使用する方法については、Terraform を使ってみるをご覧ください。

デフォルトのブランチ戦略を使用する

デフォルトでは、Terraform コードを含むすべてのリポジトリで次の戦略を使用します。

  • main ブランチはプライマリ開発ブランチであり、承認された最新のコードを表します。main ブランチは保護されています。
  • 開発は、main ブランチから分岐する機能ブランチとバグ修正ブランチで行う。
    • 機能ブランチ feature/$feature_name に名前を付ける。
    • バグ修正ブランチ fix/$bugfix_name に名前を付ける。
  • 機能またはバグ修正が完了したら、そのブランチを pull リクエストで main ブランチにマージする。
  • マージの競合を防ぐには、マージする前にブランチをリベースします。

ルート構成に環境ブランチを使用する

Google Cloud に直接デプロイされるルート構成を含むリポジトリには、安全なロールアウト戦略が必要です。環境ごとに別々のブランチを設定することをおすすめします。したがって、Terraform 構成の変更は、異なるブランチ間で変更をマージすることでプロモートできます。

環境ごとに個別のブランチ

広範な公開設定を許可する

Terraform ソースコードとリポジトリを、エンジニアリング組織全体、インフラストラクチャ オーナー(SRE など)およびインフラストラクチャの関係者(デベロッパーなど)が幅広く閲覧してアクセスできるようにします。これにより、インフラストラクチャの関係者は依存するインフラストラクチャをより深く理解できます。

変更リクエスト プロセスの一環として、インフラストラクチャの関係者にマージ リクエストを送信するように促します。

シークレットを commit しない

Terraform 構成を含め、シークレットをソース管理に commit しないでください。代わりに、Secret Manager などのシステムにアップロードし、データソースを使用して参照します。

このような機密性の高い値は状態ファイルに残り、出力として公開される可能性があるので注意してください。

チームの境界に基づいてリポジトリを整理する

別々のディレクトリを使用してリソース間の論理境界を管理できますが、組織の境界とロジスティクスによってリポジトリ構造が決まります。一般に、「承認要件と管理要件が異なる構成は、異なるソース管理リポジトリに分割する」という設計の基本原則に従ってください。この原則を説明するために、次のようなリポジトリ構成が考えられます。

  • 1 つの中央リポジトリ: このモデルでは、すべての Terraform コードが 1 つのプラットフォーム チームによって一元管理されます。このモデルは、すべてのクラウド管理を専任のインフラストラクチャ チームが担当し、他のチームが要求した変更を承認する場合に最も効果的です。

  • チーム リポジトリ: このモデルでは、各チームが独自の Terraform リポジトリを担当し、所有するインフラストラクチャに関連するすべての管理を行います。たとえば、セキュリティ チームに、すべてのセキュリティ管理を管理するリポジトリがあり、アプリケーション チームごとに、アプリケーションのデプロイと管理を行う独自の Terraform リポジトリがあるとします。

    ほとんどの企業のシナリオでは、チームの境界に従ってリポジトリを整理するのが最適な構造です。

  • 分離されたリポジトリ: このモデルでは、論理的な Terraform コンポーネントがそれぞれ独自のリポジトリに分割されます。たとえば、ネットワーキングには専用のリポジトリがあり、プロジェクトの作成と管理のために個別のプロジェクト ファクトリ リポジトリが存在する場合があります。これは、チーム間で責任が頻繁に変化する、高度に分散された環境で最適に機能します。

リポジトリ構造の例

これらの原則を組み合わせることで、Terraform 構成を異なるリポジトリ タイプに分割できます。

  • 基礎
  • アプリケーションとチーム固有

基盤リポジトリ

フォルダや組織 IAM など、中心的な主要コンポーネントを含む基盤リポジトリ。このリポジトリは、中央のクラウドチームが管理できます。

  • このリポジトリには、各主要コンポーネント(フォルダ、ネットワークなど)のディレクトリを含めます。
  • コンポーネント ディレクトリで、環境ごとに個別のフォルダを指定します(前述のディレクトリ構造のガイダンスを反映します)。

基盤リポジトリ構造

アプリケーションとチーム固有のリポジトリ

アプリケーションとチーム固有のリポジトリをチームごとに個別にデプロイし、アプリケーション固有の Terraform 構成を管理できます。

アプリケーションとチームに固有のリポジトリ構造

次のステップ