Migrer votre objet ConfigManagement

Cette page explique comment migrer votre configuration Git d'un objet ConfigManagement vers un objet RootSync. La migration active les API RootSync et RepoSync, ce qui vous permet d'utiliser des fonctionnalités supplémentaires :

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. Assurez-vous que votre objet ConfigManagement n'est pas enregistré dans votre source de référence et qu'il est bien géré par Config Sync. Si tel est le cas, vous devez modifier l'objet ConfigManagement dans votre source de référence en suivant les étapes décrites dans la section Migration manuelle.

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. Le dépôt racine peut être un dépôt non structuré ou un dépôt hiérarchique. Une fois que vous avez migré la configuration pour utiliser l'objet RootSync, vous pouvez scinder le dépôt en plusieurs dépôts et configurer la synchronisation à partir de plusieurs dépôts.

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

Ouvrez l'objet ConfigManagement.
Faites une copie des valeurs dans les champs spec.git. Ces valeurs s'utilisent pour créer l'objet RootSync.
Supprimez tous les champs spec.git (y compris git:) de l'objet ConfigManagement.

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

Appliquez les modifications :

kubectl apply -f config-management.yaml

Attendez que le CRD RootSync soit créé.

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

En utilisant les valeurs que vous avez copiées à partir de l'objet ConfigManagement, créez l'objet RootSync. Exemple :
```
# 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
```
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 Federation for GKE 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 ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
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

Configurer la synchronisation à partir de plusieurs dépôts