Questa pagina è stata tradotta dall'API Cloud Translation.

Suddividere un repository in più repository

Questa pagina mostra come suddividere in modo sicuro un repository radice in due o più repository root. I passaggi possono essere applicati anche ai repository degli spazi dei nomi.

Un repository sincronizzato da Config Sync si riferisce alla combinazione di un repository Git, un ramo, una revisione e una directory.

Quando nel repository radice è presente un numero elevato di risorse, ad esempio più di 5000, Config Sync potrebbero non comportarsi bene per i seguenti due motivi:

L'oggetto ResourceGroup potrebbe superare il limite di dimensioni dell'oggetto etcd. L'oggetto ResourceGroup registra il gruppo, il tipo, lo spazio dei nomi e il nome di tutte le risorse nel repository Git. Un numero elevato di risorse comporta un oggetto ResourceGroup di grandi dimensioni.
La sincronizzazione di tutte le risorse richiede più tempo rispetto a un repository con un numero minore di risorse. Config Sync applica le risorse in sequenza al cluster. A volte non è possibile applicare correttamente le risorse la prima volta e Config Sync dovrà riprovare ad applicarle.

Quando riscontri questi problemi, puoi suddividere il repository radice da una a più risorse, in modo che ogni repository root abbia meno risorse.

Suddividere un repository root non strutturato

Gli oggetti RootSync vengono utilizzati per spiegare i passaggi. I passaggi possono essere applicata agli oggetti RepoSync.

Supponiamo che il repository principale sia sincronizzato dall'oggetto RootSync root-sync. Dopo la suddivisione, avrai due repository principali. Uno è sincronizzato L'oggetto RootSync root-sync mentre l'altro è sincronizzato da Oggetto RootSync root-split.

Per suddividere il repository:

Nel repository principale esistente, scegli le risorse che prevedi di spostare in un altro repository o in una directory e aggiungi l'annotazione configmanagement.gke.io/managed: disabled. Questa annotazione garantisce che gli oggetti esistenti nel cluster non siano interessati quando sposti la loro configurazione da un repository a un altro. Se utilizzi il formato Kustomize o i grafici Helm, puoi scegliere circa la metà delle basi e aggiungere l'annotazione comune al file kustomization.yaml, come in questo esempio:
```
# kustomization.yaml
commonAnnotations:
  configmanagement.gke.io/managed: disabled
```
Esegui il commit e il push della modifica: git commit -am 'disable Config Sync management on subset of the configuration'
Attendi che l'oggetto RootSync root-sync esistente venga sincronizzato utilizzando il comando 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
```
Sostituisci MEMBERSHIP_NAME con il nome dell'abbonamento del cluster registrato.
Per configurare il secondo repository:
1. Crea un nuovo repository o una nuova directory nel tuo repository Git esistente.
2. Copia le risorse con annotazioneconfigmanagement.gke.io/managed: disabled nel nuovo repository o nella nuova directory.
3. Rimuovi l'annotazione configmanagement.gke.io/managed: disabled nel nuovo repository o nella nuova directory.
4. Se stai suddividendo il repository principale in più di due repository, ripeti questi passaggi in base alle necessità.

Esegui il commit e il push della modifica:

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

Applica un oggetto RootSync root-split sincronizzare il nuovo repository o la nuova directory gli oggetti esistenti nel cluster saranno gestiti Oggetto 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
```
Sostituisci quanto segue:
- NEW_ROOT_REPOSITORY: l'URL del repository Git da utilizzare come nuovo repository principale. Puoi inserire gli URL utilizzando il protocollo HTTPS HTTP(S) o SSH. Ad esempio,https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS. Se non inserisci un protocollo, l'URL viene trattato come URL HTTPS.
- NEW_ROOT_REVISION: (facoltativo) aggiungi la revisione Git (tag o hash) del nuovo repository root.
- NEW_ROOT_BRANCH: (facoltativo) aggiungi il ramo della nuova directory principale il repository da cui eseguire la sincronizzazione.
- NEW_ROOT_DIRECTORY: (Facoltativo) aggiungi il percorso nel repository Git alla nuova directory principale contenente la configurazione con cui vuoi eseguire la sincronizzazione.
- ROOT_AUTH_TYPE: deve essere uguale al RootSync/root-sync esistente.
- ROOT_EMAIL: deve essere uguale all'oggetto RootSync/root-sync esistente.
Attendi la sincronizzazione del nuovo oggetto RootSync root-split. Questa operazione può essere eseguita mediante l'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
```
Sostituisci MEMBERSHIP_NAME con il nome dell'abbonamento del cluster registrato. con cui viene sincronizzato il repository root.
Rimuovi le risorse con l'annotazione configmanagement.gke.io/managed: disabled dal repository originale. Esegui il commit e il push della modifica:
```
git commit -am 'remove configuration managed by the new root repository'
```
Attendi che l'oggetto RootSync esistente root-sync venga sincronizzato utilizzando il comando gcloud:
```
$ gcloud alpha anthos config sync repo describe --cluster MEMBERSHIP_NAME \
 --sync-namespace config-management-system  --sync-name root-sync
```
Sostituisci MEMBERSHIP_NAME con il nome dell'abbonamento del cluster registrato.

Scomporre un repository radice gerarchico

I passaggi per suddividere un repository gerarchico sono simili a quelli per suddividere un repository non strutturato.

Esistono tre differenze principali:

Anche il nuovo repository principale (o la nuova directory) deve essere gerarchico. Devi copiare la directory esistente system/ e clusterregistry/ nel nuovo repository radice (o nella nuova directory).
Le risorse in uno spazio dei nomi non possono essere distribuite in più repository. In caso contrario, diversi riconciliatori lottano per gestire lo spazio dei nomi.
L'oggetto RootSync root-split deve utilizzare spec.sourceFormat: hierarchical.

Poiché consigliamo i repository non strutturati, ti consigliamo anche di convertire il tuo repository gerarchico in un repository non strutturato prima di suddividerlo.