Migre o seu objeto ConfigManagement

Esta página mostra 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 lhe permitem usar funcionalidades adicionais:

Pode ativar estas APIs mesmo que queira usar apenas um repositório raiz e não queira usar nenhum repositório de espaço de nomes.

Migre as suas definições do ConfigManagement

Se estiver a usar RootSync com spec.enableLegacyFields, siga as instruções para deixar de usar campos antigos.

Se o seu objeto ConfigManagement estiver a usar spec.git, mas spec.enableMultiRepo estiver definido como falso, siga as instruções para migrar para o RootSync.

Deixe de usar campos antigos

Após a versão 1.19.0 e posteriores, o campo spec.enableLegacyFields não é suportado e a definição deste campo vai causar erros. Para usar o Config Sync versão 1.19.0 e posterior, conclua os passos seguintes para remover os campos antigos:

  1. Abra o objeto ConfigManagement.

  2. No objeto ConfigManagement, remova os campos spec.enableLegacyFields e spec.git. O objeto ConfigManagement deve ser semelhante ao seguinte:

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

  3. Aplique as alterações:

    kubectl apply -f config-management.yaml

Os campos antigos estão agora desativados sem afetar o objeto RootSync gerado a partir dos campos spec.git do objeto ConfigManagement. A migração foi concluída e já pode usar os campos git diretamente no objeto RootSync.

Migre para o RootSync

Se o seu objeto ConfigManagement estiver a usar 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, o nomos fornece o comando nomos migrate para ativar as APIs RootSync e RepoSync. Tem de atualizar nomos para a versão 1.10.0 ou posterior.

Para mais detalhes sobre como executar o comando, siga o artigo Migre de um objeto ConfigManagement para um objeto RootSync. Certifique-se de que o objeto ConfigManagement não está registado na sua fonte de verdade e é gerido pela sincronização de configuração. Se for, deve modificar o objeto ConfigManagement na sua fonte de informações fidedignas seguindo os passos descritos na migração manual.

Migração manual

Se a versão do nomos for anterior à 1.10.0, pode migrar manualmente as suas definições. Tem de definir spec.enableMultiRepo como true no objeto ConfigManagement e criar um objeto RootSync que sincronize o 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, pode dividir um repositório em vários repositórios e configurar a sincronização a partir de vários repositórios.

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

  1. Abra o objeto ConfigManagement.
  2. Crie uma cópia dos valores nos campos spec.git. Use estes valores quando 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 que copiou 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 o seguinte:

    • ROOT_FORMAT: adicione unstructured para usar um repositório não estruturado ou adicione hierarchy para usar um repositório hierárquico. Estes valores são sensíveis a maiúsculas e minúsculas. Este campo é opcional e o valor predefinido é hierarchy. Recomendamos que adicione unstructured, uma vez que este formato permite organizar as configurações da forma mais conveniente para si.
    • ROOT_REPOSITORY: adicione o URL do repositório Git a usar como repositório raiz. Pode introduzir URLs através do protocolo HTTPS ou SSH. Por exemplo, o https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Se não introduzir um protocolo, o URL é tratado como um URL HTTPS. Este campo é obrigatório.
    • ROOT_REVISION: adicione a revisão de Git (etiqueta ou hash) para fazer o check-out. Este campo é opcional e o valor predefinido é HEAD.
    • ROOT_BRANCH: adicione a ramificação do repositório a partir da qual quer sincronizar. Este campo é opcional e o valor predefinido é master.
    • ROOT_DIRECTORY: adicione o caminho no repositório Git ao diretório de raiz que contém a configuração que quer sincronizar. Este campo é opcional e a predefinição é o diretório de raiz (/) do repositório.

    • ROOT_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

      • none: Não usar autenticação
      • ssh: Use um par de chaves SSH
      • cookiefile: use um cookiefile
      • token: usar um token
      • gcpserviceaccount: Use uma conta de serviço Google para aceder a um repositório no Cloud Source Repositories.

      • gcenode: Use uma conta de serviço Google para aceder a um repositório no Cloud Source Repositories. Selecione esta opção apenas se a Workload Identity Federation para o GKE não estiver ativada no seu cluster.

        Para mais informações sobre estes tipos de autenticação, consulte o artigo Conceder acesso de leitura apenas ao Git para a sincronização de configuração.

      Este campo é obrigatório.

    • ROOT_EMAIL: se adicionou gcpserviceaccount como o seu ROOT_AUTH_TYPE, adicione o endereço de email da conta de serviço Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

  8. Aplique as alterações:

    kubectl apply -f root-sync.yaml

Tabela de comparação entre o ConfigManagement e o RootSync

A tabela seguinte oferece uma vista geral de como os campos no seu objeto ConfigManagement são mapeados para os campos num 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 (este é um valor fixo nos objetos ConfigManagement) spec.git.secretRef.name
spec.sourceFormat spec.sourceFormat
spec.git.proxy.httpProxy ou spec.git.proxy.httpsProxy spec.git.proxy

O que se segue?