| 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:19] – [Indications pour construire l'image] qduchemi | technique:docker:good_practices:misc [2020/10/13 16:19] (Version actuelle) – [Healthcheck] qduchemi |
|---|
| ## Version du fichier Compose | ## 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 | ```yaml |
| 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. | 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. | 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> | |
| |
| <bootnote>On utilise la directive `build` pour dire à Compose comment construire l'image. Cette directive est au niveau d'un service, par exemple : | <bootnote>On utilise la directive `build` pour dire à Compose comment construire l'image. Cette directive est au niveau d'un service, par exemple : |
| services: | services: |
| example: | example: |
| image: | image: <image> |
| build: | build: <context> |
| ``` | ``` |
| </bootnote> | </bootnote> |
| <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> | <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 maintenir à la main. Heureusement, Compose sait construire une image depuis un dépôt distant. | 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 : | 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 | ```yaml |
| |
| 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. | 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. |