Différences

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

--- docker_compose [2025/08/02 16:00] – luc
+++ docker_compose [2025/09/09 09:15] (Version actuelle) – luc
@@ Ligne 9: / Ligne 9: @@
 ===== Fichier de configuration =====
+[[https://docs.docker.com/reference/compose-file/|doc officielle]]
 Contient les règles pour décrire le service que l'on souhaite. Il peut être composé de plusieurs containers, de volumes et de networks.
-Traditionnellement, le nom du fichier est (par ordre de préférence) : ''compose.yaml'', ''compose.yml'', docker-compose.yaml'' ou ''docker-compose.yml''. L'emploi d'un de ces noms permet d'omettre le Compose file à utiliser lorsqu'on écrit des CLI comme ''docker compose up''.
+Traditionnellement, le nom du fichier est (par ordre de préférence) : ''compose.yaml'', ''compose.yml'', ''docker-compose.yaml'' ou ''docker-compose.yml''. L'emploi d'un de ces noms permet d'omettre le Compose file à utiliser lorsqu'on écrit des CLI comme ''docker compose up''.
+Il est conseillé d'avoir un dossier avec un Compose file pour chaque application (ensemble de services visant une fonctionnalité, par exemple un serveur web intranet, une station météo auront chacun leur dossier contenant leur Compose file).
+On trouve plusieurs infos sur la structure d'un Compose file. La spécification a évoluée, et certains directives (comme top-level version) sont obsolètes. Je ne vais lister ici que ce qui est à jour à la date de création de cet article (2/08/2025).
-===== Docker compose CLI =====
+=== Elements de config ===
-=== Les versions ===
+(/!\ orthographe et casse)
-La première version était un executable à part, ''docker-compose''.
-Depuis, les fonctionnalités ont été intégrées à l'executable docker (écrit en Go ?), on a donc ''docker compose''.\\
+Top-level :
-Etant donné que c'est la version référencée dans les [[https://docs.docker.com/reference/compose-file/|docs officielles de docker]], nous utiliserons celle-ci pour la suite).
-Il est conseillé d'avoir un dossier avec un Compose file pour chaque application (ensemble de services visant une fonctionnalité, par exemple un serveur web intranet, une station météo auront chacun leur dossier contenant leur Compose file).
+  * ''name'' : définit le project name. Servira de préfixe à tout le reste (nom des containers -avec suffixe "-1"-, des networks, des volumes...). Si name n'est pas définit, docker prendra le nom du dossier qui contient le Compose file. Limite : si ''container_name'' est défini, il n'y a pas de préfixe
-On trouve plusieurs infos sur la structure d'un Compose file. La spécification a évoluée, et certains directives (comme top-level version) sont obsolètes. Je ne vais lister ici que ce qui est à jour à la date de création de cet article (2/08/2025).
+  * ''services'' : (OBLIGATOIRE) A service is an abstract definition of a computing resource within an application which can be scaled or replaced independently from other components. Services are backed by containers.
+    * Contient donc des containers, qui sont définis par des arguments:
+      * Peut contenir une section ''build'' pour construire une image docker.
+      * ''image'' : spécifie l'image utilisée pour construire le container. [[https://github.com/opencontainers/.github/blob/main/docs/docs/introduction/digests.md|Format de l'adresse de l'image]] : ''[<registry>/][<project>/]<image>[:<tag>|@<digest>]''
+      * ''container-name'' : définit le nom du container, pour éviter un nom aléatoire (pose de pb en cas de scaling -??-)
+      * ''links'' : définit les liens / networks pour être réliés à d'autres containers (?? version simplifiée des networks ??)
+      * ''ports'' : définit le mapping des ports entre l'hôte et les containers. Syntaxe (avec des ''" "''): ''"[HOST:]CONTAINER[/PROTOCOL]"'', avec
+        * HOST is [IP:](port | range) (optional). If it is not set, it binds to all network interfaces (0.0.0.0).
+        *  CONTAINER is port | range.
+        * PROTOCOL restricts ports to a specified protocol either tcp or udp(optional). Default is tcp.
+      * ''restart'' : définit la politique de (re)démarrage automatique : "no", always, unless-stopped, on-failure[:max-retries]
+      * ''secrets'' : pour définir des accès à des secrets comme des certificats, nécessite aussi une définition de secrets en top-level (comme volumes et networks)
+  * ''volumes'' : permet la configuration de named volumes pour l'application
+    * Pour utiliser un volume dans plusieurs services, il faut que chacun l'exprime explicitement dans l'attribut ''volume'' de ce service
+    * L'attribut ''external'' (true/false) indique que le volume existe déjà et est géré à l'extérieur du Compose file
+  * ''networks'' : permet aux services de communiquer entre eux.
+    * Par défaut, il y a 1 seul réseau pour toute l'application, nommé ''default''
+    * Il faut détailler la config du réseau sous la directive top-level ''networks''
+    * à minima il faut donner un nom au réseau
+    * Si un service est connectée à un réseau, il faut l'indiquer dans la définition du service par l'attribut ''networks''
-top-level instructions (/!\\ orthographe et casse) :
+=== Exemple ===
-  * ''name'' : définit le project name
-  * ''services'' :
 <code yaml>
 name: nom_de_mon_application
+services:
+    nom_container_1:
+        image: example/webapp
+        networks:
+            - network_name_1
+        secrets:
+            - secret_name_1
+    nom_container_2:
+        image: example/backapp
+        volumes:
+            - volume_name_1:/mount/path/inside/container
+        ports:
+              - "3000"
+              - "3000-3005"
+              - "8000:8000"
+              - "9090-9091:8080-8081"
+              - "127.0.0.1:8001:8001"
+              - "6060:6060/udp"
+    nom_container_3:
+        image: example/mon-image
+        links:
+            - nom_container_1
+        restart: always
+networks:
+    network_name_1:
+volumes:
+    volume_name_1:
+        external: true
+secrets:
+    secret_name_1:
+        file: /path/to/file
 </code>
+===== Docker compose CLI =====
+=== Les versions ===
+La première version était un executable à part, ''docker-compose''.
+Depuis, les fonctionnalités ont été intégrées à l'executable docker (écrit en Go ?), on a donc ''docker compose''.\\
+Etant donné que c'est la version référencée dans les [[https://docs.docker.com/reference/compose-file/|docs officielles de docker]], nous utiliserons celle-ci pour la suite).
 === CLI ===
@@ Ligne 45: / Ligne 110: @@
 # Executer les recettes du fichier dpcker-compose.yml du dossier actuel
 # Créer et démarrer les containers
-docker compose up
+docker compose up --detach
+# --detach pour lancer en arrière plan
 # Stop and remove containers, networks
@@ Ligne 65: / Ligne 131: @@
 De nombreuses commande de ''docker'' sont aussi présentes pour ''docker compose'', elles s'appliquent aux image/container/volume/network listés dans le Compose file (si j'ai bien compris). On listera : ''ls'', ''logs'', ''rm'', ''volumes'' etc.
+===== Définir des variables d'environnement =====
+Parfois, certaines valeurs du docker compose file sont reprises à plusieurs endroits, et il fait sens de regrouper ces valeurs dans un fichier ''.venv''. Ainsi, la modification est centralisée. Il s'agit souvent de variables d'environnement qu'on souhaite passer au container (pas seulement au docker compose).
+=== Fichier .venv ===
+Le fichier ''.venv'' est placé dans le même dossier que le fichier de configuration ''compose.yml''.\
+Le contenu du fichier est une liste de paramètres, format ini ou properties :
+<code properties>
+# Des lignes commentaires précédées d'un "#"
+#
+TAG=15-slim
+OPENPROJECT_HTTPS=false
+OPENPROJECT_HOST__NAME=localhost
+PORT=127.0.0.1:8080
+PGDATA="/var/lib/postgresql/data"
+</code>
+L'utilisation dans le ''compose.yml'' se fait via des variables ''${PORT}'' dont le nom doit correspondre à celui dans le fichier ''.venv'' :
+<code properties>
+web:
+  environment:
+    - DEBUG=${DEBUG}
+</code>
+Note: Dans la version docker CLI, on passe les variables avec l'argument ''-e DEBUG=1''
+=== Interpolation ===
+L'interpolation permet de définir des variables et des comportements (par défaut, alternative, etc.) [https://docs.docker.com/compose/how-tos/environment-variables/variable-interpolation/#interpolation-syntax|source]:
+  * Direct substitution
+    * ''${VAR}'' -> value of VAR
+  * Default value
+    * ''${VAR:-default}'' -> value of VAR if set and non-empty, otherwise default
+    * ''${VAR-default}'' -> value of VAR if set, otherwise default
+  * Required value
+    * ''${VAR:?error}'' -> value of VAR if set and non-empty, otherwise exit with error
+    * ''${VAR?error}'' -> value of VAR if set, otherwise exit with error
+  * Alternative value
+    * ''${VAR:+replacement}'' -> replacement if VAR is set and non-empty, otherwise empty
+    * ''${VAR+replacement}'' -> replacement if VAR is set, otherwise empty