Usine logicielle
Objectifs du chapitre et prérequis
Dans le chapitre précédent, vous avez abordé le principe de compilation d’une image Docker. L’accent va maintenant être mis sur l’automatisation de cette tâche. En effet, les images Docker sont rarement compilées manuellement.
Dans le cas de certains sites (GitLab ou GitHub), cette automatisation est prise en charge à l’aide de fichiers YAML à ajouter à la racine du dépôt Git. Un exemple avec GitLab sera présenté pour comprendre le principe de fonctionnement.
Une autre méthode sera présentée en s’appuyant sur Jenkins et prendra en charge également l’aspect déploiement continu. Le successeur Jenkins X sera également présenté de manière succincte.
Au niveau des prérequis, vous devrez avoir une connaissance minimale sur l’utilisation de Git comme :
-
ajouter un fichier ;
-
modifier le contenu d’un dépôt ;
-
pousser le contenu sur un dépôt distant (GitHub, GitLab, BitBucket, etc.) ;
-
mettre en place des hooks d’événements.
Compilation à l’aide de GitLab
1. Application à compiler
Dans ce qui suit, l’application Flask du chapitre précédent sera intégrée dans un repository GitLab.
Le seul ajout viendra du fichier .gitlab-ci.yml qui définira le lancement de la compilation des éléments du dépôt Git.
2. Mécanisme de pipeline GitLab
Le fichier .gitlab-ci.yml est un fichier au format YAML qui se trouve à la racine du dépôt. Il contient des instructions à utiliser pour construire les éléments du dépôt Git.
À chaque changement, le pipeline de déploiement est déclenché et s’appuie sur un gestionnaire de tâches (Runner).
Comme le fichier .gitlab-ci.yml est stocké avec le code, il devient possible de compiler de vieilles versions du logiciel ou de maintenir des versions différentes en fonction des branches Git.
3. Adresse et contenu du dépôt
Le dépôt GitLab d’exemple est disponible à l’adresse suivante : https://gitlab.com/yannig.perre/flask-healthcheck
La récupération du contenu de ce dépôt se fait à l’aide de la commande suivante :
$ git clone https://gitlab.com/yannig.perre/flask-healthcheck.git
À la racine de ce dépôt, vous pourrez trouver les éléments suivants :
-
les fichiers de l’application Flask du chapitre précédent ;
-
les instructions de compilation dans le fichier .gitlab-ci.yml.
4. Structure du fichier .gitlab-ci.yml
Par défaut, un fichier de construction GitLab contient trois phases :
-
la phase build en charge de la compilation ;
-
la phase test en charge du lancement des tests ;
-
la phase deploy en charge du déploiement.
Ces phases seront exécutées dans cet ordre et le rattachement à ces phases se fait à l’aide du mot-clé stage au niveau d’une tâche (job).
Une tâche est une déclaration de YAML pouvant contenir les champs suivants :
-
before_script ...
Déploiement continu avec Jenkins
1. À propos de Jenkins
Dans ce qui va suivre, le logiciel Jenkins sera mis en place dans Kubernetes.
Des exemples seront mis en œuvre afin de créer un pipeline de construction d’images Docker ainsi qu’un mécanisme de mise à jour automatique.
Tout comme pour GitLab, ce chapitre n’a pas pour vocation de présenter de fond en comble le fonctionnement de Jenkins. Il s’agit plutôt d’un guide pour quelqu’un ayant déjà une première expérience sur le sujet.
Pour plus de détails, n’hésitez pas consulter le site de Jenkins à l’adresse suivante : https://jenkins.io
2. Installation de Jenkins
a. Configuration du chart
L’installation de Jenkins se fera à l’aide du chart Helm jenkins/jenkins. Afin de le rendre accessible de l’extérieur, le master sera exposé à l’aide du mécanisme Ingress.
Ajoutez tout d’abord la source de paquets Jenkins :
$ helm repo add jenkins https://charts.jenkins.io
Ci-dessous la configuration à utiliser pour exposer le master sur Internet à l’adresse https://jenkins.eni.yannig.ovh avec création d’un certificat SSL/TLS :
controller:
ingress:
enabled: true
annotations:
kubernetes.io/tls-acme: "true"...
Pipeline de déploiement continu avec Jenkins
1. Prérequis
Pour les exemples qui vont suivre, le dépôt Git https://github.com/Yannig/eni-kubernetes.git sera utilisé. Charge à vous de changer l’adresse pour pointer vers un dépôt Git lui appartenant.
2. Présentation du mécanisme de déploiement continu
Dans Jenkins, un pipeline de déploiement continu est un programme écrit en Groovy qui va piloter le déroulement d’un déploiement. Un déploiement se déroule généralement de la manière suivante :
-
récupération du code source ;
-
compilation du programme ;
-
sauvegarde du résultat de la compilation ;
-
mise à jour de l’application sur l’environnement de déploiement continu.
Le pipeline d’exemple reprendra ces grandes phases.
Schéma de principe du pipeline de déploiement continu
L’application à construire est stockée dans le sous-répertoire flask-healthcheck. Cette application est une application Flask qui dispose d’un fichier Dockerfile.
Cette image sera stockée sur le registre public de Docker sous le nom yannig/flask-healthcheck.
3. Stockage des identifiants Docker
Afin de pouvoir pousser l’image compilée sur Docker Hub, un secret sera créé dans l’espace de noms de Jenkins.
Créez ce secret à l’aide de la commande suivante :
$ kubectl create secret docker-registry docker-hub-cred \
--docker-server=docker.io \
--namespace=jenkins \
--docker-username=yannig \
--docker-password=xxx
4. Création de l’environnement develop
Afin de mettre à jour en continu une version de l’application, l’espace de noms develop sera créé avec un déploiement de test.
En premier lieu, créez l’espace de noms :
$ kubectl create ns develop
Dans cet espace de noms, créez un déploiement de test de l’image yannig/flask-healthcheck en version latest :
$ kubectl -n develop create deployment \
--image docker.io/yannig/flask-healthcheck:latest test
5. Création du pipeline
a. Création du pod de compilation
La première chose...
Un mot sur Jenkins X
La mise en place d’un processus d’intégration et de déploiement continu à l’aide de Jenkins dans Kubernetes réclame un certain savoir-faire :
-
choisir les extensions Jenkins ;
-
gérer la mise en place des droits ;
-
orchestrer les opérations à l’aide du pipeline.
Jenkins X propose une réponse plus simple à mettre en œuvre pour un développeur en prenant en charge les aspects communication/création du cluster Kubernetes. L’utilisateur peut ainsi se concentrer sur sa tâche principale : le développement.
N’hésitez pas à consulter les adresses suivantes pour en savoir plus sur ce logiciel :
-
le dépôt Git de Jenkins X sur GitHub : https://github.com/jenkins-x/jx
-
le site principal de Jenkins X : https://jenkins-x.io/