Nous avons un Gitlab offrant les services de dépôts de sources et d’images docker mis en place dans le billet Docker – Registry avec GitLab. L’étape suivante sera de mettre en oeuvre l’integration continue et par la suite le deploiement continu.
Répétablité de la construction
La construction doit être un processus répétable. Même en conservant les sources et les dependances, le système exécutant la construction n’est pas à l’abri de changement. Ainsi le maven doit être figé, ses outils et paramétrages également. Cela permet de reproduire la construction ailleur. C’est là que docker rentre sur la scène : on va dockeriser la construction.
Docker pour construire
Docker permet de mettre en boîte une application (code, dependance et paramétrage). Cela assure une exécution identique où que le code s’executera ensuite.
Comme notre but est de lancer des commandes docker dans la phase de construction, docker doit lancer du docker. D’un point de vue technique l’integration continue doit lancer un conteneur docker qui est lui-même docker.
Une double couche
C’est là où on entrevoit le changement de paradigme dans l’approche de l’exécution d’un programme. Le principe n’est pas nouveau et on peut faire une analogie avec Java.
Analogie avec Java
Java offre une promesse d’exécution identique quelque soit la platforme. Pourvu que l’on ait une JVM. Si le but de mon application est d’executer du code Java en entrée, il est sensé d’écrire une JVM en Java. Ainsi l’exécution d’un programme devient indépendante de la JVM hôte puisque celle-ce exécute une JVM. Pourquoi est-ce mieux ? pourquoi ne pas simplement exécuter le code java en entrée sur la JVM hôte ? Parce que le code java en entrée va avoit les effets de bord de la JVM hôte comme par exemple les librairies endorsed…
Performances
L’idée n’est pas nouvelle mais là où l’émulation d’une JVM par une JVM va entrainer des lenteurs car la seconde JVM sera exécutée par un code Java contrairement à la JVM hôte qui est en code natif du système et qui exécute la JVM émulée, avec Docker on a beaucoup moins ce problème.
En effet l’application dans le conteneur s’exécute à vitesse réelle sur le noyau de l’hôte. L’isolation se fait par le noyau de l’hôte via des techniques d’isolation du système de fichiers (chroot), de la memoire et des processus (cgroup) etc… docker c’est de l’isolation de processus et non pas de la virtualisation de materiel.
Docker in docker
Il existe une image docker de docker appelée Docker in docker (dind). L’objectif sera donc de faire en sorte que GitLab lance les constructions via ce docker conteneurisé.
Gitlab et le CI décentralisé
L’implémentation de l’intégration continue dans GitLab utilise un mecanisme client-serveur. Des processus clients appelés Gitlab-runner s’executent sur une machine de construction: le serveur hébergeant GitLab ou une tout autre machine.
Le client gitlab-runner peut au choix et entre autre d’executer
- une commande shell quelconque
- ou bien une commande docker via Dind
Le second exemple est un cas particulier où le gitlab-runner exécute une commande de construction via docker. Au lieu d’utiliser docker pour lancer un maven conteneurisé, par exemple, on va utiliser docker pour lancer un docker conteneurisé.
Il permet également de factoriser l’installation de docker utilisé. Toutes les constructions, quel que soit leur lieu, se feront de la même manière puisque conteneurisées !
L’installation du gitlab-runner sur le système qui va exécuter la construction peut elle-même être conteneurisée. Cette solution me paraît interessante dans l’optique de migrer à terme tous les composants de l’atelier logiciel (Gitlab, registry, gitlab-runner) sur une VM à conteneurs dédiée indépendante de ma machine hôte afin de réserver à cette dernière l’unique fonction de station de travail.
Au prochain billet, la mise en œuvre !
Tags: devOps Docker Gitlab