Différences

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

--- technique:docker:picasoft:new [2022/05/24 20:32] – ppom
+++ technique:docker:picasoft:new [2022/09/24 10:39] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. rdelaage
@@ Ligne 80: / 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 90: / 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 118: / 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''.
 <bootnote>Cette section n'est pertinente que pour les services avec une base de données.</bootnote>
@@ Ligne 124: / Ligne 124: @@
 ### Création des backups
-Modifier la configuration selon [la documentation](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/tree/master/pica-db-backup), puis redémarrer le service de backup sur la machine où tournera le nouveau service.
+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.
 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'').
@@ Ligne 130: / Ligne 130: @@
 ### 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''.
-Modifier la configuration selon la [documentation](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/tree/master/pica-db-backup-rotation), puis redémarrer le service de rotation sur la machine où tournera le nouveau service.
+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.
@@ Ligne 141: / 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:collect:service_metrics|à peu près toujours la même]].