• 10 heures
  • Difficile

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 22/02/2021

Déployez et testez votre code sur différents environnements

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Dans cette partie, vous allez déployer les images précédemment buildées sur un environnement Docker, grâce au pipeline de livraison continue. Puis, nous lancerons les tests grâce à la méthode Canary Release.

Préparez votre environnement de travail

Afin de vous faciliter la tâche et de ne pas installer des dépendances inutiles, je vous conseille de créer un environnement sur le site Play-With-Docker. Ce site va vous permettre de créer une infrastructure Docker rapidement. Rendez-vous sur le site, et connectez-vous avec vos identifiants Docker Hub.

Une fois connecté, une session de 4 heures est créée afin de vous permettre de déployer vos images. Sur la page d'accueil, cliquez sur l'icône 🔧 et sélectionnez le template 3 Managers and 2 Workers.

Cela va vous créer un cluster Docker Swarm, nécessaire au déploiement des images. Une fois le cluster créé, vous allez récupérer l'URL de l'environnement. Il suffit de copier l'URL présente dans la case SSH.

Copiez l'URL SSH de votre Docker Swarm sur le Play-With-Docker
Copiez l'URL SSH de votre Docker Swarm sur le Play-With-Docker

Cette URL sera utilisée pour configurer l'environnement de déploiement dans le fichier .gitlab-ci.yml. Maintenant, modifiez ce fichier pour ajouter deux nouvelles lignes. La première ligne à ajouter est au niveau de variables. Cette nouvelle variable va contenir l'URL copiée précédemment (ip172-18-0-51-bihm1906chi000b37l6g chez moi) :

PWD: ip172-18-0-51-bihm1906chi000b37l6g

La deuxième ligne est à ajouter juste après l'étape package. Cette étape supplémentaire sera le déploiement des images sur un environnement de staging :

deploy_staging_job:
stage: deploy
image: docker:stable
script:
- apk add --no-cache openssh-client py-pip python-dev libffi-dev openssl-dev gcc libc-dev make
- pip install docker-compose
- export DOCKER_HOST=tcp://$PLAYWD.direct.labs.play-with-docker.com:2375
- docker-compose down
- docker-compose up -d
environment:
name: staging
url: http://$PLAYWD-8080.direct.labs.play-with-docker.com

La syntaxe est la même que les précédentes étapes. Dans la partie script, nous avons ajouté la copie du fichier docker-compose.yml, ainsi que le dossier docker. Enfin, nous démarrons le projet grâce à Docker Compose.

Si tout s'est bien passé, vous devriez voir apparaître dans vos environnements (Opérations > Environnements), le nouvel environnement Staging.

Votre nouvel environnement de Staging
Votre nouvel environnement de staging

Vous pouvez alors cliquer sur le lien "Open live environment" sur la droite de cet environnement, afin de voir l'application déployée.

Votre application déployée
Votre application déployée

Maintenant que l'environnement Staging est déployé, il est possible de lancer des tests impossibles à lancer lors de la phase d'intégration continue. Dans ce cours, nous allons lancer un test de performance, afin de mesurer les temps de réponse de l'application. Pour ce faire, vous allez utiliser Apache Benchmark pour simuler de la charge sur le serveur.

Il faut alors ajouter de nouvelles lignes dans le fichier .gitlab-ci.yml, afin de lancer les tests de performance sur le nouvel environnement :

performance_job:
stage: performance
image: docker:git
variables:
URL: http://$PLAYWD-8080.direct.labs.play-with-docker.com/
services:
- docker:stable-dind
script:
- apk add --no-cache curl
- x=1; while [[ "$(curl -s -o /dev/null -w ''%{http_code}'' http://$PLAYWD-8080.direct.labs.play-with-docker.com/)" != "200" || $x -le 60 ]]; do sleep 5; echo $(( x++ )); done || false
- mkdir gitlab-exporter
- wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/master/index.js
- mkdir sitespeed-results
- docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:6.3.1 --plugins.add ./gitlab-exporter --outputFolder sitespeed-results $URL
- mv sitespeed-results/data/performance.json performance.json
artifacts:
paths:
- sitespeed-results/
reports:
performance: performance.json

Dans ce nouveau bloc, la syntaxe reste la même. Nous récupérons dans un premier temps l'utilitaire de test de performance dans le bloc script. Nous lançons ensuite une application qui va se charger de tester notre site et d'en extraire des métriques de performance. Ces métriques sont ensuite uploadées sur GitLab afin d'être accessibles.

Ensuite, modifiez aussi le début du fichier afin d'ajouter une nouvelle ligne dans le bloc stages :

stages:
- build
- test
- quality
- package
- deploy
- performance

Enfin, une fois l'environnement de staging déployé et testé, il ne reste plus qu'à déployer l'application sur l'environnement de production. Pour cela, vous allez une nouvelle fois modifier le fichier .gitlab-ci.yml afin d'ajouter l'étape de mise en production :

deploy_prod_job:
stage: deploy
image: docker:stable
script:
- apk add --no-cache openssh-client py-pip python-dev libffi-dev openssl-dev gcc libc-dev make
- pip install docker-compose
- export DOCKER_HOST=tcp://$PLAYWD.direct.labs.play-with-docker.com:2375
- docker-compose down
- docker-compose up -d
environment:
name: prod
url: http://$PLAYWD-8080.direct.labs.play-with-docker.com
when: manual

Dans cette étape, nous ajoutons le mot clé when: manual afin de ne déployer en production qu'avec l'intervention d'un être humain. La validation est requise afin de savoir s'il existe des erreurs lors du déploiement sur staging. Si des erreurs existent, il n'y aura alors pas de mise en production.

Sur votre pipeline de livraison continue, le déploiement manuel est symbolisé par l'icône ▶️ à côté de l'étape deploy_prod :

Le déploiement manuel sur Gitlab CI
Le déploiement manuel sur GitLab CI

Ces erreurs seront analysées lors de la prochaine étape : le monitoring.

Enfin, une technique largement utilisée lors de l'utilisation de la livraison continue est le Canary Release. Le principe du Canary Release est le même que dans les mines de charbon. À l'époque, les mineurs de charbon qui descendait à la mine plaçaient un canari devant eux, au bout d'une perche dans une cage. Si le canari mourait, cela voulait dire que l'air était non respirable et les mineurs avaient le temps de rebrousser chemin afin d'éviter un sort fatal.

Le principe est le même dans le déploiement : une partie seulement des utilisateurs vont être redirigés vers la nouvelle version de production, et si quelque chose se passe mal, il n'y aura uniquement qu'une petite partie des utilisateurs qui sera impactée. Pour le mettre en place sur notre projet, modifiez le fichier .gitlab-ci.yml en ajoutant un nouveau bloc canary :

canary_job:
stage: canary
image: docker:stable
script:
- apk add --no-cache openssh-client py-pip python-dev libffi-dev openssl-dev gcc libc-dev make
- pip install docker-compose
- export DOCKER_HOST=tcp://$PLAYWD.direct.labs.play-with-docker.com:2375
- docker-compose down
- docker-compose up -d
environment:
name: prod
url: http://$PLAYWD-8080.direct.labs.play-with-docker.com
when: manual
only:
- master

Le principe ici est exactement le même que la production, la différence étant que le déploiement en canary est décorrélé de la production.

Ensuite, modifiez le début du fichier afin que dans le bloc stages soit ajoutée l'étape canary :

stages:
- build
- test
- quality
- package
- canary
- deploy
- performance

Nous avons maintenant un environnement qui se déploie en parallèle de la production, et qui contient uniquement une sous-partie des utilisateurs. Cet environnement sera très utile afin de faire des analyses en temps réel du comportement de l'application, et voir s'il n'y a pas d'erreurs.

Nous avons maintenant un pipeline complet de livraison continue, de la compilation du projet au déploiement sur un environnement de staging, une possibilité de déploiement en production via l'intervention d'une personne de l'équipe d'ops, par exemple, et un environnement Canary qui contient un sous-ensemble des utilisateurs, afin de voir comment se comporte l'application.

En résumé

Dans ce chapitre, vous avez créé votre environnement de staging sur GitLab, afin d'y effectuer vos tests avant le déploiement en production que vous pourrez faire manuellement via GitLab. Vous avez également mis en place une étape de test de type Canary Release.

Dans le prochain chapitre, vous verrez comment superviser votre application en production, et comment mettre en place des notifications d'alerte sur Slack en cas de problème.

Exemple de certificat de réussite
Exemple de certificat de réussite