ConfigManagement オブジェクトを移行する

注: ConfigManagement オブジェクトの spec.git フィールドの提供は終了しました。バージョン 1.19.0 以降、spec.git フィールドを使用して Git リポジトリを管理する新しい構成を作成することはできません。引き続き spec.git フィールドを使用している場合は、このページを使用して Git 構成を RootSync に移行できます。spec.enableLegacyFields を使用して RootSync をブートストラップした場合は、spec.git フィールドと spec.enableLegacyFields フィールドの両方を削除する必要があります。

このページでは、Git 構成を ConfigManagement オブジェクトから RootSync オブジェクトに移行する方法について説明します。この移行により、RootSync API と RepoSync API が有効になり、追加の機能を使用できます。

• 複数の信頼できる情報源から同期する
• Config Sync ダッシュボードを使用する
• Cloud Monitoring、Prometheus、またはカスタム モニタリング システムを使用して Config Sync をモニタリングする
• Kustomize 構成と Helm チャートをレンダリングする
• Artifact Registry から OCI アーティファクトを同期する
• Artifact Registry から Helm チャートを同期する
• リソース上限の変更や取得する Git commit 数の更新など、システム値をオーバーライドする

ルート リポジトリのみを使用し、Namespace リポジトリを使用しない場合は、これらの API を有効にできます。

ConfigManagement の設定を移行する

spec.enableLegacyFields で RootSync を使用している場合は、手順に沿って以前のフィールドの使用を停止します。

ConfigManagement オブジェクトで spec.git を使用しているにもかかわらず、spec.enableMultiRepo が false に設定されている場合は、手順に沿って RootSync に移行します。

以前のフィールドの使用を停止する

バージョン 1.19.0 以降では、spec.enableLegacyFields フィールドはサポートされていません。このフィールドを設定するとエラーが発生します。Config Sync バージョン 1.19.0 以降を使用するには、次の手順で以前のフィールドを削除します。

注: ConfigManagement オブジェクトから以前のフィールドを削除したら、代わりに RootSync オブジェクトを直接変更できます。

1. ConfigManagement オブジェクトを開きます。

2. ConfigManagement オブジェクトで、spec.enableLegacyFields フィールドと spec.git フィールドを削除します。ConfigManagement オブジェクトは次のようになります。

   # config-management.yaml
   apiVersion: configmanagement.gke.io/v1
   kind: ConfigManagement
   metadata:
     name: config-management
   spec:
     enableMultiRepo: true
   

3. 変更を適用します。

   kubectl apply -f config-management.yaml
   

これで、以前のフィールドが無効になりました。ただし、ConfigManagement オブジェクトの spec.git フィールドから生成された RootSync オブジェクトには影響しません。移行が完了し、RootSync オブジェクトの git フィールドを直接使用できるようになりました。

RootSync に移行する

ConfigManagement オブジェクトで spec.git を使用しているにもかかわらず、spec.enableMultiRepo が false に設定されている場合は、このガイドに沿って RootSync API と RepoSync API を有効にします。

nomos migrate を使用する

バージョン 1.10.0 以降では、nomos で nomos migrate コマンドを使用すると、RootSync API と RepoSync API を有効にできます。nomos を 1.10.0 以降に更新する必要があります。

コマンドを実行する詳しい方法については、ConfigManagement オブジェクトから RootSync オブジェクトに移行するをご覧ください。ConfigManagement オブジェクトが信頼できる情報源にチェックインされて Config Sync によって管理されていないことを確認します。チェックインされている場合は、手動移行の手順に沿って、信頼できる情報源の ConfigManagement オブジェクトを変更する必要があります。

手動移行

nomos バージョンが 1.10.0 より前の場合、設定を手動で移行できます。ConfigManagement オブジェクトで spec.enableMultiRepo を true に設定して、ルート リポジトリをクラスタに同期する RootSync オブジェクトを作成する必要があります。ルート リポジトリは、非構造化リポジトリまたは階層リポジトリのいずれかになります。RootSync オブジェクトを使用するように移行した後は、リポジトリを複数のリポジトリに分割して、複数のリポジトリからの同期を構成できます。

構成を移行してルート リポジトリを構成するには、次の操作を行います。

1. ConfigManagement オブジェクトを開きます。
2. spec.git フィールドの値をコピーします。これらの値は、RootSync オブジェクトを作成するときに使用します。
3. ConfigManagement オブジェクトから spec.git フィールド（git: を含む）をすべて削除します。

4. ConfigManagement オブジェクトの spec.enableMultiRepo フィールドを true に設定します。

   # config-management.yaml
   apiVersion: configmanagement.gke.io/v1
   kind: ConfigManagement
   metadata:
     name: config-management
   spec:
     enableMultiRepo: true
   

5. 変更を適用します。

   kubectl apply -f config-management.yaml
   

6. RootSync CRD が作成されるまで待ちます。

   kubectl wait --for=condition=established crd rootsyncs.configsync.gke.io
   

7. ConfigManagement オブジェクトからコピーした値を使用して、RootSync オブジェクトを作成します。次に例を示します。

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: root-sync
     namespace: config-management-system
   spec:
     sourceFormat: ROOT_FORMAT
     git:
       repo: ROOT_REPOSITORY
       revision: ROOT_REVISION
       branch: ROOT_BRANCH
       dir: "ROOT_DIRECTORY"
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       # secretRef should be omitted if the auth type is none, gcenode, or gcpserviceaccount.
       secretRef:
         name: git-creds
   

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

   • ROOT_FORMAT: 非構造化リポジトリを使用するには unstructured を追加し、階層型リポジトリを使用するには hierarchy を追加します。この値では大文字と小文字が区別されます。このフィールドは省略可能で、デフォルト値は hierarchy です。unstructured を追加することをおすすめします。この形式では自分にとって最も便利な方法で構成ファイルを整理できます。
   • ROOT_REPOSITORY: ルート リポジトリとして使用する Git リポジトリの URL を記述します。HTTPS または SSH プロトコルを使用する URL を入力できます。たとえば、https://github.com/GoogleCloudPlatform/anthos-config-management-samples では HTTPS プロトコルを使用します。プロトコルを入力しない場合、URL は HTTPS URL として扱われます。このフィールドは必須です。
   • ROOT_REVISION: チェックアウトする Git リビジョン（タグまたはハッシュ）を記述します。このフィールドは省略可能で、デフォルト値は HEAD です。
   • ROOT_BRANCH: 同期元となるリポジトリのブランチを記述します。このフィールドは省略可能で、デフォルト値は master です。
   • ROOT_DIRECTORY: 同期先への構成を含むルート ディレクトリへの Git リポジトリのパスを記述します。このフィールドは省略可能で、デフォルトはリポジトリのルート ディレクトリ（/）です。

   • ROOT_AUTH_TYPE: 次のいずれかの認証タイプを記述します。

     • none: 認証なし
     • ssh: SSH 認証鍵ペアを使用
     • cookiefile: cookiefile を使用
     • token: トークンを使用
     • gcpserviceaccount: Google サービス アカウントを使用して Cloud Source Repositories 内のリポジトリにアクセス。

     • gcenode: Google サービス アカウントを使用して Cloud Source Repositories 内のリポジトリにアクセス。このオプションは、Workload Identity Federation for GKE がクラスタで有効になっていない場合にのみ選択してください。

       この認証の種類の詳細については、Config Sync に Git の読み取り専用アクセス権を付与するをご覧ください。

     このフィールドは必須です。

   • ROOT_EMAIL: ROOT_AUTH_TYPE として gcpserviceaccount を追加した場合は、Google サービス アカウントのメールアドレスを追加します。例: acm@PROJECT_ID.iam.gserviceaccount.com

8. 変更を適用します。

   kubectl apply -f root-sync.yaml
   

ConfigManagement と RootSync の比較表

次の表に、ConfigMangent オブジェクトのフィールドと RootSync オブジェクトのフィールドの対応を示します。

ConfigManagement のフィールド	RootSync のフィールド
spec.git.gcpServiceAccountEmail	spec.git.gcpServiceAccountEmail
spec.git.syncRepo	spec.git.repo
spec.git.syncBranch	spec.git.branch
spec.git.policyDir	spec.git.dir
spec.git.syncWait	spec.git.period
spec.git.syncRev	spec.git.revision
spec.git.secretType	spec.git.auth
git-creds（これは ConfigManagement オブジェクトの固定値です）	spec.git.secretRef.name
spec.sourceFormat	spec.sourceFormat
spec.git.proxy.httpProxy または spec.git.proxy.httpsProxy	spec.git.proxy

次のステップ

• 複数のリポジトリからの同期の構成