132 lines
4.9 KiB
Markdown
132 lines
4.9 KiB
Markdown
\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](https://github.com/moby/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 :
|
||
|
||
<div lang="en-US">
|
||
```
|
||
mkdir -p ~/.docker/cli-plugins
|
||
curl https://github.com/docker/buildx/releases/download/v0.6.3/buildx-v0.6.3.linux-amd64 \
|
||
-L -s -S -o ~/.docker/cli-plugins/docker-buildx
|
||
chmod +x ~/.docker/cli-plugins/docker-buildx
|
||
```
|
||
</div>
|
||
|
||
#### 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 :
|
||
|
||
<div lang="en-US">
|
||
```
|
||
docker buildx build .
|
||
```
|
||
</div>
|
||
|
||
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 :
|
||
|
||
<div lang="en-US">
|
||
```dockerfile
|
||
# syntax=docker/dockerfile:1.2
|
||
FROM ubuntu
|
||
RUN apt-get update && apt-get install gimp
|
||
```
|
||
</div>
|
||
|
||
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](https://github.com/po3rin/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](https://openllb.github.io/hlb/) : une syntaxe prometteuse, plus proche
|
||
pour les développeurs.
|
||
- [Earthly](https://earthly.dev/) : 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](https://www.packer.io/docs/builders/docker)
|
||
- [Nix et Guix](https://nix.dev/tutorials/building-and-running-docker-images)
|
||
- [Kubler](https://github.com/edannenberg/kubler)
|
||
- et bien d'autres.
|