4.9 KiB
\newpage
D'autres méthodes pour créer des images
Les images utilisées par Docker pour lancer les conteneurs répondent avant tout
aux spécifications OCI. Le format étant standard, il est normal que d'autres
outils puissent utiliser mais aussi créer des images. Nous allons voir dans
cette partie l'avenir des Dockerfile ou simplement d'autres outils plus
spécifiques.
buildx
Docker buildx est un plugin qui apporte
BuildKit. Tout en étant compatible avec la
syntaxe des Dockerfile existant, BuildKit apporte une gestion concurrente des
nœuds de construction : très utile lorsque l'on construit une image pour
plusieurs architectures.
Installation Windows et MacOS {-}
Avec Docker Desktop, le plugin est déjà installé, vous n'avez aucune action supplémentaire à effectuer, vous pouvez commencer à l'utiliser.
Installation Linux {-}
En fonction de la méthode d'installation que vous avez suivie, vous avez
peut-être déjà le plugin installé. Si vous n'avez pas d'erreur en exécutant
docker buildx, mais que vous voyez l'aide de la commande, c'est bon. Sinon,
vous pouvez l'installer comme ceci :
Utilisation\
Nous pouvons réutiliser le Dockerfile que vous avez écrit pour youp0m, en
remplaçant simplement la ligne de docker build par celle-ci :
Nous ne rentrerons pas plus dans les détails de cette nouvelle commande, mais sachez qu'on la retrouve particulièrement fréquemment dans les GitHub Actions : https://github.com/marketplace/actions/docker-setup-buildx
Changer la syntaxe de nos Dockerfile\
Parfois on peut se sentir un peu frustré par la syntaxe des Dockerfile ou par
son manque d'évolutivité. Avec BuildKit, il est possible de préciser un parseur
à utiliser pour l'évaluation de la syntaxe du Dockerfile. Les parseurs
(frontend dans la documentation en anglais) sont des images Docker, on
indique leur nom dans un commentaire au tout début du fichier :
La possibilité d'avoir plusieurs implémentations de Dockerfile apporte pas mal
d'avantages :
- La version de l'image frontend est systématiquement comparée en ligne au
début du parsing du
Dockerfile, ce qui assure la récupération des derniers correctifs/versions, sans nécessiter une mise à jour du daemon Docker. - On s'assure que chaque développeur/utilisateur utilise la même implémentation, avec la même version.
- L'évolution de la syntaxe peut être plus souple car elle ne dépend plus de la
version de Docker installée, mais de la version déclarée dans le
Dockerfile. - On peut même créer de nouvelles syntaxes facilement.
Les images de parseur sont chargées, à partir d'un fichier lisible et compréhensible par un humain, de créer une représentation intermédiaire (LLB). Cette représentation intermédiaire se compose d'une liste d'opérations basiques (ExecOp, CacheOp, SecretOp, SourceOp, CopyOp, ...).
N'hésitez pas à jeter un œil aux autres langages de Dockerfile existants,
notamment :
- Gockerfile : bien que dépassé faute de mise à jour, cette implémentation est très simple à comprendre : elle a pour but de créer une image contenant un unique binaire Go, à partir du nom de son dépôt.
- hlb : une syntaxe prometteuse, plus proche pour les développeurs.
- Earthly : qui tend à regrouper
Makefile,Dockerfile, et autres scripts de CI et de tests.
docker/dockerfile:1.3\
La version habituelle de la syntaxe des Dockerfile est la version 1.1. En
utilisant BuildKit, nous pouvons dès à présent passer à la version 1.2 (stable)
ou 1.3 (expérimentale).
Les ajouts par rapport à la syntaxe usuelle sont répertoriés sur cette page :
https://hub.docker.com/r/docker/dockerfile.
Exercice {-}
Faites en sorte que le Dockerfile que vous avez créé pour youp0m indique un
frontend BuildKit à utiliser, tout en restant compatible avec la syntaxe du
docker build classique.
Des images sans Docker
Il est aussi possible de se passer complètement de Docker. La plupart des outils qui sont capables de générer des images de machines virtuelles, sont aussi capable de générer des images Docker. Citons notamment :
- Hashicorp Packer
- Nix et Guix
- Kubler
- et bien d'autres.