{"id":872,"date":"2020-12-18T15:17:30","date_gmt":"2020-12-18T14:17:30","guid":{"rendered":"https:\/\/loeilduse.fr\/?p=872"},"modified":"2020-12-21T17:13:48","modified_gmt":"2020-12-21T16:13:48","slug":"passer-du-code-source-a-une-image-container-en-une-seule-commande","status":"publish","type":"post","link":"https:\/\/loeilduse.fr\/?p=872&lang=fr","title":{"rendered":"Passer du code source \u00e0 une image container en une seule commande"},"content":{"rendered":"

Le passage d’un code source \u00e0 une image container pr\u00eate \u00e0 \u00eatre consomm\u00e9e est une \u00e9tape indispensable et l’effort que cela n\u00e9cessite est souvent sous-estim\u00e9. Pour synth\u00e9tiser, ce passage consiste \u00e0 cr\u00e9er un fichier de configuration pour renseigner sur quel image de syst\u00e8me d’exploitation doit fonctionner le container, comment t\u00e9l\u00e9charger le compilateur, comment compiler l’application et comment ex\u00e9cuter l’application. Ensuite, il faut lancer la commande de construction du container puis le charger dans une registry pour un t\u00e9l\u00e9chargement et une ex\u00e9cution ult\u00e9rieurs. Sur un petit environnement avec quelques containers, quelques fichiers de configuration et quelques commandes \u00e0 ex\u00e9cuter, c’est faisable. Cependant, \u00e7a devient vite plus compliqu\u00e9 \u00e0 mesure o\u00f9 le nombre de container cro\u00eet. \u00c7a sera d’autant plus compliqu\u00e9 avec l’in\u00e9vitable gestion du cycle de vie des applications, celle-ci est induite par la mise \u00e0 jour du code applicatif et par les mises \u00e0 jour de s\u00e9curit\u00e9 des composants li\u00e9s au syst\u00e8me d’exploitation. C’est une t\u00e2che fastidieuse et chronophage.
\n<\/span><\/p>\n

L’agilit\u00e9 \u00e9tant l’objectif premier de l’utilisation des containers, l’automatisation du processus de cr\u00e9ation d’image container est vite devenue indispensable. Dans la majorit\u00e9 des cas, l’utilisation d’un pipe-line est privil\u00e9gi\u00e9e pour encha\u00eener les commandes de cr\u00e9ation et de mise \u00e0 jour. La mise en place et le maintien en condition op\u00e9rationnel de ce pipeline n’est pas non plus \u00e0 n\u00e9gliger. <\/span><\/p>\n

J’ai r\u00e9cemment test\u00e9 VMware Tanzu Build Service (TBS), je me suis vite rendu compte qu’il simplifie drastiquement ce processus et j’ai \u00e9t\u00e9 s\u00e9duit par sa facilit\u00e9 d’utilisation. En effet en une seule commande, le code source est transform\u00e9 en image container puis stock\u00e9e dans une registry et ce sans que le d\u00e9veloppeur n’ait \u00e0 g\u00e9n\u00e9rer de fichier de configuration.
\n<\/span><\/p>\n

\"\"<\/span><\/p>\n

Les containers sont cr\u00e9\u00e9s au format OCI (Open Container Initiative, lanc\u00e9e en 2015 par Docker) assurant leur fonctionnement sur l’ensemble des runtime container du march\u00e9 \u00e0 condition qu’ils respectent cette initiative.<\/span><\/p>\n

D’un point de vu macro, l’image container g\u00e9n\u00e9r\u00e9e est d\u00e9coup\u00e9e en 3 parties ind\u00e9pendantes : la Stack, le buildpack et l’Application qui permettent une modification granulaire.<\/span><\/p>\n

\"\"<\/p>\n

La stack (appel\u00e9e aussi Cloudstack) concerne la partie li\u00e9e au syst\u00e8me d’exploitation, le Buildpack concerne la partie qui permet de construire et d’ex\u00e9cuter l’application (java, nodejs, php, …), la partie Application concerne le code source de l’application. Cela permet de mettre \u00e0 jour granulairement chaque partie de mani\u00e8re ind\u00e9pendante. Ainsi, si par exemple une faille de s\u00e9curit\u00e9 est d\u00e9tect\u00e9e sur la partie stack, TBS permettra de mettre \u00e0 jour que cette partie en appliquant un patch de s\u00e9curit\u00e9.
\n<\/span><\/p>\n

Voyons le fonctionnement principal :<\/span><\/strong><\/span><\/p>\n

En entr\u00e9e TBS a besoin d’un code source (les langages pris en charge sont fonctions des buildpack install\u00e9s (Java, go, php, …)), ce code source peut \u00eatre, dans un r\u00e9pertoire local, sur un repository git ou encore sur un blob store http au format zip, tgz ou tar.<\/span><\/p>\n

En sortie, TBS va stocker le container image dans une registry de type Harbor, GCRIO ou autre. <\/span><\/p>\n

Comme exemple, la commande ci-dessous avec en entr\u00e9e un repository git et en sortie un lien vers une registry priv\u00e9e Harbor :<\/span><\/p>\n

kp image create<\/strong> spring-music –tag<\/strong> harbor.cpod-velocity.az-fkd.cloud-garage.net\/tanzu\/spring-music:1 –git<\/strong> https:\/\/github.com\/fbenrejdal\/spring-music.git –git-revision<\/strong> master<\/span><\/p>\n

TBS d\u00e9tecte automatiquement les buildpacks dont l’application a besoin pour construire et ex\u00e9cuter l’image.<\/span><\/p>\n

L’option –git-revision master<\/span> indique \u00e0 TBS de surveiller les modifications de la version master <\/span>et d’enclencher automatiquement une mise \u00e0 jour de l’image container si une nouvelle version a \u00e9t\u00e9 “commit\u00e9e”. dans ce cas, seule la partie Application de l’image container est modifi\u00e9e.<\/span><\/p>\n

 <\/p>\n

La solution TBS vient d\u00e9j\u00e0 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\u00e9j\u00e0 install\u00e9s.
\n<\/span><\/p>\n

$ kp clusterstore status default<\/strong><\/span>
\nStatus: Ready<\/span><\/p>\n

BUILDPACKAGE ID VERSION HOMEPAGE<\/span>
\npaketo-buildpacks\/procfile 2.0.2 https:\/\/github.com\/paketo-buildpacks\/procfile<\/span>
\ntanzu-buildpacks\/dotnet-core 0.0.5<\/span>
\ntanzu-buildpacks\/go 1.0.6<\/span>
\ntanzu-buildpacks\/httpd 0.0.38<\/span>
\ntanzu-buildpacks\/java 3.8.0 https:\/\/github.com\/pivotal-cf\/tanzu-java<\/span>
\ntanzu-buildpacks\/java-native-image 3.6.0 https:\/\/github.com\/pivotal-cf\/tanzu-java-native-image<\/span>
\ntanzu-buildpacks\/nginx 0.0.46<\/span>
\ntanzu-buildpacks\/nodejs 1.2.1<\/span>
\ntanzu-buildpacks\/php 0.0.3<\/span><\/p>\n

 <\/p>\n

Pour r\u00e9sumer, Tanzu Build Service permet de r\u00e9duire drastiquement le temps et les op\u00e9rations de cr\u00e9ation ainsi que les mises \u00e0 jour des images containers, le d\u00e9veloppeur n’a plus \u00e0 se soucier \u00e0 g\u00e9rer des fichiers de configuration, il se focalise juste sur son code. TBS d\u00e9tecte tout seul en fonction du code source les d\u00e9pendances dont il a besoin et est capable aussi de d\u00e9tecter les mises \u00e0 jour qui ont \u00e9t\u00e9 “commit\u00e9es” pour g\u00e9n\u00e9rer une nouvelle image container. TBS d\u00e9coupe l’image container en couche : Stack, Buildpack et Application afin de pouvoir mettre \u00e0 jour unitairement chaque partie.<\/span><\/p>\n

Pour voir comment cr\u00e9er une image et la mettre \u00e0 jour, j’ai cr\u00e9\u00e9 deux courtes vid\u00e9os :<\/span><\/p>\n

TBS creation d’une image container \u00e0 partir de github<\/a><\/span><\/p>\n

TBS d\u00e9tection automatique d’une mise \u00e0 jour<\/span><\/a><\/p>\n

Mes coll\u00e8gues sp\u00e9cialistes Alexandre et Guillaume ont anim\u00e9 un webinar en Fran\u00e7ais plus d\u00e9taill\u00e9 sur ce sujet : <\/span><\/p>\n

Cloud Native Buildpack : La formule pour transformer vos applications en conteneurs avec Kubernetes<\/span><\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Le passage d’un code source \u00e0 une image container pr\u00eate \u00e0 \u00eatre consomm\u00e9e est une \u00e9tape indispensable et l’effort que cela n\u00e9cessite est souvent sous-estim\u00e9. Pour synth\u00e9tiser, ce passage consiste \u00e0 cr\u00e9er un fichier de configuration pour renseigner sur quel image de syst\u00e8me d’exploitation doit fonctionner le container, comment t\u00e9l\u00e9charger le compilateur, comment compiler l’application<\/p><\/div>\n

Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":true,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22,111,112,1],"tags":[192,191,190,189],"post_mailing_queue_ids":[],"_links":{"self":[{"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/posts\/872"}],"collection":[{"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=872"}],"version-history":[{"count":43,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/posts\/872\/revisions"}],"predecessor-version":[{"id":918,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=\/wp\/v2\/posts\/872\/revisions\/918"}],"wp:attachment":[{"href":"https:\/\/loeilduse.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=872"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=872"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/loeilduse.fr\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=872"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}