{{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.