Différences

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

--- technique:docker:picasoft:dockerfiles [2020/09/30 16:45] – qduchemi
+++ technique:docker:picasoft:dockerfiles [2022/05/24 19:56] (Version actuelle) – ppom
@@ Ligne 1: / Ligne 1: @@
+{{indexmenu_n>10}}
+# Comprendre la gestion des services
+<bootnote warning>
+Prérequis : les articles de [[technique:docker:general:start|cette section]].
+</bootnote>
+## Préambule
+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).
+<bootnote>Pour gérer les conteneurs Docker, nous utilisons [[technique:tech_team:pres_docker|Docker Compose]].
+Les fichiers permettant de construire les images, de créer les conteneurs et de configurer les services sont sauvegardés dans leurs dépôts Git. Chaque dépôt se suffit à lui-même pour lancer le service Picasoft en question. Ils sont accessibles ici : https://gitlab.utc.fr/picasoft/projets .</bootnote>
+<bootnote>Traditionnellement, ils sont clonés dans le répertoire `/DATA/docker/services` sur les machines virtuelles.</bootnote>
+## Objectifs
+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.
+<bootnote question>Comment savoir ce qu'il y a dans une image, si on perd le Dockerfile ? Quel Dockerfile correspond à quelle version de l'image ? Si on perd l'accès à la machine, comment récupérer la configuration, remonter rapidement le service ? Comment versionner les changements de configuration ? Revenir à la version d'il y a deux semaines ?</bootnote>
+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.
+## Contenu des dépôts
+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).
+<bootnote>Chaque service a son propre fichier Compose, lui permettant d'être déployé indépendamment des autres.</bootnote>
+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.
+## Utiliser les dépôts sur les machines
+<bootnote warning>Cette section ne concerne que les services qui ne sont pas encore présents sur la machine virtuelle où l'on veut le déployer.</bootnote>
+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](https://git-scm.com/docs/git-init#Documentation/git-init.txt---sharedfalsetrueumaskgroupallworldeverybody0xxx) 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](https://git-scm.com/docs/git-init#Documentation/git-init.txt---sharedfalsetrueumaskgroupallworldeverybody0xxx).
+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 :
+```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 :
+```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 {} \;
+```