Livraison continue avec Kubernetes

Dans ce TP, nous allons étudier comment mettre en place des mécanismes de livraison continue, pour déployer une application Web dans un cluster GKE.

Dans la suite, nous allons considérer un pipeline d’intégration et de livraison continue mis en oeuvre au travers de Gitlab CI/CD. Les principes que nous allons couvrir sur suffisamment génériques pour s’appliquer de manière assez similaire avec d’autres outils de CI/CD (par exemple, GitHub Actions). Cependant, il est requis d’utiliser Gitlab.com pour ce TP.

Pour ce TP, nous allons avoir 3 étapes principales:

  1. Créer un dépôt pour nos images Docker sur GCP et configurer un Service Account permettant de publier des images sur ce dépôt
  2. Configurer un agent Gitlab pour pouvoir communiquer entre les runners Gitlab et notre cluster GKE
  3. Mettre en place la pipeline de CI/CD pour pousser automatiquement l’image de notre application Web vers le dépôt d’images et lancer l’application dans le cluster Kubernetes.

AVERTISSEMENT

!!! Si vous ne supprimez pas les ressources que vous allouez, elles continuent à consommer des crédits sur GCP même lorsque vous êtes déconnecté. !!!

Peu importe la rapidité avec laquelle vous progressez dans le TP, vous devez supprimer toutes les ressources que vous avez créées avant de terminer.

Veuillez consulter les instructions du TP d’introduction à Kubernetes pour la suppression des ressources.

Les étapes préliminaires

Création d’un compte et d’un projet sur Gitlab.com

La première étape de ce TP est de se créer un compte sur Gitlab.com si vous n’en avez pas déjà un.

Pour simplifier les interactions avec vos projets sur gitlab, vous devez utiliser une clé SSH. Vous pouvez utiliser une clé SSH que vous avez déjà ou en créer une nouvelle.

Les instructions pour associer une clé SSH à votre compte Gitlab sont disponibles ici.

Ensuite vous devez créer un nouveau projet vide (Voir ici). C’est le projet que nous allons utiliser pour mettre en place le pipeline de CI/CD.

Dans la suite nous supposerons que ce projet s’appelle k8s-cd-project.

Configurer sa machine et démarrer un cluster GKE

Pour ce TP, nous allons déployer une application Web dans un cluster GKE. Nous rappelons qu’un tutoriel permettant de découvrir GCP (Google Cloud Platform) et GKE (Google Kubernetes Engine) est disponible ici.

En particulier, vous trouverez dans ce tutoriel les instructions pour:

Comme lors de ce précédent TP, nous travaillerons dans la zone europe-west6-a.

Suivez ces différentes étapes pour créer un cluster GKE avec les paramètres par défaut.

L’application Web

Dans ce TP, nous considérons une application de type serveur Web. Nous allons utiliser l’application hello-app (déjà utilisée dans le tutoriel GKE).

Plus précisément, nous allons utiliser les fichiers main.go et Dockerfile présents dans ce dépôt.

Si ce n’est pas déjà fait, clonez le projet k8s-cd-project pour en récupérer une copie locale.

Copiez les 2 fichiers dans votre copie locale du projet et poussez les vers le dépôt distant.

[Petit exercice de rappel sur Docker] Ouvrez le fichier *Dockerfile* et expliquez 
la manière dont est construite l'image de l'application *hello-app*

Publier des images Docker dans un registre d’artefacts

Création du dépôt

Artefact Registry est un service de Google Cloud permettant aux utilisateurs de créer leur propre dépôt d’artefacts. Dans notre cas, nous allons y stocker des images Docker.

L’ensemble des documentations de ce service est disponible ici.

Pour utiliser ce service, vous devez tout d’abord activer l’API correspondante:

gcloud services enable artifactregistry.googleapis.com

Pour créer notre dépôt d’images Docker, nous allons suivre les principales étapes décrites dans la documentation.

Tout d’abord, il est à noter qu’il est nécessaire de choisir une zone géographique dans laquelle votre dépôt d’image va être créé.

Comme expliqué ici, vous avez le choix entre une région simple ou une zone multi-region.

Dans notre cas, nous allons utiliser une région simple. Expliquez pourquoi.

Pour récupérer la liste complète des régions disponibles, exécutez :

gcloud artifacts locations list

Nous allons choisir la zone europe-west6 pour ce TP.

La commande que nous allons utiliser pour créer un registre d’image Docker est la suivante :

gcloud artifacts repositories create [REPOSITORY] \
    --repository-format=docker \
    --location=[LOCATION] \
    --description="[DESCRIPTION]"

Dans cette commande, remplacez :

Vous devriez maintenant voir votre dépôt apparaître en exécutant :

gcloud artifacts repositories list

Pour obtenir une description détaillée de votre dépôt, exécutez :

gcloud artifacts repositories describe [REPOSITORY] --location=[LOCATION]

Vous devriez pouvoir observer que pour l’instant votre dépôt est vide.

Nous ne l’avons pas fait mais nous aurions pu ajouter l’option --immutable-tags pour notre dépôt. Ce concept est documenté ici.

Expliquez les intérêts possibles d'utiliser l'option --immutable-tags

Publier des images sur le dépôt

Dans la suite nous allons vouloir publier des images Docker dans le dépôt depuis Gitlab. Cependant, ceci n’est pas possible par défaut pour des raisons de sécurité.

Différentes solutions existent pour permettre à un processus d’obtenir l’accès à notre dépôt.

Création d’un Service Account

Pour des raisons de simplicité, nous allons utiliser une solution se basant sur un Service Account.

Expliquez à quoi servent les Services Accounts

Pour pouvoir manipuler des Services Accounts, la première étape est d’activer l’API IAM (Identity and Access Management) :

gcloud services enable iam.googleapis.com

Ensuite nous pouvons créer un nouveau Service Account comme décrit ici :

gcloud iam service-accounts create [SA_NAME] \
    --description="[DESCRIPTION]" \
    --display-name="[DISPLAY_NAME]"

L’option importante ici est [SA_NAME], qui est le nom que vous voulez donner à votre Service Account. Pour les autres options, nous vous laissons consulter la documentation.

Une fois le Service Account créé, nous pouvons observer les droits qui lui sont associés :

gcloud projects get-iam-policy [PROJECT_ID]  \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:[SA_NAME]"

Vous devriez observer qu’aucun droit ne lui est associé pour le moment.

Pour limiter les risques de sécurité liés à l’utilisation d’un Service Account, nous allons y associer seulement les droits strictement nécessaires pour interagir avec le dépôt. Comme nous pouvons le voir, nous avons besoin des droits en écriture (roles/artifactregistry.writer) et en lecture (roles/artifactregistry.reader) sur les registres d’artefact.

La commande pour associer un nouveau droit (aussi appelé role) à un Service Account est la suivante :

gcloud projects add-iam-policy-binding [PROJECT_ID] \
    --member="serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com" \
    --role="[ROLE_NAME]"

Ajoutez les droits en lecture et en écriture sur les registres d’artefact pour le Service Account que vous avez créé.

Vérifiez ensuite que les droits associés au Service Account ont bien été mis à jour.

D'après vous, quels sont exactement les droits que vous avez associés à votre 
Service Account ? Autrement dit, votre Service Account permet:
- De lire et d'écrire seulement dans le dépôt que nous avons créé précédemment ?
- De lire et d'écrire dans n'importe quel dépôt qui serait lié à votre projet ?
- De lire et d'écrire dans n'importe quel dépôt qui serait lié à votre compte Google Cloud ?
- De lire et d'écrire dans n'importe quel dépôt Google Cloud ?

Enfin, pour pouvoir utiliser ce Service Account, nous devons obtenir une clé permettant à un processus de s’authentifier auprès de Google Cloud en tant que Service Account et donc d’obtenir les droits associés.

La clé que nous allons obtenir est au format json. Voici la commande pour obtenir la clé :

gcloud iam service-accounts keys create [KEY_FILE] \
    --iam-account=[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com

Ici [KEY_FILE] est le fichier dans lequel vous souhaitez que la clé soit stockée.

Étudiez le contenu du fichier [KEY_FILE] et confirmez/complétez votre réponse à la 
question précédente.

Publier une image sur notre dépôt

Pour tester que tout fonctionne correctement, nous allons essayer de pousser une image Docker de notre hello-app vers le registre que nous avons créé en utilisant notre Service Account depuis notre machine locale.

Pour cela, commencez par créer une image permettant de déployer l’application hello-app en utilisant le Dockerfile que nous avons récupéré précédemment.

Pour pouvoir publier l’image sur notre dépôt, il faut tout d’abord la tagger avec les bonnes coordonnées. Comme décrit ici, l’image doit être taggée avec les coordonnées suivantes :

[LOCATION]-docker.pkg.dev/[PROJECT-ID]/[REPOSITORY]/[IMAGE]

Ici:

Pour rappel, tagger une image Docker se fait avec la commande suivante :

docker tag [IMAGE] [TAG]

Ensuite, sur votre machine locale, connectez Docker à votre dépôt en utilisant la clé associée à votre Service Account :

cat [KEY-FILE] | docker login -u [KEY-TYPE] --password-stdin https://[LOCATION]-docker.pkg.dev

Ici la valeur pour [KEY-TYPE] sera _json_key.

Enfin, vous pouvez publier votre image sur votre dépôt :

docker push [TAG]

Vous pouvez ensuite vérifier que votre dépôt n’est plus vide :

gcloud artifacts repositories describe [REPOSITORY] --location=[LOCATION]

Pour vérifier que tout fonctionne correctement, vous pouvez même déployer cette nouvelle image depuis le dépôt dans votre cluster GKE, en utilisant les commandes vues ici.

Une fois vérifié que votre application hello-app est bien déployée sur votre cluster, vous pouvez supprimer ce premier déploiement.

Connecter Gitlab et notre cluster Kubernetes

Dans cette partie, notre objectif est de permettre à un pipeline de CI/CD Gitlab d’exécuter des commandes sur un cluster K8s.

Cette partie est fortement inspirée de la documentation Gitlab sur le sujet.

Dans notre cas, nous voulons permettre à notre pipeline s’exécutant sur gitlab.com de communiquer avec notre cluster GKE.

Installation de l’agent Gitlab

Pour permettre à Gitlab d’exécuter des commandes dans notre cluster K8s, nous devons installer l’agent Gitlab dans notre cluster.

La première étape est de créer le fichier de configuration de l’agent dans votre projet Gitlab. Dans un premier temps, nous allons créer un fichier vide.

touch .gitlab/agents/[AGENT_NAME]/config.yaml

Pour choisir le nom de votre agent, veuillez suivre les règles décrites ici.

Poussez ce fichier vers le dépôt distant.

Ensuite vous devez inscrire un agent auprès de Gitlab.com. Pour cela suivez les étapes décrites ici. En résumé :

  1. Dans l’interface Web de Gitlab.com, allez dans votre projet.
  2. Allez dans le menu Operate > Kubernetes clusters.
  3. A partir de cette étape, suivez attentivement les étapes telles que décrites dans la documentation Gitlab (étapes 3 à 6).

Important: Vous devez copier dans un fichier en local sur votre machine la commande que Gitlab va vous proposer comme méthode d’instanciation de l’agent et la conserver précieusement (pour des raisons de sécurité, vous n’aurez pas la possibilité de récupérer à nouveau cette commande plus tard). C’est cette commande que nous allons utiliser pour démarrer notre agent.

Cette commande devrait ressembler à ça :

helm upgrade --install [AGENT_NAME] gitlab/gitlab-agent \
    --namespace gitlab-agent-[AGENT_NAME] \
    --create-namespace \
    --set image.tag=v16.8.0 \
    --set config.token=[SECRET_TOKEN] \
    --set config.kasAddress=wss://kas.gitlab.com

Comme nous le voyons dans la commande ci-dessus, nous allons utiliser Helm pour déployer notre agent dans le cluster K8s.

- D'après la page d'accueil du projet Helm, résumez en quelques mots l'objectif de ce projet.
- Réferrez-vous à la documentation de Helm et expliquez ce qu'est un "Chart" dans la
terminologie Helm.

Pour pouvoir déployer notre agent en utilisant Helm, nous allons d’abord devoir installer l’outil sur notre machine locale (sur le cloud shell, Helm est déjà installé).

Pour cela, suivez les instructions fournies et procédez à l’installation à partir des fichiers binaires fournis.

Notez que plutôt que copier le binaire dans le répertoire /usr/local/bin, vous pouvez simplement ajouter le répertoire dans lequel se trouve l’exécutable à votre variable PATH :

export PATH=[PATH_TO_HELM]:$PATH

Vous pouvez ensuite vérifier si Helm est installé correctement en exécutant :

helm help

Les charts Helm packagés sont stockés dans des registres (un peu à la manière de ce qui est fait pour les images Docker). Pour pouvoir utiliser un chart, il faut d’abord enregistrer le registre dans lequel il est stocké auprès du client Helm local. Pour notre cas, ceci est fait avec la commande suivante :

helm repo add gitlab https://charts.gitlab.io

Après avoir ajouté ce nouveau registre, il faut mettre à jour la liste des charts disponibles :

helm repo update

Avant de déployer gitlab-agent, nous vous proposons d’étudier un peu plus en détails le chart que nous allons déployer.

Pour obtenir une définition du chart, exécutez :

helm show chart gitlab/gitlab-agent

On peut obtenir l’ensemble des paramètres par défaut utilisés pour ce chart avec :

helm show values gitlab/gitlab-agent

D'après les valeurs observées combien de réplicas vont être créés lors du déploiement du chart ?

La définition du chart doit vous montrer que le code du chart est stocké sur le dépôt suivant : https://gitlab.com/gitlab-org/charts/gitlab-agent.

Sur ce dépôt, vous pouvez notamment trouver le fichier templates/deployment.yaml qui décrit la manière dont le chart va être déployé. Prenez quelques minutes pour observer le contenu de ce fichier.

Enfin, avant de pouvoir déployer le chart dans notre cluster GKE, nous devons tout d’abord nous connecter à notre cluster GKE, comme décrit dans le TP précédent.

Vous pouvez maintenant déployer votre agent gitlab dans le cluster avec la commande fournie par Gitlab lors de la déclaration de votre agent :

helm upgrade --install [AGENT_NAME] gitlab/gitlab-agent \
    --namespace gitlab-agent-[AGENT_NAME] \
    --create-namespace \
    --set image.tag=v16.8.0 \
    --set config.token=[SECRET_TOKEN] \
    --set config.kasAddress=wss://kas.gitlab.com

Autoriser l’agent à accéder à notre projet

La dernière étape pour cette partie est d’autoriser l’agent s’exécutant dans notre cluster Kubernetes à accéder au projet pour lequel nous voulons mettre en place de l’intégration continue.

Pour cela, nous allons modifier le fichier .gitlab/agents/[AGENT_NAME]/config.yaml, que nous avons ajouté à notre projet sur Gitlab comme décrit ici. Ainsi, le fichier devra contenir les lignes suivantes :

ci_access:
  projects:
    - id: path/to/project

où path/to/project est l’URL de votre projet (sans la partie gitlab.com).

Poussez les modifications vers le dépôt distant. À partir de ce moment, un runner gitlab exécutant un pipeline de CI/CD pour votre projet est capable de déployer un service au sein de votre cluster GKE.

D'après la documentation, est-il nécessaire de créer un nouvel agent pour chaque projet 
qui sera à déployer dans le cluster ?

Construire le pipeline de CI/CD

Dans la dernière partie de ce TP, nous allons construire le pipeline de CI/CD qui va nous permettre d’automatiser la livraison de notre application.

Quelques bases sur les pipelines de livraison continue

Si les concepts d’intégration et de livraison continues ne vous sont pas très familiers, nous vous conseillons de commencer par consulter les slides suivants (slides 1–31).

Définissez "Intégration Continue", "Livraison Continue", et "Déploiement Continu" et expliquez 
le lien entre ces trois concepts.

Pour mettre en place notre pipeline de livraison continue, nous allons utiliser Gitlab CI/CD.

Dans ce jeu de slides (slides 32–38), vous trouverez un résumé des concepts principaux associés aux pipelines de livraison continue dans Gitlab.

A l’aide de ces slides et de la documentation Gitlab:

- Définissez les concepts de "Job" et de "Stage"
- Explicitez la condition nécessaire pour passer d'une étape (stage) à une autre dans un 
  pipeline
- Comment est déterminé l'ordre dans lequel sont exécutées les étapes d'un pipeline ?
- Définissez le concept de "Runner"
- Est ce qu'un Runner démarre un nouveau conteneur Docker pour chaque pipeline ? Pour chaque 
  Stage ? Pour chaque Job ?

Pour les projets hébergés sur Gitlab.com, Gitlab fournit des shared runners. Ainsi nous n’aurons pas besoin d’instancier notre propre runner.

Construire notre 1er pipeline de livraison continue

Dans un premier temps, nous allons construire un pipeline minimaliste dont le seul objectif sera de vérifier que nous sommes capables de communiquer entre notre pipeline et notre cluster Kubernetes.

Pour définir votre pipeline d’intégration continue, vous devez créer un fichier .gitlab-ci.yml à la racine de votre projet.

Pour ce qui est du contenu du fichier, nous vous proposons de partir de cet exemple proposé dans la documentation Gitlab :

deploy:
  image:
    name: bitnami/kubectl:latest
    entrypoint: ['']
  script:
    - kubectl config get-contexts
    - kubectl config use-context path/to/agent/project:agent-name
    - kubectl get pods

Dans ce fichier, la seule chose à changer sera de définir path/to/agent/project:agent-name.

Avant de pousser le fichier de description du pipeline vers le dépôt distant, nous vous proposons d’étudier son contenu :

- À votre avis, que va faire la séquence de 3 commandes kubectl définie dans le pipeline ?
- Pour la définition de l'image utilisée, nous pouvons observer cette ligne en plus 
qui permet  de redéfinir l'Entrypoint de l'image. Pourquoi ceci est-il nécessaire ? 
(La réponse peut être trouvée en lisant ce paragraphe: 
https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#where-scripts-are-executed)

Poussez maintenant votre fichier .gitlab-ci.yml vers le dépôt distant, ce qui va déclencher l’exécution du pipeline.

Suivez les instructions suivantes pour observer l’exécution de votre pipeline.

Un pipeline un peu plus complet

Une fois que ce premier pipeline fonctionne, nous allons écrire un pipeline un peu plus complet. Dans ce pipeline, notre objectif va être de publier automatiquement une image docker de notre application dans le registre que nous avons créé précédemment.

Ainsi, dans notre pipeline nous allons devoir :

  1. Construire une nouvelle image Docker à partir de la dernière version du code de hello-app présent sur le dépôt
  2. Nous connecter au registre d’artefacts que nous avons créé précédemment
  3. Publier notre nouvelle image dans le registre
À votre avis, par défaut, est ce qu'il faut exécuter ces trois étapes dans le même job ou 
dans 3 jobs différents ? (rappelez-vous ce qu'il se passe lors de l'exécution d'un job)

Docker-in-Docker

Pour construire notre image, nous allons rencontrer un problème :

Est-ce-que vous pouvez anticiper le problème de nous allons rencontrer ?

Pour résoudre ce problème, nous allons utiliser une solution appelée Dind (“Docker-in-docker”) comme expliqué ici.

Si Dind est un sujet qui vous intéresse, nous vous recommandons le poste de blog de Jerôme Petazzoni sur le sujet.

Pour utiliser Dind, nous allons nous baser sur les instructions fournies ici.

Bonne nouvelle ! Les shared runners de Gitlab sont déjà configurés pour faire du Dind. Ainsi, nous devons juste nous inspirer de l’exemple de ficher .gitlab-ci.yml fourni et reproduit ci-dessous :

default:
  image: docker:24.0.5
  services:
    - docker:24.0.5-dind
  before_script:
    - docker info

variables:
  # When using dind service, you must instruct docker to talk with the
  # daemon started inside of the service. The daemon is available with
  # a network connection instead of the default /var/run/docker.sock socket.
  #
  # The 'docker' hostname is the alias of the service container as described at
  # https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#accessing-the-services
  #
  # If you're using GitLab Runner 12.7 or earlier with the Kubernetes executor and Kubernetes 1.6 or earlier,
  # the variable must be set to tcp://localhost:2375 because of how the
  # Kubernetes executor connects services to the job container
  # DOCKER_HOST: tcp://localhost:2375
  #
  DOCKER_HOST: tcp://docker:2375
  #
  # This instructs Docker not to start over TLS.
  DOCKER_TLS_CERTDIR: ""

build:
  stage: build
  script:
    - docker build -t my-docker-image .
    - docker run my-docker-image /script/to/run/tests

Dans le fichier présenté dans la documentation, expliquez:
- À quoi correspond la section "default" ?
- Qu'est ce que le concept de "service" défini dans la section "default" ?
- À quoi sert le service que nous définissons ici ?
- À quoi correspond la section "variables" ?
- Pourquoi nous devons définir la variable "DOCKER_HOST" ?

Les ressources suivantes doivent vous permettre de répondre à ces questions:

Avant de mettre en place notre pipeline, nous devons traiter un dernier problème lié à la gestion des secrets.

Gestion des secrets

Le dernier problème que nous avons à résoudre est de permettre au runner Gitlab de publier des données dans notre registre. Pour cela, dans la première partie du TP, nous avons créé un Service Account et obtenu une clé permettant à un processus de s’authentifier en tant que Service Account.

Nous allons donc devoir partager cette clé avec Gitlab. Cependant, nous devons prendre quelques précautions dans la manière de le faire. En effet, si nous publions cette clé d’une manière qui ferait que tout le monde peut y avoir accès sur Internet, cela peut constituer une faille de sécurité importante. (Notez que la faille de sécurité resterait très limitée dans notre cas étant donné le peu de droits associés à notre Service Account.)

Pour stocker notre clé, plusieurs mécanismes sont à notre disposition :

Bien que la solution basée sur un service externe de gestion de secrets soit la solution recommandée en pratique, nous allons utiliser l’autre solution dans un soucis de simplification pour ce TP.

Nous avons vu plus haut que nous pouvons définir des variables directement dans le 
fichier `.gitlab-ci.yml`. Est ce que vous pensez que ce serait une bonne solution de procéder 
ainsi pour notre clé secrète ?

Ce que nous voulons éviter est que notre clé apparaisse en clair dans un endroit facilement accessible pour d’autres utilisateurs. Pour cela, nous allons associer une variable à notre projet Gitlab tel que décrit ici.

Ici, comme notre clé est en fait un fichier JSON, nous allons créer une variable de type File. Cette variable ne sera accessible qu’aux personnes ayant suffisamment de droits pour le projet.

Nous devons aussi faire particulièrement attention à ce que notre clé n’apparaisse pas en clair dans les logs d’exécution de nos jobs de CI/CD. Pour cela, Gitlab fournit une fonctionnalité de masquage du contenu des variables dans les logs. Cependant, cette fonctionnalité ne s’applique qu’à du contenu dont le format répond à certains critères, auxquels ne répond pas notre clé. Nous n’allons donc pas pouvoir utiliser cette option de masquage.

Ainsi, il va être de votre responsabilité d’écrire des jobs qui n’affichent pas le contenu de vos variables directement dans le terminal (pas de panique, vous devriez y arriver sans problème !)

Mise en place du pipeline

Nous avons maintenant toutes les informations nécessaires pour être capables de mettre en place notre pipeline de livraison continue.

En vous inspirant de l’exemple dind vu précédemment, construisez votre propre pipeline de livraison continue qui devra répondre à la spécification suivante :

Un pipeline encore plus complet

Nous avons maintenant l’ensemble des éléments nécessaires pour construire un pipeline encore plus complet. Ainsi, notre objectif est maintenant de construire un pipeline capable de :

  1. Construire une nouvelle image Docker pour notre application
  2. Publier cette image Docker dans notre registre
  3. Déployer automatiquement notre application dans le cluster Kubernetes

Première version

A vous de jouer pour construire un pipeline qui répond à la spécification suivante :

Deuxième version (la livraison continue)

Dans la version précédente de notre pipeline, nous avons une approche de type déploiement continu. Si toutes les étapes du pipeline sont exécutées avec succès, alors l’application est automatiquement déployée sur notre cluster (c’est-à-dire, en production).

Dans beaucoup de scénarios réels, il est préférable que la décision finale concernant le déploiement en production revienne à un être humain, car il peut y avoir de forts enjeux associés.

Gitlab nous permet de définir des jobs dans notre pipeline qui ne s’exécutent pas automatiquement, mais qui demandent une action manuelle pour être exécutés. Consultez la documentation sur ce point.

Faites évoluer votre pipeline pour que l’étape deploy ne soit exécutée qu’après une validation par un être humain

Troisième version (Mettre à jour le service et éviter les temps d’indisponibilité du service)

Quand des modifications vont être faites dans le code de notre application, ce qu’on aimerait maintenant est le serveur web qui tourne en production soit mis à jour (si l’action est validée par un être humain).

Une manière de faire ceci est d’arrêter le serveur web actuel et de déployer un nouveau serveur à partir de la nouvelle version du code. Une telle solution a l’inconvénient que le service devient indisponible entre le moment où l’ancienne version est arrêtée et la nouvelle version est démarrée.

Pour éviter ce problème, nous aimerions faire à la place une Rolling Update, c’est-à-dire remplacer progressivement les pods de l’ancienne version du serveur par des pods exécutant la nouvelle version du serveur.

Mettez en place cette solution dans votre pipeline Gitlab en vous basant sur la documentation de Kubernetes sur le sujet.

Ensuite mettez en place un test pour vérifier que votre solution fonctionne correctement. Pour cela, vous devez :