Configurar a infraestrutura como código

Esta página apresenta as operações do dia 2 do fluxo de trabalho de infraestrutura como código (IaC).

Pré-requisitos

Faça login no GitLab.

  1. Abra o console da Web do GitLab em https://iac.GDC_URL.

    Substitua GDC_URL pelo URL base do projeto do GDC.

  2. Na interface do GitLab, clique no botão Login SAML para ser redirecionado à página de login dos Serviços de federação do Active Directory (ADFS) da TI do Centro de operações (OC IT).

  3. Faça login com suas credenciais do OC IT ADFS para acessar a página inicial do GitLab.

  4. O acesso à CLI exige um token de acesso pessoal (PAT, na sigla em inglês). Crie um PAT para seu usuário com o nível de acesso necessário seguindo estas etapas do artigo do GitLab, Criar um token de acesso pessoal: https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token.

    Depois de criar um PAT, é possível fazer a autenticação usando a ferramenta de CLI.

Fluxo de trabalho de infraestrutura como código

Em geral, um fluxo de trabalho de IaC consiste nas seguintes etapas:

  1. Gere as mudanças correspondentes em YAML no repositório iac do GitLab da seguinte maneira:

    • Se o arquivo não existir, selecione o ícone Novo arquivo na barra lateral.

    menu do repositório com a opção "Novo arquivo"

    • Na janela pop-up Criar novo arquivo, insira o nome do novo arquivo com o caminho completo e selecione Criar arquivo.

    criar um novo pop-up de arquivo para digitar o caminho do arquivo na caixa de texto

    • Se o arquivo existir, selecione-o na barra lateral para abrir em um novo painel.

    • Faça as mudanças necessárias no arquivo.

  2. Faça upload da mudança como uma confirmação do Git e envie para uma revisão de código obrigatória da seguinte forma:

    1. Selecione a opção Commit na barra lateral para abrir mais opções.

    2. Escreva uma mensagem de commit na área de texto. Inclua informações úteis na mensagem.

    3. Selecione a opção Criar uma nova ramificação.

    4. Marque a caixa de seleção Iniciar uma nova solicitação de mesclagem.

    5. Clique em Confirmar para abrir a prévia do formulário de solicitação de mesclagem.

    6. Crie uma solicitação de fusão e faça as mudanças necessárias, como:

      1. No campo Título, insira um nome para a solicitação de fusão.
      2. No campo Descrição, insira uma descrição.
      3. Na seção Opções de mesclagem, marque a caixa de seleção Excluir ramificação de origem quando a origem da mesclagem for aceita.
      4. Clique em Criar solicitação de mesclagem. O pedido de mesclagem é enviado automaticamente ao revisor.

  3. Peça ao proprietário adequado para revisar e aprovar o commit como o processo de aprovação de várias partes.

  4. Envie o commit.

  5. Verifique o resultado no cluster correspondente.

Dicas de depuração

Esta seção descreve dicas opcionais de depuração para IaC. Para verificar se as configurações estão corretas, é necessário ter a ferramenta de linha de comando nomos instalada.

Visualizar e validar configurações renderizadas

Antes de o Config Sync renderizar os configs e sincronizá-los com o cluster, verifique se os configs estão corretos. Para isso, execute nomos hydrate para visualizar a configuração renderizada e execute nomos vet para confirmar que o formato está correto.

  1. Mude para o diretório raiz do Git local.

  2. Execute o seguinte nomos hydrate com as seguintes sinalizações:

    nomos hydrate \
    --source-format=unstructured \
    --output=OUTPUT_DIRECTORY

    Nesse comando:

    • --source-format=unstructured permite que nomos hydrate trabalhe em um repositório não estruturado. Como você está usando configurações do Kustomize e gráficos do Helm, use um repositório não estruturado e adicione essa sinalização.
    • --output=OUTPUT_DIRECTORY permite definir um caminho para os configs renderizados. Substitua OUTPUT_DIRECTORY pelo local em que você quer que a saída seja salva.

  3. Verifique a sintaxe e a validade das configurações executando nomos vet com as sinalizações a seguir:

    nomos vet \
    --source-format=unstructured \
    --keep-output=true \
    --output=OUTPUT_DIRECTORY

    Nesse comando:

    • --source-format=unstructured permite que nomos vet funcione em um repositório não estruturado.
    • --keep-output=true salva as configurações renderizadas.
    • --output=OUTPUT_DIRECTORY é o caminho para as configurações renderizadas.

Verificar o processo

Para verificar o estado da sincronização, siga estas etapas:

  1. Use o alias do shell ka:

      $ alias ka='kubectl --kubeconfig $HOME/root-admin-kubeconfig'

    O alias ka configura o kubectl para se comunicar com o cluster root-admin.

  2. Verifique se a sincronização funciona:

     $ ka get rootsync/root-sync -n config-management-system

    Você vê o commit usado pelo Config Sync e qualquer erro, se houver.

Depois de verificar o estado da sincronização, use uma das seguintes opções:

  • Verifique se você aplicou a confirmação mais recente no repositório Git:

    1. Verifique o campo .status.sync no objeto RootSync ou RepoSync. É possível acessar o campo .status.sync pelo seguinte comando:

      # get .status.sync of a RootSync object
ka get rootsync ROOT_SYNC -n config-management-system -o jsonpath='{.status.sync}'

# get .status.sync of a RepoSync object
ka get reposync REPO_SYNC -n REPO_SYNC_NAMESPACE -o jsonpath='{.status.sync}'

      Substitua ROOT_SYNC pelo nome do objeto RootSync que você quer pesquisar.

      Substitua REPO_SYNC pelo nome do objeto RepoSync que você quer pesquisar.

      Substitua REPO_SYNC_NAMESPACE pelo nome do objeto RepoSync que você quer pesquisar.

      • O valor do campo .status.sync.commit precisa ser igual à confirmação mais recente.
      • O campo .status.sync não tem nenhum "erro".

    2. Verifique se os recursos da confirmação mais recente estão todos reconciliados. Para cada objeto RootSync ou RepoSync, há um objeto ResourceGroup exclusivo que captura o status de reconciliação dos recursos gerenciados declarados no repositório Git. O objeto ResourceGroup tem o mesmo namespace e nome do objeto RootSync ou RepoSync.

      Por exemplo, para o objeto RootSync com o nome root-sync no namespace config-management- system, o objeto ResourceGroup correspondente também é root-sync no namespace config-management-system. Quando a confirmação mais recente é aplicada com sucesso, o objeto ResourceGroup contém o grupo, o tipo, o namespace e o nome dos recursos gerenciados da confirmação mais recente.

      Execute o seguinte comando para receber um objeto ResourceGroup:

      # get the ResourceGroup object for a RootSync object
ka get resourcegroup ROOT_SYNC -n config-management-system -o yaml

# get the ResourceGroup object for a RepoSync object
ka get resourcegroup REPO_SYNC -n REPO_SYNC_NAMESPACE -o yaml

      Substitua ROOT_SYNC pelo nome do objeto ResourceGroup que você quer pesquisar.

      Substitua REPO_SYNC pelo nome do objeto ResourceGroup que você quer pesquisar.

      Substitua REPO_SYNC_NAMESPACE pelo nome do objeto ResourceGroup que você quer pesquisar.

      • Verifique se o .status.observedGeneration é igual ao valor do campo .metadata.generation no objeto ResourceGroup.
      • Verifique se as condições Stalled e Reconciling têm status como "False".
      • Verifique se cada item no campo .status.resourceStatuses tem o status como Current.

  • Verifique se você faz um commit usando um arquivo YAML:

    1. Opcional: use o comando nomos se você configurar seus kubectlcontextos:

      $ nomos status
Connecting to clusters...

*root-admin-admin@root-admin
  --------------------
  <root>:root-sync   https://iac.zone1.google.gdch.test/gdch/iac.git/infrastructure/zonal/zones/ZONE_NAME/root-admin@main
  SYNCED             4a276fb67d17471f1ba812c725b75a76a1715009
  Managed resources:
     NAMESPACE   NAME             STATUS
     default     service/hello    Unknown

    2. Se você confirmar um exemplo de arquivo YAML, execute:

      $ ka get svc/hello

      Um serviço criado com o exemplo de YAML vai aparecer.

    3. Execute este comando:

      ka describe svc/hello

      Você vai ver o seguinte objeto:

      Name:         myrole
Labels:       app.kubernetes.io/managed-by=configmanagement.gke.io
              configsync.gke.io/declared-version=v1
Annotations:  config.k8s.io/owning-inventory: config-management-system_root-sync
              configmanagement.gke.io/cluster-name: my-cluster
              configmanagement.gke.io/managed: enabled
              configmanagement.gke.io/source-path: config-sync-quickstart/multirepo/root/gamestore-myrole.yaml
              configmanagement.gke.io/token: 747b843a7ddbd945c0616034a935cf648b58e7b5
              configsync.gke.io/declared-fields: {"f:rules":{}}
              configsync.gke.io/git-context: {"repo":"https://github.com/GoogleCloudPlatform/anthos-config-management-samples","branch":"main","rev":"HEAD"}
              configsync.gke.io/manager: :root
              configsync.gke.io/resource-id: rbac.authorization.k8s.io_role_gamestore_myrole
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get list]

    4. Adicione uma nova anotação ao serviço:

      $ ka annotate --overwrite svc/hello google.com/test=aaa

      Execute describe mais uma vez, confirme se a anotação existe e verifique se o Config Sync não a substituiu.

    5. Substituir uma anotação gerenciada pela IaC:

      $ ka annotate --overwrite svc/hello google.com/annotation-in-iac=value-from-kubectl

      A mudança será negada na seguinte mensagem de erro:

      $ ka annotate --overwrite svc/hello google.com/annotation-in-iac=asfas
Error from server (Forbidden): admission webhook "v1.admission-webhook.configsync.gke.io" denied the request: kubernetes-admin cannot modify fields of object "_service_default_hello" managed by Config Sync: .metadata.annotations.google.com/annotation-in-iac

Resolver problemas na instalação

Se você receber erros de renderização, como o Kustomize não renderizar as configurações, use:

$ ka logs -n config-management-system deployment/root-reconciler -c hydration-controller -f

Os contêineres em root-reconciler são os seguintes:

  • git-sync: clona o repositório Git remoto.
  • Hydration-controller:renderiza configurações do Kustomize e gráficos do Helm se o arquivo de configuração do Kustomization existir no diretório raiz.
  • reconciler: Nivela a hierarquia do repositório, a reconcilia com o servidor da API e verifica se há erros.

Para mais informações, siga o guia oficial "Solucionar problemas do Config Sync" Gerenciamento de configurações Google Cloud: https://cloud.google.com/anthos-config-management/docs/how-to/troubleshooting-config-sync.

Solução de problemas

Reverter o login somente com o ADFS

Para fins de depuração, pode ser útil fazer login como o usuário inicial do ioadmin usando o login com senha padrão. Para adicionar novamente o login com senha no GitLab, execute os seguintes comandos kubectl.

  export TOOLBOX=$(kubectl get pods --no-headers=true -n gitlab-system -lapp=toolbox,release=gitlab -o name | cut -c 5-)
  # Wait for pod to be ready.
  kubectl wait pods -n gitlab-system -lapp=toolbox,release=gitlab --for condition=Ready
  kubectl exec $TOOLBOX -n gitlab-system -- /srv/gitlab/bin/rails runner "Gitlab::CurrentSettings.update!(password_authentication_enabled_for_web: true)"

Quando terminar de usar o usuário local, reative a autenticação somente do ADFS usando:

export TOOLBOX=$(kubectl get pods --no-headers=true -n gitlab-system -lapp=toolbox,release=gitlab -o name | cut -c 5-)
# Wait for pod to be ready.
kubectl wait pods -n gitlab-system -lapp=toolbox,release=gitlab --for condition=Ready
kubectl exec $TOOLBOX -n gitlab-system -- /srv/gitlab/bin/rails runner "Gitlab::CurrentSettings.update!(password_authentication_enabled_for_web: false)"

Integrar um novo usuário do ADFS

Um usuário faz login no Distributed Cloud com o ADFS. Isso cria uma conta de usuário no GitLab com a conta do AD.

Como administrador, siga estas etapas para adicionar manualmente um usuário recém-criado ao grupo do GitLab:

  1. Faça login no GitLab como administrador do GitLab ou administrador do grupo do Distributed Cloud no GitLab.

  2. Navegue até o grupo Distributed Cloud no GitLab ou https://iac.GDC_URL/gdch.

  3. Clique em Ver grupo na Área de administração em https://iac.GDC_URL/admin/groups/gdch.

  4. Adicione uma conta de um usuário recém-criado ao grupo do Distributed Cloud como desenvolvedor.

Confirmar o status da conciliação

Para mais etapas de solução de problemas, verifique se o subcomponent foi reconciliado:

root@count-bootstrapper:~/adfs# kr get subcomponent -n root iac-gitlab
NAME         AGE   STATUS
iac-gitlab   10d   ReconciliationCompleted

Verifique se o CR gitlab está no estado Running:

root@count-bootstrapper:~/adfs# kr get gitlab -n gitlab-system gitlab
NAME     STATUS    VERSION
gitlab   Running   7.11.10

Por fim, se um job de migração parecer travado, verifique o gráfico do Helm do subcomponente e confira se não há segredos ausentes.