Scinder un dépôt en plusieurs dépôts

Cette page explique comment scinder en toute sécurité un dépôt racine en plusieurs dépôts racines. La procédure peut également être appliquée aux dépôts d'espaces de noms.

Un dépôt synchronisé par Config Sync fait référence à la combinaison d'un dépôt Git, d'une branche, d'une révision et d'un répertoire.

Lorsque le dépôt racine contient un grand nombre de ressources, par exemple plus de 5 000, Config Sync peut ne pas se comporter correctement pour les deux raisons suivantes :

L'objet ResourceGroup peut dépasser la limite de taille de l'objet etcd. L'objet ResourceGroup enregistre le groupe, le genre, l'espace de noms et le nom de toutes les ressources dans le dépôt Git. Si vous disposez d'un grand nombre de ressources, l'objet ResourceGroup est volumineux.
La synchronisation de toutes les ressources prend plus de temps qu'un dépôt contenant un plus petit nombre de ressources. Config Sync applique les ressources de manière séquentielle au cluster. Parfois, les ressources ne peuvent pas être appliquées correctement la première fois, et Config Sync doit réessayer de les appliquer.

Lorsque vous rencontrez ces problèmes, vous pouvez scinder votre dépôt racine en plusieurs dépôts afin que chacun d'eux dispose de moins de ressources.

Scinder un dépôt racine non structuré

Les objets RootSync sont utilisés pour expliquer les étapes. Ces étapes peuvent également être appliquées aux objets RepoSync.

Supposons que votre dépôt racine est synchronisé par l'objet RootSync root-sync. Après l'avoir scindé, vous disposez de deux dépôts racines. L'un est synchronisé par l'objet RootSync root-sync, tandis que l'autre est synchronisé par l'objet RootSync root-split.

Pour scinder le dépôt, procédez comme suit :

Dans votre dépôt racine existant, choisissez les ressources que vous souhaitez déplacer vers un autre dépôt ou répertoire, puis ajoutez-y l'annotation configmanagement.gke.io/managed: disabled. Cette annotation garantit que les objets existants du cluster ne sont pas affectés lorsque vous déplacez leur configuration d'un dépôt vers un autre. Si vous utilisez le format Kustomize ou des charts Helm, vous pouvez choisir environ la moitié des bases et ajouter l'annotation commune au fichier kustomization.yaml, comme dans l'exemple suivant :
```
# kustomization.yaml
commonAnnotations:
  configmanagement.gke.io/managed: disabled
```
Procédez au commit et au transfert de la modification : git commit -am 'disable Config Sync management on subset of the configuration'
Attendez que l'objet RootSync root-sync existant soit synchronisé à l'aide de la commande gcloud alpha anthos config sync repo describe :
```
# gcloud command
gcloud alpha anthos config sync repo describe --cluster MEMBERSHIP_NAME \
  --sync-namespace config-management-system  --sync-name root-sync
```
Remplacez MEMBERSHIP_NAME par le nom d'appartenance de votre cluster enregistré.
Configurez votre deuxième dépôt en procédant comme suit :
1. Créez un dépôt ou un répertoire dans votre dépôt Git existant.
2. Copiez les ressources avec l'annotation configmanagement.gke.io/managed: disabled dans le nouveau dépôt ou le nouveau répertoire.
3. Supprimez l'annotation configmanagement.gke.io/managed: disabled dans le nouveau dépôt ou le nouveau répertoire.
4. Si vous scindez votre dépôt racine en plus de deux dépôts, répétez ces étapes si nécessaire.

Procédez au commit et au transfert de la modification :

git commit -am 'add configuration for the new root repository'

Appliquez un objet RootSync root-split pour synchroniser le nouveau dépôt ou le nouveau répertoire afin que les objets existants du cluster soient gérés par le nouvel objet RootSync root-split.
```
 apiVersion: configsync.gke.io/v1beta1
 kind: RootSync
 metadata:
   name: root-split
   namespace: config-management-system
 spec:
   sourceFormat: unstructured
   git:
     repo: NEW_ROOT_REPOSITORY
     revision: NEW_ROOT_REVISION
     branch: NEW_ROOT_BRANCH
     dir: "NEW_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 les éléments suivants :
- NEW_ROOT_REPOSITORY : URL du dépôt Git à utiliser comme nouveau 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.
- NEW_ROOT_REVISION (facultatif) : ajoutez la révision Git (tag ou hachage) du nouveau dépôt racine à examiner.
- NEW_ROOT_BRANCH (facultatif) : ajoutez la branche du nouveau dépôt racine à partir duquel vous souhaitez effectuer la synchronisation.
- NEW_ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au nouveau répertoire racine contenant la configuration que vous souhaitez synchroniser.
- ROOT_AUTH_TYPE : doit être identique à l'objet RootSync/root-sync existant.
- ROOT_EMAIL : doit être identique à l'objet RootSync/root-sync existant.
Attendez que le nouvel objet RootSync root-split soit synchronisé. Pour ce faire, exécutez la commande gcloud alpha anthos config sync repo describe :
```
$ gcloud alpha anthos config sync repo describe --cluster MEMBERSHIP_NAME \
  --sync-namespace config-management-system  --sync-name root-split
```
Remplacez MEMBERSHIP_NAME par le nom d'appartenance de votre cluster enregistré dans lequel le dépôt racine est synchronisé.
Supprimez les ressources avec l'annotation configmanagement.gke.io/managed: disabled du dépôt d'origine. Procédez au commit et au transfert de la modification :
```
git commit -am 'remove configuration managed by the new root repository'
```
Attendez que l'objet RootSync root-sync existant soit synchronisé à l'aide de la commande gcloud :
```
$ gcloud alpha anthos config sync repo describe --cluster MEMBERSHIP_NAME \
 --sync-namespace config-management-system  --sync-name root-sync
```
Remplacez MEMBERSHIP_NAME par le nom d'appartenance de votre cluster enregistré.

Scinder un dépôt racine hiérarchique

La procédure permettant de scinder un dépôt hiérarchique est semblable à celle d'un dépôt non structuré.

Il existe trois différences principales :

Le nouveau dépôt racine (ou le nouveau répertoire) doit également être hiérarchique. Vous devez copier les répertoires existants system/ et clusterregistry/ dans le nouveau dépôt racine (ou le nouveau répertoire).
Les ressources d'un espace de noms ne peuvent pas être réparties dans plusieurs dépôts. Sinon, les différents rapprochements auront du mal à gérer l'espace de noms.
L'objet RootSync root-split doit utiliser spec.sourceFormat: hierarchical.

Comme nous recommandons des dépôts non structurés, vous pouvez également envisager de convertir votre dépôt hiérarchique en dépôt non structuré avant de le diviser.