Configure 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

Inicie sessão no GitLab

  1. Abra a consola Web do GitLab em https://iac.GDC_URL.

    Substitua GDC_URL pelo URL base do projeto do GDC.

  2. Na IU do GitLab, clique no botão Início de sessão SAML para ser redirecionado para a página de início de sessão dos Active Directory Federation Services (ADFS) do centro de TI do centro de operações (OC IT).

  3. Inicie sessão com as suas credenciais do ADFS de TI da OC para ver a página inicial do GitLab.

  4. O acesso à CLI requer uma chave de acesso pessoal (PAT). Crie um PAT para o seu utilizador com o nível de acesso necessário seguindo estes passos do artigo do GitLab, Crie 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, pode fazer a autenticação através da ferramenta CLI.

Fluxo de trabalho de infraestrutura como código

Em geral, um fluxo de trabalho de IaC consiste nos seguintes passos:

  1. Gere as alterações YAML correspondentes no repositório iac do GitLab da seguinte forma:

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

    Menu do repositório com a opção Novo ficheiro

    • Na janela de pop-up Criar novo ficheiro, introduza o nome do novo ficheiro com o caminho completo e selecione Criar ficheiro.

    criar pop-up de novo ficheiro para escrever o caminho do ficheiro na caixa de texto

    • Se o ficheiro existir, na barra lateral, selecione o ficheiro para o abrir num novo painel.

    • Faça as alterações necessárias ao ficheiro.

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

    1. Selecione a opção Confirmar na barra lateral para expandir 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. Selecione a caixa de verificação Iniciar um novo pedido de união.

    5. Clique em Confirmar para abrir a pré-visualização do formulário de pedido de união.

    6. Crie um pedido de união e faça as alterações necessárias, como:

      1. No campo Título, introduza um nome para o pedido de união.
      2. No campo Descrição, introduza uma descrição.
      3. Na secção Opções de união, selecione a caixa de verificação Eliminar ramo de origem quando a origem da união for aceite.
      4. Clique em Criar pedido de união. O pedido de união é enviado automaticamente para o revisor.
  3. Peça ao proprietário adequado para rever e aprovar a confirmação como o processo de aprovação de várias partes.

  4. Envie a consolidação.

  5. Valide o resultado no cluster correspondente.

Sugestões de depuração

Esta secção descreve dicas de depuração opcionais para a IaC. Para verificar se as suas configurações estão corretas, tem de ter a ferramenta de linha de comandos nomos instalada.

Pré-visualize e valide as configurações renderizadas

Antes de o Config Sync renderizar as configurações e sincronizá-las com o cluster, certifique-se de que as configurações estão corretas executando nomos hydrate para pré-visualizar a configuração renderizada e executando nomos vet para validar se o formato está correto.

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

  2. Execute o seguinte comando nomos hydrate com as seguintes flags:

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

    Neste comando:

    • --source-format=unstructured permite que nomos hydrate funcione num repositório não estruturado. Uma vez que está a usar configurações do Kustomize e gráficos do Helm, tem de usar um repositório não estruturado e adicionar este sinalizador.
    • O --output=OUTPUT_DIRECTORY permite-lhe definir um caminho para as configurações renderizadas. Substitua OUTPUT_DIRECTORY pela localização onde quer guardar o resultado.
  3. Verifique a sintaxe e a validade das suas configurações executando nomos vet com os seguintes flags:

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

    Neste comando:

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

Valide o processo

Para validar o estado da sincronização, siga os passos seguintes:

  1. Use o alias de shell ka:

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

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

  2. Verifique se a sincronização funciona:

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

    Vê a confirmação que o Config Sync usa e qualquer erro, se estiver presente.

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

  • Verifique se aplicou a consolidação mais recente no repositório Git com êxito:

    1. Verifique o campo .status.sync no objeto RootSync ou RepoSync. Pode aceder ao campo .status.sync através do 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 quer procurar.

      Substitua REPO_SYNC pelo nome do objeto RepoSync que quer procurar.

      Substitua REPO_SYNC_NAMESPACE pelo nome do objeto RepoSync que quer procurar.

      • O valor do campo .status.sync.commit tem de ser igual à sua confirmação mais recente.
      • O campo .status.sync não tem "erros".
    2. Verifique se todos os recursos na confirmação mais recente estão reconciliados. Para cada objeto RootSync ou RepoSync, existe um objeto ResourceGroup único que capta o estado de conciliação dos recursos geridos declarados no repositório Git. O objeto ResourceGroup tem o mesmo espaço de nomes e nome que o objeto RootSync ou RepoSync.

      Por exemplo, para o objeto RootSync com o nome root-sync no espaço de nomes config-management- system, o objeto ResourceGroup correspondente também é root-sync no espaço de nomes config-management-system. Quando tiver aplicado a confirmação mais recente com êxito, o objeto ResourceGroup contém o grupo, o tipo, o espaço de nomes e o nome dos recursos geridos da confirmação mais recente.

      Execute o seguinte comando para obter 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 quer procurar.

      Substitua REPO_SYNC pelo nome do objeto ResourceGroup que quer procurar.

      Substitua REPO_SYNC_NAMESPACE pelo nome do objeto ResourceGroup que quer procurar.

      • Verifique se o valor de .status.observedGeneration é igual ao valor do campo .metadata.generation no objeto ResourceGroup.
      • Verifique se a condição Stalled e a condição Reconciling têm status como "False".
      • Verifique se cada item no campo .status.resourceStatuses tem o estado Current.
  • Verifique se faz uma confirmação através de um ficheiro YAML:

    1. Opcional: use o comando nomos se configurar os 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 confirmar um ficheiro YAML de exemplo, execute:

      $ ka get svc/hello
      

      Vê um serviço criado a partir do YAML de exemplo.

    3. Execute o seguinte comando:

      ka describe svc/hello
      

      Vê 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 que a anotação existe e verifique se o Config Sync não a substituiu.

    5. Substitua uma anotação gerida pela IaC:

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

      A alteração é recusada e é apresentada a 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
      

Resolva problemas de instalação

Se 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 contentores no 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 ficheiro de configuração do Kustomization existir no diretório raiz.
  • reconciler: Aplaina a hierarquia do repositório, reconcilia-a através do servidor da API e verifica se existem erros.

Para mais informações, siga o guia oficial, Resolução de problemas da sincronização de configuração Gestão de configuração Google Cloud: https://cloud.google.com/anthos-config-management/docs/how-to/troubleshooting-config-sync.

Resolução de problemas

Reverta o início de sessão apenas do ADFS

Para fins de depuração, pode ser útil iniciar sessão como o utilizador ioadmin inicial através do início de sessão com a palavra-passe predefinida. Para voltar a adicionar a iniciar sessão através de uma palavra-passe com o 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 utilizador local, reative a autenticação apenas do ADFS através do seguinte comando:

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)"

Integre um novo utilizador do ADFS

Um utilizador inicia sessão no Distributed Cloud com o ADFS. Isto cria uma conta de utilizador no GitLab com a respetiva conta do AD.

Como administrador, conclua os passos seguintes para adicionar manualmente um utilizador recém-criado ao grupo do GitLab:

  1. Inicie sessão no GitLab como administrador do GitLab ou administrador do grupo Distributed Cloud no GitLab.

  2. Navegue para 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 utilizador recém-criado ao grupo Distributed Cloud como programador.

Confirme o estado de reconciliação

Para ver passos adicionais de resolução de problemas, verifique se a subcomponent foi reconciliada:

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

Certifique-se de que 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 último, se uma tarefa de migração parecer estar bloqueada, verifique o gráfico Helm do subcomponente e certifique-se de que não existem segredos em falta.