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

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:

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

  4. 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

  5. Aplique as alterações:

    kubectl apply -f config-management.yaml

  6. Aguarde a criação do CRD RootSync.

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

  7. Usando os valores copiados do objeto ConfigManagement, crie o objeto RootSync. 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 identidade da carga de trabalho não estiver ativada em seu 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.

  8. 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