Le passage d’un code source à une image container prête à être consommée est une étape indispensable et l’effort que cela nécessite est souvent sous-estimé. Pour synthétiser, ce passage consiste à créer un fichier de configuration pour renseigner sur quel image de système d’exploitation doit fonctionner le container, comment télécharger le compilateur, comment compiler l’application et comment exécuter l’application. Ensuite, il faut lancer la commande de construction du container puis le charger dans une registry pour un téléchargement et une exécution ultérieurs. Sur un petit environnement avec quelques containers, quelques fichiers de configuration et quelques commandes à exécuter, c’est faisable. Cependant, ça devient vite plus compliqué à mesure où le nombre de container croît. Ça sera d’autant plus compliqué avec l’inévitable gestion du cycle de vie des applications, celle-ci est induite par la mise à jour du code applicatif et par les mises à jour de sécurité des composants liés au système d’exploitation. C’est une tâche fastidieuse et chronophage.
L’agilité étant l’objectif premier de l’utilisation des containers, l’automatisation du processus de création d’image container est vite devenue indispensable. Dans la majorité des cas, l’utilisation d’un pipe-line est privilégiée pour enchaîner les commandes de création et de mise à jour. La mise en place et le maintien en condition opérationnel de ce pipeline n’est pas non plus à négliger.
J’ai récemment testé VMware Tanzu Build Service (TBS), je me suis vite rendu compte qu’il simplifie drastiquement ce processus et j’ai été séduit par sa facilité d’utilisation. En effet en une seule commande, le code source est transformé en image container puis stockée dans une registry et ce sans que le développeur n’ait à générer de fichier de configuration.
Les containers sont créés au format OCI (Open Container Initiative, lancée en 2015 par Docker) assurant leur fonctionnement sur l’ensemble des runtime container du marché à condition qu’ils respectent cette initiative.
D’un point de vu macro, l’image container générée est découpée en 3 parties indépendantes : la Stack, le buildpack et l’Application qui permettent une modification granulaire.
La stack (appelée aussi Cloudstack) concerne la partie liée au système d’exploitation, le Buildpack concerne la partie qui permet de construire et d’exécuter l’application (java, nodejs, php, …), la partie Application concerne le code source de l’application. Cela permet de mettre à jour granulairement chaque partie de manière indépendante. Ainsi, si par exemple une faille de sécurité est détectée sur la partie stack, TBS permettra de mettre à jour que cette partie en appliquant un patch de sécurité.
Voyons le fonctionnement principal :
En entrée TBS a besoin d’un code source (les langages pris en charge sont fonctions des buildpack installés (Java, go, php, …)), ce code source peut être, dans un répertoire local, sur un repository git ou encore sur un blob store http au format zip, tgz ou tar.
En sortie, TBS va stocker le container image dans une registry de type Harbor, GCRIO ou autre.
Comme exemple, la commande ci-dessous avec en entrée un repository git et en sortie un lien vers une registry privée Harbor :
kp image create spring-music –tag harbor.cpod-velocity.az-fkd.cloud-garage.net/tanzu/spring-music:1 –git https://github.com/fbenrejdal/spring-music.git –git-revision master
TBS détecte automatiquement les buildpacks dont l’application a besoin pour construire et exécuter l’image.
L’option –git-revision master indique à TBS de surveiller les modifications de la version master et d’enclencher automatiquement une mise à jour de l’image container si une nouvelle version a été “commitée”. dans ce cas, seule la partie Application de l’image container est modifiée.
La solution TBS vient déjà avec un certain nombre de buildpack mais il est possible de construire ses propres buildpacks. La commande ci-dessous permet de visualiser les buildpacks déjà installés.
$ kp clusterstore status default
Status: Ready
BUILDPACKAGE ID VERSION HOMEPAGE
paketo-buildpacks/procfile 2.0.2 https://github.com/paketo-buildpacks/procfile
tanzu-buildpacks/dotnet-core 0.0.5
tanzu-buildpacks/go 1.0.6
tanzu-buildpacks/httpd 0.0.38
tanzu-buildpacks/java 3.8.0 https://github.com/pivotal-cf/tanzu-java
tanzu-buildpacks/java-native-image 3.6.0 https://github.com/pivotal-cf/tanzu-java-native-image
tanzu-buildpacks/nginx 0.0.46
tanzu-buildpacks/nodejs 1.2.1
tanzu-buildpacks/php 0.0.3
Pour résumer, Tanzu Build Service permet de réduire drastiquement le temps et les opérations de création ainsi que les mises à jour des images containers, le développeur n’a plus à se soucier à gérer des fichiers de configuration, il se focalise juste sur son code. TBS détecte tout seul en fonction du code source les dépendances dont il a besoin et est capable aussi de détecter les mises à jour qui ont été “commitées” pour générer une nouvelle image container. TBS découpe l’image container en couche : Stack, Buildpack et Application afin de pouvoir mettre à jour unitairement chaque partie.
Pour voir comment créer une image et la mettre à jour, j’ai créé deux courtes vidéos :
TBS creation d’une image container à partir de github
TBS détection automatique d’une mise à jour
Mes collègues spécialistes Alexandre et Guillaume ont animé un webinar en Français plus détaillé sur ce sujet :
Cloud Native Buildpack : La formule pour transformer vos applications en conteneurs avec Kubernetes
Laisser un commentaire