Différences

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

--- technique:docker:picasoft:new [2021/09/02 22:45] – qduchemi
+++ technique:docker:picasoft:new [2022/09/24 10:39] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. rdelaage
@@ Ligne 1: / Ligne 1: @@
 {{indexmenu_n>50}}
 # Créer un nouveau service
+<bootnote warning>
+Prérequis : les articles de [[technique:docker:general:start|cette section]].
+</bootnote>
 ## Préambule
-Cette page donne quelques pistes pour lancer un nouveau service, versionné sur le dépôt `dockerfiles` (voir [[technique:docker:picasoft:dockerfiles|gestion des services]]).
+Cette page donne quelques pistes pour lancer un nouveau service, versionné sur un nouveau dépôt à créer dans `services` (voir [[technique:docker:picasoft:dockerfiles|gestion des services]]).
-L'idée de ce dépôt est de rendre nos services **indépendants** des machines virtuelles sur lesquels ils sont lancés, c'est-à-dire qu'à partir de ce dépôt, on devrait pouvoir remonter sans aucun problème un service sur une machine quelconque (sauf les données, bien sûr).
+L'idée de chaque dépôt est de rendre son service **indépendant** des machines virtuelles sur lesquelles il est lancé, c'est-à-dire qu'à partir de ce dépôt, on devrait pouvoir remonter sans aucun problème un service sur une machine quelconque (sauf les données, bien sûr).
 Le dossier [template](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/tree/master/template) est une bonne base pour commencer un nouveau service.
-<bootnote warning>Si on utilise pas d'image maison, il n'est pas nécessaire d'utiliser un `Dockerfile`.</bootnote>
+<bootnote warning>Si on n'utilise pas d'image maison, il n'est pas nécessaire d'utiliser un `Dockerfile`.</bootnote>
 <bootnote tip>Pour le contenu des fichiers `Dockerfile` et `docker-compose.yml`, on se référera au [[technique:docker:general:tips|guide des bonnes pratiques pour les Dockerfile]] et au [[technique:docker:good_practices:start|guide des bonnes pratiques pour Compose]] en cas de doute.</bootnote>
@@ Ligne 16: / Ligne 20: @@
 Pour savoir si vous avez versionné tout les fichiers nécessaires et automatisé le démarrage du service, posez-vous la question suivante :
-<bootnote question>Si je fais un `git pull` sur n'importe quelle machine puis un `docker-compose up -d`, est-ce-que mon service démarre correctement ?</bootnote>
+<bootnote question>Si je fais un `git clone` sur n'importe quelle machine, `cd` puis un `docker-compose up -d`, est-ce-que mon service démarre correctement ?</bootnote>
 Si non, voici quelques pistes.
@@ Ligne 46: / Ligne 50: @@
 Il y a deux solutions :
    * Soit on part de l'image officielle, avec un `FROM`, et on travaille dessus en rajoutant des fichiers, en enlevant des paquets... Cette solution a l'inconvénient de multiplier les *layers* inutiles, et d'augmenter la taille de l'image.
-   * Soit on copie le `Dockerfile` de l'image officielle (c'est le cas pour [Mattermost](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/blob/master/pica-mattermost/Dockerfile)), et on fait nos modifications. Cette solution a pour inconvénient de devoir se synchroniser avec les modifications du `Dockerfile` officiel à chaque mise à jour, s'il contient des améliorations ou corrections importantes.
+   * Soit on copie le `Dockerfile` de l'image officielle (c'est le cas pour [Mattermost](https://gitlab.utc.fr/picasoft/projets/services/mattermost/-/blob/master/Dockerfile)), et on fait nos modifications. Cette solution a pour inconvénient de devoir se synchroniser avec les modifications du `Dockerfile` officiel à chaque mise à jour, s'il contient des améliorations ou corrections importantes.
 </bootnote>
 Le `Dockerfile` peut contenir des directives `COPY` pour ajouter des fichiers à l'image. S'il s'agit d'un ou deux fichiers de configuration, ou d'un peu de code pour personnaliser une page d'accueil, aucun souci pour les versionner directement sur le dépôt.
-<bootnote important>Si vous avez besoin de copier le code d'un service entier, il est préférable de créer un dépôt spécifique qui contiendra le code du service, et de faire un `git pull` dans le `Dockerfile`, ou de récupérer une release avec un `wget`. En effet, le dépôt `dockerfiles` ne contient en théorie que de la configuration pour Docker, pas le code des services.</bootnote>
+<bootnote important>Si vous avez besoin de copier le code d'un service entier, il est préférable de créer un dépôt spécifique qui contiendra le code du service, et de faire un `git pull` dans le `Dockerfile`, ou de récupérer une release avec un `wget`. En effet, le dépôt d'un service ne contient en théorie que de la configuration pour Docker, pas le code du service.</bootnote>
 ### Fichiers de configuration
@@ Ligne 76: / Ligne 80: @@
 <bootnote>Il ne faut pas hésiter à créer une image personnalisée basée sur l'image officielle "juste" pour ajouter un `entrypoint` personnalisé ! Ça ne coûte pas grand chose, ça fait gagner du temps, et ça évite les erreurs (exemple : une instruction d'initialisation de base de donnée sur une instance qui tourne déjà).</bootnote>
-<bootnote tip>On pourra marquer le fait qu'un service a déjà été initialisé en créant un fichier "marqueur" dans un volume. Voir [Plume](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/tree/master/pica-plume) pour un exemple. D'autres techniques sont possibles :)</bootnote>
+<bootnote tip>On pourra marquer le fait qu'un service a déjà été initialisé en créant un fichier "marqueur" dans un volume. Voir [Plume](https://gitlab.utc.fr/picasoft/projets/services/plume) pour un exemple. D'autres techniques sont possibles :)</bootnote>
 ### Modification du fichier de configuration au démarrage
@@ Ligne 86: / Ligne 90: @@
 * Mais qu'on a besoin de modifier la configuration lors de l'initialisation,
-Alors on créera nos propres variables d'environnement et un `entrypoint` personnalisé. C'est ce qu'on fait pour [Mattermost](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/blob/master/pica-mattermost/entrypoint.sh) : `config.json` n'est pas versionné, mais l'`entrypoint` récupère la configuration via l'environnement et l'injecte dans `config.json`.
+Alors on créera nos propres variables d'environnement et un `entrypoint` personnalisé. C'est ce qu'on fait pour [Mattermost](https://gitlab.utc.fr/picasoft/projets/services/mattermost/-/blob/master/entrypoint.sh) : `config.json` n'est pas versionné, mais l'`entrypoint` récupère la configuration via l'environnement et l'injecte dans `config.json`.
 ## Gestion des secrets
@@ Ligne 102: / Ligne 106: @@
 ## Choisir un nom de domaine
-Picasoft est propriétaire du domaine ''picasoft.net'', il est donc possible de [[technique:internal_serv:dns:zonefile|créer des nom de domaine]] sur celui-ci. On veillera à choisir un nom clair et représentatif. De plus ce n'est pas une obligation mais nos noms sont souvent en anglais, il peut être pratique pour les utilisateurs de continuer ainsi pour plus de cohérence.
+Picasoft est propriétaire du domaine ''picasoft.net'', il est donc possible de [[technique:adminsys:dns:zonefile|créer des nom de domaine]] sur celui-ci. On veillera à choisir un nom clair et représentatif. De plus ce n'est pas une obligation mais nos noms sont souvent en anglais, il peut être pratique pour les utilisateurs de continuer ainsi pour plus de cohérence.
 <bootnote>
@@ Ligne 108: / Ligne 112: @@
 </bootnote>
-## Gestion des backups
+## Gestion des backups des bases de données
-### Mise en place de la création des backups
 Il existe actuellement deux systèmes de backup sur l’infrastructure de Picasoft.
@@ Ligne 116: / Ligne 118: @@
 Le premier système consiste en un backup régulier de la totalité des machines virtuelles, il n'y a rien à faire de particulier pour ces backups lors de la mise en place d'un service.
-Le second système concerne les backups des bases de données, nous avons sur chaque machine virtuelle [[technique:adminsys:backup:db:start|un service dédié]] dans un conteneur docker qui s'occupe de ces backups, il s'agit du service ''pica-db-backup'' dans le dépôt des dockerfiles.
+Le second système concerne les backups des bases de données, nous avons sur chaque machine virtuelle [[technique:old:adminsys:backup:db:start|un service dédié]] dans un conteneur docker qui s'occupe de ces backups, il s'agit du service ''db-backup''.
-Pour que le backup soit faisable par ce service il faut qu'il soit en mesure de communiquer avec la base de donnés du nouveau service, pour cela on utilise les réseaux docker, il faut ajouter le service de backup dans le réseau dédié du nouveau service (dans la section ''networks'' du fichier ''docker-compose.yml'').
+<bootnote>Cette section n'est pertinente que pour les services avec une base de données.</bootnote>
-Une fois que le service de backup peut communiquer avec la base de données il faut lui indiquer qu'il doit faire un backup, pour cela on modifie le fichier ''config/backup_config.json'', on peut reprendre la configuration d'un autre service et l'adapter. Les différents paramètres sont :
+### Création des backups
-  * ''Host'' : le nom du conteneur de base de données
+Modifier la configuration selon [la documentation](https://gitlab.utc.fr/picasoft/projets/services/db-backup), puis redémarrer le service de backup sur la machine où tournera le nouveau service.
-  * ''Port'' : le port correspondant à la base de données
-  * ''User'' : le nom d'utilisateur utilisé pour se connecter à la base de données, on utilisera les fichiers de secret
+Pour que le backup soit faisable par ce service il faut qu'il soit en mesure de communiquer avec la base de donnés du nouveau service, pour cela on utilise les réseaux docker, il faut ajouter le service de backup dans le réseau dédié du nouveau service (dans la section ''networks'' du fichier ''docker-compose.yml'').
-  * ''Password'' : le mot de passe de l'utilisateur, on utilisera les fichiers de secret
-  * ''Database'' : le nom de la base de données
-  * ''Type'' : le type de base de données à sauvegarder, parmi ''postgres'', ''mongo'' ou ''mysql''
-  * ''Folder'' : le nom du dossier de backup utilisé
-  * ''Cron'' : la fréquence des backup au format Cron
-  * ''Init-Backup'' : indique si le backup doit être fait au démarrage du service indépendament du cron
-  * ''Options'' : permet de passer des options au programme de backup dans le cas de MySQL
 ### Mise en place de la rotation des backups
-Une fois que les backups sont executés il faut activer la rotation des backups afin qu'il ne prennent pas trop de place. Encore une fois nous avons un service dédié dans un conteneur dans le dossier ''pica-db-backup-rotation''.
+Une fois que les backups sont exécutés il faut activer la rotation des backups afin qu'ils ne prennent pas trop de place. Encore une fois, nous avons un service dédié dans un conteneur dans le dossier ''db-backup-rotation''.
-Pour celui-ci, il suffit de modifier le fichier de configuration, pas besoin d'ajouter des réseaux. Le fichier de configuration est dans ''config/backup_config.json''. On peut reprendre la configuration d'un autre service et l'adapter. La liste des paramètres est :
+Modifier la configuration selon la [documentation](https://gitlab.utc.fr/picasoft/projets/services/db-backup-rotation), puis redémarrer le service de rotation sur la machine où tournera le nouveau service.
-  * ''Folder'' : le dossier contenant les backups
-  * ''Backup-Rota'' : la configuration de la rotation :
-    * ''Hour'' : le nombre de backups horaires à conserver
-    * ''Day'' : le nombre de backups quotidiens à conserver
-    * ''Week'' : le nombre de backups hebdomadaires à conserver
-    * ''Month'' : le nombre de backups mensuels à conserver
 ## Collecte de métriques et alerting
@@ Ligne 152: / Ligne 141: @@
 </bootnote>
-De plus en plus de services web proposent un exporter Prometheus qui sert des métriques sur `/metrics`. Parfois, l'exporter est intégré au service, parfois il se présente sous la forme d'un processus à part. Si aucun exporter n'existe, il est pertinent d'écrire votre propre exporter et peut-être même de le proposer au projet ! À titre d'exemple, Picadrop exporte ses métriques grâce à un [exporter maison](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/tree/master/pica-lufi/prometheus-exporter).
+De plus en plus de services web proposent un exporter Prometheus qui sert des métriques sur `/metrics`. Parfois, l'exporter est intégré au service, parfois il se présente sous la forme d'un processus à part. Si aucun exporter n'existe, il est pertinent d'écrire votre propre exporter et peut-être même de le proposer au projet ! À titre d'exemple, Picadrop exporte ses métriques grâce à un [exporter maison](https://gitlab.utc.fr/picasoft/projets/services/lufi/-/tree/master/prometheus-exporter).
-Dans tous les cas, la configuration pour exposer et récupérer les métriques d'un service est [[technique:adminsys:monitoring:metrologie:collect:service_metrics|à peu près toujours la même]].
+Dans tous les cas, la configuration pour exposer et récupérer les métriques d'un service est [[technique:adminsys:monitoring:collect:service_metrics|à peu près toujours la même]].
 Si les métriques s'y prêtent, on pourra [[technique:adminsys:monitoring:alerting:vmalert|rajouter une alerte]].
+<bootnote critical>
+Dans tous les cas, rajouter le service nouvellement créé dans la liste des services surveillés par [[technique:adminsys:monitoring:collect:blackbox|Blackbox]] !
+</bootnote>
+## Vérifier les mises à jour
+Pour ce faire, modifier la configuration du [[technique:adminsys:secu:services_updates|bot des mises à jour]], qui publie un message sur Mattermost chaque fois qu'il y a une nouvelle mise à jour d'un service.
 ## Que faire ensuite ?
 Une fois que tout est prêt, vous pouvez [[technique:docker:picasoft:test|tester votre service]].