La construction d’image docker est un processus qui ne ressemble pas beaucoup a du développement applicatif mais plus à de l’installation système. En effet on part d’un système de fichier d’ailleurs rarement vide scratch mais souvent alpine ou debian:stable-slim, que l’on enrichie par adjonction de fichiers sources et le lancement de commande dans l’image en construction. C’est donc une activité pure administration système: création de fichier et lancement de commandes. Il n’y a donc pas de place évidente à la conception comme on l’entend dans le développement.
Réutilisation du code
Cela amène naturellement à avoir des projets Dockerfile avec qui ne partagent qui ne partagent pas grands choses entre eux. Seul l’héritage de l’image parente, permet de réutiliser du code de construction mais uniquement par ajout de nouvelles instructions de construction dans l’image fille. L’héritage est un pilier de la conception dans pas le seul.
Pour quelle raison je m’attache à la conception ? car la définition d’une bonne conception est l’écriture d’un code qui marchera avec un code qui n’est pas encore écrit. Je trouve cette définition très belle en plus d’être juste. Une classe mère dont on peut héritée est bien conçue quand le code fils, écrit par définition après, peut tirer partie de cette héritage. Une librairie de log bien conçue permet son utilisation par des applications écrites après coup. Dans ces 2 exemples j’insiste sur le fait que le code de la classe mère ou celui du composant de log peut s’exécuter en collaboration (en appelant) du code dans la classe fille ou dans l’application (par implémentation d’interface du composant de log par ex.) ! C’est ce que j’appelle du code qui fonctionne avec du code pas encore écrit.
FROM pour partager
Dans le monde des images Docker on peut imaginer facilement une image qui offre un service comme générer du code 😉 C’est très facile à imaginer (voir mes archetypes de génération). Une fois que cette image est construite on aimerait pouvoir l’étendre pour pouvoir générer de nouveaux codes. Comment faire avec les seuls instruction FROM, COPY et RUN de docker.
Une première approche est de prévoir lors de l’exécution de l’image parente une fonction qui permette de pendre un argument un personnalisation pour générer du nouveau code. C’est alors l’image parente qui « exécute » le « code » nouveau mais nous n’avons pas vraiment créé de code nouveau. Nous avons seulement passé un paramètre à du code existant. Nous n’avons d’ailleurs pas créé d’image docker nouvelle !
Et si on créer une image docker nouvelle qui lance l’image parente ? On se heurte alors à des complication où le conteneur nouvellement créé doit lancer une image docker. Possible mais on ajoute le concept du docker qui appelle docker…. En oubliant un instant docker, les langages objet nous donne une solution élégante. L’image parente doit pouvoir par héritage donner à l’image fille la possibilité d’étendre son comportement. Oui mais… il n’y a pas vraiment d’héritage en docker. La commande FROM n’implémente pas un héritage de comportement mais juste un héritage de données ie le contenu de l’image parente.
Héritage et extension de comportement
Les instruction de construction d’image ne nous donnent pas la solution. Comme évoqué plus haut avec l’idée du passage de paramètre via un shell qui lance l’image , il nous faut passer par le code qui s’exécute quand on lance le conteneur. Si on se limite pour l’exemple à un conteneur parent qui utilise le shell pour faire son travail, alors pour étendre son comportement il suffit que l’image fille ajoute des scripts shell dans l’image à l’attention de l’image parente, voir écrase certains existants. On réinvente l’héritage et le polymorphisme. Il faut donc concevoir non pas avec le code docker mais au sein de l’image avec le code de son choix mais les langage de script sont bien adaptés.
Ainsi dans mes archétype, l’image de base appelle les scriptes qui sont dans un répertoire défini. Charge au images filles de mettre dans ce répertoire des scriptes spécifiques afin d’étendre le comportement de l’image mère. Lorsque l’on instancie l’image fille et que l’on exécute, c’est l’entrypoint.sh de l’image mère qui est lancée. Celle-ci appelle ses propres scrptes puis termine en appelant les scripts présents dans le répertoire hook.
Tags: Docker