Migrer votre objet ConfigManagement

Cette page explique comment migrer votre objet ConfigManagement vers un objet RootSync. La migration d'un objet ConfigManagement vers un objet RootSync active les API RootSync et RepoSync. Ces API vous permettent d'utiliser des fonctionnalités supplémentaires. Vous pouvez ainsi afficher des configurations Kustomize et des graphiques Helm et remplacer des valeurs système, par exemple modifier les limites de ressources et modifier le nombre de commits Git à récupérer. Vous pouvez activer ces API même si vous souhaitez n'utiliser qu'un dépôt racine et ne souhaitez pas utiliser de dépôts d'espaces de noms.

Migrer vos paramètres ConfigManagement

Utiliser nomos migrate

À partir de la version 1.10.0, nomos fournit la commande nomos migrate pour activer les API RootSync et RepoSync. Vous devez mettre à jour nomos vers la version 1.10.0 et ultérieure.

Pour en savoir plus sur l'exécution de la commande, consultez la section Migrer depuis un objet ConfigManagement vers un objet RootSync.

Migration manuelle

Si votre version de nomos est antérieure à la version 1.10.0, vous pouvez migrer manuellement vos paramètres. Vous devez définir spec.enableMultiRepo sur true dans votre objet ConfigManagement et créer un objet RootSync qui synchronise votre dépôt racine avec le cluster. Vous ne pouvez créer qu'un seul dépôt racine par cluster et le dépôt racine peut être un dépôt non structuré ou un dépôt hiérarchique.

Pour configurer le dépôt racine en migrant la configuration, effectuez les tâches suivantes :

  1. Ouvrez l'objet ConfigManagement.
  2. Faites une copie des valeurs dans les champs spec.git. Ces valeurs s'utilisent pour créer l'objet RootSync.
  3. Supprimez tous les champs spec.git (y compris git:) de l'objet ConfigManagement.
  4. Dans l'objet ConfigManagement, définissez le champ spec.enableMultiRepo sur true :

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

    kubectl apply -f config-management.yaml
    
  6. Attendez que le CRD RootSync soit créé.

    kubectl wait --for=condition=established crd rootsyncs.configsync.gke.io
    
  7. En utilisant les valeurs que vous avez copiées à partir de l'objet ConfigManagement, créez l'objet RootSync. Exemple :

    # root-sync.yaml
    # If you are using a Config Sync version earlier than 1.7.0,
    # use: apiVersion: configsync.gke.io/v1alpha1
    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
    

    Remplacez l'élément suivant :

    • ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
    • ROOT_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.
    • ROOT_REVISION : ajoutez la révision Git (tag ou hachage) à récupérer. Ce champ est facultatif et la valeur par défaut est HEAD.
    • ROOT_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master.
    • ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
    • ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

      • none : n'utiliser aucune authentification
      • ssh : utiliser une paire de clés SSH
      • cookiefile : utiliser un cookiefile
      • token : utiliser un jeton
      • gcpserviceaccount : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories.
      • gcenode : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.

        Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.

      Ce champ est obligatoire.

    • ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.

  8. Appliquez les modifications :

    kubectl apply -f root-sync.yaml
    

Tableau de comparaison ConfigManagement et RootSync

Le tableau suivant présente une correspondance des champs de votre objet ConfigMangent avec les champs d'un objet RootSync.

Champ ConfigManagement Champ 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 (il s'agit d'une valeur fixe dans les objets ConfigManagement) spec.git.secretRef.name
spec.sourceFormat spec.sourceFormat
spec.git.proxy.httpProxy ou spec.git.proxy.httpsProxy spec.git.proxy

Étape suivante