Comprendre la gestion des services

Par service, on entend la plupart des applications tournant sur les serveurs de Picasoft, qu’ils soient publics, comme Mattermost, ou “privés”, comme le serveur LDAP ou le serveur mail. Ces services sont majoritairement gérés par Docker. Une rule of thumb est ce tout ce qui touche à l’administration système d’une machine, avec une configuration très spécifique (pare-feu, serveur SSH…) sera installé directement sur la machine, sans Docker.

Pour le reste, qui pourrait être lancé sur une machine virtuelle quelconque, on privilégiera Docker (qui a justement l’avantage de construire des images qui peuvent être lancées de n’importe où, sans configuration spécifique adaptée au système d’exploitation).

Historiquement, Picasoft procède de la manière suivante :

• Rédiger les Dockerfiles et la configuration sur sa machine personnelle, ou sur une machine virtuelle,
• Construire les images Docker à partir de ces fichiers sur une machine quelconque, puis les tagger et pousser manuellement sur un registre privé,
• Gérer un fichier Compose global par machine virtuelle, qui contient la configuration et les secrets.

Cette approche pose plusieurs problèmes.

L’objectif de ces dépôts est de rendre possible le déploiement de n’importe quel service Picasoft avec la procédure suivante :

• Cloner le bon dépôt
• Se rendre dedans
• Lancer un docker-compose up -d pour démarrer le service

Son objectif secondaire est de pouvoir revenir à l’état antérieur d’un service. En versionnant toute la configuration nécessaire, revenir à une ancienne version du service revient à :

• Cloner le dépôt
• Checkout le commit correspondant
• Lancer le service normalement

Son dernier objectif est de permettre de rendre publics nos fichiers Compose et la configuration, sans exposer les secrets (mots de passe, etc).

Mis à part les données à proprement parler du service, il n’y a donc aucune différence entre un service lancé sur une de nos machines et un service lancé à partir de ce dépôt sur une machine quelconque, ce qui s’inscrit dans la philosophie Docker.

Chaque dépôt correspond à un service Picasoft au sens large, c’est-à-dire à un ensemble de conteneurs liés entre eux techniquement (e.g. Mattermost et sa base de données) et/ou sémantiquement (e.g. sites web statiques, relai et boîte à mail).

Ainsi, chaque dépôt contient, selon les situations :

• Zéro, un ou plusieurs Dockerfile permettant de construire des images personnalisées pour Picasoft,
• Un fichier docker-compose.yml permettant de lancer le service,
• Si possible, un ou des fichiers de configuration permettant de personnaliser le service selon nos besoins,
• Un fichier d’exemple de secrets (mots de passe…) nécessaires au lancement du service,
• Un README.md résumant les paramètres modifiables sur le dépôt, les mécanismes pour en rajouter, etc,
• Pour les images maison, un CHANGELOG.md résumant les modifications faites au fil des versions.

Si la machine virtuelle est toute nouvelle, on créé le dossier où l’on clonera les services :

mkdir /DATA/docker/services

On clone le dépôt :

cd /DATA/docker/services
git clone https://gitlab.utc.fr/picasoft/projets/services/<NOM-DU-DEPOT>

Le dépôt sera partagé et les fichiers doivent être éditables par tous les membres de Picasoft.

Or, avec Git, tout git pull va associer les nouveaux fichiers écrits au compte qui effectue la commande, avec des permissions d’écriture uniquement pour ce membre (pour plus de détails, se référer à la documentation Git et comprendre la notion de umask).

Une solution pour rendre le dépôt “partagé” (i.e. éditable par tous les membres du groupe docker), quelles que soient les permissions initiales, est la suivante.

Éditer /DATA/docker/services/<NOM-DU-DEPOT>/.git/config, et ajouter, sous [core] :

sharedrepository = group

Ainsi, le dépôt sera “partagé”, c’est-à-dire que les fichiers créés seront en théorie partagé avec le groupe propriétaire du dépôt, qui devrait être docker. Voir la documentation.

Pour être certain que les fichiers créés manuellement sur la machine par les utilisateurs soient accessibles par le groupe docker, on entrera la commande suivante :

snippet.bash

sudo setfacl -Rdm g:docker:rwx /DATA/docker/services/

Ainsi, les fichiers créés auront le groupe docker par défaut ainsi que les permissions d’écriture pour le groupe.

On terminera, pour être sûr·e, par :

snippet.bash

sudo chgrp -R docker /DATA/docker/services
sudo chmod -R g+w /DATA/docker/services
sudo chmod g-w /DATA/docker/services/<NOM-DU-DEPOT>/.git/objects/pack/*
find /DATA/docker/services -type d -exec sudo chmod g+s {} \;