Brève introduction à Kustomize

[référence au conte pour enfants américain « Le Petit Train Qui Peut » (« The Little Engine That Could ») — note du trad.]

Comment créer automatiquement de petites images Docker selon vos besoins

Une obsession inhabituelle

Depuis quelques mois, j'étais obsédé par une idée fixe : jusqu'où peut-on réduire une image Docker tout en permettant à l'application de fonctionner ?

Je comprends, l'idée semble étrange.

Avant de plonger dans les détails et les subtilités techniques, je voudrais expliquer pourquoi ce problème m’a tant interpellé et en quoi il vous concerne.

Pourquoi la taille compte

En réduisant le contenu de l'image Docker, nous minimisons également la liste des vulnérabilités. De plus, nous rendons les images plus propres, car elles contiennent uniquement ce qui est nécessaire au fonctionnement des applications.

Il y a un autre petit avantage — les images se téléchargent un peu plus vite, mais personnellement, je ne pense pas que cela soit si important.

À noter : Si la taille vous préoccupe, les images Alpine sont par elles-mêmes petites et conviendront certainement à vos besoins.

Images distroless

Le projet Distroless propose une collection de « distroless » de base, ne contenant pas de gestionnaires de paquets, de shells et d'autres utilitaires que vous avez l'habitude de voir dans une ligne de commande. Par conséquent, vous ne pouvez pas utiliser des gestionnaires de paquets comme pip et apt :

FROM gcr.io/distroless/python3
RUN pip3 install numpy

Dockerfile utilisant l'image distroless Python 3

Envoi du contexte de construction au démon Docker  2.048kB
Étape 1/2 : FROM gcr.io/distroless/python3
 ---> 556d570d5c53
Étape 2/2 : RUN pip3 install numpy
 ---> Exécution dans dbfe5623f125
/bin/sh: 1: pip3: introuvable

Aucun pip dans l'image

Ce problème est généralement résolu par une construction multi-étapes :

FROM python:3 as builder
RUN pip3 install numpy

FROM gcr.io/distroless/python3
COPY --from=builder /usr/local/lib/python3.7/site-packages /usr/local/lib/python3.5/

Construction multi-étapes

À l'arrivée, on obtient une image de 130 Mo. Ce n'est pas si mal ! Pour comparer : l'image Python par défaut pèse 929 Mo, tandis que la version « allégée » (3,7-slim) — 179 Mo, l'image alpine (3,7-alpine) — 98,6 Mo, alors que l'image distroless de base utilisée dans l'exemple — 50,9 Mo.

On peut légitimement souligner que dans l'exemple précédent, nous copions un répertoire entier /usr/local/lib/python3.7/site-packages, qui peut contenir des dépendances dont nous n'avons pas besoin. Il est clair que la différence de taille entre toutes les images de base Python existantes varie.

Au moment de la rédaction de ces lignes, Google distroless prend en charge encore peu d'images : Java et Python — en phase expérimentale, et Python n'existe que pour 2.7 et 3.5.

Petites images

Revenons à ma passion pour la création de petites images.

En fait, je voulais voir comment fonctionnent les images distroless. Le projet distroless utilise l'outil de construction de Google bazel. Cependant, pour installer Bazel et écrire mes propres images, cela a nécessité pas mal d'efforts (et pour être tout à fait honnête, réinventer la roue est à la fois amusant et instructif). Je voulais simplifier la création d'images réduites : le processus de création d'une image devrait être d'une simplicité extrême, banale. Afin qu'il n'y ait aucun fichier de configuration, juste une ligne dans la console : il suffit de construire une image pour.

Donc, si vous souhaitez créer vos propres images, sachez qu'il existe une image Docker unique, scratch. Scratch est une image "vide", elle ne contient pas de fichiers, bien qu'elle pèse par défaut — wow ! — 77 octets.

FROM scratch

L'image scratch

L'idée de l'image scratch est que vous pouvez copier toutes les dépendances depuis la machine hôte et soit les utiliser à l'intérieur du Dockerfile (c'est comme les copier dans apt et installer à partir de zéro), soit plus tard, lorsque l'image Docker est matérialisée. Cela permet de contrôler entièrement le contenu du conteneur Docker et ainsi de contrôler complètement la taille de l'image.

Maintenant, nous devons d'une certaine manière rassembler ces dépendances. Les outils existants comme apt permettent de télécharger des paquets, mais ils sont liés à la machine actuelle et, finalement, ne supportent pas Windows ou MacOS.

Ainsi, j'ai décidé de créer mon propre outil qui rassemblerait automatiquement une image de base de la plus petite taille possible tout en exécutant n'importe quelle application. J'ai utilisé des paquets Ubuntu/Debian, j'ai fait un échantillonnage (obtenant des paquets directement depuis les dépôts) et j'ai trouvé leurs dépendances de manière récursive. Le programme devait télécharger automatiquement la dernière version stable du paquet, minimisant ainsi les risques de sécurité.

J'ai nommé l'outil fetchy, car il… trouve et apporte… ce dont vous avez besoin [de l'anglais « fetch », « apporter » — N.D.T.]. L'outil fonctionne via une interface en ligne de commande, mais propose également une API.

Pour créer une image en utilisant fetchy (prenons cette fois l'image Python), il vous suffit d'utiliser le CLI comme suit : fetchy dockerize python. On peut vous demander le système d'exploitation cible et le nom de code, car fetchy utilise pour l'instant uniquement des paquets basés sur Debian et Ubuntu.

Vous pouvez maintenant choisir quelles dépendances ne sont vraiment pas nécessaires (dans notre contexte) et les exclure. Par exemple, Python dépend de Perl, bien qu'il fonctionne parfaitement sans que Perl soit installé.

Résultats

L'image Python, créée avec la commande fetchy dockerize python3.5 pèse seulement 35Mo (je suis plus que sûr qu'à l'avenir, il sera possible de l'alléger encore plus). Ainsi, l'image distroless a réussi à réduire encore 15Mo.

Vous pouvez voir toutes les images collectées jusqu'à présent ici.

Le projet — ici.

Si vous avez besoin de fonctionnalités supplémentaires, créez simplement une demande — je serai heureux de vous aider 🙂. En fait, je travaille actuellement sur l'intégration d'autres gestionnaires de paquets dans fetchy, afin d'éliminer le besoin de constructions multi-étapes.

Source : habr.com