Comment créer vos propres images de base Docker à partir de « Scratch »

Les images Docker sont créées à partir d’un Dockerfile qui définit une image de base et une série d’instructions qui ajoutent vos propres couches de système de fichiers. Que se passe-t-il si vous voulez faire votre posséder « image de base » cependant ? Voici comment repartir de zéro et créer un système de fichiers conteneur complet à partir de zéro.

Qu’est-ce qu’une image ?

Les images Docker utilisent généralement une distribution Linux populaire comme image de base. Si vous avez écrit FROM ubuntu:latest, FROM debian:latest ou FROM alpine:latest, vous avez utilisé un système d’exploitation comme base. Vous pouvez également utiliser une image préconfigurée pour un langage ou un framework de programmation particulier, tel que FROM php:8.0 ou FROM node:16.

Toutes ces images constituent un point de départ utile pour vos applications. Ils sont livrés avec des utilitaires Unix communs et des progiciels clés. Tout cela augmente cependant la taille de votre image finale. Une image vraiment minimale doit être construite en construisant votre propre système de fichiers à partir des premiers principes.

L’image « à gratter »

Docker fournit une image de base spéciale qui indique que vous souhaitez contrôler la première couche du système de fichiers. Il s’agit de la couche la plus basse de votre image, généralement définie par l’image de base indiquée par votre FROM instruction.

Lorsque vous souhaitez créer une image « à partir de zéro », écrivez FROM scratch dans votre Dockerfile est la voie à suivre ! Cela vous donne un système de fichiers qui est une ardoise vierge pour commencer.

FROM scratch

Vous devez ensuite utiliser le reste de votre Dockerfile comme d’habitude pour remplir le système de fichiers du conteneur avec les binaires et les bibliothèques dont vous avez besoin.

Qu’est-ce que « scratch »?

Les scratch « image » ressemble à une image Docker normale. Il est même répertorié dans Docker Hub. scratch n’est pas réellement une image cependant – c’est un mot-clé réservé qui désigne la couche de système de fichiers la plus basse d’une image fonctionnelle. Toutes les images Docker se trouvent au sommet scratch comme leur socle commun.

Tu ne peux pas docker pull scratch et il n’est pas possible d’exécuter des conteneurs en l’utilisant. Il représente un calque d’image vide, il n’y a donc rien à exécuter pour Docker. Les images ne peuvent pas être marquées comme scratch soit en raison de son caractère réservé.

Que peut-on ajouter aux images de base ?

Vous n’avez pas besoin de grand-chose pour construire une image fonctionnelle au-dessus scratch. Tout ce que vous devez ajouter est un binaire Linux compilé statiquement que vous pouvez utiliser comme commande de votre image.

Voici une démo fonctionnelle qui exécute un petit programme « hello world » compilé à partir de C :

#include <stdio.h>
 
int main() {
    printf("Hello World");
    return 0;
}

Compilez votre code C en binaire :

gcc -o helloworld hello.c

Exécutez votre binaire et observez que « hello world » est imprimé sur votre terminal :

./helloworld

Vous pouvez maintenant créer un conteneur Docker basé sur scratch qui exécute votre binaire :

FROM scratch
COPY helloworld /
CMD ["helloworld"]

Construisez votre image :

docker build -t hello:latest .

Inspecter l’image avec docker inspect montrera qu’il a une seule couche. Le système de fichiers de cette image ne contient qu’un seul fichier, le helloworld binaire.

Exécutez maintenant un conteneur à l’aide de votre image :

docker run hello:latest

Vous verrez « hello world » dans votre terminal pendant que votre binaire compilé est exécuté. Votre image à base de scratch contient uniquement votre binaire, sa taille ne sera donc que de quelques Ko. L’utilisation de n’importe quelle image de base du système d’exploitation augmenterait cela à plusieurs mégaoctets, même avec une distribution minimale comme Alpine.

Pratiquement toutes les images auront des dépendances au-delà d’un simple binaire statique. Vous devrez les ajouter à votre image dans le cadre de votre Dockerfile. N’oubliez pas qu’aucun des outils que vous considérez comme acquis dans les distributions Linux standard ne sera disponible tant que vous ne les ajouterez pas manuellement au système de fichiers de l’image.

Quand utiliser Scratch ?

La décision de partir de scratch doit être basé sur les dépendances de votre application et vos objectifs en matière de portabilité des images. Images construites à partir de scratch sont les plus adaptés à l’hébergement de binaires compilés statiquement où la taille de l’image et les temps de construction sont importants.

scratch vous fournit une table rase sur laquelle travailler, il faut donc un investissement initial pour écrire correctement votre Dockerfile et l’entretenir dans le temps. Certaines commandes Docker comme attach ne fonctionnera pas par défaut car il n’y aura pas de shell à l’intérieur de votre conteneur à moins que vous n’en ajoutiez un.

À l’aide de scratch peut poser plus de problèmes qu’il n’en vaut la peine lorsque vous utilisez des langages interprétés avec de lourdes dépendances environnementales. Vous devrez continuellement mettre à jour votre image de base pour référencer les dernières versions de ces packages. Il est généralement plus pratique et maintenable d’utiliser une version minimale d’une image de base Docker Hub existante.

Sommaire

FROM scratch dans un Dockerfile indique que vous voulez commencer à partir d’un système de fichiers vide où vous contrôlez chaque couche ajoutée. Il facilite des images hautement rationalisées purgées de tout, à l’exception des dépendances dont votre application a besoin.

Il est peu probable que la plupart des développeurs utilisent scratch directement car il ne convient pas à la majorité des cas d’utilisation de conteneurs. Vous pouvez choisir de l’utiliser si vous souhaitez conteneuriser des binaires statiques autonomes avec peu d’exigences environnementales.

scratch fonctionne également comme un indicateur clair de la différence entre les « conteneurs » et les machines virtuelles. Une image contenant un seul fichier exécutable est un conteneur Docker utilisable car le processus est exécuté sur le noyau de votre hôte. Une machine virtuelle ordinaire doit démarrer indépendamment de son hôte, elle doit donc inclure un noyau de système d’exploitation complet dans son image.