technique:docker:good_practices:misc

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision		 Révision précédente
technique:docker:good_practices:misc [2020/10/13 12:20] – qduchemitechnique:docker:good_practices:misc [2020/10/13 16:19] (Version actuelle) – [Healthcheck] qduchemi
Ligne 1: Ligne 1:
 +{{indexmenu_n>1}}
 +# Recommandations générales
  
 +## 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ésentées dans toute la section.
 +
 +```yaml
 +version: '3.7'
 +```
 +
 +## Indications pour construire l'image
 +
 +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>
 +
 +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.