Config Controller でリソースを管理する

Config Connector、Policy Controller、Config Sync がプリインストールされた Config Controller インスタンスを作成する方法について説明します。また、次の作業を行ってインスタンスの利用方法を学びます。

• Config Connector で Google Cloud リソースを作成し、管理する。
• デプロイする前に Policy Controller の制約を作成してポリシーを適用し、ポリシー違反を検出する。
• Google Cloud リソースを含むサンプル リポジトリと同期するように Config Sync を構成して、GitOps を設定する。

始める前に

1. Google Cloud アカウントにログインします。Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
2. Google Cloud CLI をインストールします。

3. gcloud CLI を初期化するには:

   gcloud init

4. Google Cloud プロジェクトを作成または選択します。

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

   • Google Cloud プロジェクトを作成します。

     gcloud projects create PROJECT_ID

     PROJECT_ID は、作成する Google Cloud プロジェクトの名前に置き換えます。

   • 作成した Google Cloud プロジェクトを選択します。

     gcloud config set project PROJECT_ID

     PROJECT_ID は、実際の Google Cloud プロジェクト名に置き換えます。

5. Google Cloud プロジェクトで課金が有効になっていることを確認します。

6. KRM、GKE API、Resource Manager、Service Usage API を有効にします。

   gcloud services enable krmapihosting.googleapis.com container.googleapis.com cloudresourcemanager.googleapis.com serviceusage.googleapis.com

7. Google Cloud CLI をインストールします。

8. gcloud CLI を初期化するには:

   gcloud init

9. Google Cloud プロジェクトを作成または選択します。

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

   • Google Cloud プロジェクトを作成します。

     gcloud projects create PROJECT_ID

     PROJECT_ID は、作成する Google Cloud プロジェクトの名前に置き換えます。

   • 作成した Google Cloud プロジェクトを選択します。

     gcloud config set project PROJECT_ID

     PROJECT_ID は、実際の Google Cloud プロジェクト名に置き換えます。

10. Google Cloud プロジェクトで課金が有効になっていることを確認します。

11. KRM、GKE API、Resource Manager、Service Usage API を有効にします。

    gcloud services enable krmapihosting.googleapis.com container.googleapis.com cloudresourcemanager.googleapis.com serviceusage.googleapis.com

Config Controller インスタンスを作成する

1. ターミナルで Autopilot Config Controller インスタンスを作成します。

   gcloud anthos config controller create cc-example \
       --location=us-central1 \
       --full-management
   

   この操作は、完了まで最大で 15 分ほどかかります。

   次のような出力が表示されます。

   Created instance [cc-example].
   Fetching cluster endpoint and auth data.
   kubeconfig entry generated for krmapihost-cc-example.
   

2. Config Controller エンドポイントと通信するように kubectl を構成するため、必要な認証情報とエンドポイント情報を取得します。

   gcloud anthos config controller get-credentials cc-example \
       --location us-central1
   

3. Config Controller インスタンスの一覧を表示して、インスタンスが作成されたことを確認します。

   gcloud anthos config controller list --location=us-central1
   

   次のような出力が表示されます。

   NAME                 LOCATION                 STATE
   cc-example           us-central1              RUNNING
   

成功: Config Sync、Policy Controller、Config Management コンポーネントを活用してクラスタの管理を簡素化できる Config Controller インスタンスが作成されました。

Config Controller に必要な権限を付与する

このセクションでは、Google Cloud リソースを管理する権限を Config Controller に付与します。

1. サービス アカウントのメールアドレスを格納する環境変数を設定します。

   export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \
       -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"
   

2. ポリシー バインディングを作成します。

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member "serviceAccount:${SA_EMAIL}" \
       --role "roles/owner" \
       --project PROJECT_ID
   

   PROJECT_ID は、実際のプロジェクト ID に置き換えます。

   出力は次のようになります。

   Updated IAM policy for project [PROJECT_ID].
   auditConfigs:
   - auditLogConfigs:
     - logType: ADMIN_READ
     - logType: DATA_READ
     - logType: DATA_WRITE
     service: gkehub.googleapis.com
   # Remainder of output omitted
   

Config Controller インスタンスを使用する

以降のセクションでは、Config Controller インスタンスの使用方法について説明します。

Config Connector で Google Cloud リソースを作成する

Config Controller インスタンスでは、Config Connector を活用して、Kubernetes ツールと API を使用する多くの Google Cloud サービスとリソースを管理できます。このセクションでは、Config Controller を使用して PubSubTopic リソースを作成します。

Config Connector で Pub/Sub トピックを作成手順は次のとおりです。

1. Config Connector を使用して Pub/Sub API を有効にします。

   1. 任意のテキスト エディタで enable-pubsub.yaml という名前のファイルを作成し、そのファイルに次の YAML をコピーします。

      # enable-pubsub.yaml
      apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1
      kind: Service
      metadata:
        name: pubsub.googleapis.com
        namespace: config-control
      spec:
        projectRef:
          external: projects/PROJECT_ID
      

      PROJECT_ID は、実際のプロジェクト ID に置き換えます。

   2. Pub/Sub API を有効にするには、マニフェストをクラスタに適用します。

      kubectl apply -f enable-pubsub.yaml
      

      この API の有効化には数分かかることがあります。

2. Config Connector を使用して Pub/Sub トピックを作成します。

   1. pubsub-topic.yaml という名前のファイルを作成して、次の YAML をコピーします。

      # pubsub-topic.yaml
      apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
      kind: PubSubTopic
      metadata:
        annotations:
          cnrm.cloud.google.com/project-id: PROJECT_ID
        labels:
          label-one: "value-one"
        name: example-topic
        namespace: config-control
      

   2. Pub/Sub トピックを作成します。

      kubectl apply -f pubsub-topic.yaml
      

3. Pub/Sub トピックの一覧を表示して、Config Controller によって Google Cloud にリソースが作成されていることを確認します。

   gcloud pubsub topics list
   

   出力は次のようになります。

   ---
   name: projects/PROJECT_ID/topics/start-instance-event
   ---
   labels:
     label-one: value-one
     managed-by-cnrm: 'true'
   name: projects/PROJECT_ID/topics/example-topic
   

成功: Config Controller によって Pub/Sub トピックが作成されました。同じプロセスで別のタイプの Google Cloud リソースも作成できます。詳細なリストについては、Config Connector のリソースをご覧ください。

Policy Controller でポリシーを適用する

Config Controller インスタンスでは、Policy Controller と Policy Controller の制約を使用できます。Policy Controller の一部として、Config Controller は制約テンプレート ライブラリを自動的にインストールします。このライブラリのテンプレートを使用して、Config Controller インスタンスに共通のセキュリティ管理とコンプライアンス管理を適用できます。

このセクションでは、GCPStorageLocationConstraintV1 制約テンプレートを使用して制約を作成します。このテンプレートを使用すると、Cloud Storage バケットが作成されるロケーションを制限できます。このテンプレートを使用して作成する制約では、ロケーションを us-central1 に制限します。この制約を使用して、優れた費用対効果を提供するリージョンにバケットが作成されるようにします。

制約を作成するには:

1. bucket-constraint.yaml という名前のファイルを作成して、次の YAML をコピーします。

   # bucket-constraint.yaml
   apiVersion: constraints.gatekeeper.sh/v1beta1
   kind: GCPStorageLocationConstraintV1
   metadata:
     name: storage-only-in-us-central1
   spec:
     match:
       kinds:
       - apiGroups:
         - storage.cnrm.cloud.google.com
         kinds:
         - StorageBucket
     parameters:
       locations:
       - us-central1
   

2. 制約を作成します。

   kubectl apply -f bucket-constraint.yaml
   

   次のような出力が表示されます。

   gcpstoragelocationconstraintv1.constraints.gatekeeper.sh/storage-only-in-us-central1 created`
   

3. 制約が機能していることを確認するには、Config Connector を使用して asia-southeast1 に StorageBucket リソースを作成します。

   1. asia-storage-bucket.yaml という名前のファイルを作成して、次の YAML をコピーします。

      # asia-storage-bucket.yaml
      apiVersion: storage.cnrm.cloud.google.com/v1beta1
      kind: StorageBucket
      metadata:
        name: bucket-in-disallowed-location
        namespace: config-control
      spec:
        location: asia-southeast1
      

   2. Cloud Storage バケットを作成してみましょう。

      kubectl apply -f asia-storage-bucket.yaml
      

      次のような出力が表示されます。

      Error from server (Forbidden): error when creating "STDIN": admission webhook "validation.gatekeeper.sh" denied the request: [storage-only-in-us-central1] Cloud Storage bucket <bucket-in-disallowed-location> uses a disallowed location <asia-southeast1>, allowed locations are ["us-central1"]
      

成功: Policy Controller によって制約が適用されています。これで、us-central1 にのみ Cloud Storage バケットが作成されるようになりました。制約の使用に関する詳細は、制約テンプレート ライブラリを使用するをご覧ください。

Config Sync で GitOps を設定する

Config Sync は、Git リポジトリ、OCI イメージ、Helm リポジトリに保存されている構成ファイル、ポリシー、Google Cloud リソースに Config Controller インスタンスを同期できる GitOps サービスです。Config Sync は Config Controller の状態をソースの構成ファイルに合わせて継続的に調整するため、一貫性のあるインスタンス構成を実現できます。

このセクションでは、Config Controller インスタンスを公開 GitHub リポジトリに同期させます。このリポジトリには別の PubSubTopic リソースが含まれています。このリポジトリからインスタンスを同期すると、リソースが自動的に作成され、インスタンスに適用されます。GitOps ワークフローを使用する場合は、リソースを直接適用するのではなく、Config Sync を使用してリソースを作成することすることもできます。

注: 本番環境では、安全な限定公開のリポジトリを使用します。

1. GitHub から同期するには、Cloud NAT を設定します。これを行う必要があるのは、Config Controller インスタンスが限定公開 Google Kubernetes Engine（GKE）Enterprise エディションのクラスタによってバックアップされ、限定公開クラスタノードに外部へのインターネット アクセスがないためです。

   1. Cloud NAT ルーターを作成します。このルーターは、NAT ゲートウェイを設定するために必要です。

      gcloud compute routers create cc-nat-router \
          --network default \
          --region us-central1
      

      出力は次のようになります。

      Creating router [cc-nat-router]...done.
      NAME           REGION       NETWORK
      cc-nat-router  us-central1  default
      

   2. 前の手順で作成したルーターに NAT ゲートウェイを設定します。

      gcloud compute routers nats create cc-nat-config \
          --router-region us-central1 \
          --router cc-nat-router \
          --nat-all-subnet-ip-ranges \
          --auto-allocate-nat-external-ips
      

      次のような出力が表示されます。

      Creating NAT [cc-nat-config] in router [cc-nat-router]...done.
      

2. サンプル リポジトリと同期するように Config Controller インスタンスを構成するには、cc-rootsync.yaml という名前のファイルを作成して、そのファイルに次の YAML をコピーします。

   # cc-rootsync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: root-sync
     namespace: config-management-system
   spec:
     sourceFormat: unstructured
     git:
       repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
       branch: main
       dir: config-controller-quickstart
       auth: none
   

3. 構成を適用します。

   kubectl apply -f cc-rootsync.yaml
   

   インスタンスがリポジトリと同期した後、Config Sync は Pub/Sub トピックを作成し、Config Controller インスタンスに適用します。

4. Config Sync が Git リポジトリを Config Controller インスタンスに同期させていることを確認します。

   nomos status --contexts gke_PROJECT_ID_us-central1_krmapihost-cc-example
   

   出力は次のようになります。

   *gke_PROJECT_ID_us-central1_krmapihost-cc-example
   --------------------
   <root>:root-sync                         https://github.com/GoogleCloudPlatform/anthos-config-management-samples/config-controller-quickstart@main
   SYNCED @ 2023-01-10 18:31:02 +0000 UTC   715b4295d3eac07b057cce2543275c1ee104cad8
   Managed resources:
      NAMESPACE        NAME                                                               STATUS   SOURCEHASH
      config-control   pubsubtopic.pubsub.cnrm.cloud.google.com/pubsub-topic-sample-sync  Current   715b429
      config-control   service.serviceusage.cnrm.cloud.google.com/pubsub.googleapis.com   Current   715b429
   

   この出力が表示されない場合は、数分待ってからもう一度試してください。

5. Config Controller がリソースを作成していることを確認します。

   gcloud pubsub topics list
   

   出力は次のようになります。

   name: projects/PROJECT_ID/topics/start-instance-event
   ---
   labels:
     managed-by-cnrm: 'true'
   name: projects/PROJECT_ID/topics/sample-topic
   ---
   labels:
     managed-by-cnrm: 'true'
   name: projects/PROJECT_ID/topics/pubsub-topic-sample-sync
   ---
   labels:
     label-one: value-one
     managed-by-cnrm: 'true'
   name: projects/PROJECT_ID/topics/example-topic
   

   この出力には、Config Controller インスタンスの作成セクションで作成した Pub/Sub と、インスタンスを GitHub リポジトリに同期して作成した Pub/Sub が含まれています。

成功: Config Sync を使用してリソースをデプロイできました。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトを削除する

注意: プロジェクトを削除すると、次のような影響があります。

• プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

Google Cloud プロジェクトを削除します。

gcloud projects delete PROJECT_ID

個々のリソースを削除する

1. Config Connector PubSubTopic リソースを削除します。

   kubectl delete -f pubsub-topic.yaml
   

2. Policy Controller の制約を削除します。

   kubectl delete -f bucket-constraint.yaml
   

3. NAT ルーターを削除します。

   gcloud compute routers delete cc-nat-router \
       --project=PROJECT_ID \
       --region=us-central1
   

   プロンプトが表示されたら、y キーを押します。

4. Config Sync が作成した Pub/Sub リソースを削除します。

   kubectl delete PubSubTopic pubsub-topic-sample-sync -n config-control
   

5. RootSync リソースを削除します。

   kubectl delete rootsync root-sync -n config-management-system
   

6. 任意のテキスト エディタを使用して、作成した YAML ファイルをすべて削除します。

   • enable-pubsub.yaml
   • pubsub-topic.yaml
   • bucket-constraint.yaml
   • asia-storage-bucket.yaml
   • cc-rootsync.yaml

7. Config Controller インスタンスを削除します。

   gcloud anthos config controller delete --location=us-central1 cc-example
   

   プロンプトが表示されたら、y キーを押します。

次のステップ

• Config Controller の設定方法を確認する。
• Config Controller の詳細を確認する。