| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédenteDernière révisionLes deux révisions suivantes |
| technique:docker:general:tips [2020/10/13 10:17] – qduchemi | technique:docker:general:tips [2020/10/13 18:52] – [Contrôle de la santé d'un conteneur] qduchemi |
|---|
| En outre il existe deux solutions pour récupérer du code existant, versionné sur un dépôt Git distant : | En outre il existe deux solutions pour récupérer du code existant, versionné sur un dépôt Git distant : |
| |
| | * Utiliser un `wget` sur une release particulière (Gitlab, Github), permettant de récupérer une archive contenant le code source d'une version spécifique. |
| * Installer Git dans le `Dockerfile`, utiliser un `git clone` puis un `git checkout <tag>` sur la version souhaitée et copier le code dans l'image. | * Installer Git dans le `Dockerfile`, utiliser un `git clone` puis un `git checkout <tag>` sur la version souhaitée et copier le code dans l'image. |
| * Utiliser un [submodule](https://git-scm.com/book/fr/v2/Utilitaires-Git-Sous-modules) dans le dossier du service, en particulier si le dépôt où se trouve le code est de petite taille et qu'il n'utilise pas les tags. En effet, comme un submodule est lié à un numéro de commit, chaque commit de ce dépôt sera associé à un commit précis du dépôt distant. On peut donc retrouver l'état du code distant avec le numéro de commit du submodule associé au commit local. | |
| |
| <bootnote>En général, on préférera télécharger une release du code que d'utiliser Git.</bootnote> | <bootnote>En général, on préférera télécharger une release du code que d'utiliser Git.</bootnote> |
| ## Exécution de commandes au démarrage | ## Exécution de commandes au démarrage |
| |
| Pour lancer directement le binaire d'un service au démarrage, on utilisera la directive [CMD](https://docs.docker.com/engine/reference/builder/#cmd) avec la forme tableau (`[ "commande", "arg1", "arg2" ]`). | Pour lancer directement le binaire d'un service au démarrage, on utilisera la directive [CMD](https://docs.docker.com/engine/reference/builder/#cmd) avec la forme tableau (`[ "commande", "arg1", "arg2" ]`). En effet, cette forme permet de démarrer le processus directement, tandis que la forme sans tableau est exécutée par `/bin/sh`, ce qui pose des problèmes ([explications ici](https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html)). |
| |
| Lorsque l'on a besoin d'exécuter des instructions préalables (injection de secrets, test du contact avec la base de données, etc...), on utilisera la directive [ENTRYPOINT](https://docs.docker.com/engine/reference/builder/#entrypoint) en conjonction avec `CMD`, toujours sous la forme tableau. | Lorsque l'on a besoin d'exécuter des instructions préalables (injection de secrets, test du contact avec la base de données, etc...), on utilisera la directive [ENTRYPOINT](https://docs.docker.com/engine/reference/builder/#entrypoint) en conjonction avec `CMD`, toujours sous la forme tableau. |
| <bootnote warning>Souvent, les commandes comme `curl` et `wget` ne sont pas installées, il faut y penser.</bootnote> | <bootnote warning>Souvent, les commandes comme `curl` et `wget` ne sont pas installées, il faut y penser.</bootnote> |
| |
| Notez que lorsqu'un `HEALTHCHECK` est présent, Traefik ne prend pas en compte le conteneur tant que celui-ci n'est pas noté `healthy`. Si l'intervalle de vérification est d'une minute, il faudra donc au moins une minute pour que le conteneur soit accessible sur Internet. | <bootnote web>Référence pour les `HEALTHCHECK` : https://docs.docker.com/engine/reference/builder/#healthcheck</bootnote> |
| | |
| Si le service est "critique", il faudra donc choisir un intervalle court. | |
| | |
| Référence : https://docs.docker.com/engine/reference/builder/#healthcheck | |
| |
| ## Ne pas utiliser les directives VOLUME | ## Ne pas utiliser les directives VOLUME |