Différences

Ci-dessous, les différences entre deux révisions de la page.

--- technique:docker:good_practices:misc [2020/10/13 12:10] – qduchemi
+++ technique:docker:good_practices:misc [2020/10/13 16:19] (Version actuelle) – [Healthcheck] qduchemi
@@ Ligne 4: / Ligne 4: @@
 ## Version du fichier Compose
-On utilisera une version récente dans les fichiers `docker-compose.yml`, et au minimum la 3.7 pour profiter des fonctionnalités présentes dans ce guide.
+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.
 ```yaml
@@ Ligne 14: / Ligne 14: @@
 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.
-<bootnote question>Quel intérêt par rapport à un `docker build` manuel ?\\
+<bootnote question>Quel intérêt par rapport à un `docker build` manuel ?</bootnote>
 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.
+<bootnote>On utilise la directive `build` pour dire à Compose comment construire l'image. Cette directive est au niveau d'un service, par exemple :
+```yaml
+services:
+  example:
+    image: <image>
+    build: <context>
+```
 </bootnote>
+### Cas général
+Le `Dockerfile` se trouve dans le même dossier que le fichier Compose. On indiquera :
+```yaml
+build: .
+```
+Ce qui indique à Compose d'utiliser le dossier actuel comme **contexte** de build, et de chercher le `Dockerfile` dedans.
+### Dockerfile avec nom alternatif
+On précisera le nom du Dockerfile :
+```yaml
+build:
+  context: .
+  dockerfile: <nom du Dockerfile>
+```
+### Dockerfile dans un dossier différent
+On changera le contexte de construction :
+```yaml
+build: <dossier où se trouve le Dockerfile>
+```
+### Depuis un dépôt Git distant
+<bootnote>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](https://gitlab.utc.fr/picasoft/projets/delete-pad-after-delay)).</bootnote>
+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`.
+```yaml
+build: https://repo.git#tag
+```
+<bootnote web>La syntaxe complète pour le contexte Git est disponible [sur la documentation officielle](https://docs.docker.com/engine/reference/commandline/build/#git-repositories).</bootnote>
 ## Politique de redémarrage
 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.
+## Écrasement du HEALTHCHECK
+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](https://docs.docker.com/compose/compose-file/#healthcheck) pour plus de souplesse, voire d'écraser le `HEALTHCHECK` existant.