Stratégie de construction d'images Docker et la fantaisie de réduction de la taille des images

Chez Scalingo, nous utilisons Docker comme un outil de base de notre infrastructure. Nous parions dessus depuis ses débuts pour construire ce PaaS. Nos clients envoient leur code, nous le transformons en image Docker, qui est exécutée dans notre infrastructure. Nous avons souvent entendu dire que l'optimisation de la taille des images Docker est une sorte de Saint Graal que tout le monde devrait respecter. C'est parfois vrai, et parfois ce n'est pas le cas. Lorsque vous construisez de nombreuses images différentes, vous serez assez heureux de les voir partager une base commune. Cet article expliquera comment nous utilisons les images Docker et comment, dans un cas, il est utile de penser à la taille d'une image, et parfois ce n'est pas le cas.

Contexte de Scalingo

Nous utilisons des conteneurs Docker à deux étapes différentes du flux de travail que nous proposons. La première étape est l'étape de construction. Un conteneur est créé, votre code et toutes ses dépendances sont rassemblés grâce aux buildpacks, aboutissant finalement à une image Docker, stockée dans un registre privé hautement disponible hébergé dans notre infrastructure. Chaque fois que notre orchestrateur envoie une demande pour démarrer un conteneur de votre application, un ou plusieurs serveurs de notre infrastructure récupèrent l'image que nous avons précédemment construite et l'exécutent, c'est l'étape de exécution.

Dans ce cas, nous avons couvert ce que nous appelons images d'application, des images qui sont construites dynamiquement en fonction de l'application déployée. Nous gérons également un autre type d'images : images de base de données, image pré-construite pour exécuter les différents types de bases de données gérées par la plateforme : MySQL, PostgreSQL, MongoDB, Redis, Elasticsearch.

Structure des images d'application

Lorsqu'une application est déployée, nous créons un conteneur basé sur ce que nous avons appelé une image de constructeur, cette image est open-source et vous la trouverez dans le Docker Hub, nommée scalingo/builder. Chaque fois qu'un utilisateur déploie une nouvelle version de son application, un conteneur est créé basé sur cette image de constructeur. Une fois la construction de l'application et de ses dépendances terminée, une autre couche unique est ajoutée à l'image résultant en l'image d'application. Dès que l'image est envoyée au registre, cette dernière couche uniquement est envoyée car toutes les autres couches sont communes.

L'image de constructeur est une base commune à toutes les applications hébergées sur la plateforme, par conséquent, elle devrait être une image générique qui est non spécialisée. C'est pourquoi elle est basée sur un environnement stable Ubuntu LTS (actuellement 14.04 LTS).

Dans cette image de constructeur, nous avons installé différentes bibliothèques et logiciels qui sont couramment utilisés, dans le processus de construction d'application ou à utiliser par un humain lors de l'exécution de conteneurs ponctuels. Vous trouverez :

• Outils essentiels de construction (GCC, make, autotools et plus.)

• curl, git, telnet, client ssh, openssl

• NodeJS, Ruby, Perl, Python, Java (version système, rien de spécifique à l'application)

• Imagemagicks

• MySQL, PostgreSQL, clients MongoDB, Redis et bibliothèques de développement

Rendre ces bibliothèques et logiciels par défaut optionnels a fait partie de notre réflexion. Nous savons que toutes les applications n'utiliseront pas par exemple imagemagicks, mais nous avons considéré que gérer un ensemble d'images de constructeur au lieu d'une seule n'en vaut pas la peine. En fait, une question courante posée est : “pourquoi utilisez-vous une image unique au lieu de plusieurs images basées sur la technologie de l'application, cela ne ralentirait-il pas le processus de déploiement ?”

Déplacer une image à travers un cluster est beaucoup plus facile et pratique que de gérer une myriade d'images. Même si nous sacrifions quelques mégaoctets d'espace disque pour cette image précise. Une fois qu'elle a été récupérée sur un nœud d'hébergement, nous avons fini. Lorsqu'une nouvelle application doit démarrer, la couche d'application est récupérée et rien d'autre. Elle contient tout ce qui est nécessaire pour exécuter l'application contenue. Par exemple, imaginez que nous voulons créer une image spécialisée pour les applications ruby, nous devrions maintenir les images pour toutes les versions de ruby depuis 1.8.7, cela représenterait plus ou moins 30 images à préparer et maintenir dans le temps.

Les gens discutent souvent de la taille de l'image Docker, mais dans ce cas, nous avons considéré qu'avoir une grande image de base commune est la bonne voie à suivre. Il n'y a pas de différence pour nous si l'image fait 800 Mo ou 1000 Mo, les serveurs la récupèrent une fois et l'utilisent des milliers de fois. Voici le schéma de la structure de notre image de constructeur :

Images de base de données

Avec les images de base de données, nous avons eu une autre approche, car nous contrôlons ce qui sera exécuté dans les conteneurs, nous n'avons pas besoin de construire ces images sur une pile vraiment générique, tout ce qui doit faire est d'exécuter la base de données que nous recherchons et de le faire bien.

De plus, nous travaillons avec cinq types de bases de données, chacune ayant plusieurs versions, donc pour éviter de remplir nos disques avec des images de base de données, nous avons commencé à chercher comment réduire leur taille de manière significative. Dans ce domaine, les images Docker basées sur Alpine Linux au lieu de Ubuntu ou Debian semblent gagner la course.

Alpine Linux est une distribution linux légère pesant pas plus de 5 Mo. C'est beaucoup moins que l'image standard Ubuntu, qui est, comme nous l'avons vu dans le schéma, 200 Mo lourde.

En conséquence, notre image redis pèse désormais 14 Mo. Auparavant, nous ne prêtions jamais attention à la taille de l'image, elle faisait 364 Mo. Réduire la taille d'une image par un facteur de 30× sans perdre aucune fonctionnalité de ce que l'image devrait faire, en vaut vraiment la peine. Travailler avec de telles images nous donne plus de flexibilité et nous permet de migrer les bases de données plus rapidement.

Toutes nos images Docker de base de données sont disponibles sur le Docker Hub, n'hésitez pas à les essayer.

Conclusion

Comme vous pouvez le voir, réduire la taille des images Docker peut parfois être utile. Cependant, ce n'est pas L'objectif ultime que vous devriez atteindre en premier. Surtout si vous construisez plusieurs images Docker contenant différentes applications en cours de développement intensif. En savoir plus sur notre Construction d'images Docker en tant que Service sur build.scalingo.com.