Configura Infrastructure as Code

Questa pagina introduce le operazioni del secondo giorno del flusso di lavoro Infrastructure as Code (IaC).

Prerequisiti

Accedi a GitLab

  1. Apri la console web GitLab all'indirizzo https://iac.GDC_URL.

    Sostituisci GDC_URL con l'URL di base del progetto GDC.

  2. Nell'interfaccia utente di GitLab, fai clic sul pulsante SAML Login (Accesso SAML) per essere reindirizzato alla pagina di accesso di ADFS (Active Directory Federation Services) di Operations Center IT (OC IT).

  3. Accedi con le tue credenziali OC IT ADFS per visualizzare la home page di GitLab.

  4. L'accesso alla CLI richiede un token di accesso personale (PAT). Crea un PAT per il tuo utente con il livello di accesso richiesto seguendo questi passaggi dell'articolo di GitLab, Create a personal access token: https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token.

    Una volta creato un PAT, puoi eseguire l'autenticazione utilizzando lo strumento CLI.

Flusso di lavoro Infrastructure as Code

In generale, un flusso di lavoro IaC è costituito dai seguenti passaggi:

  1. Genera le modifiche YAML corrispondenti nel repository GitLab iac nel seguente modo:

    • Se il file non esiste, seleziona l'icona Nuovo file nella barra laterale.

    menu del repository con l'opzione Nuovo file

    • Nella finestra popup Crea nuovo file, inserisci il nome del nuovo file con il percorso completo e seleziona Crea file.

    popup per la creazione di un nuovo file per digitare il percorso del file nella casella di testo

    • Se il file esiste, selezionalo nella barra laterale per aprirlo in un nuovo riquadro.

    • Apporta le modifiche necessarie al file.

  2. Carica la modifica come commit Git e invia il commit per una revisione del codice obbligatoria come segue:

    1. Seleziona l'opzione Commit nella barra laterale per espandere altre opzioni.

    2. Scrivi un messaggio di commit nell'area di testo. Includi nel messaggio tutte le informazioni utili.

    3. Seleziona l'opzione Crea un nuovo ramo.

    4. Seleziona la casella di controllo Avvia una nuova richiesta di unione.

    5. Fai clic su Esegui commit per aprire l'anteprima del modulo di richiesta di unione.

    6. Crea una richiesta di unione e apporta le modifiche necessarie, ad esempio:

      1. Nel campo Titolo, inserisci un nome per la richiesta di unione.
      2. Nel campo Descrizione, inserisci una descrizione.
      3. Nella sezione Opzioni di unione, seleziona la casella di controllo Elimina il ramo di origine quando l'origine dell'unione viene accettata.
      4. Fai clic su Crea richiesta di unione. La richiesta di unione viene inviata automaticamente al revisore.

  3. Chiedi al proprietario appropriato di esaminare e approvare il commit come procedura di approvazione di più parti.

  4. Esegui il push del commit.

  5. Verifica il risultato nel cluster corrispondente.

Suggerimenti per il debug

Questa sezione descrive suggerimenti di debug facoltativi per l'IaC. Per verificare che le configurazioni siano accurate, devi aver installato lo strumento a riga di comando nomos.

Visualizzare l'anteprima e convalidare le configurazioni sottoposte a rendering

Prima che Config Sync esegua il rendering delle configurazioni e le sincronizzi con il cluster, assicurati che le configurazioni siano accurate eseguendo nomos hydrate per visualizzare l'anteprima della configurazione e nomos vet per verificare che il formato sia corretto.

  1. Passa alla directory principale di Git locale.

  2. Esegui il seguente comando nomos hydrate con i seguenti flag:

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

    In questo comando:

    • --source-format=unstructured consente a nomos hydrate di lavorare su un repository non strutturato. Poiché utilizzi configurazioni Kustomize e grafici Helm, devi utilizzare un repository non strutturato e aggiungere questo flag.
    • --output=OUTPUT_DIRECTORY ti consente di definire un percorso per le configurazioni sottoposte a rendering. Sostituisci OUTPUT_DIRECTORY con la posizione in cui vuoi salvare l'output.

  3. Controlla la sintassi e la validità delle configurazioni eseguendo nomos vet con i seguenti flag:

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

    In questo comando:

    • --source-format=unstructured consente a nomos vet di lavorare su un repository non strutturato.
    • --keep-output=true salva le configurazioni sottoposte a rendering.
    • --output=OUTPUT_DIRECTORY è il percorso delle configurazioni renderizzate.

Verificare la procedura

Per verificare lo stato della sincronizzazione, segui questi passaggi:

  1. Utilizza l'alias della shell ka:

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

    L'alias ka configura kubectl per comunicare con il cluster root-admin.

  2. Verifica che la sincronizzazione funzioni:

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

    Viene visualizzato il commit utilizzato da Config Sync e l'eventuale errore.

Una volta verificato lo stato della sincronizzazione, utilizza una delle seguenti opzioni:

  • Controlla se hai applicato correttamente l'ultimo commit nel repository Git:

    1. Controlla il campo .status.sync nell'oggetto RootSync o RepoSync. Puoi accedere al campo .status.sync con il seguente 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}'

      Sostituisci ROOT_SYNC con il nome dell'oggetto RootSync che vuoi cercare.

      Sostituisci REPO_SYNC con il nome dell'oggetto RepoSync che vuoi cercare.

      Sostituisci REPO_SYNC_NAMESPACE con il nome dell'oggetto RepoSync che vuoi cercare.

      • Il valore del campo .status.sync.commit deve essere uguale al tuo ultimo commit.
      • Il campo .status.sync non contiene "errori".

    2. Verifica che tutte le risorse nell'ultimo commit siano riconciliate. Per ogni oggetto RootSync o RepoSync, esiste un oggetto ResourceGroup univoco che acquisisce lo stato di riconciliazione delle risorse gestite dichiarate nel repository Git. L'oggetto ResourceGroup ha lo stesso spazio dei nomi e lo stesso nome dell'oggetto RootSync o RepoSync.

      Ad esempio, per l'oggetto RootSync con il nome root-sync nello spazio dei nomi config-management- system, l'oggetto ResourceGroup corrispondente è anche root-sync nello spazio dei nomi config-management-system. Una volta applicato correttamente l'ultimo commit, l'oggetto ResourceGroup contiene il gruppo, il tipo, lo spazio dei nomi e il nome delle risorse gestite dell'ultimo commit.

      Esegui questo comando per ottenere un oggetto 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

      Sostituisci ROOT_SYNC con il nome dell'oggetto ResourceGroup che vuoi cercare.

      Sostituisci REPO_SYNC con il nome dell'oggetto ResourceGroup che vuoi cercare.

      Sostituisci REPO_SYNC_NAMESPACE con il nome dell'oggetto ResourceGroup che vuoi cercare.

      • Verifica che .status.observedGeneration sia uguale al valore del campo .metadata.generation nell'oggetto ResourceGroup.
      • Verifica che la condizione Stalled e la condizione Reconciling abbiano entrambe status come "False".
      • Controlla che ogni elemento nel campo .status.resourceStatuses abbia lo stato Current.

  • Controlla se esegui un commit utilizzando un file YAML:

    1. (Facoltativo) Utilizza il comando nomos se configuri i contesti kubectl:

      $ 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 esegui il commit di un file YAML di esempio, esegui:

      $ ka get svc/hello

      Viene visualizzato un servizio creato dall'esempio YAML.

    3. Esegui questo comando:

      ka describe svc/hello

      Viene visualizzato il seguente oggetto:

      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. Aggiungi una nuova annotazione al servizio:

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

      Esegui di nuovo describe, conferma che l'annotazione esiste e verifica che Config Sync non l'abbia sovrascritta.

    5. Eseguire l'override di un'annotazione gestita da IaC:

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

      La modifica viene negata nel seguente messaggio di errore:

      $ 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

Risolvere i problemi di installazione

Se ricevi errori di rendering, ad esempio Kustomize non esegue il rendering delle configurazioni, utilizza:

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

I container in root-reconciler sono i seguenti:

  • git-sync: clona il repository Git remoto.
  • Hydration-controller:esegue il rendering delle configurazioni Kustomize e dei grafici Helm se il file di configurazione Kustomization esiste nella directory principale.
  • reconciler: Appiattisce la gerarchia del repository, la riconcilia tramite il server API e verifica la presenza di errori.

Per ulteriori informazioni, segui la guida ufficiale Risolvi i problemi di Config Sync Config Management Google Cloud: https://cloud.google.com/anthos-config-management/docs/how-to/troubleshooting-config-sync.

Risoluzione dei problemi

Eseguire il rollback dell'accesso solo ADFS

A scopo di debug, può essere utile accedere come utente ioadmin iniziale utilizzando l'accesso con password predefinita. Per aggiungere di nuovo l'accesso tramite password con GitLab, esegui i seguenti comandi 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)"

Al termine dell'utilizzo dell'utente locale, riattiva l'autenticazione solo ADFS utilizzando:

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

Eseguire l'onboarding di un nuovo utente da ADFS

Un utente accede a Distributed Cloud con ADFS. In questo modo viene creato un account utente all'interno di GitLab con il relativo account AD.

Come amministratore, completa i seguenti passaggi per aggiungere manualmente un utente appena creato al gruppo GitLab:

  1. Accedi a GitLab come amministratore di GitLab o amministratore del gruppo Distributed Cloud in GitLab.

  2. Vai al gruppo Distributed Cloud in GitLab o https://iac.GDC_URL/gdch.

  3. Fai clic su Visualizza gruppo nell'area amministratore di https://iac.GDC_URL/admin/groups/gdch.

  4. Aggiungi un account di un utente appena creato al gruppo Distributed Cloud come sviluppatore.

Confermare lo stato di riconciliazione

Per ulteriori passaggi per la risoluzione dei problemi, verifica che la subcomponent sia stata riconciliata:

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

e assicurati che la CR gitlab sia nello stato Running:

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

Infine, se un job di migrazione sembra bloccato, controlla il grafico Helm del sottocomponente e assicurati che non manchino secret.