Migrar seu objeto ConfigManagement

Nesta página, mostramos como migrar a configuração do Git de um objeto ConfigManagement para um objeto RootSync. A migração ativa as APIs RootSync e RepoSync, que permitem usar outros recursos:

É possível ativar essas APIs mesmo se você quiser usar apenas um repositório raiz e não quiser usar repositórios de namespace.

Migrar as configurações do ConfigManagement

Se você estiver usando RootSync com spec.enableLegacyFields, siga as instruções para Parar de usar campos legados.

Se o objeto ConfigManagement estiver usando spec.git, mas spec.enableMultiRepo estiver definido como falso, siga as instruções para Migrar para o RootSync.

Parar de usar campos legados

A partir da versão 1.19.0 e mais recentes, o campo spec.enableLegacyFields não tem suporte, e a definição desse campo vai causar erros. Para usar o Config Sync versão 1.19.0 e mais recentes, siga estas etapas para remover os campos legados:

Abra o objeto ConfigConfig.

No objeto ConfigManagement, remova os campos spec.enableLegacyFields e spec.git. Seu objeto ConfigManagement vai ser parecido com este:

# config-management.yaml
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  enableMultiRepo: true

Aplique as alterações:

kubectl apply -f config-management.yaml

Os campos legados agora são desativados sem afetar o objeto RootSync gerado a partir dos campos spec.git do objeto ConfigManagement. A migração foi concluída, e agora você pode usar os campos do Git no objeto RootSync diretamente.

Migrar para o RootSync

Se o objeto ConfigManagement estiver usando spec.git, mas spec.enableMultiRepo estiver definido como falso, siga este guia para ativar as APIs RootSync e RepoSync.

Usar `nomos migrate`

A partir da versão 1.10.0, nomos fornece o comando nomos migrate para ativar as APIs RootSync e RepoSync. Você precisa atualizar o nomos para a versão 1.10.0 e posterior.

Para mais detalhes sobre como executar o comando, siga Migrar de um objeto ConfigManagement para um objeto RootSync. Verifique se o objeto ConfigManagement não está verificado na sua fonte de verdade e é gerenciado pelo Config Sync. Se for, modifique o objeto ConfigManagement na fonte de verdade seguindo as etapas em Migração manual.

Migração manual

Se a versão do nomos for anterior à 1.10.0, será possível migrar as configurações manualmente. Defina spec.enableMultiRepo como true no objeto ConfigManagement e crie um objeto RootSync que sincronize seu repositório raiz com o cluster. O repositório raiz pode ser um repositório não estruturado ou um repositório hierárquico. Depois de migrar para usar o objeto RootSync, é possível dividir um repositório em vários repositórios e configurar a sincronização de vários repositórios.

Para configurar o repositório raiz migrando a configuração, conclua as tarefas a seguir:

Abra o objeto ConfigConfig.
Faça uma cópia dos valores nos campos de spec.git. Use esses valores ao criar o objeto RootSync.
Remova todos os campos spec.git, incluindo git:, do objeto ConfigManagement.

No objeto ConfigManagement, defina o campo spec.enableMultiRepo como true:

# config-management.yaml
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  enableMultiRepo: true

Aplique as alterações:

kubectl apply -f config-management.yaml

Aguarde a criação do CRD RootSync.

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

Usando os valores copiados do objeto ConfigManagement, crie o objeto RootSync. Por exemplo:
```
# 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
```
Substitua:
- ROOT_FORMAT: adicione unstructured para usar um repositório não estruturado ou hierarchy para usar um repositório hierárquico. Esses valores diferenciam maiúsculas de minúsculas. Este campo é opcional e o valor padrão é hierarchy. Recomendamos que você adicione unstructured como esse formato para organizar suas configurações da maneira mais conveniente para você.
- ROOT_REPOSITORY: adicione o URL do repositório Git para usar como 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. Este campo é obrigatório.
- ROOT_REVISION: adicione a revisão do Git (tag ou hash) para check-out. Este campo é opcional e o valor padrão é HEAD.
- ROOT_BRANCH: adicione a ramificação do repositório com que sincronizar. Este campo é opcional e o valor padrão é master.
- ROOT_DIRECTORY: adicione o caminho no repositório Git ao diretório raiz que contém a configuração com a qual você quer sincronizar. Esse campo é opcional, e o padrão é o diretório raiz (/) do repositório.
- ROOT_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:
  - none: não usa autenticação
  - ssh: use um par de chaves SSH
  - cookiefile: use um cookiefile
  - token: usar um token
  - gcpserviceaccount: use uma conta de serviço do Google para acessar um repositório no Cloud Source Repositories.
  - gcenode: use uma conta de serviço do Google para acessar um repositório no Cloud Source Repositories. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.
    
    Para mais informações sobre esses tipos de autenticação, consulte Como conceder acesso somente leitura do Config Sync ao Git.
  Este campo é obrigatório.
- ROOT_EMAIL: se você adicionou gcpserviceaccount como ROOT_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.
Aplique as alterações:
```
kubectl apply -f root-sync.yaml
```

Tabela de comparação ConfigManagement e RootSync

A tabela a seguir fornece uma visão geral de como os campos no objeto ConfigMangent são mapeados para os campos em um objeto RootSync.

Campo ConfigManagement	Campo 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` (valor fixo em objetos ConfigManagement)	`spec.git.secretRef.name`
`spec.sourceFormat`	`spec.sourceFormat`
`spec.git.proxy.httpProxy` ou `spec.git.proxy.httpsProxy`	`spec.git.proxy`

A seguir

Configurar a sincronização a partir de vários repositórios