Infrastruktur als Code konfigurieren

Auf dieser Seite werden die Abläufe am zweiten Tag des Infrastruktur als Code-(IaC-)Workflows vorgestellt.

Vorbereitung

Bei GitLab anmelden

  1. Öffnen Sie die GitLab-Webkonsole unter https://iac.GDC_URL.

    Ersetzen Sie GDC_URL durch die Basis-URL des GDC-Projekts.

  2. Klicken Sie in der GitLab-Benutzeroberfläche auf die Schaltfläche SAML-Anmeldung, um zur Anmeldeseite von Operations Center IT (OC IT) Active Directory Federation Services (ADFS) weitergeleitet zu werden.

  3. Melden Sie sich mit Ihren OC IT-ADFS-Anmeldedaten an, um die GitLab-Startseite aufzurufen.

  4. Für den CLI-Zugriff ist ein persönliches Zugriffstoken (Personal Access Token, PAT) erforderlich. Erstellen Sie ein PAT für Ihren Nutzer mit der erforderlichen Zugriffsebene. Folgen Sie dazu dieser Anleitung aus dem GitLab-Artikel Create a personal access token (Persönliches Zugriffstoken erstellen): https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token.

    Nachdem Sie ein PAT erstellt haben, können Sie die Authentifizierung mit dem CLI-Tool durchführen.

Workflow für Infrastruktur als Code

Im Allgemeinen besteht ein IaC-Workflow aus den folgenden Schritten:

  1. Generieren Sie die entsprechenden YAML-Änderungen im GitLab-Repository iac so:

    • Wenn die Datei nicht vorhanden ist, wählen Sie in der Seitenleiste das Symbol Neue Datei aus.

    Repository-Menü mit der Option „Neue Datei“

    • Geben Sie im Pop-up-Fenster Neue Datei erstellen den Namen der neuen Datei mit dem vollständigen Pfad ein und wählen Sie Datei erstellen aus.

    Popup zum Erstellen einer neuen Datei, in dem der Dateipfad in das Textfeld eingegeben werden kann

    • Wenn die Datei vorhanden ist, wählen Sie sie in der Seitenleiste aus, um sie in einem neuen Bereich zu öffnen.

    • Nehmen Sie die erforderlichen Änderungen an der Datei vor.

  2. Laden Sie die Änderung als Git-Commit hoch und senden Sie das Commit zur obligatorischen Codeüberprüfung:

    1. Wählen Sie in der Seitenleiste die Option Commit aus, um weitere Optionen zu maximieren.

    2. Schreiben Sie eine Commit-Nachricht in das Textfeld. Geben Sie alle nützlichen Informationen in der Nachricht an.

    3. Wählen Sie die Option Neuen Zweig erstellen aus.

    4. Aktivieren Sie das Kästchen Neue Zusammenführungsanfrage starten.

    5. Klicken Sie auf Commit, um die Vorschau des Zusammenführungsanfrageformulars zu öffnen.

    6. Erstellen Sie eine Zusammenführungsanfrage und nehmen Sie die erforderlichen Änderungen vor, z. B.:

      1. Geben Sie im Feld Titel einen Namen für den Merge-Request ein.
      2. Geben Sie im Feld Beschreibung eine Beschreibung ein.
      3. Wählen Sie im Abschnitt Zusammenführungsoptionen das Kästchen Quellzweig löschen, wenn die Zusammenführungsquelle akzeptiert wird aus.
      4. Klicken Sie auf Zusammenführungsanfrage erstellen. Die Zusammenführungsanfrage wird automatisch an den Prüfer gesendet.

  3. Bitten Sie den entsprechenden Inhaber, den Commit im Rahmen des Genehmigungsprozesses durch mehrere Parteien zu prüfen und zu genehmigen.

  4. Übertragen Sie das Commit per Push.

  5. Prüfen Sie das Ergebnis im entsprechenden Cluster.

Tipps zur Fehlerbehebung

In diesem Abschnitt werden optionale Tipps zur Fehlerbehebung für IaC beschrieben. Um zu prüfen, ob Ihre Konfigurationen korrekt sind, muss das Nomos-Befehlszeilentool installiert sein.

Vorschau gerenderter Konfigurationen anzeigen und diese validieren

Bevor Config Sync die Konfigurationen rendert und mit dem Cluster synchronisiert, prüfen Sie, ob die Konfigurationen korrekt sind. Führen Sie dazu nomos hydrate aus, um eine Vorschau der gerenderten Konfiguration anzuzeigen, und nomos vet, um zu prüfen, ob das Format korrekt ist.

  1. Wechseln Sie in das lokale Git-Stammverzeichnis.

  2. Führen Sie den folgenden nomos hydrate-Befehl mit den folgenden Flags aus:

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

    Dabei gilt:

    • Mit --source-format=unstructured kann nomos hydrate an einem unstrukturierten Repository arbeiten. Da Sie Kustomize-Konfigurationen und Helm-Diagramme verwenden, müssen Sie ein unstrukturiertes Repository verwenden und dieses Flag hinzufügen.
    • Mit --output=OUTPUT_DIRECTORY können Sie einen Pfad zu den gerenderten Konfigurationen definieren. Ersetzen Sie OUTPUT_DIRECTORY durch den Speicherort, an dem die Ausgabe gespeichert werden soll.

  3. Prüfen Sie die Syntax und Gültigkeit Ihrer Konfigurationen. Führen Sie dazu nomos vet mit den folgenden Flags aus:

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

    Dabei gilt:

    • Mit --source-format=unstructured kann nomos vet an einem unstrukturierten Repository arbeiten.
    • --keep-output=true speichert die gerenderten Konfigurationen.
    • --output=OUTPUT_DIRECTORY ist der Pfad zu den gerenderten Konfigurationen.

Prozess überprüfen

So prüfen Sie den Status der Synchronisierung:

  1. Verwenden Sie den Shell-Alias ka:

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

    Mit dem Alias ka wird kubectl für die Kommunikation mit dem Cluster root-admin konfiguriert.

  2. Prüfen Sie, ob die Synchronisierung funktioniert:

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

    Sie sehen den Commit, den Config Sync verwendet, und gegebenenfalls einen Fehler.

Nachdem Sie den Synchronisierungsstatus überprüft haben, haben Sie zwei Möglichkeiten:

  • Prüfen Sie, ob Sie den letzten Commit im Git-Repository erfolgreich angewendet haben:

    1. Prüfen Sie das Feld .status.sync im RootSync- oder RepoSync-Objekt. Mit dem folgenden Befehl können Sie auf das Feld .status.sync zugreifen:

      # 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}'

      Ersetzen Sie dabei ROOT_SYNC durch den Namen des RootSync-Objekts, das Sie prüfen möchten.

      Ersetzen Sie REPO_SYNC durch den Namen des RepoSync-Objekts, das Sie prüfen möchten.

      Ersetzen Sie REPO_SYNC_NAMESPACE durch den Namen des RepoSync-Objekts, das Sie prüfen möchten.

      • Der Wert des Felds .status.sync.commit muss Ihrem letzten Commit entsprechen.
      • Das Feld .status.sync enthält keine „Fehler“.

    2. Prüfen Sie, ob die Ressourcen im letzten Commit abgeglichen wurden. Für jedes RootSync- oder RepoSync-Objekt gibt es ein eigenes ResourceGroup-Objekt, das den Abgleichsstatus der im Git-Repository deklarierten verwalteten Ressourcen erfasst. Das ResourceGroup-Objekt hat denselben Namespace und denselben Namen wie das RootSync- oder RepoSync-Objekt.

      Beispiel: Für das RootSync-Objekt mit dem Namen root-sync im Namespace config-management- system ist das entsprechende ResourceGroup-Objekt auch root-sync im Namespace config-management-system. Wenn Sie den letzten Commit erfolgreich angewendet haben, enthält das ResourceGroup-Objekt die Gruppe, die Art, den Namespace und den Namen der verwalteten Ressourcen des letzten Commits.

      Führen Sie den folgenden Befehl aus, um ein ResourceGroup-Objekt abzurufen:

      # 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

      Ersetzen Sie ROOT_SYNC durch den Namen des ResourceGroup-Objekts, das Sie prüfen möchten.

      Ersetzen Sie REPO_SYNC durch den Namen des ResourceGroup-Objekts, das Sie prüfen möchten.

      Ersetzen Sie REPO_SYNC_NAMESPACE durch den Namen des ResourceGroup-Objekts, das Sie prüfen möchten.

      • Prüfen Sie, ob .status.observedGeneration dem Wert des Felds .metadata.generation im ResourceGroup-Objekt entspricht.
      • Prüfen Sie, ob die Bedingungen Stalled und Reconciling beide als status den Wert "False" haben.
      • Prüfen Sie, ob jedes Element im Feld .status.resourceStatuses den Status Current hat.

  • Prüfen Sie, ob Sie einen Commit mit einer YAML-Datei vornehmen:

    1. Optional: Verwenden Sie den Befehl nomos, wenn Sie Ihre kubectl-Kontexte konfigurieren:

      $ 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. Wenn Sie eine Beispiel-YAML-Datei committen, führen Sie Folgendes aus:

      $ ka get svc/hello

      Sie sehen einen Dienst, der aus dem Beispiel-YAML erstellt wurde.

    3. Führen Sie dazu diesen Befehl aus:

      ka describe svc/hello

      Sie sehen das folgende Objekt:

      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. Fügen Sie dem Dienst eine neue Annotation hinzu:

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

      Führen Sie describe noch einmal aus, bestätigen Sie, dass die Annotation vorhanden ist, und prüfen Sie, ob sie von Config Sync überschrieben wurde.

    5. Von IaC verwaltete Anmerkung überschreiben:

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

      Die Änderung wird in der folgenden Fehlermeldung abgelehnt:

      $ 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

Fehlerbehebung bei der Installation

Wenn Sie Rendering-Fehler erhalten, z. B. wenn Kustomize die Konfigurationen nicht rendert, verwenden Sie:

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

Die Container in root-reconciler sind:

  • git-sync: Klonen des Remote-Git-Repositorys.
  • Hydration-controller:Rendert Kustomize-Konfigurationen und Helm-Diagramme, wenn die Kustomization-Konfigurationsdatei im Stammverzeichnis vorhanden ist.
  • reconciler: vereinfacht die Repository-Hierarchie, gleicht sie über den API-Server ab und prüft auf Fehler.

Weitere Informationen finden Sie im offiziellen Leitfaden zur Fehlerbehebung bei Config Sync – Config Management  Google Cloud: https://cloud.google.com/anthos-config-management/docs/how-to/troubleshooting-config-sync.

Fehlerbehebung

Rollback der reinen ADFS-Anmeldung

Für das Debugging kann es hilfreich sein, sich mit dem Standardpasswort als ursprünglicher ioadmin-Nutzer anzumelden. Wenn Sie die Anmeldung über ein Passwort mit GitLab wieder hinzufügen möchten, führen Sie die folgenden kubectl-Befehle aus.

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

Wenn Sie den lokalen Nutzer nicht mehr benötigen, aktivieren Sie die ADFS-Authentifizierung wieder mit folgendem Befehl:

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

Neuen Nutzer über ADFS einarbeiten

Ein Nutzer meldet sich mit ADFS in Distributed Cloud an. Dadurch wird in GitLab ein Nutzerkonto mit dem AD-Konto erstellt.

Führen Sie als Administrator die folgenden Schritte aus, um einen neu erstellten Nutzer manuell zur GitLab-Gruppe hinzuzufügen:

  1. Melden Sie sich in GitLab als GitLab-Administrator oder als Administrator der Distributed Cloud-Gruppe in GitLab an.

  2. Rufen Sie in GitLab oder https://iac.GDC_URL/gdch die Gruppe „Distributed Cloud“ auf.

  3. Klicken Sie in https://iac.GDC_URL/admin/groups/gdch im Admin-Bereich auf Gruppe ansehen.

  4. Fügen Sie der Distributed Cloud-Gruppe ein Konto eines neu erstellten Nutzers als Entwickler hinzu.

Abgleichstatus bestätigen

Weitere Schritte zur Fehlerbehebung:subcomponent

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

Prüfen Sie, ob sich die CR gitlab im Status Running befindet:

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

Wenn ein Migrationsjob schließlich nicht mehr reagiert, prüfen Sie das Helm-Chart der Unterkomponente und stellen Sie sicher, dass keine Secrets fehlen.