Published by

Il y a 6 mois -

Temps de lecture 12 minutes

Autour des conteneurs : Les petits conteneurs

Dockeriser son application devient de plus en plus une norme, mais qui dit norme dit également dérive. Dans cette article nous allons parler d’un problème de taille. Oui, de taille. Vous avez peut être déjà utilisé des images qui pouvaient faire 100Mo, 500Mo, parfois même plusieurs Go, alors que derrière le process exécuté ne représente de 5 à 10% de l’espace occupé. Certains diront que aujourd’hui entre le débit internet et l’espace disque dont nous disposons ce n’est pas très important. Cependant en embarquant la terre entière dans vos livrables vous prenez plus de risque d’embarquer une faille de sécurité, un bug ou un outil qui peut un jour disparaître et impacter votre application alors que vous n’en aviez même pas besoin.

À travers un exemple, je vous propose de découvrir ce qui fait qu’une image peut rapidement être énorme et comment se débarrasser tout ce qui occupe de l’espace pour rien.

Avant d’entrer dans le vif du sujet, je vous propose de vous prêter à l’exercice à l’aveugle. Votre objectif, dockeriser le front de l’application hello-world NodeJS et créer l’image la plus petite possible. Pour connaitre la taille de votre image, vous pouvez utiliser la commande suivante :

docker image <image_name>

Vous pourrez alors comparer votre image à celle obtenu à la fin de cet article. Réussirez-vous à faire plus petit ?

Version 1 : Image de base ubuntu

Pour cette première version de notre image docker, je ne réfléchis pas trop. Je calque la façon dont je construis et lance l’application sans docker sur mon ordinateur. Je travaille sous ubuntu 18.04, et pour déployer un site internet j’utilise nginx. Le front est développé en nodeJS, pour le construire j’ai besoin de npm et nodeJS. Dans un Dockerfile, ça donne :

FROM ubuntu:18.04

# port à exposer pour accéder à l'application
EXPOSE 80

# on installe les outils nécessaire à la construction et à l'exécution
RUN apt update &amp;&amp; apt install node npm nginx -y

# on se place dans un dossier de travail et on y copie tout le code de l'application
WORKDIR /app
COPY . ./

# On construit l'application et on la déplace dans le bon dossier pour nginx
RUN npm install
RUN npm run build
RUN cp dist/* /var/www

# Commande lancée lors du run de l'image docker
CMD ["nginx", "-g", "daemon off;"]

Je construis et je vérifie la taille de mon image :

docker build -t hello-step1 .
...
docker images hello-step1
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
hello-step1         latest              e649dbd95c46        29 seconds ago      606MB

Ça fait un livrable de 606Mo pour un front qui faisait 2.4Mo. Sans surprise, c’est beaucoup trop. Je suis parti de Ubuntu qui prend déjà beaucoup d’espace. Pour faire tourner un front, il n’y a pas besoin d’un OS comme Ubuntu.

Version 2 : Image de base nginx alpine

Si vous cherchez dans la liste des images officiel du docker hub, vous trouverez déjà plein de logiciel dockerisé en libre service. Et si jamais celui que vous chercher n’est pas dans la liste des images officielles, vous avez encore de grande chance d’en trouver une version non officielle mais quand même supportée par la communauté.

Nous avons besoin de nginx pour exposer notre front. Mais au lieu de l’installer nous même dans notre Dockerfile, ne serait-il pas plus simple de chercher si il existe une image déjà construite comme il faut avec nginx dedans ? Ça tombe bien, c’est le cas ! Une image officiel nginx est disponible sur le docker hub. Dans la liste des tags associé à l’image, nous voyons que la dernière est la 1.17.5. En revanche c’est étrange, il existe la même version suffixé par alpine avec une taille indiqué à 8Mo au lieu de 50Mo. Qu’est-ce que cela signifie ?

Alpine Linux est une version très petite de Linux. Elle est basée sur MUSL, le standard libc le plus léger qui existe. Cet OS est très utilisé comme image de base dans le monde des conteneurs car il permet de réduire considérablement la taille de nos images finales. Lorsqu’un tag docker et suffixé par alpine, l’auteur nous informe qu’il s’est basé sur l’image docker d’Alpine Linux plutôt qu’un Debian comme pour l’image docker nginx:1.17.5.

C’est parfait pour nous, voyons voir ce que cela donne si on part d’une image nginx alpine.

FROM nginx:1.17.5-alpine

# port à exposer pour accéder à l'application
EXPOSE 80

# Sous Alpine, on utilise plus apt mais apk
RUN apk add nodejs npm

# on se place dans un dossier de travail et on y copie tout le code de l'application
WORKDIR /app
COPY . ./

# On construit l'application et on la déplace dans le bon dossier pour nginx
RUN npm install
RUN npm run build
RUN cp -r dist/* /usr/share/nginx/html
docker build -t hello-step2 .
...
docker images hello-step2
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
hello-step2         latest              767388e5b567        24 seconds ago      318MB

318Mo ! C’est mieux mais c’est encore beaucoup… Mince alors j’ai pourtant utilisé une version alpine de nginx ! Il est indiqué que cette image fait seulement 8Mo… Mais attend ! Quand j’y repense, l’image Ubuntu dont je suis parti en version 1 faisait 42Mo seulement elle aussi ! Comment j’ai pu atteindre 600Mo sur mon image ?

Version 3 : Utiliser un conteneur de build

Dans nos Dockerfiles, la première chose qu’on fait c’est installer les outils nécessaire à la construction de notre application : NodeJS et npm. Des outils qui eux même peuvent avoir des dépendances qu’ils installent à leur tour. On lance ensuite la construction de l’application, qui va télécharger toutes les librairies nodeJS utilisées dans le projet pour générer le front à exposer.

Le problème c’est que ces outils prennent de l’espace pour rien. En effet, il n’y a pas besoin de NodeJS et de npm pour exposer un front via un webserver. Il n’y a pas non plus besoin des librairies téléchargées par npm pour construire le front.

Une solution serait de construire l’application en dehors de notre Dockerfile et d’utiliser COPY pour récupérer le dossier dist. Mais cela va à l’encontre de ce qu’on voulait en introduction :

Nous appellerons optimisé une image de petite taille, qui se téléchargera rapidement, et qui se construira et lancera facilement, sans avoir à installer de dépendance ni aucune manipulation autre qu’un docker build et docker run.

Nous allons faire un Dockerfile multistage. C’est à dire que nous aurons plusieurs instructions FROM qui représenteront chacun un stage. Nous utiliserons le premier stage comme conteneur de build.

# premier stage basé sur une image node qui contient tout ce qu'il faut pour pour construire notre front
FROM node:8.4.0-wheezy AS builder

WORKDIR /app
# on récupère tout le projet
COPY . ./

# on construit l'application comme avant
RUN npm install
RUN npm run build

# deuxième stage, basé sur notre nginx
FROM nginx:1.17.5-alpine

# port à exposer pour accéder à l'application
EXPOSE 80

# on récupère le résultat de notre conteneur de build
COPY --from=builder /app/dist/ /usr/share/nginx/html

L’avantage de cette méthode, c’est que l’image docker produite ne contiendra que ce qui a été exécuté dans le dernier stage. Dans ce cas là, le filesystem de l’image nginx alpine et le dossier dist récupéré du stage builder. Si on regarde la taille finale de notre image :

docker build -t hello-step3 .
...
docker images hello-step3
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
hello-step3         latest              92e06636ca2c        5 minutes ago       23.8MB

23.8Mo ! Pas mal, on a divisé par 10 la taille de notre image de la version 2. Quoi ? Quel est le problème ? 8.34Mo + 2.4Mo ne fait pas 23.8Mo ? Ah mais oui c’est normal, sur le dockerhub ils indiquent la taille des images dans un format compressé. La preuve :

docker images nginx:1.17.5-alpine
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nginx               1.17.5-alpine       b6753551581f        5 minutes ago       21.4MB

21.4Mo + 2.4Mo = 23.8Mo. Le compte est bon. On a la preuve qu’on a construit une image clean avec le strict minimum pour faire tourner notre frontend. Enfin… Est-ce qu’on a vraiment besoin d’un système d’exploitation pour ça ? Est-ce qu’Alpine ne serait pas de trop ?

Version 4 : Utiliser un binaire statique

Tout d’abord, petit rappel de ce qu’est un conteneur :

Un conteneur est un process démon qui va être isolé des autres. On pourrait faire un amalgame avec les VMs mais une VM est faite pour simuler un OS au complet et y faire tourner une multitude de process comme si vous étiez sur votre ordinateur directement. Non, un conteneur est un process, c’est tout. Il partagera le même système d’exploitation que votre machine hébergeante.

conteneur vs machine virtuelle

Si un conteneur c’est juste un seul process, tout ce qui sera exécuté au final c’est un serveur web. À aucun moment on exécutera un système d’exploitation. Finalement, Alpine n’est pas là pour être l’OS de notre process nginx, mais pour apporter dans le filesystem les dépendances dont nginx a besoin comme la libc.

Bon c’est bien ce que je pensais, l’intégralité d’Alpine n’est pas nécessaire. Ce qu’il faut c’est que je trouve une image docker d’un webserver compilé statiquement et basé sur un filesystem vide (from scratch).

Après une brève recherche, il n’existe pas dans docker hub une telle image à disposition. J’ai donc créé ma propre image que j’ai nommé franckcussac/rust-webserver:static basée sur le gist simple HTTP example for rust. Elle va me servir de base pour l’image de mon frontend.

FROM node:8.4.0 AS builder

WORKDIR /app
COPY . ./

RUN npm install
RUN npm run build

# on récupère l'image construite à partir du gist
FROM franckcussac/rust-webserver:static

# port à exposer pour accéder à l'application
EXPOSE 80

# on récupère le résultat de notre conteneur de build
COPY --from=builder /app/dist/ /public/

On construit et on regarde la taille de notre image :

docker build -t hello-step4 .
...
docker images hello-step4
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
hello-step4         latest              e5ae3d50bdf1        9 minutes ago       5.24MB

Version 5 : MUSL c’est trop lourd

Nous venons de créer une image docker pour notre frontend avec dedans :

  • un binaire de webserver
  • le site internet

Pour une taille totale de 5.24Mo, dont 2.4Mo incompressible. Ça nous fait 2.8Mo seulement dédié au webserver… On se dit qu’on peut pas aller plus loin ? Hé, en vrai regardez le code du webserver, il fait 100 lignes. 2.8Mo de binaire pour un code de 100 lignes ? C’est beaucoup non ? Ah oui bien sur, il faut inclure MUSL dans le binaire. Mais MUSL c’est plein de choses du standard C dont je n’ai pas besoin. Est-il possible de se passer de MUSL ou toute librairie faisant partie du standard d’un langage ?

Oui, pour ça il nous faudrait un webserver en assembleur ! Ça tombe bien il y en a plein déjà existant, et certains sont même sur le dockerhub tout prêt. Voyons voir la taille d’une de ces images.

3ko !! Alors là même si c’est la taille compressée c’est vraiment léger. Notre site web faisant 2.4Mo, 3ko c’est totalement négligeable. Et comme l’image docker existe déjà, j’ai juste à l’utiliser en base et à déposer mon site internet dans le bon dossier.

FROM node:8.4.0-wheezy AS builder

WORKDIR /app
COPY . ./

RUN npm install
RUN npm run build

# l'image docker du webserver en assembleur
FROM jtyr/asmttpd:0.4.4-1 

COPY --from=builder /app/dist/ /dist
EXPOSE 80

# la commande pour lancer le webserver
CMD ["/asmttpd", "/dist", "80"]

On build et on regarde la taille de l’image finale :

docker build -t hello-step5 .
...
docker images hello-step5
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
hello-step5         latest              1807f0568b7d        12 seconds ago      2.36MB

2.36Mo, c’est la taille de notre frontend. Mission accomplie, on ne pourra plus réduire d’avantage.

Ce qu’il faut retenir de tout ça

En 5 étapes, nous sommes passés d’une image docker de plus de 600Mo à 2.36Mo. C’est 300 fois plus petit qu’au départ. En revanche, on notera quelques petits défauts à partir de la version 4.

Déjà, la version 4 a été un peu plus complexe à réaliser puisse qu’il a fallut d’abord dockeriser un projet ne nous appartenant pas pour ensuite l’utiliser comme base sur notre projet. Ensuite, dans les version 4 et 5 nous utilisons des images FROM scratch. C’est-à-dire qu’il n’y a rien dessus. Même pas de /bin/sh comme sur Alpine pour debugger notre application en cas de problème. De plus, la version 5 utilise un serveur web en assembleur, qui est une très mauvaise idée pour aller en production niveau sécurité.

Donc si entre la version 3 et 5 il y a quand même 19Mo de différence (soit ~600% plus petit), cela vaut-il vraiment toute la peine que l’on se rajoute ? Pour la version 4 cela peut dépendre de votre contexte, mais je vous déconseille fortement d’aller chercher des logiciels en assembleur pour construire votre application comme fait en version 5.

Au prochain épisode nous verrons comment debugger un conteneur FROM scratch.

Retrouvez le code source sur le github xke-petits-conteneurs.

Retrouvez le format vidéo qui devait être joué au Devoxx 2020 :

Published by

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.