ランディング ゾーンのブループリントをデプロイする

Config Controller を使用すると、Google Cloud のランディング ゾーンを宣言的にデプロイして管理できます。

このチュートリアルでは、組織の管理者がランディング ゾーンのブループリントをデプロイして、本番環境対応のスケーラブルなエンタープライズ ワークロード向けに Google Cloud を設定する際に役立つ情報(ネットワーキング、セキュリティ、リソース管理のベスト プラクティスなど)を提供します。

目標

ランディング ゾーンのデプロイ プロセスでは、次のことを行います。

  1. Config Controller を設定し、Git リポジトリから Google Cloud 環境にリソースを同期するように構成します。
  2. 共有 VPC のデプロイなど、Google Cloud の一般的なデザイン パターンをキャプチャするブループリントを探します。
  3. Cloud Build に基づく独自のデプロイ パイプラインを作成します。ブループリントをカスタマイズして kpt 関数で変換し、Config Connector を使用してリソースをデプロイします。

これらのコンポーネントを組み合わせて、次の図のようなワークフローを構築します。

プラットフォーム管理者が Config Controller でデプロイするブループリント

費用

始める前に

ランディング ゾーンを設定する前に、いくつかの準備を行う必要があります。

  1. Google アカウントにログインします。

    Google アカウントをまだお持ちでない場合は、新しいアカウントを登録します。

  2. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

    プロジェクト セレクタに移動

  3. Cloud プロジェクトに対して課金が有効になっていることを確認します。プロジェクトに対して課金が有効になっていることを確認する方法を学習する

  4. Cloud SDK をインストールして初期化します。
  5. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

    プロジェクト セレクタに移動

  6. Cloud プロジェクトに対して課金が有効になっていることを確認します。プロジェクトに対して課金が有効になっていることを確認する方法を学習する

  7. Cloud SDK をインストールして初期化します。
  8. 組織へのアクセス権を付与する際に使用する Google グループを作成します。特に、組織管理者課金管理者からなるグループが必要です。
  9. このチュートリアルで使用する Kubernetes ツール(nomoskubectlkpt){:.external} をインストールします。(Cloud Shell で実行している場合は、これらのツールがすでにインストールされているため、この手順はスキップできます。)各ページからコンポーネントを直接インストールすることもできます。
    gcloud components install pkg

環境の準備

ランディング ゾーンのブループリントをデプロイする前に、いくつかの環境変数を設定する必要があります。

export PROJECT_ID=PROJECT_ID
export CONFIG_CONTROLLER_NAME=config-controller-1
export BILLING_ACCOUNT=$(gcloud alpha billing projects describe $PROJECT_ID \
  '--format=value(billingAccountName)' | sed 's/.*\///')
export ORG_ID=$(gcloud projects get-ancestors ${PROJECT_ID} --format='get(id)' | tail -1)
gcloud config set project ${PROJECT_ID}

以下を置き換えます。

  • PROJECT_ID: Config Controller をホストするプロジェクト ID

Config Controller の設定

Config Controller は、クラウド リソースの構成するための Kubernetes ベースのマネージド コントロール プレーンを提供します。Config Controller には、Policy ControllerConfig SyncConfig Connector がプリインストールされています。

  1. プロジェクトで、Config Controller API と、Config Controller が依存している GKE API を有効にします。
     gcloud services enable krmapihosting.googleapis.com container.googleapis.com
    
  2. Config Controller を作成します。この操作には 15 分以上かかることがあります。
    gcloud alpha anthos config controller create ${CONFIG_CONTROLLER_NAME} \
      --location=us-central1
  3. Config Controller が正常に作成されたことを確認します。
    gcloud alpha anthos config controller list --location=us-central1
  4. 構成の適用を開始できるように、Config Controller を認証します。
    gcloud alpha anthos config controller get-credentials ${CONFIG_CONTROLLER_NAME} \
      --location us-central1
  5. 管理プロジェクトの Google Cloud リソースを管理する権限を Config Controller に付与します。
    export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \
      -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"
    gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
      --member "serviceAccount:${SA_EMAIL}" \
      --role "roles/owner" \
      --project "${PROJECT_ID}"
  6. 組織レベルのリソースを管理する権限を Config Controller に付与して、ランディング ゾーンのブループリントをデプロイします。
    gcloud organizations add-iam-policy-binding $ORG_ID \
      --role=roles/resourcemanager.organizationAdmin \
      --condition=None \
      --member="serviceAccount:${SA_EMAIL}"

GitOps パイプラインの作成

Git リポジトリと同期するように Config Controller を設定すると、ランディング ゾーンの変更作業を共同で行い、堅牢な監査証跡を保持できます。

このステップでは、最初のブループリントをデプロイします。このブループリントには以下のものが含まれます。

  • 2 つの Cloud Source Repositories: 変更を commit するソース リポジトリと、Config Controller に適用される最終的な構成のコピーを含むデプロイ リポジトリ。
  • ソース リポジトリで変更を監視し、それに含まれる kpt 関数を実行して、最終出力をデプロイ リポジトリに commit する Cloud Build トリガー。
  • Config Controller をデプロイ リポジトリに接続する Config Sync 構成

ブループリントをデプロイする

  1. プロジェクトで Resource Manager サービスを有効にします。
    gcloud services enable cloudresourcemanager.googleapis.com
  2. kpt を使用して、GitHub からローカルマシンに GitOps ブループリントをダウンロードします。
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/gitops@kpt-v1 gitops
  3. このブループリントは、多数の setters を使用してカスタマイズできます。gitops/setters.yaml ファイルを開いて修正を行います。
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters-config
    data:
      # You can leave these defaults
      namespace: config-control
      # This should be the name of your Config Controller instance
      cluster-name: cluster-name
      deployment-repo: deployment-repo
      # This should be the project where you deployed Config Controller
      project-id: project-id
      project-number: "1234567890123"
      source-repo: source-repo
    
  4. このブループリントをカスタマイズするには、上記のファイルの次のセッターを置き換えます。
    • cluster-name: Config Controller に選択した名前
    • project-id: Config Controller がデプロイされているプロジェクト ID
    • project-number: Config Controller がデプロイされているプロジェクトの番号。このコマンドで取得できます。
      gcloud projects describe ${PROJECT_ID} --format='get(projectNumber)'
  5. カスタマイズをすべてのリソースに反映するには、ブループリントをレンダリングします。
    kpt fn render gitops/
  6. ブループリントを初期化して、Config Controller クラスタで使用できるようにします。
    kubectl apply --wait -f gitops/ --recursive
  7. ブループリントによってリポジトリが作成されるまで待ちます。
    kubectl wait --for=condition=READY -f gitops/source-repositories.yaml

ブループリントを Git に保存する

ここでは、ブループリントが作成した Git リポジトリにブループリントを保存します。これにより、カスタマイズ内容を保存し、今後の変更を追跡できます。

  1. ブループリントによって作成された Git リポジトリをチェックアウトします。
    gcloud source repos clone source-repo
  2. GitOps のブループリントを Git リポジトリに移動します。
    mv gitops source-repo/
  3. Git リポジトリを開きます。
    cd source-repo/
  4. ブループリントを Git に commit し、変更を push します。
    git add gitops/
    git commit -m "Add GitOps blueprint"
    git push

成功を検証する

上記のブートストラップ プロセスが正常に完了したことを確認します。

  • Config Connector が正常にインストールされたことを確認します。
    kubectl wait -n cnrm-system --for=condition=Ready pod --all
  • Cloud Source Repositories が正常に作成されたことを確認します。
    gcloud source repos list
  • Config Controller で必要なリソースが作成されていることを確認します。
    kubectl get gcp -n config-control -o yaml \
      | grep "^    name: \|message"
    出力は次のようになります。
        name: source-repo-cicd-trigger
          message: The resource is up to date
        name: allow-configsync-sa-read-csr
          message: The resource is up to date
        name: configsync-sa-workload-identity-binding
          message: The resource is up to date
        name: deployment-repo-cloudbuild-write
          message: The resource is up to date
        name: source-repo-cloudbuild-read
          message: The resource is up to date
        name: config-sync-sa
          message: The resource is up to date
        name: cloudbuild.googleapis.com
          message: The resource is up to date
        name: sourcerepo.googleapis.com
          message: The resource is up to date
        name: deployment-repo
          message: The resource is up to date
        name: source-repo
          message: The resource is up to date
    

ランディング ゾーンの初期化

Config Controller が Git に接続されたところで、今度はランディング ゾーンのブループリントを初期化します。

このブループリントは、次のような組織全体の構成を設定して、ランディング ゾーンを準備します。

  • hierarchyloggingnetworkingprojectspolicies を管理するための別の名前空間を Config Controller 内に作成します。各名前空間には、異なる最小権限の Google Cloud サービス アカウントが割り当てられます。
  • 課金管理者グループに課金管理者ロールを割り当て、組織管理者グループに組織管理者ロールを割り当てます。
  • 組織内のベスト プラクティスの組織のポリシーを有効にします。

ブループリントをデプロイする

上でクローンを作成したソース リポジトリから、ランディング ゾーンをデプロイします。

  1. ベース ランディング ゾーンのブループリントをダウンロードし、リポジトリに追加します。
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/landing-zone@kpt-v1 ./landing-zone
    git add landing-zone/
    git commit -m "Add landing zone"
  2. このブループリントには、ランディング ゾーンを構成するためのいくつかのセッターが含まれています。landing-zone/setters.yaml ファイルを開いて修正を行います。
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      # Organization ID and billing account
      org-id: "123456789012"
      billing-account-id: AAAAAA-BBBBBB-CCCCCC
      # Groups to use for org-level roles
      group-org-admins: gcp-organization-admins@example.com
      group-billing-admins: gcp-billing-admins@example.com
      # The project where Config Controller is deployed
      management-project-id: management-project-id
      # This default is safe to keep
      management-namespace: config-control
    
  3. このブループリントをカスタマイズするには、上記のファイルの次のセッターを置き換えます。
    • org-id: ランディング ゾーンの組織の ID
    • billing-account-id: 新しいプロジェクトに使用するデフォルトの請求先アカウント
    • management-project-id: Config Controller がデプロイされているプロジェクト ID
    • group-org-admins: 組織管理者の Google グループのメールアドレス(例: gcp-organization-admins@example.com
    • group-billing-admins: 課金管理者 Google グループのメールアドレス(例: gcp-billing-admins@example.com
  4. ブループリントに対して行ったカスタマイズを確認します。
    git diff
  5. 変更内容をリポジトリに push します。リポジトリでは、変更内容が Config Controller に自動的に同期され、適用されます。
    git commit -a -m "Customize landing zone blueprint"
    git push
    

組織のポリシーを管理する

ランディング ゾーンのブループリントには、環境のセキュリティを強化するためのベスト プラクティスに対応する組織ポリシーの制約がいくつか含まれています。

制約 説明
compute.disableNestedVirtualization すべての Compute Engine VM に対するハードウェア アクセラレーションによりネストされた仮想化を無効にします。
compute.disableSerialPortAccess Compute Engine VM へのシリアルポート アクセスを無効にします。
compute.disableGuestAttributesAccess VM のゲスト属性への Compute Engine API アクセスを無効にします。
compute.vmExternalIpAccess 外部 IP アドレスの使用が許可されている Compute Engine VM インスタンスのセットを制限します。
compute.skipDefaultNetworkCreation プロジェクトの作成時に、Google Cloud はデフォルト ネットワークと関連リソースの作成をスキップします。
compute.restrictXpnProjectLienRemoval 共有 VPC プロジェクト リーエンを削除できる一連のユーザーを制限します。
sql.restrictPublicIp Cloud SQL インスタンス上のパブリック IP アドレスを制限します。
iam.disableServiceAccountKeyCreation ダウンロード可能なサービス アカウント キーの作成を無効にします。
storage.uniformBucketLevelAccess 統一された IAM ベースのバケットレベルのアクセスを使用するために、バケットを要求します。

制約の削除

いずれかのデフォルトの制約が組織に問題を引き起こしている場合は、ソース リポジトリから関連する YAML ファイルを削除して、デフォルトの動作に戻します。

たとえば、シリアルポートへのアクセスを妨げる制約を削除する方法は次のとおりです。

  1. ファイルを削除します。
    git rm ./landing-zone/policies/disable-serial-port.yaml
  2. 変更を commit して push します。
    git commit -m "Remove serial port org policy"
    git push
    

成功を検証する

次の方法で、ランディング ゾーンが初期化されたことを確認できます。

  • Cloud Build 実行パイプラインのステータスを確認します。
  • Git リポジトリが Config Controller と同期されていることを確認します。
    nomos status
  • 名前空間 hierarchyprojectspoliciesloggingnetworking が存在することを確認します。
    kubectl get ns
  • Config Controller で必要なリソースが作成されていることを確認します。
    kubectl get gcp --all-namespaces -o yaml \
      | grep "^    name: |message"
  • CLI を使用して組織のポリシーを一覧表示します。
    gcloud resource-manager org-policies list --organization=$ORG_ID

リソース階層の設定

Google Cloud では、リソースはフォルダとプロジェクトに整理されます。

  • プロジェクトには、仮想マシン、データベース、ストレージ バケットなどのクラウド リソースが含まれます。
  • フォルダを使用してプロジェクトをグループ化し、ポリシー管理を簡素化します(IAM などを使用)。たとえば、財務部門や小売部門などの主要部門のフォルダを作成できます。本番環境と非本番環境などのフォルダを作成することもできます。フォルダを相互にネストしてリソース階層を形成できます。

Google では、さまざまな組織構造に合わせて 4 つの異なるリソース階層ブループリントを用意しています。

  • シンプル: environments を表す単一レイヤのフォルダが配置されたシンプルなブループリントです。
  • チーム: このブループリントには、teams -> environments の 2 つのレイヤのフォルダが配置されています。
  • ビジネス ユニット: このブループリントでは、組織を自律的なビジネス ユニット divisions -> teams -> environments に焦点を当てて、3 つのレベルのフォルダに分割します。
  • 環境: このブループリントでは、環境中心のポリシー environments -> divisions -> teams に焦点を当てて、3 つのレベルのフォルダを配置します。

ブループリントをデプロイする

優先するリソース階層を選択したら、適切な手順でデプロイします。

シンプル

このブループリントは、クラウドを管理する目的で環境ごとに一連の簡単なポリシーを必要とする組織に適していますが、すべてのチームが均一に扱われます。

  1. ブループリントをダウンロードします。
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/simple@kpt-v1 ./landing-zone/hierarchy/
  2. 必要な組織構造を反映するように landing-zone/hierarchy/hierarchy.yaml ファイルを編集します。
    spec:
      config:
        - shared
        - dev
        - prod
        - qa
      parentRef:
        # This should match your organization ID
        external: "123456789012"

    これらの値は hierarchy.yaml で更新する必要があります。

    • spec.config: 目的の環境です。最上位のフォルダになります。
    • spec.parentRef.external: 組織 ID に合わせてこの値を更新します
  3. landing-zone/hierarchy/policies/naming-constraint.yaml に含まれる命名制約を編集して、フォルダの優先命名スキームを反映します。命名規則は正規表現として定義されます。特に、この式を調整して、定義した追加の環境を含める必要があります。
    spec:
      parameters:
        naming_rules:
          - kind: Folder
            patterns:
              # Matches words like "dev", "prod" or "staging"
              - ^(dev|prod|staging|qa|shared)$
  4. 階層を追加して、git リポジトリに push します。
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

チーム

このブループリントは、各チームが独自のクラウド運用を担当し、クラウドの使用方法に関するカスタム ポリシーを設定する権限を付与されているシンプルな組織に適しています。

  1. ブループリントをダウンロードします。
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/team@kpt-v1 ./landing-zone/hierarchy/
  2. 必要な組織構造を反映するように landing-zone/hierarchy/hierarchy.yaml ファイルを編集します。
    spec:
      config:
        - retail:
            $subtree: environments
        - finance:
            $subtree: environments
      parentRef:
        # This should match your organization ID
        external: "123456789012"
      subtrees:
        environments:
          - dev
          - prod
          - qa

    これらの値は hierarchy.yaml で更新する必要があります。

    • spec.config: 希望するチーム(最上位のフォルダになる)
    • spec.subtrees.environments: 目的の環境。各チームのサブフォルダになります。
    • spec.parentRef.external: 組織 ID に合わせてこの値を更新します
  3. landing-zone/hierarchy/policies/naming-constraint.yaml に含まれる命名制約を編集して、フォルダの優先命名スキームを反映します。命名規則は正規表現として定義されます。特に、この式を調整して、定義した追加の環境を含める必要があります。
    spec:
      parameters:
        naming_rules:
          - kind: Folder
            patterns:
              # Matches words like "dev", "prod" or "staging"
              - ^(dev|prod|staging|qa|shared)$
  4. 階層を追加して、git リポジトリに push します。
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

ビジネス ユニット

このブループリントは、各ビジネス ユニットまたは部門が独自のクラウド運用の大部分を担う、規模が大きく複雑な組織に適しています。各ビジネス ユニットがすべてのチームに適用するポリシーを簡単に設定できるようにする一方で、個別のチームが(それらの最上位の制約の中で)独自の環境を担当することになります。

  1. ブループリントをダウンロードします。
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/bu@kpt-v1 ./landing-zone/hierarchy/
  2. 必要な組織構造を反映するように landing-zone/hierarchy/hierarchy.yaml ファイルを編集します。
    spec:
      config:
        - retail:
            - apps:
                $subtree: environments
            - data:
                $subtree: environments
        - finance:
            - commercial:
                $subtree: environments
      parentRef:
        # This should match your organization ID
        external: "123456789012"
      subtrees:
        environments:
          - dev
          - prod

    これらの値は hierarchy.yaml で更新する必要があります。

    • spec.config: 目的の組織構造。これには部門の下にネストされているチームを含めることができます。たとえば、ブループリントは、アプリおよびデータのサブフォルダを含む小売部門から始まります。
    • spec.subtrees.environments: 目的の環境。各チームのサブフォルダになります。
    • spec.parentRef.external: 組織 ID に合わせてこの値を更新します
  3. landing-zone/hierarchy/policies/naming-constraint.yaml に含まれる命名制約を編集して、フォルダの優先命名スキームを反映します。命名規則は正規表現として定義されます。特に、この式を調整して、定義した追加の環境を含める必要があります。
    spec:
      parameters:
        naming_rules:
          - kind: Folder
            patterns:
              # Matches words like "dev", "prod" or "staging"
              - ^(dev|prod|staging|qa|shared)$
  4. 階層を追加して、git リポジトリに push します。
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

環境

このブループリントは、環境ポリシーに対する強力で一貫した制御(例: 本番環境のリソースへのアクセス制限)を表しつつ、部門やチームごとの詳細なポリシーを柔軟に設定する必要がある大規模な組織に適しています。

  1. ブループリントをダウンロードします。
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/env-bu@kpt-v1 ./landing-zone/hierarchy/
  2. 必要な組織構造を反映するように landing-zone/hierarchy/hierarchy.yaml ファイルを編集します。
    spec:
      config:
        - dev:
            $subtree: environment
        - prod:
            $subtree: environment
      parentRef:
        # This should match your organization ID
        external: "123456789012"
      subtrees:
        environment:
          - retail:
              - apps
              - data
          - finance:
              - commercial

    これらの値は hierarchy.yaml で更新する必要があります。

    • spec.config: 希望する最上位の環境フォルダ(環境サブツリーの完全なコピーが含まれるフォルダ)
    • spec.subtrees.environment: 各環境でミラーリングする、望ましい部門とチームの階層。たとえば、ブループリントは、アプリおよびデータのサブフォルダを含む小売部門から始まります。
    • spec.parentRef.external: 組織 ID に合わせてこの値を更新します
  3. 階層を追加して、git リポジトリに push します。
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

成功を検証する

リソース階層が正常に作成されたことを確認するには、次の操作を行います。

  • 組織内のフォルダを一覧表示します。
    gcloud resource-manager folders list --organization=$ORG_ID
  • クラスタの階層名前空間からフォルダのステータスを直接取得します。
    kubectl get folders -n hierarchy -o yaml \
      | grep "^    name: |message"

ネットワーク接続を確立する

ランディング ゾーンの一部として、共有 VPC ネットワーク アーキテクチャをデプロイすることをおすすめします。提供されているネットワーキング ブループリントを使用してネットワークを設定し、ハイブリッド接続用の Cloud VPN を確立します。

ホスト プロジェクトを作成する

ネットワークをデプロイする前に、ネットワークをホストするプロジェクトを作成する必要があります。これは、付属のプロジェクト ファクトリーのブループリントを使用して、環境ごとに 1 回行う必要があります。

  1. プロジェクト ブループリントをランディング ゾーンにダウンロードして、ホスト プロジェクトを作成します。
    export NET_PROJECT_ID="NETWORK_PROJECT_ID"
    export ENVIRONMENT="ENVIRONMENT"
    
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/project@kpt-v1 \
      ./landing-zone/projects/${NET_PROJECT_ID}
    

    以下を置き換えます。

    • ENVIRONMENT: 共有 VPC を構成する環境(dev など)。
    • NETWORK_PROJECT_ID: ネットワーキング プロジェクトに割り当てる ID。
  2. landing-zone/projects/NETWORK_PROJECT_ID/setters.yaml ファイルを開きます。 このブループリントをカスタマイズするには、次のセッターを置き換えます。
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      folder-name: name.of.folder
      project-id: project-id
      # These defaults can be kept
      folder-namespace: hierarchy
      networking-namespace: networking
    
    次のように値を設定します。
    • project-id: 選択した ID
    • folder-name: ネットワーク プロジェクトを格納するフォルダの ID。フォルダには接頭辞として親フォルダの名前が付加されます。たとえば、dev 環境内の shared フォルダには dev.shared の ID が割り当てられます。
  3. ブループリントを追加して、プロジェクトを共有 VPC ホスト プロジェクトにします。
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/shared-vpc@kpt-v1 \
      ./landing-zone/projects/${NET_PROJECT_ID}/host-project
    
  4. 変更を commit してプロジェクトの作成をトリガーします。
    git add ./landing-zone/projects/${NET_PROJECT_ID}/
    git commit -m "Add networking host project"
    git push
    

ネットワークを作成する

ホスト プロジェクトが完成したため、ネットワーキング ブループリントを使用して共有 VPC を作成できます。

  1. ネットワークのブループリントをランディング ゾーンに追加します。
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/network@kpt-v1 \
      ./landing-zone/network/${ENVIRONMENT}/
    
  2. landing-zone/network/ENVIRONMENT/setters.yaml ファイルを開きます。 このブループリントをカスタマイズするには、次のセッターを置き換えます。
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      # Required setters
      network-name: network-name
      project-id: project-id
      region: us-central1
      # Optional setters
      namespace: networking
      vpn-secret-key: vpn-shared-secret
      vpn-secret-name: vpn-shared-secret
      prefix: ""
    
    次のように値を設定します。
    • network-name: ネットワークに使用する名前(例: dev-network-shared
    • region: 最初のサブネットをデプロイするリージョン(例: us-east4
    • project-id: ネットワークをホストするプロジェクト ID。(NETWORK_PROJECT_ID
  3. Cloud VPN で使用される事前共有キー用のシークレットを作成します。この値は機密性が高いため、Git リポジトリに commit しないでください。代わりに、Config Controller に直接送信します。
    kubectl create secret generic vpn-shared-secret \
      --from-literal=vpn-shared-secret="SECRET_VALUE" \
      -n networking
  4. カスタマイズされたブループリントを commit して、ネットワークをデプロイします。
    git add ./landing-zone/network/
    git commit -m "Add network setup"
    git push
    

ネットワークのデプロイを確認する

次の方法で、ネットワークが正常に作成されたことを確認できます。

  • プロジェクトが正常に作成されたことを確認します。
    kubectl describe project ${NET_PROJECT_ID} -n projects
  • クラスタの階層名前空間からフォルダのステータスを直接取得します。
    kubectl get gcp \
      -n networking -o yaml \
      | grep "^    name: |message"
  • Cloud Console を介してネットワークを検査します。

ロギングデータのエクスポート

エンタープライズ企業向けの Google Cloud のベスト プラクティスの 1 つは、監査ログを詳細にモニタリングして保持することです。

ランディング ゾーンのブループリントには、ログのエクスポートと保持を管理するための複数のオプションが含まれています。

以下の手順に沿って、ブループリントをデプロイします。これにより、組織から BigQuery にすべてのログがエクスポートされ、長期的な保持と分析が可能になります。

ホスト プロジェクトを作成する

ログを BigQuery にエクスポートする場合は、ログをホストするプロジェクトが必要です。組織全体のログをエクスポートするため、このプロジェクトを本番環境に配置する必要があります。これは、ブループリントを使用して作成できます。

  1. プロジェクト ブループリントをランディング ゾーンにダウンロードして、ホスト プロジェクトを作成します。
    export LOGGING_PROJECT_ID="LOGGING_PROJECT_ID"
    
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/project@kpt-v1 \
      ./landing-zone/projects/${LOGGING_PROJECT_ID}
    

    以下を置き換えます。

    • LOGGING_PROJECT_ID: ネットワーキング プロジェクトに割り当てる ID。
  2. landing-zone/projects/LOGGING_PROJECT_ID/setters.yaml ファイルを開きます。 このブループリントをカスタマイズするには、次のセッターを置き換えます。
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      folder-name: name.of.folder
      project-id: project-id
      # These defaults can be kept
      folder-namespace: hierarchy
      networking-namespace: networking
    
    次のように値を設定します。
    • project-id: ログ エクスポートの保存用に選択したプロジェクト ID(LOGGING_PROJECT_ID
    • folder-name: ロギング プロジェクトを格納するフォルダの ID。フォルダには接頭辞として親フォルダの名前が付加されます。たとえば、dev 環境内の shared フォルダには dev.shared の ID が割り当てられます。
  3. 変更を commit してプロジェクトの作成をトリガーします。
    git add ./landing-zone/projects/${LOGGING_PROJECT_ID}/
    git commit -m "Add logging project"
    git push
    

ログを BigQuery にエクスポートする

ログを BigQuery にエクスポートすると、後で分析するためにログを保持できます。このブループリントでは、ログを保存する BigQuery データセットを作成し、そのデータセットへのエクスポートを構成します。

  1. ロギングのブループリントをランディング ゾーンに追加します。
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/log-export/org/bigquery-export@kpt-v1 ./landing-zone/logging/bigquery-export
  2. landing-zone/logging/bigquery-export/setters.yaml ファイルを開きます。 このブループリントは、プロジェクト ID を置き換えてカスタマイズします。
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      # This is required
      project-id: my-project-id
      # These defaults can be left unchanged
      namespace: logging
      dataset-description: BigQuery audit logs for organization
      dataset-location: US
      dataset-name: audit-logs
      default-table-expiration-ms: "3600000"
      delete-contents-on-destroy: "false"
      filter: ""
    
    次のように値を設定します。
    • project-id: ログの保存に選択したプロジェクト ID(LOGGING_PROJECT_ID
  3. ブループリントを commit してログのエクスポートを作成します。
    git add ./landing-zone/logging/
    git commit -m "Add log export to BigQuery"
    git push

ログのエクスポートを確認する

次の方法で、ログのエクスポートが正常に構成されていることを確認します。

  • プロジェクトが正常に作成されたことを確認します。
    kubectl describe project ${LOGGING_PROJECT} -n projects
    gcloud projects describe ${LOGGING_PROJECT_ID}
    
  • logging 名前空間内のリソースのステータスを取得します。
    kubectl get bigquerydatasets,iampolicymembers,logginglogsinks -n logging -o yaml \
      | grep "^    name: |message"
  • gcloud CLI を使用してログのエクスポートのステータスを取得します(新しいシンクがリストに表示されます)。
    gcloud logging sinks list --organization=${ORG_ID}
  • シンクが構成されてから少し経過してから、ログが BigQuery に送信されていることを確認します。

    # List tables
    bq ls --project_id ${LOGGING_PROJECT_ID} bqlogexportdataset
    
    # Query a table
    # Change this to a result of "bq ls" above so that the name matches one of your tables
    TABLE_OF_INTEREST=git_sync_20201130
    bq query --project_id ${LOGGING_PROJECT_ID} "SELECT * FROM bqlogexportdataset.${TABLE_OF_INTEREST} LIMIT 2"
    

トラブルシューティング

デフォルト ネットワーク

Config Controller を作成する際に、デフォルト ネットワークを使用できないというエラーが表示される場合があります。

Error 400: Project "" has no network named "default"., badRequest\n\n  on main.tf line 35, in resource "google_container_cluster" "acp_cluster"

このエラーは、Config Controller がデフォルト ネットワークがあることを前提としているため発生します。この問題を解決するには、新しいデフォルト ネットワークを作成する必要があります。

gcloud compute networks create default --subnet-mode=auto

ハイドレーションと Cloud Build

GitOps のブループリントの一部として、ソース リポジトリをモニタリングして変更を確認する Cloud Build トリガーを作成しました。

  1. これらの変更の内容を kpt 関数を使用して検証します。
  2. 最終的なハイドレートされた構成を生成します。この構成はデプロイ リポジトリに保存され、Config Sync によってクラスタに適用されます。

この Cloud Build パイプラインは、Console または gcloud からモニタリングできます。この gcloud コマンドを使用して、最新のビルド ステータスを取得できます。

FILTER="source.repo_source.commit_sha=$(git rev-parse HEAD)"
# You can poll on this command until status is either SUCCESS or FAILURE
gcloud builds list --project=${PROJECT_ID} --filter=${FILTER}

BUILD_ID=$(gcloud builds list --project=${PROJECT_ID} --filter=${FILTER} --format='get(id)' | head -n 1)
# View logs for your run. You can use this to debug errors
gcloud builds log --project=${PROJECT_ID} $BUILD_ID

ローカルでの実行

Cloud Build パイプラインによって送信されるよりも早く問題のフィードバックを送信する必要がある場合は、kpt を使用して次のコマンドを実行し、パイプラインをローカルで実行することもできます(ソース リポジトリのルートから実行します)。

kpt fn render ./landing-zone/

変更不可のフィールドとリソース

プロジェクト ID や VPC ネットワークの名前など、基盤となる Google Cloud リソースのフィールドには、変更できないものがあります。Config Connector は、そのようなフィールドの編集をブロックし、変更を有効にすることはできません。こうした変更不可フィールドの 1 つを編集する必要がある場合は、まず(Git で)元のリソースを削除し、続いて新しい値で追加し直す必要があります。

Deployment と Config Sync

deployment リポジトリには、ランディング ゾーンを定義する完全にハイドレートされたリソースが含まれています。これらのリソースは、Config Sync を使用して Config Controller に同期されます。この同期プロセスのエラーは、nomos コマンドで確認できます。

nomos status

課金

ランディング ゾーンのブループリントでは、組織内で請求を管理するための適切な課金権限が自動的に設定されます。プロジェクトを請求先アカウントに関連付けることができない場合は、請求先アカウントが組織外に存在する可能性があります。このため、請求先アカウントを管理する権限を、projects サービス アカウントに直接付与する必要があります。

export PROJECTS_SA="$(kubectl get ConfigConnectorContext -n projects -o jsonpath='{.items[0].spec.googleServiceAccount}')"
gcloud alpha billing accounts add-iam-policy-binding $BILLING_ACCOUNT \
  --role=roles/billing.admin \
  --member="serviceAccount:${PROJECTS_SA}"

クリーンアップ

ランディング ゾーンの使用を停止する場合は、作成したすべてのリソースをクリーンアップする必要があります。Config Controller 自体を削除する前に、まず Config Controller からリソースを削除する必要があります。

または、宣言型ワークフローを放棄してランディング ゾーンのリソースを保持する場合は、必要に応じて Config Controller の削除の処理に直接進むことができます(ただし、これはおすすめしません)。

リソースの削除

リソースは、関連付けられているファイルをランディング ゾーンの Git リポジトリから削除するだけで削除できます。この方法は、個別のリソースまたはパッケージ全体で有効です。

ただし、ランディング ゾーン全体を一度に削除することはできません(誤って削除されることを回避するためです)。代わりに、以下の手順を行い、ランディング ゾーンのリソースを破棄する必要があります

# Delete downstream resources
git rm -rf ./landing-zone/logging/
git rm -rf ./landing-zone/network/
git commit -m "Delete downstream resources"
git push
# Confirm Config Sync successfully applies

# Delete projects
git rm -rf ./landing-zone/projects/
git commit -m "Delete projects"
git push
# Confirm Config Sync successfully applies

# Delete folders and organization policies, but leave the policy template (see below for why)
git rm -rf ./landing-zone/hierarchy/
find ./landing-zone/policies/ -type f -not \( -name 'folder-naming-constraint-template.yaml' \) -delete
git add ./landing-zone/
git commit -m "Delete hierarchy and organization policies"
git push
# Confirm Config Sync successfully applies

# Delete landing zone except for 1 cluster-scoped resource
# (folder-naming-constraint-template.yaml) and 1 empty namespace (projects.yaml).
# See /anthos-config-management/docs/reference/errors#knv2006
find ./landing-zone/ -type f -not \( -name 'folder-naming-constraint-template.yaml' -or -name 'projects.yaml' \) -delete
cat <<EOF > ./landing-zone/namespaces/projects.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: projects
EOF
git add ./landing-zone/
git commit -m "Delete all landing zone resources except 1 cluster-scoped resource and 1 namespace"
git push
# Confirm Config Sync successfully applies

# Delete remaining resources
git rm -rf ./landing-zone/
git commit -m "Delete remaining resources"
git push

Config Controller の削除

gcloud alpha anthos config controller delete --location=us-central1 ${CONFIG_CONTROLLER_NAME}