technique:docker:picasoft:dockerfiles

Différences

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

Lien vers cette vue comparative

Prochaine révision		 Révision précédente
technique:docker:picasoft:dockerfiles [2020/09/30 16:45] – créée qduchemitechnique:docker:picasoft:dockerfiles [2022/05/24 19:56] (Version actuelle) – ppom
Ligne 1: Ligne 1:
-# Comprendre la gestion des services de Picasoft+{{indexmenu_n>10}} 
 + 
 +# Comprendre la gestion des services 
 + 
 +<bootnote warning> 
 +Prérequis : les articles de [[technique:docker:general:start|cette section]]. 
 +</bootnote>
  
 ## Préambule ## Préambule
  
-Par service, on entend la plupart des applications tournant sur les serveurs de Picasoft, qu'ils soient publics ou "privés", comme le serveur LDAP ou le serveur mail.+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. 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). 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).
  
-Pour gérer les conteneurs Docker, nous utilisons [Docker Compose](https://docs.docker.com/compose/). +<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 centralisés sur un dépôt Git, appelé `dockerfiles`. C'est la seule ressource nécessaire pour lancer n'importe quel service Picasoft, et est accessible ici : https://gitlab.utc.fr/picasoft/projets/dockerfiles.+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>
  
-Traditionnellement, il est cloné dans le répertoire `/DATA/docker/dockerfiles` sur les machines virtuelles.+<bootnote>Traditionnellement, ils sont clonés dans le répertoire `/DATA/docker/services` sur les machines virtuelles.</bootnote>
  
-## Philosophie+## Objectifs
  
 Historiquement, Picasoft procède de la manière suivante : 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, * 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é, * 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. * Gérer un fichier Compose global par machine virtuelle, qui contient la configuration et les secrets.
  
-Cette approche pose plusieurs problèmes. 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 ?+Cette approche pose plusieurs problèmes. 
  
-L'objectif de ce dépôt est de rendre possible le déploiement de n'importe quel service Picasoft avec la procédure suivante : +<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> 
-* Cloner le dépôt + 
-* Se rendre dans le répertoire du service+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 * 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 à : 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 * Cloner le dépôt
-* Checkout le commit correspondant+* *Checkout* le commit correspondant
 * Lancer le service normalement * 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). Son dernier objectif est de permettre de rendre publics nos fichiers Compose et la configuration, sans exposer les secrets (mots de passe, etc).
  
-Mises à 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.+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 du dépôt+## Contenu des dépôts
  
-Le dépôt est organisé en dossiers. Chaque dossier 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).+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 dossier du dépôt contient, selon les situations :+<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, * Zéro, un ou plusieurs `Dockerfile` permettant de construire des images personnalisées pour Picasoft,
Ligne 47: Ligne 60:
 * Un fichier d'exemple de secrets (mots de passe...) nécessaires au lancement du service, * 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, * 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 version.+* Pour les images maison, un `CHANGELOG.md` résumant les modifications faites au fil des versions.
  
-Chaque service a son propre fichier Compose, lui permettant d'être déployé indépendamment des autres.+## Utiliser les dépôts sur les machines
  
-## Utiliser le dépôt 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 vous clonez le dépôt sur une nouvelle machine virtuelle, il est important de faire quelques opérations.+Si la machine virtuelle est toute nouvelle, on créé le dossier où l'on clonera les services : 
 +``` 
 +mkdir /DATA/docker/services 
 +```
  
-À moins qu'on ouvre une nouvelle machine, ça ne devrait pas arriver - le dépôt existe déjà dans `/DATA/docker/dockerfiles` sur toutes les machines actuelles.+On clone le dépôt : 
 + 
 +``` 
 +cd /DATA/docker/services 
 +git clone https://gitlab.utc.fr/picasoft/projets/services/<NOM-DU-DEPOT> 
 +```
  
-En effet, le dépôt sera partagé et les fichiers doivent être éditables par tous les membres de Picasoft.+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`). 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`).
Ligne 63: Ligne 84:
 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. 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/dockerfiles/.git/config`, et ajouter, sous `[core]` :+Éditer `/DATA/docker/services/<NOM-DU-DEPOT>/.git/config`, et ajouter, sous `[core]` :
  
 ``` ```
Ligne 74: Ligne 95:
  
 ```bash ```bash
-sudo setfacl -Rdm g:docker:rwx /DATA/docker/dockerfiles+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. 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, par :+On terminera, pour être sûr·e, par :
  
 ```bash ```bash
-sudo chgrp -R docker /DATA/docker/dockerfiles +sudo chgrp -R docker /DATA/docker/services 
-sudo chmod -R g+w /DATA/docker/dockerfiles +sudo chmod -R g+w /DATA/docker/services 
-sudo chmod g-w /DATA/docker/dockerfiles/.git/objects/pack/* +sudo chmod g-w /DATA/docker/services/<NOM-DU-DEPOT>/.git/objects/pack/* 
-find /DATA/docker/dockerfiles -type d -exec sudo chmod g+s {} \;+find /DATA/docker/services -type d -exec sudo chmod g+s {} \;
 ``` ```
  • technique/docker/picasoft/dockerfiles.1601477127.txt.gz
  • de qduchemi