Différences

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

--- technique:docker:picasoft:new [2021/11/22 22:30] – ↷ Liens modifiés en raison d'un déplacement. qduchemi
+++ technique:docker:picasoft:new [2022/05/24 20:32] – ppom
@@ Ligne 8: / Ligne 8: @@
 ## 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 20: / 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 50: / 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 143: / Ligne 143: @@
 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).
-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:metrologie:collect:blackbox|Blackbox]] !
+Dans tous les cas, rajouter le service nouvellement créé dans la liste des services surveillés par [[technique:adminsys:monitoring:collect:blackbox|Blackbox]] !
 </bootnote>