Administrer les services

Tous les services lancés avec Docker ont leur configuration versionnée dans leur dépôt, accessible ici (voir gestion des services).

En particulier, les fichiers docker-compose.yml présents dans chaque dépôt, ainsi que les fichiers de configuration et de secrets, permettent de lancer n’importe quel service de façon autonome, sur n’importe quelle machine.

Note:

Pour chacune des opérations détaillées dans cette page, on suppose que :

  • Vous savez sur quelle machine tourne ou doit tourner le service (pica01, monitoring…). Si vous ne le savez pas, les graphes des services peuvent vous aider.
  • Vous avez une connexion SSH active sur cette machine
  • Vous êtes dans le dossier /DATA/docker/services/<depot-service>, sur la branche master.
  • Vous êtes sur la branche master et à jour si besoin (git pull)

La branche master devant refléter l’état des services en production, toutes les opérations sur les machines de production devront être réalisées depuis master : cela signifie que les branches sur lesquelles vous travaillez devront être fusionnées à la fin de vos tests, et donc avant la mise en production.

Par exemple : je veux faire quelque chose avec Mattermost. Mattermost tourne sur pica02 (cf graphes des services), je suis dans le dossier /DATA/docker/services/mattermost, j’ai vérifié que je suis sur master et j’ai fait un git pull, je suis prêt à effectuer une opération.

Important:

Cette page présente le cas général, mais avant toute opération de mise à jour, il faut absolument lire le fichier README.md du sous-dossier du service. Certains nécessitent des précautions avant de lancer une nouvelle version de l’image.

A Savoir:

La documentation de l’outil en ligne de commande de Docker Compose est accessible ici : https://docs.docker.com/compose/reference/overview/

Important:

Un conteneur noté Unhealthy à cause d’un mauvais HEALTHCHECK sera exclu de Traefik, même s’il fonctionne bien. Ceci se traduira par une erreur 404. Comme les HEALTHCHECK s’exécutent pas défaut toutes les minutes, il ne faut pas “s’inquiéter” si un service n’est pas accessible tout de suite. On peut vérifier la santé des conteneurs avec un docker ps.

Attention:

Si le dossier du service n’existe pas… Alors, vous êtes probablement sur la mauvaise machine. Si vous lancez un nouveau service, voir plus bas.

Note:

Le nom des services à utiliser dans les commandes Compose sont les clés du fichier docker-compose.yml, et non le nom des conteneurs. La commande

docker-compose config --services

permet de voir les services définis dans le fichier.

snippet.bash
docker-compose ps

affiche tous les conteneurs lancés par le fichier Compose courant.

snippet.bash
docker-compose top

affiche tous les processus à l’intérieur des conteneurs lancés par le fichier Compose courant.

docker-compose exec <service> <commande>

Très utile pour ouvrir un shell dans un conteneur, avec bash ou sh pour commande.

Par exemple, à la recherche d’une erreur.

snippet.bash
docker-compose logs -f [--tail <n>]

Note:

n est le nombre de lignes à afficher et est optionnel. -f permet de suivre les logs en direct.

Par exemple, s’il a planté.

snippet.bash
docker-compose restart [service]

Note:

Le nom du service est optionnel : si on veut tout redémarrer, on ne le met pas. Sinon, on indique le nom du service présent dans le fichier docker-compose.yml.

Par exemple, suite à une mise à jour de l’image ou de la configuration.

Note:

La recréation est différente du redémarrage : elle écrase toutes les modifications faites à l’intérieur du conteneur qui ne sont pas persistées dans des volumes, et est nécessaire pour prendre en compte un changement de variable d’environnement, de réseau, d’image…

snippet.bash
docker-compose up -d [service]

Note:

Le docker-compose pull est essentiel : il permet de récupérer les nouvelles versions des images et de s’assurer qu’on a bien la dernière version indiquée dans le Compose.

snippet.bash
docker-compose stop [service]
snippet.bash
docker-compose down

Lorsque vous lancez un nouveau service, il y a parfois quelques opérations à faire avant de lancer les conteneurs. En effet, bien qu’en théorie un docker-compose up -d suffise, il y a quelques cas particuliers.

Les secrets, tels que les mots de passe, ne sont évidemment pas présents sur le dépôt. Lorsque des secrets sont utilisés, ils sont systématiquement indiqués par la présence de fichiers dans un sous-répertoire secrets.

Dans ce cas, on copiera tous les fichiers *.secrets.example en *.secrets, et on remplacera les valeurs.

Cette opération n’est nécessaire que lors du premier lancement. Il y a plusieurs situations.

Mot de passe technique

Le mot de passe est “inédit”, et ne concerne pas les utilisateurs (comme le mot de passe d’un utilisateur de base de données). On pourra générer un mot de passe avec la commande suivante :

snippet.bash
< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-32};echo;

Mot de passe externe

Le mot de passe est connu, par exemple le mot de passe d’un compte LDAP. On le récupérera sur le vaultwarden.

Mot de passe administratif

Le mot de passe est “inédit”, mais doit être accessibles aux administrateurs (par exemple le mot de passe d’administration d’Etherpad). On le créera directement dans le vaultwarden (picapass insert...) et on le copiera dans le fichier de secrets.

Si des volumes sont déclarés external dans le fichier Compose (ce qui n’est pas recommandé), il faut les créer manuellement au préalable :

snippet.bash
docker volume create <volume>

Certains services (comme le serveur mail) nécessitent des opérations manuelles : créer des dossiers, puis générer des clés ou des certificats… Se référer au README.md du service.

  • technique/docker/picasoft/admin.txt
  • de 127.0.0.1