====== Docker compose ======

Après s'être familiarisé avec [[informatique:devops:docker|Docker]], il faut passer à //docker compose// pour respecter un principe de ses architectures:\\
<blockquote>un conteneur = un service</blockquote>\\
ou presque… en effet on va trouver des conteneur apache/php ou nginx/php par exemple.

===== Développer =====

On va pouvoir mettre en œuvre un groupe de conteneurs pour avoir le serveur web(apache ou nginx) + php, le serveur de base de données (MariaDB, Posgres…), si besoin le phpmyadmin ou équivalent…\\
Il y a souvent quelques différences entre ce qui est défini en développement et en production… donc on va généralement avoir un docker-compose.yml différent pour les deux, même s'il y aura évidemment beaucoup de point commun.

Y a-t-il besoin de Dockerfile? … ça dépend si on a besoin de modifier la/les images(s) de base. Pour créer le conteneur PHP-nginx, on a en général besoin d'un Dockerfile pour ajouter nginx à l'image de base php et ajouter des modules… en revanche les conteneurs de bases de données en ont rarement besoin, le passage de variables d'environnement et de fichiers de configuration suffisent.

Le fichier docker-compose.yml va souvent contenir plusieurs configuration, notamment une pour le développement et une pour construire d'image de production. Celle de dév s'appelle souvent //app//. Pour les variables d'environnement, on aura aussi un //.env// et éventuellement un //.env.local// pour le dév. Cela peut donner, pour lancer l'instanciation du conteneur de dév :
<code bash>docker compose --env-file .env.local up app -d</code>

===== Réseau =====

Si on fait un <code bash>docker network ls</code> on visualise les différents réseaux, notamment **bridge**.\\
Un <code bash>docker inspect <id></code> où //<id>// est à remplacer par l'identifiant d'un réseau du type //nomprojet_default//, permet de voir le détail de ce réseau interne entre les conteneurs


===== En prod =====
Quelques précautions sont nécessaires lorsque nos conteneurs sont utilisés en production…

On évite au maximum d'arrêter des conteneurs de prod… donc si on a besoin de faire une modification, on modifie le fichier **docker-compose.yml** (attention les tabulations) puis on fait un 
<code bash>
docker compose up -d
</code>
Il lit alors le fichier et met à jour les conteneurs. Exemple d'utilisation, ajouter un volume (dans ce cas, attention aux droits, pour un var/log, il faut bien le mettre en root et pas en www−data !)

Quand on ajoute un nouveau service, on peut commencer par n'exécuter que ce service avec :
<code bash>
docker compose up monService
</code>
qu'on peut quitter avec //Ctrl+Z// en laissant en tâche de fond (cf. [[https://gitlab.huma-num.fr/bdavid/admin-serveur/-/issues/6]])

==== Restart ====
Surprise, votre serveur web est arrêté… suite au redémarrage du host après des mises à jour par exemple.\\
Il faut bien que chaque conteneur (service) comporte la ligne:
<code bash>
restart: always
</code>

===== Registres =====
Il est souvent pratique de sauvegarder nos images dans un "registre" (registry), notamment gitlab… s'il est instancié. Ainsi l'instance gitlab.huma-num.fr n'en dispose pas alors que gitlab.in2p3.fr en dispose.\\
Il faut créer un projet dans le gitlab et définir un token avec lecture/écriture pour pouvoir pousser et tirer les images. Pour ce token, on va dans le menu **Settings** puis **Access Token**. On crée un token en saisissant un nom, puis en cochant **read_registry** et **write_registry** et validant le bouton **Create project access token**, bien récupérer le token (à mémoriser dans un séquestre !), allez ensuite dans le menu **members** et mémoriser le nom associé qui se trouve sous le nom donnée au token, après le caractère **@**\\
Voir aussi : [[:informatique:devops:registry-gitlab]]

Ensuite pour "pousser" l'image dans le registre, il faut sur le serveur ou la machine de développement, tout d'abord se connecter avec notre token :
<code bash>docker login <adresse-du-serveur>/<nom-utilisateur>/<nom-du-projet>/<nom-du-registre></code> qui va demander le nom et le mot de passe du token, mémoriser précédemment dans notre séquestre,\\
puis, on "pousse" avec
<code bash>docker push <adresse-du-serveur>/<nom-utilisateur>/<nom-du-projet>/<nom-du-registre>:<tag></code>

puis, sur le serveur, il faut récupérer l'image à jour avec :
<code bash>docker pull <adresse-du-serveur>/<nom-utilisateur>/<nom-du-projet>/<nom-du-registre>:<tag></code>
puis mettre à jour l'instance en production :
<code bash>docker compose up -d</code> qui ne met à jour (//Recreating//) que la ou les instance(s) dont l'image a évoluée.

===== Logs =====
Il est souvent utile de visualiser les logs d'un conteneur.\\
On peut simplement faire :
<code bash>
docker logs nom-du-conteneur
</code>

et si on veut comme pour un tail -f /var/log…
<code bash>
docker logs -f --tail 10 nom-du-conteneur
</code>
ou 10 est à priori le nombre de lignes