On utilisera une version récente dans les fichiers docker-compose.yml, et au minimum la 3.7 pour profiter des fonctionnalités présentées dans toute la section.
version: '3.7'
Lorsque l’image référencée par le fichier Compose via la directive image n’est pas présente sur un registry officiel, il est très utile de préciser à Compose comment la construire et à partir de quoi.
Question:
Quel intérêt par rapport à un docker build manuel ?
La commande docker-compose build construira automatiquement toutes les images du fichier Compose qui doivent l’être, en allant chercher les fichiers au bon endroit, et les taggera automatiquement en fonction de la directive image. C’est très pratique et ça évite les erreurs manuelles.
Note:
On utilise la directive build pour dire à Compose comment construire l’image. Cette directive est au niveau d’un service, par exemple :
services: example: image: <image> build: <context>
Le Dockerfile se trouve dans le même dossier que le fichier Compose. On indiquera :
build: .
Ce qui indique à Compose d’utiliser le dossier actuel comme contexte de build, et de chercher le Dockerfile dedans.
On précisera le nom du Dockerfile :
build: context: . dockerfile: <nom du Dockerfile>
On changera le contexte de construction :
build: <dossier où se trouve le Dockerfile>
Note:
Dans certains cas, un dépôt Git existe avec le Dockerfile ainsi que tous les fichiers nécessaires pour construire l’image (code…), mais l’image construite n’est pas disponible sur un dépôt officiel (exemple : delete pads after delay).
Si le Dockerfile nous convient, il serait pénible de le copier sur notre dépôt et de le synchroniser à la main au fil des évolutions. Heureusement, Compose sait construire une image depuis un dépôt distant.
Comme il est préférable de récupérer une version précise, par exemple via un tag Git, on pourra utiliser la syntaxe suivante pour construire l’image depuis le dépôt accessible à l’URL https://repo.git, avec le tag tag.
build: https://repo.git#tag
Lien:
La syntaxe complète pour le contexte Git est disponible sur la documentation officielle.
On préférera utiliser la politique restart: unless-stopped pour les services. Ceci évite qu’un service arrêté explicitement ne se relance tout seul au démarrage de la machine.
Les HEALTHCHECK définis dans les Dockerfile ont souvent un intervalle assez long, ce qui empêche les conteneurs d’être pris en compte rapidement par Traefik (car un conteneur qui n’est pas noté healthy est exclu de la configuration Traefik).
Il est donc intéressant de les définir directement dans le fichier Compose pour plus de souplesse, voire d’écraser le HEALTHCHECK existant.