Cloud Build を使用して複数の環境で Config Sync を使用する

このチュートリアルでは、Anthos Config Management のベスト プラクティスに従って、開発環境と本番環境の 2 つの環境で Google Kubernetes Engine(GKE)の Config Sync を設定する方法について説明します。

このシナリオでは、Foo Corp のプラットフォーム管理を例にして説明します。このプラットフォーム管理チームでは、Foo Corp アプリケーションを GKE にデプロイし、リソースを devprod の 2 つのプロジェクトに分割しています。dev プロジェクトには開発環境用の GKE クラスタが含まれ、prod プロジェクトには本番環境用の GKE クラスタが含まれています。プラットフォーム管理者は、両方の環境が Foo Corp のポリシーを遵守し、両方の環境で基本レベルのリソース(Kubernetes の Namespace やサービス アカウントなど)の整合性を維持することを目標としています。

次の図は、このチュートリアルで設定する環境の概要を示しています。

このチュートリアルで設定する環境の概要。

上の図のように、このチュートリアルでは次のリソースを作成します。

  • 2 つの Google Cloud プロジェクト(開発環境用と本番環境用)。
  • 各プロジェクトに 1 つの GKE クラスタ(devprod)。
  • 3 つの GitHub リポジトリ(foo-config-sourcefoo-config-devfoo-config-prod)。これらは、Foo Corp の YAML 構成ファイルを含む Config Sync の非構造化リポジトリです。
  • Config Sync。両方のクラスタにインストールします。dev クラスタが foo-config-dev リポジトリに、prod クラスタが foo-config-prod リポジトリに同期されます。
  • Git ユーザー名と開発者トークンを含む Secret Manager シークレット。Cloud Build は、これらのシークレットを使用して GitHub リポジトリに commit します。
  • foo-config-source リポジトリに push される Cloud Build パイプライン。このパイプラインでは、kustomize build を使用します。foo-config-source のベースとオーバーレイを使用して、YAML 構成ファイルでカスタマイズされた foo-config-dev リポジトリと foo-config-prod リポジトリをレンダリングします。これらの Kustomize オーバーレイは config-source/ フォルダにあります。

目標

  • スクリプトを実行して、Config Sync で使用するクラスタとリポジトリの作成と構成を行い、環境を準備します。
  • Kustomize を使用して 2 つの異なる環境の構成を自動的にレンダリングするため、Cloud Build トリガーを作成します。
  • 2 つの別々の環境でレンダリングされた構成を同期するように Config Sync を設定します。

費用

このチュートリアルでは、課金対象である次の Google Cloud コンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。 新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このチュートリアルを終了した後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

このチュートリアルを開始する前に、次の手順が完了していることを確認してください。

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

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

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

  3. GitHub アカウントを作成するか、アカウントへのアクセス権を取得します。

  4. GitHub で、repodelete_repo のスコープを持つ個人用のアクセス トークンを作成します。トークンの値をクリップボードにコピーします。これは後の手順で必要になります。

環境の準備

次の手順を行い、このチュートリアルで使用する環境を準備します。

  1. Cloud Shell を開きます。

    1. Google Cloud Console に移動します。

      Google Cloud Console

    2. Console の右上隅にある [Cloud Shell をアクティブにする] ボタン をクリックします。

    Cloud Shell には nomos ツールと kubectl ツールがプリインストールされています。これらのツールは、このチュートリアルで必要になります。

  2. Anthos Config Management のサンプル リポジトリのクローンを作成します。

    git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git
    
  3. このチュートリアルに必要なリソースが含まれているフォルダに移動します。

    cd anthos-config-management-samples/multi-environments-kustomize/
    
  4. このチュートリアルで使用するスクリプトを実行できるように、次の変数を設定します。

    export DEV_PROJECT="DEV_PROJECT_ID"
    export PROD_PROJECT="PROD_PROJECT_ID"
    export DEV_CLUSTER_ZONE="DEV_CLUSTER_ZONE"
    export PROD_CLUSTER_ZONE="PROD_CLUSTER_ZONE"
    export GITHUB_USERNAME="GITHUB_USERNAME"
    export GITHUB_TOKEN="GITHUB_TOKEN"
    export GITHUB_EMAIL="GITHUB_EMAIL"
    export CM_CONFIG_DIR="cloud-build-rendering"
    

    次のように置き換えます。

    • DEV_PROJECT_ID: 開発環境プロジェクトとして使用する Google Cloud プロジェクトのプロジェクト ID
    • PROD_PROJECT_ID: 本番環境プロジェクトとして使用する Google Cloud プロジェクトのプロジェクト ID
    • DEV_CLUSTER_ZONE: 開発環境クラスタを作成する Compute Engine ゾーン。例: us-central1-c
    • PROD_CLUSTER_ZONE: 本番環境クラスタを作成する Compute Engine ゾーン
    • GITHUB_USERNAME: GitHub のユーザー名
    • GITHUB_TOKEN: 始める前にで作成した個人用のアクセス トークン
    • GITHUB_EMAIL: GitHub メールアドレス
  5. GitHub のユーザー名とパスワードを使用するように、ローカルの Git 環境を構成します。

    git config --global user.name $GITHUB_USERNAME
    git config --global user.email $GITHUB_EMAIL
    git config --global credential.helper store
    git config --global credential.helper cache
    

リソースの作成

複数の環境用に Config Sync を構成する際に必要となるワークフローに集中できるように、Config Sync の構成を自動化するスクリプトが multi-environments-kustomize ディレクトリに用意されています。

クラスタを作成して登録する

  1. ./create-clusters.sh スクリプトを実行して、2 つのクラスタを作成します。

    ./create-clusters.sh
    

    このスクリプトを実行すると、dev プロジェクトに dev という名前の GKE クラスタが作成され、prod プロジェクトに prod という名前の GKE クラスタが作成されます。また、GKE と Anthos API が有効になり、dev クラスタと prod クラスタに接続します。これにより、kubectl で API にアクセスできるようになります。

    出力例:

    kubeconfig entry generated for dev.
    Fetching cluster endpoint and auth data.
    kubeconfig entry generated for prod.
    ⭐️ Done creating clusters.
    
  2. register-clusters.sh スクリプトを実行して、クラスタを 2 つの Anthos フリートに登録します。

    ./register-clusters.sh
    

    このスクリプトを実行すると、Anthos クラスタ登録用に Google Cloud サービス アカウントとキーが作成されます。このアカウントとキーが作成されたら、gcloud container hub memberships register コマンドを使用して、それぞれのプロジェクトで dev クラスタと prod クラスタを Anthos に登録します。

    出力例:

    Waiting for Feature Config Management to be created...done.
    ⭐️ Done registering clusters.
    

GitHub リポジトリを作成する

  1. 3 つの GitHub リポジトリを作成するには、create-repos.sh スクリプトを実行します。

    ./create-repos.sh
    

    このスクリプトは、foo-config-sourcefoo-config-devfoo-config-prod の 3 つの GitHub リポジトリを作成します。ユーザーが構成ファイルをソース リポジトリに commit します。CI パイプライン(数ステップで作成)は、devprod 固有の値を使用して、残りの 2 つのリポジトリに構成ファイルをレンダリングします。それ以降は、dev クラスタが foo-config-dev から同期され、prod クラスタが foo-config-prod から同期されます。

    出力例:

    # Output omitted
    😸 Creating foo-config-prod repo...
    {
      "id": 364312792,
      "node_id": "MDEwOlJlcG9zaXRvcnkzNjQzMTI3OTI=",
      "name": "foo-config-prod",
     ...
    }
    Cloning into 'foo-config-prod'...
    warning: You appear to have cloned an empty repository.
    [main (root-commit) b681a3d] Initialize
     1 file changed, 0 insertions(+), 0 deletions(-)
     create mode 100644 README.md
    Enumerating objects: 3, done.
    Counting objects: 100% (3/3), done.
    Writing objects: 100% (3/3), 211 bytes | 211.00 KiB/s, done.
    Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
    To https://github.com/askmeegs/foo-config-prod.git
    * [new branch]      main -> main
    

シークレットを作成する

  1. Git 認証情報を使用して本番環境プロジェクトに Secret Manager のシークレットを作成するには、secret-manager-git.sh スクリプトを実行します。

    ./secret-manager-git.sh
    

    この方法でシークレットを作成すると、Cloud Build が GitHub に push できるようになります。次に設定する Cloud Build パイプラインでは、Secret Manager から直接 GitHub 認証情報を取得します。

    予想される出力:

    🔐 Creating secret manager secrets in prod project...
    Created secret [github-username].
    Created version [1] of the secret [github-username].
    Created secret [github-email].
    Created version [1] of the secret [github-email].
    Created secret [github-token].
    Created version [1] of the secret [github-token].
    ✅ Granting Cloud Build secret manager access...
    Project number is: ########
    Updated IAM policy for project [project-id].
    # Output omitted
    

Cloud Build トリガーの作成

環境の構成が完了したので、Cloud Build パイプラインについて確認してみましょう。

次のコマンドを実行して、Cloud Build パイプラインを表示します。

cat foo-config-source/cloudbuild.yaml

このパイプラインでは Kustomize を使用しています。base/ ディレクトリのマニフェストを使用して、開発環境リポジトリと本番環境リポジトリのマニフェストをレンダリングしています。

予想される出力:

steps:
- name: 'gcr.io/google-samples/cloudbuild-kustomize:latest'
  id: Render foo-config-dev
  entrypoint: 'bash'
  args:
  - '-eEuo'
  - 'pipefail'
  - '-c'
  - |-
    git clone https://github.com/$$GITHUB_USERNAME/foo-config-dev && \
    cd foo-config-dev
    git config user.email $$GITHUB_EMAIL
    git config user.name $$GITHUB_USERNAME
    git remote set-url origin https://$$GITHUB_USERNAME:$$GITHUB_TOKEN@github.com/$$GITHUB_USERNAME/foo-config-dev.git
    cd ..

    kustomize build overlays/dev --output foo-config-dev/
    cd foo-config-dev

    rm README.md
    echo "Update: ${SHORT_SHA}" > README.md

    git add . && \
    git commit -m "Rendered: ${SHORT_SHA}
    Built from commit ${COMMIT_SHA} of repository foo-config-source - main branch
    Author: $(git log --format='%an <%ae>' -n 1 HEAD)" && \
    git push origin main
  secretEnv: ['GITHUB_EMAIL', 'GITHUB_USERNAME', 'GITHUB_TOKEN']
- name: 'gcr.io/google-samples/cloudbuild-kustomize:latest'
  id: Render foo-config-prod
...

GitHub の foo-config-source/ リポジトリに移動すると、base/ マニフェスト、このパイプラインで使用される dev/prod/ Kustomize オーバーレイを確認できます。

このリポジトリの各ディレクトリには kustomization.yaml ファイルが含まれています。このファイルには、Kustomize が管理してクラスタに適用する必要があるファイルが記述されています。dev/kustomization.yamlprod/kustomization.yaml では、一連のパッチが定義されています。これらのパッチは、特定の環境用の base/ リソースを操作します。

たとえば、foo-config-dev リポジトリの RoleBinding は、すべての Foo Corp のデベロッパーに、開発環境クラスタへの Pod のデプロイを許可しています。foo- config-prod リポジトリの RoleBinding は、継続的デプロイ エージェントである deploy-bot@foo-corp.com にのみ本番環境への Pod のデプロイを許可しています。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../../base
patches:
# ServiceAccount - make name unique per environ
- target:
    kind: ServiceAccount
    name: foo-ksa
  patch: |-
    - op: replace
      path: /metadata/name
      value: foo-ksa-dev
    - op: replace
      path: /metadata/namespace
      value: foo-dev
# Pod creators - give all Foo Corp developers access
- target:
    kind: RoleBinding
    name: pod-creators
  patch: |-
    - op: replace
      path: /subjects/0/name
      value: developers-all@foo-corp.com
commonLabels:
  environment: dev

トリガーを作成する

このセクションでは、ソースコードの変更で自動的にビルドを開始するように Cloud Build トリガーを作成します。

  1. Google Cloud Console で、本番環境プロジェクトを使用して Cloud Build トリガーのページに移動します。

    トリガーを開く

  2. [リポジトリを接続] をクリックします。

  3. [リポジトリを接続] ウィンドウで、次の操作を行います。

    1. [ソースの選択] フィールドで、GitHub を選択したままにして [続行] をクリックします。
    2. [GitHub アカウント] フィールドで、以前に定義した GITHUB_USERNAME が選択されていることを確認します。
    3. [リポジトリ] プルダウン リストで、foo-config-source リポジトリを選択し、[OK] をクリックします。
    4. チェックボックスをオンにして利用規約に同意します。
    5. [接続] をクリックします。
  4. リポジトリが接続されたら、[トリガーを作成] をクリックします。

  5. 表示された [トリガーの作成] ページで、次のフィールドに入力します。

    1. [名前] フィールドに、Foo-Config-Render を追加します。
    2. 必要に応じて [説明] と [タグ] フィールドを構成します。このチュートリアルでは必須ではありません。
    3. [イベント] フィールドで [ブランチに push する] を選択したままにします。
    4. [リポジトリ] プルダウン リストから foo-config-source を選択します。
    5. [ブランチ] フィールドは ^main$ のままにします。
    6. [種類] フィールドで [自動検出] を選択したままにします。
    7. [ロケーション] フィールドで、[リポジトリ] を選択したままにします。
    8. [作成] をクリックします。トリガーの概要ページに戻ります。

トリガーを実行する

このトリガーを作成する前に foo-config-source リポジトリに push されているので、開発環境リポジトリと本番環境リポジトリのレンダリングを手動でトリガーできます。

  1. トリガーリストの Foo-Config-Render 行で、[実行] をクリックします。[トリガーの実行] ウィンドウが表示されます。
  2. [トリガーの実行] ウィンドウで、[ブランチ] フィールドが main であることを確認し、[トリガーの実行] をクリックします。
  3. ブランチメインでビルドが開始しました」というメッセージが表示されます。このメッセージの [表示] をクリックすると、[ビルドの詳細] ページが表示されます。

    ビルドが正常に実行されると、Kustomize ビルドの出力がそれぞれ foo-config-dev リポジトリと foo-config-prod リポジトリに書き込まれます。

  4. ビルドが完了したら、GitHub で開発環境リポジトリまたは本番環境リポジトリのいずれかを開きます。リポジトリを含む YAML ファイルが表示されます。README が更新され、このリポジトリの最後のビルドで使用された foo-config-source リポジトリの commit SHA が表示されます。

Config Sync の設定

リポジトリに構成ファイルが追加されたので、次に Config Sync をインストールして、その結果を確認します。

Config Sync のインストール

Config Sync をインストールするには、開発環境クラスタと本番環境クラスタで、install-config-sync.sh スクリプトを実行します。

./install-config-sync.sh

予想される出力:

😺 Populating configmangement.yaml with your GitHub repo info...
🔁 Installing ConfigSync on the dev cluster...
Updated property [core/project].
Switched to context "DEV_CLUSTER".
Waiting for Feature Config Management to be updated...done.
🔁 Installing ConfigSync on the prod cluster...
Updated property [core/project].
Switched to context "PROD_CLUSTER".
Waiting for Feature Config Management to be updated...done.

これで Config Sync がリポジトリ内の構成ファイルと同期されました。

構成を確認する

このセクションでは、クラスタがリポジトリ内の構成ファイルと同期されていることを確認します。

  1. nomos status コマンドを実行して、Config Sync のインストール状態を確認します。

    nomos status
    

    開発環境クラスタと本番環境クラスタの両方がそれぞれのリポジトリと同期されているはずです。

    gke_DEV_PROJECT_ID_us-central1-c_dev
      --------------------
      <root>   https:/github.com/GITHUB_USERNAME/foo-config-dev@main
      SYNCED   8f2e196f
      Managed resources:
         NAMESPACE   NAME                                                 STATUS
                     clusterrole.rbac.authorization.k8s.io/pod-creator    Current
                     namespace/default                                    Current
                     namespace/foo                                        Current
         default     rolebinding.rbac.authorization.k8s.io/pod-creators   Current
         foo         serviceaccount/foo-ksa-dev                           Current
    
    *gke_PROD_PROJECT_ID_us-central1-c_prod
       --------------------
       <root>   https:/github.com/GITHUB_USERNAME/foo-config-prod@main
       SYNCED   c91502ee
       Managed resources:
          NAMESPACE   NAME                                                 STATUS
                      clusterrole.rbac.authorization.k8s.io/pod-creator    Current
                      namespace/default                                    Current
                      namespace/foo                                        Current
          default     rolebinding.rbac.authorization.k8s.io/pod-creators   Current
          foo         serviceaccount/foo-ksa-prod                          Current
    
      ```
    
  2. kubectl を使用して開発環境クラスタに切り替えます。

    kubectl config use-context "gke_${DEV_PROJECT}_${DEV_CLUSTER_ZONE}_dev"
    
  3. リソースが同期されていることを確認するため、名前空間を取得します。foo-config-dev リポジトリと同期された foo 名前空間が表示されるはずです。

    kubectl get namespace
    

    出力例:

    NAME                           STATUS   AGE
    config-management-monitoring   Active   9m38s
    config-management-system       Active   9m38s
    default                        Active   47h
    foo                            Active   9m5s
    kube-node-lease                Active   47h
    kube-public                    Active   47h
    kube-system                    Active   47h
    resource-group-system          Active   9m30s
    

    これで、複数の Google Cloud プロジェクトと環境で、開発環境と本番環境の構成ファイルが自動的にレンダリングされるようになりました。

クリーンアップ

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

すべてのリソースを削除する

このチュートリアルで作成したリソースを削除して、開発環境プロジェクトと本番環境プロジェクトの両方をそのまま保持するには、クリーンアップ スクリプトを実行します。

./cleanup.sh

プロジェクトを削除する

  1. Cloud Console で [リソースの管理] ページに移動します。

    [リソースの管理] に移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ