Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
technique:docker:picasoft:dockerfiles [2020/09/30 16:45] qduchemitechnique: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 {} \;
 +```