Dividir um repositório em vários repositórios

Nesta página, mostramos como dividir um repositório raiz com segurança em dois ou mais repositórios raiz. As etapas também podem ser aplicadas a repositórios de namespace.

Um repositório sincronizado pelo Config Sync refere-se à combinação de um repositório Git, uma ramificação, uma revisão e um diretório.

Quando há um grande número de recursos, por exemplo, mais de 5.000, no seu repositório raiz, o Config Sync pode não se comportar bem pelos dois motivos a seguir:

  1. O objeto ResourceGroup pode exceder o limite de tamanho do objeto etcd. O objeto ResourceGroup registra o grupo, o tipo, o namespace e o nome de todos os recursos no repositório Git. Ter um grande número de recursos gera um grande objeto ResourceGroup.
  2. A sincronização de todos os recursos é mais demorada do que um repositório com um número menor de recursos. O Config Sync aplica os recursos sequencialmente ao cluster. Às vezes, os recursos não podem ser aplicados na primeira vez, e o Config Sync precisa aplicá-los novamente.

Ao encontrar esses problemas, é possível dividir o repositório raiz de um para vários. Assim, cada repositório raiz terá menos recursos. A sincronização de vários repositórios raiz é compatível com o Config Sync versão 1.11.0 ou posterior. Se a versão do Config Sync for anterior à 1.11.0, faça upgrade para a versão 1.11.0 ou posterior antes de interromper o repositório raiz.

Interromper um repositório raiz não estruturado

Os objetos RootSync são usados para explicar as etapas. As etapas também podem ser aplicadas aos objetos do RepoSync.

Suponha que seu repositório raiz seja sincronizado pelo objeto RootSync root-sync. Após dividi-lo, você terá dois repositórios raiz. Um é sincronizado pelo objeto RootSync root-sync, enquanto o outro é sincronizado pelo objeto RootSync root-split.

Para dividir o repositório, siga estas etapas:

  1. No repositório raiz atual, escolha os recursos que você planeja mover para um repositório diferente ou um diretório e adicione a anotação configmanagement.gke.io/managed: disabled a eles. Essa anotação garante que os objetos no cluster não sejam afetados quando você move a configuração de um repositório para outro. Se você usar o formato Kustomize ou gráficos do Helm, poderá escolher cerca de metade das bases e adicionar a anotação comum ao arquivo kustomization.yaml, como neste exemplo:

    # kustomization.yaml
    commonAnnotations:
      configmanagement.gke.io/managed: disabled
    
  2. Confirme e envie a mudança: git commit -am 'disable Config Sync management on subset of the configuration'

  3. Aguarde até que o objeto RootSync root-sync seja sincronizado usando o 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
    

    Substitua MEMBERSHIP_NAME pelo nome da assinatura do cluster registrado.

  4. Para configurar o segundo repositório, siga estas etapas:

    1. Crie um novo repositório ou um novo diretório no seu repositório Git.
    2. Copie os recursos com a anotação configmanagement.gke.io/managed: disabled para o novo repositório ou novo diretório.
    3. Remova a anotação configmanagement.gke.io/managed: disabled no novo repositório ou diretório.
    4. Se você estiver dividindo seu repositório raiz em mais de dois repositórios, repita essas etapas conforme necessário.
  5. Confirme e envie a mudança:

    git commit -am 'add configuration for the new root repository'
    
  6. Aplique um objeto RootSync root-split para sincronizar o novo repositório ou diretório para que os objetos no cluster sejam gerenciados pelo novo objeto 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
    

    Substitua:

    • NEW_ROOT_REPOSITORY: o URL do repositório Git para usar como o novo repositório raiz. É possível inserir URLs usando o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Se você não inserir um protocolo, o URL será tratado como um URL HTTPS.
    • NEW_ROOT_REVISION: (opcional) adicione a revisão do Git (tag ou hash) do novo repositório raiz para verificar.
    • NEW_ROOT_BRANCH: (opcional) adicione a ramificação do novo repositório raiz para sincronizar.
    • NEW_ROOT_DIRECTORY: (opcional) adicione o caminho no repositório Git ao novo diretório raiz que contém a configuração com a qual você quer sincronizar.
    • ROOT_AUTH_TYPE: precisa ser o mesmo que o objeto RootSync/root-sync atual.
    • ROOT_EMAIL: precisa ser o mesmo que o objeto RootSync/root-sync atual.
  7. Aguarde a sincronização do novo objeto RootSync root-split. Para isso, use o comando 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
    

    Substitua MEMBERSHIP_NAME pelo nome da assinatura do cluster registrado. Com o qual o repositório raiz está sincronizado.

  8. Remova os recursos com a anotação configmanagement.gke.io/managed: disabled do repositório original. Confirme e envie a mudança:

    git commit -am 'remove configuration managed by the new root repository'
    
  9. Aguarde até que o objeto RootSync root-sync seja sincronizado usando o comando gcloud:

    $ gcloud alpha anthos config sync repo describe --cluster MEMBERSHIP_NAME \
     --sync-namespace config-management-system  --sync-name root-sync
    

    Substitua MEMBERSHIP_NAME pelo nome da assinatura do cluster registrado.

Interromper um repositório raiz hierárquico

As etapas para dividir um repositório hierárquico são semelhantes às de quebra de um repositório não estruturado.

Há três diferenças principais:

  1. O novo repositório raiz (ou novo diretório) também precisa ser hierárquico. É necessário copiar os diretórios system/ e clusterregistry/ para o novo repositório raiz (ou o novo diretório).

  2. Os recursos em um namespace não podem se espalhar por vários repositórios. Caso contrário, diferentes reconciliadores entrarão em conflito para gerenciar o namespace.

  3. O objeto RootSync root-split precisa usar spec.sourceFormat: hierarchical.

Como recomendamos repositórios não estruturados, talvez seja uma boa ideia converter seu repositório hierárquico em um repositório não estruturado antes de compartilhá-lo.