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:
- 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.
- 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.
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:
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 arquivokustomization.yaml
, como neste exemplo:# kustomization.yaml commonAnnotations: configmanagement.gke.io/managed: disabled
Confirme e envie a mudança:
git commit -am 'disable Config Sync management on subset of the configuration'
Aguarde até que o objeto RootSync
root-sync
seja sincronizado usando o comandogcloud 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.Para configurar o segundo repositório, siga estas etapas:
- Crie um novo repositório ou um novo diretório no seu repositório Git.
- Copie os recursos com a anotação
configmanagement.gke.io/managed: disabled
para o novo repositório ou novo diretório. - Remova a anotação
configmanagement.gke.io/managed: disabled
no novo repositório ou diretório. - Se você estiver dividindo seu repositório raiz em mais de dois repositórios, repita essas etapas conforme necessário.
Confirme e envie a mudança:
git commit -am 'add configuration for the new root repository'
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 RootSyncroot-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.
Aguarde a sincronização do novo objeto RootSync
root-split
. Para isso, use o comandogcloud 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.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'
Aguarde até que o objeto RootSync
root-sync
seja sincronizado usando o comandogcloud
:$ 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:
O novo repositório raiz (ou novo diretório) também precisa ser hierárquico. É necessário copiar os diretórios
system/
eclusterregistry/
para o novo repositório raiz (ou o novo diretório).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.
O objeto RootSync
root-split
precisa usarspec.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.