GitOps

Bienvenue pour ce dernier défi et non des moindres ! En effet, dans ce défi vous aurez pour tâche de mettre en place l’automatisation nécessaire pour déployer l’application via des processus GitOps.

Entre temps, l’application que vous avez manipulée a un peu évolué :

  • antennas-front fait maintenant des appels API (REST) à un composant antennas-incident.

  • antennas-incident s’appuie sur une base de données MariaDB pour stocker ses données.

Un troisième dépôt Git fait son apparition, antennas-gitops, pour stocker les manifests Kubernetes à déployer.

gitops
Figure 1. Processus GitOps

Le pipeline CI/CD que nous allons mettre en oeuvre ira construire l’application et son image de conteneur. Il déploiera l’application dans un environnement de test pour y dérouler des tests d’intégration. Ensuite, si ces tests sont concluants, il mettra à jour les manifests Kubernetes avec la nouvelle image de conteneur et créera une Merge Request sur GitLab.

Une fois cette Merge Request fusionnée dans la branche principale, OpenShift GitOps ira appliquer ces changements dans l’environnement de production.

Préparatifs

Forkez le dépôt suivant : antennas-gitops

Créez trois projets dans OpenShift, correspondant aux environnements de développement, test et production.

oc new-project antennas-dev
oc new-project antennas-test
oc new-project antennas-prod

[Challenge 6.1] Beginner

Dans ce défi, votre tâche est de réaliser la toute fin du processus GitOps pour que lors d’un Commit (dépôt antennas-gitops), les changements sont appliqués à l’environnement de production (projet antennas-prod).

Il vous faudra :

  • Installer l’opérateur OpenShift GitOps

  • Ajouter un Webhook au dépôt antennas-gitops pour qu’un commit/merge déclenche un déploiement.

  • Créer une Application ArgoCD

Ah, et n’oubliez pas de configurer votre application ArgoCD pour que les manifestes déployés utilisent votre dépôt quay.io !

Astuces en vrac

  • La commande suivante vous retournera l’URL du webhook ArgoCD

oc get route -n openshift-gitops openshift-gitops-server -o jsonpath='https://{.spec.host}/api/webhook'

  • Pour simuler la Merge Request qui sera créée par le pipeline CI, poussez un commit dans le dépot antennas-gitops altérant le fichier values-prod.yaml:

antennas-front:
  image:
    repository: "quay.io/<your_username_here>/antennas-front"
    tag: test1

Vous incrémenterez test1 à chaque test (pensez à pousser le tag correspondant) !

Pour vous aider, vous pouvez vous appuyer sur la documentation suivante.

Preuves à fournir

  • Capture d’écran du Webhook configuré avec les évènements récents en statut 200

  • Capture d’écran de la console ArgoCD montrant votre application synchronisée et fonctionnelle

  • Capture d’écran du champ image du déploiement antennas-front dans la console ArgoCD

  • Votre application ArgoCD au format YAML

Préparatifs pour le challenge 6.2

Faites une copie de votre dépôt Git antennas-front

  • Allez sur la page d’accueil de GitLab

  • Cliquez sur le dépôt antennas-front

  • Naviguez dans Paramètres > Général

  • Changez le nom du projet en antennas-front-backup

  • Cliquez sur Enregistrez les modifications

  • Dépliez la section Advanced

  • Descendez jusqu’à la section Changer le chemin

  • Changez le chemin en antennas-front-backup

  • Cliquez sur Changer le chemin

Forkez le dépôt suivant : antennas-front

  • Allez sur le dépôt antennas-front

  • Cliquez sur Créer une divergence

L’opérateur GitLab Runner a un bug (corrigé chez GitLab mais pas encore livré) qui va nous gêner dans ce défi. Pour cela, vous devrez désinstaller l’opérateur GitLab Runner que vous avez installé dans le défi numéro 2 et installer une version béta.

Désinstallez l’opérateur GitLab Runner.

  • Dans la console OpenShift, allez dans la vue Administrator

  • Dépliez Operators > Installed Operators

  • En face de la ligne GitLab Runner, cliquez sur les trois petits points et sélectionnez Uninstall Operator

Installez l’opérateur GitLab Runner en version béta.

  • Ajoutez un catalogue à la marketplace OpenShift

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: gitlab-runner-catalog
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: registry.gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/gitlab-runner-operator-catalog-source:amd64-v0.0.1-53d8a4e6
  displayName: GitLab Runner Operators
  publisher: GitLab Community (Beta)

  • Déployez la version béta de l’opérateur GitLab Runner

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: gitlab-runner-operator
  namespace: openshift-operators
spec:
  channel: stable
  name: gitlab-runner-operator
  source: gitlab-runner-catalog
  sourceNamespace: openshift-marketplace

Déployez un runner dans le projet antennas-dev (même procédure que dans le défi numéro 2).

Donnez le droit à votre runner d’exécuter des conteneurs sous n’importe quel utilisateur et donnez lui également le droit d’administration sur l’environnement de test.

oc adm policy add-role-to-user admin system:serviceaccount:antennas-dev:default -n antennas-test
oc adm policy add-scc-to-user anyuid -z default -n antennas-dev

Maintenant, nous allons configurer notre pipeline CI/CD pour qu’il puisse écrire dans le dépôt antennas-gitops et pousser les images de conteneur dans quay.io.

  • Allez sur votre profil GitLab

  • Créez un Personal Access Token avec la portée api, read_api, read_user, read_repository et write_repository.

notez soigneusement le jeton généré !

  • Allez sur quay.io

  • Cliquez sur votre nom

  • Ouvrez Account Settings

  • Générez un mot de passe chiffré (Encrypted Password)

notez soigneusement le mot de passe généré ainsi que votre identifiant (champ Username sur la même page) !

  • Allez sur le dépôt antennas-front dans GitLab

  • Ouvrez Paramètres > Intégration et livraison continues

  • Dépliez la section Variables

  • Créez trois variables :

    • GITLAB_TOKEN qui contient le Personal Access Token GitLab

    • QUAY_PASSWORD qui contient votre Encrypted Password Quay.io

    • QUAY_USERNAME qui contient votre identifiant Quay.io

Les variables GITLAB_TOKEN et QUAY_PASSWORD doivent être masquées (Masked) !

Éditez les fichier .gitlab-ci.yaml du dépôt antennas-front et ajustez les lignes suivantes à votre configuration.

#
# HEADS UP ! You will need to change those variables to match the location of
# your Quay.io repository and GitLab git repository.
#
variables:
  ANTENNAS_FRONT_IMAGE: quay.io/nmasse_itix/antennas-front
  ANTENNAS_GITOPS_REPOSITORY: gitlab.com/nmasse-itix/antennas-gitops.git
  BOT_EMAIL: nicolas.masse@itix.fr

  • ANTENNAS_FRONT_IMAGE est le dépôt quay.io que vous avez créé lors du premier défi

  • ANTENNAS_GITOPS_REPOSITORY est le dépôt antennas-gitops que vous avez copié précédemment

  • BOT_EMAIL est l’adresse email rattachée à votre compte GitLab

À cette étape, le pipeline CI/CD doit se terminer sans erreur. Si ce n’est pas le cas, revérifiez les étapes ci-dessus et appelez un facilitateur !

Le pipeline déploie l’application dans l’environnement de test et si vous avez terminé le défi précédent, il déploie aussi dans l’environnement de production ! Vous pouvez observer les Commits arriver dans le dépôt antennas-gitops.

[Challenge 6.2] Advanced

Dans ce défi, vous devrez améliorer le contenu du dépôt antennas-gitops pour réaliser une livraison applicative au format Blue/Green.

Le principe est le suivant :

  • L’application est déployée deux fois, une première fois avec une étiquette bleue et une seconde fois avec une étiquette verte.

  • Lors de la première livraison applicative, tout le trafic est dirigé vers l’application bleue.

  • Lors de la livraison suivante, les artefacts sont déployées sur l’application verte car elle ne reçoit pas de trafic.

  • Si les tests de mise en production sont satisfaisants, on bascule le trafic vers l’instance verte.

  • À la livraison suivante, c’est l’inverse : c’est l’instance bleue qui sera mise à jour. Et ainsi de suite…​

Dans la branche blue-green du dépôt antennas-front vous avez un pipeline GitLab CI adapté à ce type de livraison. Observez bien son fonctionnement ainsi que les différences avec celui de la branche main.

Dans la branche blue-green du dépôt antennas-gitops vous avez un Chart Helm mis à jour avec deux instances de l’application, une verte et une bleue.

Votre tâche sera de trouver un moyen de faire la bascule vert / bleu.

Astuces en vrac

  • Le pipeline GitLab CI met à jour le fichier values-prod.yaml dans le dépôt antennas-gitops avec la cible active (deux valeurs possibles: blue et green). À vous d’utiliser cette valeur dans le Chart Helm pour créer l’objet Kubernetes qui vous permettra de faire la bascule.

  • Le pipeline GitLab CI met 5 minutes à s’exécuter. Vous pouvez le court-circuiter durant la phase de mise au point en éditant directement les fichiers dans le dépôt antennas-gitops.

  • N’oubliez pas de mettre à jour votre Application ArgoCD avec la bonne branche Git (blue-green) et les bons paramètres Helm !

  • Pensez à passer la branche blue-green de votre dépôt antennas-front en Protected pour qu’elle puisse accéder aux variables CI/CD !

Pour vous aider, vous pouvez vous appuyer sur la documentation suivante.

Preuves à fournir

  • Capture d’écran de l’objet Kubernetes qui vous a servi à la bascule, une fois en vert, une fois en bleu.

  • Capture d’écran de votre pipeline GitLab CI terminé avec succès