Configurer Infrastructure as Code

Cette page présente les opérations du deuxième jour du workflow Infrastructure as Code (IaC).

Prérequis

Se connecter à GitLab

  1. Ouvrez la console Web GitLab à l'adresse https://iac.GDC_URL.

    Remplacez GDC_URL par l'URL de base du projet GDC.

  2. Dans l'interface utilisateur GitLab, cliquez sur le bouton SAML Login (Connexion SAML) pour être redirigé vers la page de connexion Operations Center IT (OC IT) Active Directory Federation Services (ADFS).

  3. Connectez-vous avec vos identifiants OC IT ADFS pour afficher la page d'accueil GitLab.

  4. L'accès à la CLI nécessite un jeton d'accès personnel (PAT). Créez un PAT pour votre utilisateur avec le niveau d'accès requis en suivant ces étapes de l'article GitLab Créer un jeton d'accès personnel : https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token.

    Une fois le PAT créé, vous pouvez effectuer l'authentification à l'aide de l'outil CLI.

Workflow Infrastructure as Code

En général, un workflow IaC se compose des étapes suivantes :

  1. Générez les modifications YAML correspondantes dans le dépôt GitLab iac comme suit :

    • Si le fichier n'existe pas, sélectionnez l'icône Nouveau fichier dans la barre latérale.

    Menu du dépôt avec l'option "Nouveau fichier"

    • Dans la fenêtre pop-up Créer un fichier, saisissez le nom du nouveau fichier avec le chemin d'accès complet, puis sélectionnez Créer un fichier.

    Pop-up "Créer un fichier" pour saisir le chemin d'accès au fichier dans la zone de texte

    • Si le fichier existe, sélectionnez-le dans la barre latérale pour l'ouvrir dans un nouveau volet.

    • Apportez les modifications nécessaires au fichier.

  2. Importez la modification en tant que commit Git et envoyez-la pour un examen obligatoire du code comme suit :

    1. Sélectionnez l'option Valider dans la barre latérale pour afficher plus d'options.

    2. Rédigez un message de commit dans la zone de texte. Incluez toute information utile dans le message.

    3. Sélectionnez l'option Créer une branche.

    4. Cochez la case Démarrer une nouvelle demande de fusion.

    5. Cliquez sur Commit (Valider) pour ouvrir l'aperçu du formulaire de demande de fusion.

    6. Créez une demande de fusion et apportez les modifications nécessaires, par exemple :

      1. Dans le champ Titre, saisissez un nom pour la demande de fusion.
      2. Dans le champ Description, saisissez une description.
      3. Dans la section Options de fusion, cochez la case Supprimer la branche source lorsque la source de fusion est acceptée.
      4. Cliquez sur Create merge request (Créer une demande de fusion). La demande de fusion est envoyée automatiquement au réviseur.

  3. Demandez au propriétaire approprié d'examiner et d'approuver le commit dans le cadre du processus d'approbation multipartite.

  4. Transférez le commit.

  5. Vérifiez le résultat dans le cluster correspondant.

Conseils de débogage

Cette section décrit des conseils de débogage facultatifs pour l'IaC. Pour vérifier que vos configurations sont exactes, vous devez installer l'outil de ligne de commande Nomos.

Prévisualiser et valider les configurations de rendu

Avant que Config Sync effectue le rendu des configurations et les synchronise avec le cluster, assurez-vous que les configurations sont exactes en exécutant nomos hydrate pour prévisualiser la configuration de rendu et en exécutant nomos vet pour vérifier que le format est correct.

  1. Passez au répertoire racine Git local.

  2. Exécutez la commande nomos hydrate suivante avec les options suivantes :

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

    Dans cette commande :

    • --source-format=unstructured permet à nomos hydrate de travailler sur un dépôt non structuré. Étant donné que vous utilisez des configurations Kustomize et des charts Helm, vous devez utiliser un dépôt non structuré et ajouter cette option.
    • --output=OUTPUT_DIRECTORY vous permet de définir un chemin d'accès aux configurations de rendu. Remplacez OUTPUT_DIRECTORY par l'emplacement où vous souhaitez enregistrer le résultat.

  3. Vérifiez la syntaxe et la validité de vos configurations en exécutant nomos vet avec les options suivantes :

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

    Dans cette commande :

    • --source-format=unstructured permet à nomos vet de travailler sur un dépôt non structuré.
    • --keep-output=true enregistre les configurations de rendu.
    • --output=OUTPUT_DIRECTORY est le chemin d'accès aux configurations de rendu.

Vérifier le processus

Pour vérifier l'état de la synchronisation, procédez comme suit :

  1. Utilisez l'alias de shell ka :

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

    L'alias ka configure kubectl pour communiquer avec le cluster root-admin.

  2. Vérifiez que la synchronisation fonctionne :

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

    Vous voyez le commit utilisé par Config Sync et toute erreur éventuelle.

Une fois que vous avez vérifié l'état de la synchronisation, utilisez l'une des options suivantes :

  • Vérifiez que vous avez bien appliqué le dernier commit dans le dépôt Git :

    1. Vérifiez le champ .status.sync dans l'objet RootSync ou RepoSync. Vous pouvez accéder au champ .status.sync à l'aide de la commande suivante :

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

      Remplacez ROOT_SYNC par le nom de l'objet RootSync que vous souhaitez rechercher.

      Remplacez REPO_SYNC par le nom de l'objet RepoSync que vous souhaitez rechercher.

      Remplacez REPO_SYNC_NAMESPACE par le nom de l'objet RepoSync que vous souhaitez rechercher.

      • La valeur du champ .status.sync.commit doit correspondre à votre dernier commit.
      • Le champ .status.sync ne comporte aucune "erreur".

    2. Vérifiez que les ressources du dernier commit sont toutes rapprochées. Pour chaque objet RootSync ou RepoSync, il existe un objet ResourceGroup unique qui capture l'état de rapprochement des ressources gérées déclarées dans le dépôt Git. L'objet ResourceGroup a le même espace de noms et le même nom que l'objet RootSync ou RepoSync.

      Par exemple, pour l'objet RootSync avec le nom root-sync dans l'espace de noms config-management- system, l'objet ResourceGroup correspondant est également root-sync dans l'espace de noms config-management-system. Lorsque vous avez appliqué le dernier commit, l'objet ResourceGroup contient le groupe, le genre, l'espace de noms et le nom des ressources gérées du dernier commit.

      Exécutez la commande suivante pour obtenir un objet 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

      Remplacez ROOT_SYNC par le nom de l'objet ResourceGroup que vous souhaitez rechercher.

      Remplacez REPO_SYNC par le nom de l'objet ResourceGroup que vous souhaitez rechercher.

      Remplacez REPO_SYNC_NAMESPACE par le nom de l'objet ResourceGroup que vous souhaitez rechercher.

      • Vérifiez que .status.observedGeneration correspond à la valeur du champ .metadata.generation dans l'objet ResourceGroup.
      • Vérifiez que la condition Stalled et la condition Reconciling ont status comme "False".
      • Vérifiez que chaque élément du champ .status.resourceStatuses présente l'état Current.

  • Vérifiez si vous effectuez un commit à l'aide d'un fichier YAML :

    1. Facultatif : utilisez la commande nomos si vous configurez vos contextes 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. Si vous validez un exemple de fichier YAML, exécutez la commande suivante :

      $ ka get svc/hello

      Un service créé à partir de l'exemple YAML s'affiche.

    3. Exécutez la commande suivante :

      ka describe svc/hello

      L'objet suivant s'affiche :

      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. Ajoutez une annotation au service :

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

      Exécutez describe une nouvelle fois, vérifiez que l'annotation existe et assurez-vous que Config Sync ne l'a pas écrasée.

    5. Remplacer une annotation gérée par l'IaC :

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

      Le message d'erreur suivant s'affiche pour vous indiquer que la modification a été refusée :

      $ 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

Résoudre les problèmes d'installation

Si vous recevez des erreurs de rendu, par exemple si Kustomize ne rend pas les configurations, utilisez :

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

Voici les conteneurs dans root-reconciler :

  • git-sync : clone le dépôt Git distant.
  • Hydration-controller :Effectue le rendu des configurations Kustomize et des charts Helm si le fichier de configuration Kustomization existe dans le répertoire racine.
  • reconciler: aplatit la hiérarchie du dépôt, la rapproche via le serveur d'API et recherche les erreurs.

Pour en savoir plus, consultez le guide officiel "Résoudre les problèmes liés à Config Sync Config Management" : Google Cloud : https://cloud.google.com/anthos-config-management/docs/how-to/troubleshooting-config-sync.

Dépannage

Rétablir la connexion ADFS uniquement

Pour le débogage, il peut être utile de se connecter en tant qu'utilisateur ioadmin initial à l'aide du mot de passe par défaut. Pour réactiver la connexion par mot de passe avec GitLab, exécutez les commandes kubectl suivantes.

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

Lorsque vous avez terminé d'utiliser l'utilisateur local, réactivez l'authentification ADFS uniquement à l'aide de la commande suivante :

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

Intégrer un nouvel utilisateur depuis ADFS

Un utilisateur se connecte à Distributed Cloud avec ADFS. Un compte utilisateur est ainsi créé dans GitLab avec son compte AD.

En tant qu'administrateur, suivez les étapes ci-dessous pour ajouter manuellement un utilisateur nouvellement créé au groupe GitLab :

  1. Connectez-vous à GitLab en tant qu'administrateur GitLab ou administrateur du groupe Distributed Cloud dans GitLab.

  2. Accédez au groupe Distributed Cloud dans GitLab ou https://iac.GDC_URL/gdch.

  3. Cliquez sur Afficher le groupe dans la section "Administration" de https://iac.GDC_URL/admin/groups/gdch.

  4. Ajoutez le compte d'un utilisateur nouvellement créé au groupe Distributed Cloud en tant que développeur.

Confirmer l'état du rapprochement

Pour obtenir d'autres étapes de dépannage, vérifiez que la subcomponent a terminé la réconciliation :

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

Assurez-vous que le CR gitlab est à l'état Running :

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

Enfin, si une tâche de migration semble bloquée, vérifiez le graphique Helm du sous-composant et assurez-vous qu'il ne manque aucun secret.