tuto5 done for GISTRE, split files

tutorial/5/Makefile

@@ -18,15 +18,26 @@ SOURCES_SRS	= tutorial-srs.md \
 		    ../devops/tools-drone-runner-end.md \
 		    ../devops/tools-end.md \
 		    ../devops/ci.md \
+		    ../devops/ci-about-webhook.md \
+		    ../devops/ci-define-steps.md \
+		    ../devops/ci-define-steps-end.md \
+		    ../devops/ci-qa.md \
+		    ../devops/ci-tags.md \
 		    ../devops/publish-docker.md \
+		    ../devops/publish-docker-intro-end.md \
+		    ../devops/publish-docker-howto.md \
+		    ../devops/publish-docker-howto-sample.md \
+		    ../devops/publish-docker-publish.md \
+		    ../devops/publish-docker-test.md \
+		    ../devops/publish-docker-end.md \
 		    ../devops/renovate.md ../devops/renovate-ansible.md ../devops/renovate-end.md \
 		  rendu-srs.md
 
 SOURCES_GISTRE	= tutorial-gistre.md \
+		    ../devops/devops.md \
 		    ../devops/what-gistre.md \
 		    ../devops/what-cmd.md \
 		    ../devops/what-hosts.md \
-		    ../devops/what-gistre-see-srs.md \
 		    ../devops/tools.md \
 		    ../devops/tools-gitea.md \
 		    ../devops/tools-gitea-cmd.md \
@@ -39,7 +50,18 @@ SOURCES_GISTRE	= tutorial-gistre.md \
 		    ../devops/tools-drone-runner-end.md \
 		    ../devops/tools-end.md \
 		    ../devops/ci-gistre.md \
+		    ../devops/ci-about-webhook.md \
+		    ../devops/ci-define-steps.md \
+		    ../devops/ci-define-steps-end-gistre.md \
+		    ../devops/ci-tags.md \
+		    ../devops/ci-multiarch.md \
 		    ../devops/run-gistre.md \
+		    ../devops/publish-docker.md \
+		    ../devops/publish-docker-howto.md \
+		    ../devops/publish-docker-howto-sample-gistre.md \
+		    ../devops/publish-docker-publish.md \
+		    ../devops/publish-docker-test-gistre.md \
+		    ../devops/publish-docker-end-gistre.md \
 		  rendu-gistre.md
 
 

tutorial/5/rendu-gistre.md

@@ -3,60 +3,72 @@
 Rendu
 =====
 
-Modalités de rendu
+Arborescence attendue
-------------------
-
-En tant que personnes sensibilisées à la sécurité des échanges électroniques,
-vous devrez m'envoyer vos rendus signés avec votre clef PGP.
-
-Un service automatique s'occupe de réceptionner vos rendus, de faire des
-vérifications élémentaires et de vous envoyer un accusé de réception (ou de
-rejet).
-
-Ce service écoute sur l'adresse <virli@nemunai.re>. C'est donc à cette adresse
-et exclusivement à celle-ci que vous devez envoyer vos rendus. Tout rendu
-envoyé à une autre adresse et/ou non signé et/ou reçu après la correction ne
-sera pas pris en compte.
-
-Afin d'orienter correctement votre rendu, ajoutez une balise `[TP5]` au sujet
-de votre courriel. N'hésitez pas à indiquer dans le corps du message votre
-ressenti et vos difficultés ou bien alors écrivez votre meilleure histoire
-drôle si vous n'avez rien à dire.
-
-Par ailleurs, n'oubliez pas de répondre à
-[l'évaluation du cours](https://virli.nemunai.re/quiz/17).
-
-
-Tarball
 -------
 
-Tous les fichiers identifiés comme étant à rendre pour ce TP sont à
+Tous les fichiers identifiés comme étant à rendre sont à placer dans un dépôt
-placer dans une tarball (pas d'archive ZIP, RAR, ...).
+Git privé, que vous partagerez avec [votre
+professeur](https://gitlab.cri.epita.fr/nemunaire/).
 
-Voici une arborescence type (vous pourriez avoir des fichiers
+Voici une arborescence type (vous pourriez avoir des fichiers supplémentaires) :
-supplémentaires) :
 
 <div lang="en-US">
 ```
-login_x-TP5/
+./linky2influx/
-login_x-TP5/linky2influx/
+./linky2influx/.drone.yml
-login_x-TP5/linky2influx/.drone.yml
+./linky2influx/Dockerfile
-login_x-TP5/linky2influx/Dockerfile
+./linky2influx/.dockerignore
-login_x-TP5/linky2influx/.dockerignore
+./linky2influx/...
-login_x-TP5/linky2influx/...
+./linky2influx/linky2influx.nix
-login_x-TP5/linky2influx/linky2influx.nix
+./linky2influx/snapcraft.yaml
-login_x-TP5/linky2influx/snapcraft.yaml
+./linky2influx/lxc-scripts/template.sh
-login_x-TP5/linky2influx/lxc-scripts/template.sh
+./linky2influx/lxc-scripts/sample.config
-login_x-TP5/linky2influx/lxc-scripts/sample.config
+./linky2influx/systemd/linky2influx.nspawn
-login_x-TP5/linky2influx/systemd/linky2influx.nspawn
+./linky2influx/systemd/linky2influx.service
-login_x-TP5/linky2influx/systemd/linky2influx.service
+./docker/run.sh
-login_x-TP5/docker/run.sh
+./lxc/run.sh
-login_x-TP5/lxc/run.sh
+./k3s/linky2influx.yaml
-login_x-TP5/k3s/linky2influx.yaml
+./meta-electropcool/recipes-support/linky2influx/linky2influx_9999.bb
-login_x-TP5/meta-electropcool/recipes-support/linky2influx/linky2influx_9999.bb
+./runc/config.json
-login_x-TP5/runc/config.json
+./runc/runtime.json
-login_x-TP5/runc/runtime.json
+./snap/run.sh
-login_x-TP5/snap/run.sh
+./...
-login_x-TP5/...
 ```
 </div>
+
+Votre rendu sera pris en compte en faisant un [tag **signé par votre clef
+PGP**](https://lessons.nemunai.re/keys). Consultez les détails du rendu (nom du
+tag, ...) sur la page dédiée au projet sur la plateforme de rendu.
+
+::::: {.question}
+
+Si vous utilisez un seul dépôt pour tous vos rendus, vous **DEVRIEZ**
+créer une branche distincte pour chaque rendu :
+
+<div lang="en-US">
+```
+42sh$ git checkout --orphan renduX
+42sh$ git reset
+42sh$ rm -r *
+42sh$   # Créer l'arborescence de rendu ici
+```
+</div>
+
+Pour retrouver ensuite vos rendus des travaux précédents :
+
+<div lang="en-US">
+```
+42sh$ git checkout renduY
+-- ou --
+42sh$ git checkout master
+...
+```
+</div>
+
+Chaque branche est complètement indépendante l'une de l'autre. Vous
+pouvez avoir les exercices du TP1 sur `master`, les exercices du TP6
+sur `rendu6`, ... ce qui vous permet d'avoir une arborescence
+correspondant à ce qui est demandé, sans pour autant perdre votre
+travail (ou le rendre plus difficile d'accès).
+
+::::

tutorial/5/tutorial-gistre.md

@@ -10,8 +10,8 @@ abstract: |
 
   \vspace{1em}
 
-  Les exercices de ce cours sont à rendre au plus tard le mardi 29
+  Les exercices de ce cours sont à rendre au plus tard le dimanche 18
-  novembre 2022 à 23 h 42. Consultez les sections matérialisées par un
+  décembre 2022 à 23 h 42. Consultez les sections matérialisées par un
   bandeau jaunes et un engrenage pour plus d'informations sur les
   éléments à rendre.
 ...

tutorial/devops/ci-about-webhook.md

@@ -0,0 +1,21 @@
+::::: {.question}
+
+#### Que fait Drone pour « surveiller » un dépôt ? {-}
+\
+
+Grâce aux permissions de que Drone a récupéré lors de la connexion OAuth à
+Gitea, il peut non seulement lire et récupérer le code des différents dépôts
+auxquels vous avez accès, mais il peut aussi changer certains paramètres.
+
+L'activation d'un dépôt dans Drone se traduit par la configuration d'un
+*webhook* sur le dépôt en question. On peut le voir dans les paramètres du
+dépôt, sous l'onglet *Déclencheurs Web*.
+
+:::::
+
+![L'onglet des *webhooks* dans Gitea](gitea-webhooks.png){height=6cm}
+
+À chaque fois qu'un événement va se produire sur le dépôt, Gitea va prévenir
+Drone qui décidera si l'évènement doit conduire à lancer l'intégration continue
+ou non, selon les instructions qu'on lui a donné dans la configuration du
+dépôt.

tutorial/devops/ci-define-steps-end-gistre.md

@@ -0,0 +1,17 @@
+Les étapes sont sensiblement les mêmes que dans le `Dockerfile` présent sur le
+dépôt.
+
+Committons puis poussons notre travail. Dès qu'il sera reçu par Gitea, nous
+devrions voir l'interface de Drone lancer les étapes décrites dans le fichier.
+
+![Drone en action](drone-run-linky.png){height=7.5cm}
+
+::::: {.warning}
+**IMPORTANT :** si vous avez l'impression que ça ne marche pas et que vous avez
+réutilisé le fichier présent sur le dépôt au lieu de partir de l'exemple donné
+dans la documentation, **commencez en partant de l'exemple de la
+documentation** ! Le fichier présent sur le dépôt **ne fonctionnera pas** dans
+votre situation !
+:::::
+
+Lorsqu'apparaît enfin la ligne `git.nemunai.re/linky2influx`, le projet est compilé !

tutorial/devops/ci-define-steps-end.md

@@ -0,0 +1,26 @@
+Les étapes sont sensiblement les mêmes que dans le `Dockerfile` que nous avons
+écrit précédemment.
+
+::::: {.exercice}
+
+Commencez à partir de l'exemple donné dans la documentation de Drone. Par
+rapport au `Dockerfile`, n'ajoutez pas `tags dev`, cela permettra d'embarquer
+tout le contenu statique (pages HTML, feuilles de style CSS, Javascript, ...)
+directement dans le binaire, ce qui simplifiera la distribution.
+
+*Committons* puis poussons notre travail. Dès qu'il sera reçu par Gitea, nous
+devrions voir l'interface de Drone lancer les étapes décrites dans le fichier.
+
+:::::
+
+![Drone en action](drone-run.png){height=6cm}
+
+::::: {.warning}
+**IMPORTANT :** si vous avez l'impression que ça ne marche pas et que vous avez
+réutilisé le fichier présent sur le dépôt au lieu de partir de l'exemple donné
+dans la documentation, **commencez en partant de l'exemple de la
+documentation** ! Le fichier présent sur le dépôt **ne fonctionnera pas** dans
+votre situation !
+:::::
+
+Lorsqu'apparaît enfin la ligne `git.nemunai.re/youp0m`, le projet est compilé !

tutorial/devops/ci-define-steps.md

@@ -0,0 +1,19 @@
+### Définir les étapes d'intégration
+
+Nous allons devoir rédiger un fichier `drone.yml`, que l'on placera à la racine
+du dépôt. C'est ce fichier qui sera traité par DroneCI pour savoir comment
+compiler et tester le projet.
+
+::::: {.warning}
+Un fichier `drone.yml` existe déjà à la racine du dépôt. Celui-ci pourra vous
+servir d'inspiration, mais il ne fonctionnera pas directement dans votre
+installation.
+
+**Vous rencontrerez des problèmes inattendus si vous utilisez le fichier
+`.drone.yml` du dépôt.** Vous **DEVEZ** partir d'un fichier vide et suivre la
+documentation pour obtenir un `.drone.yml` fonctionnel.
+:::::
+
+Toutes les informations nécessaires à l'écriture du fichier `.drone.yml` se
+trouvent dans l'excellente documentation du projet :\
+<https://docs.drone.io/pipeline/docker/examples/languages/golang/>.

tutorial/devops/ci-gistre.md

@@ -2,120 +2,15 @@
 
 ## Intégration continue
 
-::::: {.question}
-
-La mise en place de l'environnement de CI/CD n'est pas le cœur de la version
-GISTRE du TP (elle l'est pour les SRS). Aussi cette partie est aussi guidée que
-possible et toutes les commandes vous sont données pour réduire les frictions
-de mise en œuvre.
-
-Mais comme indiqué dans l'introduction au DevOps, vous serez susceptibles
-d'arriver dans une entreprise qui pratique correctement le DevOps. Dans cette
-situation, l'ensemble des développeurs et des administrateurs système (les
-*Ops*), doivent faire en sorte que leurs travaux soient intégrés dans les
-outils d'intégration continue. Les *Ops* vont évidemment plutôt gérer la mise
-en place des outils, proprement, c'est ce que demande de faire le TP SRS. Pour
-vous il s'agit plus de savoir interagir avec, en sachant manipuler la
-configuration des dépôts.
-
-:::::
-
 Une fois Gitea et Drone installés et configurés, nous allons pouvoir rentrer
 dans le vif du sujet : faire de l'intégration continue sur notre premier projet !
 
 ### Créez un dépôt pour `linky2influx`
 
+::::: {.exercice}
+
 Après avoir créé (ou migré pour les plus malins !) le dépôt
-[`linky2influx`](https://git.nemunai.re/nemunaire/linky2influx) dans Drone,
+[`linky2influx`](https://git.nemunai.re/nemunaire/linky2influx) dans gitea,
-synchronisez les dépôts, puis activez la surveillance de `linky2influx`.
+synchronisez les dépôts dans Drone, puis activez la surveillance de `linky2influx`.
 
-Nous allons devoir rédiger un fichier `.drone.yml`, que l'on placera à la racine
-du dépôt. C'est ce fichier qui sera traité par DroneCI pour savoir comment
-compiler et tester le projet.
-
-::::: {.warning}
-Un fichier `.drone.yml` existe déjà à la racine du dépôt. Celui-ci pourra vous
-servir d'inspiration, mais il ne fonctionnera pas directement sur votre
-installation.
-
-**Vous rencontrerez des problèmes inattendus si vous utilisez le fichier
-`.drone.yml` du dépôt.** Vous **DEVEZ** partir d'un fichier vide et suivre la
-documentation pour obtenir un `.drone.yml` fonctionnel.
 :::::
-
-
-### Définir les étapes d'intégration
-
-Toutes les informations nécessaires à l'écriture du fichier `.drone.yml` se
-trouvent dans [l'excellente documentation du
-projet](https://docs.drone.io/pipeline/docker/examples/languages/golang/).
-
-Les étapes sont sensiblement les mêmes que dans le `Dockerfile` présent sur le
-dépôt.
-
-Committons puis poussons notre travail. Dès qu'il sera reçu par Gitea, nous
-devrions voir l'interface de Drone lancer les étapes décrites dans le fichier.
-
-::::: {.warning}
-**IMPORTANT :** si vous avez l'impression que ça ne marche pas et que vous avez
-réutilisé le fichier présent sur le dépôt au lieu de partir de l'exemple donné
-dans la documentation, **commencez en partant de l'exemple de la
-documentation** ! Le fichier présent sur le dépôt **ne fonctionnera pas** dans
-votre situation !
-:::::
-
-![Drone en action](drone-run-linky.png){height=7.5cm}
-
-Lorsqu'apparaît enfin la ligne `git.nemunai.re/linky2influx`, le projet est compilé !
-
-
-### Publier le binaire correspondant aux tags/jalons
-
-Nous savons maintenant que notre projet compile bien dans un environnement
-différent de celui du développeur ! Néanmoins, le binaire produit est perdu dès
-lors que la compilation est terminée, car nous n'en faisons rien.
-
-Ajoutons donc une nouvelle règle à notre `.droneci.yml` pour placer le binaire
-au sein de la liste des fichiers téléchargeable aux côtés des tags.
-
-Vous aurez sans doute besoin de :
-
-  - <https://docs.drone.io/pipeline/conditions/>
-  - <http://plugins.drone.io/drone-plugins/drone-gitea-release/>
-
-Attention à ne pas stocker votre clef d'API dans le fichier YAML !
-
-![Binaire publié automatiquement sur Gitea](tag-released.png){height=8cm}
-
-::::: {.more}
-Lorsque l'on est plusieurs à travailler sur le projet ou pour accroître la
-sécurité, il convient de créer, un compte *bot* qui sera responsable de la
-création des *releases*. Ce sera donc sa clef d'API que l'on indiquera dans
-l'interface de Drone.
-:::::
-
-
-### Publier pour plusieurs architectures ?
-
-Le compilateur Go est fourni avec l'ensemble des backends des différentes
-architectures matérielles qu'il supporte, nous pouvons donc aisément faire de
-la compilation croisée pour d'autres architectures.
-
-Essayons maintenant de compiler `linky2influx` pour plusieurs architectures afin de
-vérifier que cela fonctionne bien !
-
-Un exemple est donné tout en haut de cette page :
-<https://docs.drone.io/pipeline/environment/syntax/>.
-
-En faisant varier `$GOARCH` en `mips`, `powerpc`, ... nous pouvons générer les
-binaires correspondant à chaque architecture et système.
-
-Ajoutez à votre fichier `.drone.yml` les deux architectures pour lesquelles les
-Raspberry Pi d'Électropcool sont compatibles. Nommez les fichiers selon
-l'architecture que pourrait renvoyer `uname -m`, cela pourrait nous simplifier la tâche ensuite...
-\
-
-Une fois taggé et poussé sur notre dépôt, nous aurons une version exécutable
-utilisable à la fois sur notre machine de développement, mais aussi sur les
-Raspberry Pi déjà déployées dans les bâtiments. Nous avons atteint l'un des
-deux objectifs qui nous était demandé. Tâchons maintenant de trouver un

tutorial/devops/ci-multiarch.md

@@ -0,0 +1,26 @@
+### Publier pour plusieurs architectures ?
+
+Le compilateur Go est fourni avec l'ensemble des backends des différentes
+architectures matérielles qu'il supporte, nous pouvons donc aisément faire de
+la compilation croisée pour d'autres architectures.
+
+Essayons maintenant de compiler `linky2influx` pour plusieurs architectures afin de
+vérifier que cela fonctionne bien !
+
+Un exemple est donné tout en haut de cette page :
+<https://docs.drone.io/pipeline/environment/syntax/>.
+
+En faisant varier `$GOARCH` en `mips`, `powerpc`, ... nous pouvons générer les
+binaires correspondant à chaque architecture et système.
+
+Ajoutez à votre fichier `.drone.yml` les deux architectures pour lesquelles les
+Raspberry Pi d'Électropcool sont compatibles. Nommez les fichiers selon
+l'architecture que pourrait renvoyer `uname -m`, cela pourrait nous simplifier la tâche ensuite...
+\
+
+Une fois taggé et poussé sur notre dépôt, nous aurons une version exécutable
+utilisable à la fois sur notre machine de développement, mais aussi sur les
+Raspberry Pi déjà déployées dans les bâtiments.
+
+Nous avons atteint l'un des deux objectifs qui nous était demandé. Tâchons
+maintenant de trouver une manière de faciliter la distribution du binaire.

tutorial/devops/ci-qa.md

@@ -0,0 +1,30 @@
+### Inspection qualité
+
+`youp0m` n'a pas de suite de tests fonctionnels, mais nous allons utiliser
+[Sonarqube](https://www.sonarqube.org/) pour faire une revue qualité du code !
+
+Tout d'abord, il faut lancer le conteneur Sonarqube :
+
+<div lang="en-US">
+```bash
+docker run --rm -d --name sonarqube --network drone -p 9000:9000 sonarqube
+```
+</div>
+
+Le service met un bon moment avant de démarrer, dès qu'il se sera initialisé,
+nous pourrons accéder à l'interface sur <http://localhost:9000>.
+
+::::: {.exercice}
+
+En attendant qu'il démarre, nous pouvons commencer à ajouter le nécessaire à
+notre `.drone.yml` : <http://plugins.drone.io/aosapps/drone-sonar-plugin/>.
+
+:::::
+
+Après s'être connecté à Sonarqube (`admin:admin`), nous pouvons aller générer
+un token, tel que décrit dans la [documentation du plugin
+Drone](http://plugins.drone.io/aosapps/drone-sonar-plugin/).
+
+Une fois la modification *commitée* et poussée, Drone enverra le code à Sonarqube
+qui en fera une analyse minutieuse. Rendez-vous sur
+<http://127.0.0.1:9000/projects> pour admirer le résultat.

tutorial/devops/ci-tags.md

@@ -0,0 +1,35 @@
+### Publier le binaire correspondant aux tags/jalons
+
+Nous savons maintenant que notre projet compile bien dans un environnement
+différent de celui du développeur ! Néanmoins, le binaire produit est perdu dès
+lors que la compilation est terminée, car nous n'en faisons rien.
+
+::::: {.exercice}
+
+Ajoutons donc une nouvelle règle à notre `.droneci.yml` pour placer le binaire
+au sein de la liste des fichiers téléchargeables aux côtés des tags.
+
+Vous aurez sans doute besoin de :
+
+  - <https://docs.drone.io/pipeline/conditions/>
+  - <http://plugins.drone.io/drone-plugins/drone-gitea-release/>
+
+::::: {.warning}
+
+#### Attention à ne pas stocker votre clef d'API dans le fichier YAML ! {-}
+\
+
+Lorsque l'on est plusieurs à travailler sur le projet ou pour accroître la
+sécurité, il convient de créer, un compte *bot* qui sera responsable de la
+création des *releases*. Ce sera donc sa clef d'API que l'on indiquera dans
+l'interface de Drone.
+
+Pour notre exercice, nous n'avons pas besoin de créer un utilisateur dédié,
+mais il est impératif d'utiliser les *secrets* de Drone pour ne pas que la clef
+d'API apparaisse dans l'historique du dépôt.
+
+:::::
+
+:::::
+
+![Binaire publié automatiquement sur Gitea](tag-released.png){height=8cm}

tutorial/devops/ci.md

@@ -21,142 +21,3 @@ activez la surveillance de `youp0m`.
 [^urlyoup0m]: <https://git.nemunai.re/nemunaire/youp0m>
 
 :::::
-
-::::: {.question}
-
-#### Que fait Drone pour « surveiller » un dépôt ? {-}
-\
-
-Grâce aux permissions de que Drone a récupéré lors de la connexion OAuth à
-Gitea, il peut non seulement lire et récupérer le code des différents dépôts
-auxquels vous avez accès, mais il peut aussi changer certains paramètres.
-
-L'activation d'un dépôt dans Drone se traduit par la configuration d'un
-*webhook* sur le dépôt en question. On peut le voir dans les paramètres du
-dépôt, sous l'onglet *Déclencheurs Web*.
-
-:::::
-
-![L'onglet des *webhooks* dans Gitea](gitea-webhooks.png){height=6cm}
-
-À chaque fois qu'un événement va se produire sur le dépôt, Gitea va prévenir
-Drone qui décidera si l'évènement doit conduire à lancer l'intégration continue
-ou non, selon les instructions qu'on lui a donné dans la configuration du
-dépôt.
-
-
-### Définir les étapes d'intégration
-
-Nous allons devoir rédiger un fichier `drone.yml`, que l'on placera à la racine
-du dépôt. C'est ce fichier qui sera traité par DroneCI pour savoir comment
-compiler et tester le projet.
-
-::::: {.warning}
-Un fichier `drone.yml` existe déjà à la racine du dépôt. Celui-ci pourra vous
-servir d'inspiration, mais il ne fonctionnera pas directement dans votre
-installation.
-
-**Vous rencontrerez des problèmes inattendus si vous utilisez le fichier
-`.drone.yml` du dépôt.** Vous **DEVEZ** partir d'un fichier vide et suivre la
-documentation pour obtenir un `.drone.yml` fonctionnel.
-:::::
-
-Toutes les informations nécessaires à l'écriture du fichier `.drone.yml` se
-trouvent dans l'excellente documentation du projet :\
-<https://docs.drone.io/pipeline/docker/examples/languages/golang/>.
-
-Les étapes sont sensiblement les mêmes que dans le `Dockerfile` que nous avons
-écrit précédemment.
-
-::::: {.exercice}
-
-Commencez à partir de l'exemple donné dans la documentation de Drone. Par
-rapport au `Dockerfile`, n'ajoutez pas `tags dev`, cela permettra d'embarquer
-tout le contenu statique (pages HTML, feuilles de style CSS, Javascript, ...)
-directement dans le binaire, ce qui simplifiera la distribution.
-
-*Committons* puis poussons notre travail. Dès qu'il sera reçu par Gitea, nous
-devrions voir l'interface de Drone lancer les étapes décrites dans le fichier.
-
-:::::
-
-![Drone en action](drone-run.png){height=6cm}
-
-::::: {.warning}
-**IMPORTANT :** si vous avez l'impression que ça ne marche pas et que vous avez
-réutilisé le fichier présent sur le dépôt au lieu de partir de l'exemple donné
-dans la documentation, **commencez en partant de l'exemple de la
-documentation** ! Le fichier présent sur le dépôt **ne fonctionnera pas** dans
-votre situation !
-:::::
-
-Lorsqu'apparaît enfin la ligne `git.nemunai.re/youp0m`, le projet est compilé !
-
-
-### Inspection qualité
-
-`youp0m` n'a pas de suite de tests fonctionnels, mais nous allons utiliser
-[Sonarqube](https://www.sonarqube.org/) pour faire une revue qualité du code !
-
-Tout d'abord, il faut lancer le conteneur Sonarqube :
-
-<div lang="en-US">
-```bash
-docker run --rm -d --name sonarqube --network drone -p 9000:9000 sonarqube
-```
-</div>
-
-Le service met un bon moment avant de démarrer, dès qu'il se sera initialisé,
-nous pourrons accéder à l'interface sur <http://localhost:9000>.
-
-::::: {.exercice}
-
-En attendant qu'il démarre, nous pouvons commencer à ajouter le nécessaire à
-notre `.drone.yml` : <http://plugins.drone.io/aosapps/drone-sonar-plugin/>.
-
-:::::
-
-Après s'être connecté à Sonarqube (`admin:admin`), nous pouvons aller générer
-un token, tel que décrit dans la [documentation du plugin
-Drone](http://plugins.drone.io/aosapps/drone-sonar-plugin/).
-
-Une fois la modification *commitée* et poussée, Drone enverra le code à Sonarqube
-qui en fera une analyse minutieuse. Rendez-vous sur
-<http://127.0.0.1:9000/projects> pour admirer le résultat.
-
-
-### Publier le binaire correspondant aux tags/jalons
-
-Nous savons maintenant que notre projet compile bien dans un environnement
-différent de celui du développeur ! Néanmoins, le binaire produit est perdu dès
-lors que la compilation est terminée, car nous n'en faisons rien.
-
-::::: {.exercice}
-
-Ajoutons donc une nouvelle règle à notre `.droneci.yml` pour placer le binaire
-au sein de la liste des fichiers téléchargeables aux côtés des tags.
-
-Vous aurez sans doute besoin de :
-
-  - <https://docs.drone.io/pipeline/conditions/>
-  - <http://plugins.drone.io/drone-plugins/drone-gitea-release/>
-
-::::: {.warning}
-
-#### Attention à ne pas stocker votre clef d'API dans le fichier YAML ! {-}
-\
-
-Lorsque l'on est plusieurs à travailler sur le projet ou pour accroître la
-sécurité, il convient de créer, un compte *bot* qui sera responsable de la
-création des *releases*. Ce sera donc sa clef d'API que l'on indiquera dans
-l'interface de Drone.
-
-Pour notre exercice, nous n'avons pas besoin de créer un utilisateur dédié,
-mais il est impératif d'utiliser les *secrets* de Drone pour ne pas que la clef
-d'API apparaisse dans l'historique du dépôt.
-
-:::::
-
-:::::
-
-![Binaire publié automatiquement sur Gitea](tag-released.png){height=8cm}

tutorial/devops/publish-docker-end-gistre.md

@@ -0,0 +1,4 @@
+### Et ensuite ?
+
+Nous avons vu une manière possible de distribuer notre projet. Essayons-en une
+autre parmis celles proposées.

tutorial/devops/publish-docker-end.md

@@ -0,0 +1,17 @@
+### Vers le déploiement
+
+Nous n'allons pas faire le déploiement aujourd'hui, car nous n'avons pas
+d'environnement de production sur lequel déployer notre service.
+
+Vous pouvez néanmoins tester les plugins
+[`scp`](http://plugins.drone.io/appleboy/drone-scp/) ou
+[`ansible`](http://plugins.drone.io/drone-plugins/drone-ansible/) si vous avez
+une machine virtuelle avec une connexion SSH. N'hésitez pas à l'ajouter à votre
+`.droneci.yml`.
+
+
+### Profitons !
+
+Sonarqube a repéré quelques erreurs dans le code de `youp0m`, essayez de les
+corriger, et publiez une nouvelle version, pour observer toute la chaîne en
+action !

tutorial/devops/publish-docker-howto-sample-gistre.md

@@ -0,0 +1,14 @@
+Nous pouvons ensuite envoyer une image pour s'assurer que tout va bien :
+
+<div lang="en-US">
+```bash
+docker build -t localhost:3000/${USER}/linky2influxdb .
+docker push localhost:3000/${USER}/linky2influxdb
+```
+</div>
+
+Rendez-vous ensuite sur la page <http://gitea:3000/${USER}/-/packages> pour
+attribuer l'image au dépôt `linky2influxdb` (voir pour cela dans les paramètres de
+l'image).
+
+![Notre image `linky2influxdb` dans Gitea !](gitea-packages.png){height=6cm}

tutorial/devops/publish-docker-howto-sample.md

@@ -0,0 +1,14 @@
+Nous pouvons ensuite envoyer une image pour s'assurer que tout va bien :
+
+<div lang="en-US">
+```bash
+docker build -t localhost:3000/${USER}/youp0m .
+docker push localhost:3000/${USER}/youp0m
+```
+</div>
+
+Rendez-vous ensuite sur la page <http://gitea:3000/${USER}/-/packages> pour
+attribuer l'image au dépôt `youp0m` (voir pour cela dans les paramètres de
+l'image).
+
+![Notre image `youp0m` dans Gitea !](gitea-packages.png){height=6cm}

tutorial/devops/publish-docker-howto.md

@@ -0,0 +1,31 @@
+#### Fonctionnement du registre de Gitea \
+
+Gitea intègre un registre d'images Docker (depuis la version 1.17,
+mi-2022). Pour le moment, les images sont uniquement liées à un compte
+utilisateur ou à une organisation, pas directement à un dépôt. Une page permet
+de rattacher l'image envoyée à un dépôt, ce que l'on fera dans un deuxième
+temps.
+
+Afin de pouvoir envoyer une image nous-même, nous devons nous connecter au
+registre :
+
+<div lang="en-US">
+```
+docker login localhost:3000
+```
+</div>
+
+::::: {.question}
+
+#### N'a-t-on pas besoin d'un certificat TLS pour utiliser un registre Docker ? {-}
+\
+
+Ceci est possible exclusivement parce que le registre `localhost` est considéré
+non-sûr par défaut. C'est-à-dire qu'il n'a pas besoin de certificat TLS valide
+sur sa connexion HTTP pour être utilisé.\
+
+Si on avait dû utiliser un autre nom de domaine, il aurait fallu [l'ajouter à
+la liste des
+`insecure-registries`](https://docs.docker.com/registry/insecure/).
+
+:::::

tutorial/devops/publish-docker-intro-end.md

@@ -0,0 +1,3 @@
+À l'inverse, `youp0m` est à la fois un programme que l'on peut télécharger et
+un service qu'il faut déployer pour le mettre à jour. Afin de simplifier son
+déploiement en production, nous utiliserons une image Docker.

tutorial/devops/publish-docker-publish.md

@@ -0,0 +1,18 @@
+#### Publication de l'image \
+
+Une fois le registre testé, il ne nous reste plus qu'à ajouter une étape de
+publication de l'image Docker. Cela se fait au moyen du plugin suivant :\
+<http://plugins.drone.io/drone-plugins/drone-docker/>.
+
+::::: {.exercice}
+
+Continuons d'éditer le fichier `.drone.yml` du dépôt pour faire générer à Drone
+l'image Docker, et la publier.
+
+Attention dans Drone, le domaine à utiliser pour contacter Gitea (et donc le
+registre), n'est pas `localhost`, mais `gitea`. Comme notre registre n'a pas de
+certificat TLS pour utiliser `https`, il est nécessaire de définir l'option
+`insecure` à `true`. Utilisez les *secrets* de Drone pour stocker le nom
+d'utilisateur et le mot de passe d'accès au registre.
+
+:::::

tutorial/devops/publish-docker-test-gistre.md

@@ -0,0 +1,12 @@
+#### Test de l'image \
+
+Sur notre hôte, nous pouvons tester que l'image a bien été publiée grâce à la
+commande suivante :
+
+<div lang="en-US">
+```bash
+docker pull localhost:3000/${USER}/linky2influxdb
+```
+</div>
+
+Si une nouvelle image est bien récupérée du dépôt, bravo, vous avez réussi !

tutorial/devops/publish-docker-test.md

@@ -0,0 +1,13 @@
+#### Test de l'image \
+
+Sur notre hôte, nous pouvons tester que l'image a bien été publiée grâce à la
+commande suivante :
+
+<div lang="en-US">
+```bash
+docker pull localhost:3000/${USER}/youp0m
+docker run --rm -p 8080:8080 localhost:3000/${USER}/youp0m
+```
+</div>
+
+Si une nouvelle image est bien récupérée du dépôt, bravo, vous avez réussi !

tutorial/devops/publish-docker.md

@@ -6,109 +6,3 @@ compilation sera simplement publié et qu'il n'y a pas de service à mettre à
 jour ensuite (par exemple, dans le cas de Firefox ou de LibreOffice, une fois
 testés, les paquets sont envoyés sur le serveur d'où ils seront distribués ; il
 n'y a pas de service/docker à relancer).
-
-À l'inverse, `youp0m` est à la fois un programme que l'on peut télécharger et
-un service qu'il faut déployer pour le mettre à jour. Afin de simplifier son
-déploiement en production, nous utiliserons une image Docker.
-
-
-#### Fonctionnement du registre de Gitea \
-
-Gitea intègre un registre d'images Docker (depuis la version 1.17,
-mi-2022). Pour le moment, les images sont uniquement liées à un compte
-utilisateur ou à une organisation, pas directement à un dépôt. Une page permet
-de rattacher l'image envoyée à un dépôt, ce que l'on fera dans un deuxième
-temps.
-
-Afin de pouvoir envoyer une image nous-même, nous devons nous connecter au
-registre :
-
-<div lang="en-US">
-```
-docker login localhost:3000
-```
-</div>
-
-::::: {.question}
-
-#### N'a-t-on pas besoin d'un certificat TLS pour utiliser un registre Docker ? {-}
-\
-
-Ceci est possible exclusivement parce que le registre `localhost` est considéré
-non-sûr par défaut. C'est-à-dire qu'il n'a pas besoin de certificat TLS valide
-sur sa connexion HTTP pour être utilisé.\
-
-Si on avait dû utiliser un autre nom de domaine, il aurait fallu [l'ajouter à
-la liste des
-`insecure-registries`](https://docs.docker.com/registry/insecure/).
-
-:::::
-
-Nous pouvons ensuite envoyer une image pour s'assurer que tout va bien :
-
-<div lang="en-US">
-```bash
-docker build -t localhost:3000/${USER}/youp0m .
-docker push localhost:3000/${USER}/youp0m
-```
-</div>
-
-Rendez-vous ensuite sur la page <http://gitea:3000/${USER}/-/packages> pour
-attribuer l'image au dépôt `youp0m` (voir pour cela dans les paramètres de
-l'image).
-
-![Notre image `youp0m` dans Gitea !](gitea-packages.png){height=6cm}
-
-
-#### Publication de l'image \
-
-Une fois le registre testé, il ne nous reste plus qu'à ajouter une étape de
-publication de l'image Docker. Cela se fait au moyen du plugin suivant :\
-<http://plugins.drone.io/drone-plugins/drone-docker/>.
-
-::::: {.exercice}
-
-Continuons d'éditer le fichier `.drone.yml` du dépôt pour faire générer à Drone
-l'image Docker, et la publier.
-
-Attention dans Drone, le domaine à utiliser pour contacter Gitea (et donc le
-registre), n'est pas `localhost`, mais `gitea`. Comme notre registre n'a pas de
-certificat TLS pour utiliser `https`, il est nécessaire de définir l'option
-`insecure` à `true`. Utilisez les *secrets* de Drone pour stocker le nom
-d'utilisateur et le mot de passe d'accès au registre.
-
-:::::
-
-
-#### Test de l'image \
-
-Sur notre hôte, nous pouvons tester que l'image a bien été publiée grâce à la
-commande suivante :
-
-<div lang="en-US">
-```bash
-docker pull localhost:3000/${USER}/youp0m
-docker run --rm -p 8080:8080 localhost:3000/${USER}/youp0m
-```
-</div>
-
-Si une nouvelle image est bien récupérée du dépôt, bravo, vous avez réussi !
-
-
-### Vers le déploiement
-
-Nous n'allons pas faire le déploiement aujourd'hui, car nous n'avons pas
-d'environnement de production sur lequel déployer notre service.
-
-Vous pouvez néanmoins tester les plugins
-[`scp`](http://plugins.drone.io/appleboy/drone-scp/) ou
-[`ansible`](http://plugins.drone.io/drone-plugins/drone-ansible/) si vous avez
-une machine virtuelle avec une connexion SSH. N'hésitez pas à l'ajouter à votre
-`.droneci.yml`.
-
-
-### Profitons !
-
-Sonarqube a repéré quelques erreurs dans le code de `youp0m`, essayez de les
-corriger, et publiez une nouvelle version, pour observer toute la chaîne en
-action !

tutorial/devops/run-gistre.md

@@ -1,5 +1,3 @@
-\newpage
-
 ## Lancement du module sur la machine cible
 
 Mettons de côté le déploiement continu, pour nous concentrer sur la manière
@@ -25,9 +23,9 @@ l'entrée correspondante dans `/dev`.
 
 L'objectif est d'établir la méthode qui sera la plus efficace pour
 Électropcool, car elle devra sans doute demander à chacune des équipes de
-réaliser le packaging des modules qu'elles maintiennent. Il faut pour cela en
+réaliser le packaging des modules qu'elles maintiennent. Il faut pour cela
-tester plusieurs. Certaines peuvent sans doute déjà être éliminées car
+tester plusieurs solutions. Certaines peuvent sans doute déjà être éliminées car
-inadaptés, c'est à vous de déterminer parmi les technologies d'empacketages
+inadaptées, c'est à vous de déterminer parmi les technologies d'empacketages
 proposées, et celles que vous connaissez, lesquelles vous écartez d'emblée,
 lesquelles vous souhaitez garder pour explorer davantage, et enfin laquelle
 retient votre attention.
@@ -59,7 +57,7 @@ accès au périphérique correspondant au compteur.
 
 <div lang="en-US">
 ```
-login_x-TP5/docker/run.sh
+./docker/run.sh
 ```
 </div>
 
@@ -78,7 +76,7 @@ au moins un script pour lancer notre conteneur, s'il est différent d'un
 
 <div lang="en-US">
 ```
-login_x-TP5/lxc/run.sh
+./lxc/run.sh
 ```
 </div>
 
@@ -87,8 +85,8 @@ permettant de créer le conteneur LXC, ainsi qu'un exemple de configuration :
 
 <div lang="en-US">
 ```
-login_x-TP5/linky2influx/lxc-scripts/template.sh
+./linky2influx/lxc-scripts/template.sh
-login_x-TP5/linky2influx/lxc-scripts/sample.config
+./linky2influx/lxc-scripts/sample.config
 ```
 </div>
 
@@ -111,7 +109,7 @@ il pourra être intégré au dépôt :
 
 <div lang="en-US">
 ```
-login_x-TP5/linky2influx/systemd/linky2influx.nspawn
+./linky2influx/systemd/linky2influx.nspawn
 ```
 </div>
 
@@ -125,7 +123,7 @@ module via un paquet `.ipk` ou similaire en fonction de votre configuration.
 
 <div lang="en-US">
 ```
-login_x-TP5/meta-electropcool/recipes-support/linky2influx/linky2influx_9999.bb
+./meta-electropcool/recipes-support/linky2influx/linky2influx_9999.bb
 ```
 </div>
 
@@ -136,7 +134,7 @@ L'expression Nix correspondant au paquet pourra être intégré au dépôt
 
 <div lang="en-US">
 ```
-login_x-TP5/linky2influx/linky2influx.nix
+./linky2influx/linky2influx.nix
 ```
 </div>
 
@@ -150,7 +148,7 @@ Intégrez au dépôt le fichier de description, par exemple :
 
 <div lang="en-US">
 ```
-login_x-TP5/linky2influx/snapcraft.yaml
+./linky2influx/snapcraft.yaml
 ```
 </div>
 
@@ -159,7 +157,7 @@ votre conteneur :
 
 <div lang="en-US">
 ```
-login_x-TP5/{snap,flatpack}/run.sh
+./{snap,flatpack}/run.sh
 ```
 </div>
 
@@ -167,28 +165,25 @@ login_x-TP5/{snap,flatpack}/run.sh
 
 ### k3s
 
-Nous en apprendrons davantage sur Kubernetes au prochain TP, mais si vous
+Si vous connaissez déjà Kubernetes, vous pourriez vouloir écrire un *Chart*
-connaissez déjà, vous pourriez vouloir écrire un *Chart* Helm :
+Helm :
 
 <div lang="en-US">
 ```
-login_x-TP5/k3s/linky2influx.yaml
+./k3s/linky2influx.yaml
 ```
 </div>
 
-Inutile de vous casser la tête avec ça si vous ne connaissez pas !
 
+### *Votre solution ici*
 
-### Votre solution
+N'hésitez pas à apporter une autre solution originale, mais tout de même
-
+adaptée à l'objectif, que celles qui seraient listées ici.
-N'hésitez pas à apporter une autre solution originale, que celles qui seraient
-listées ici.
-
-<div lang="en-US">
-```
-login_x-TP5/k3s/linky2influx.yaml
-```
-</div>
 \
 
-À vous de jouer !
+Commençons par appréhender la publication d'image Docker, que nous maîtrisons
+plutôt bien normalement.
+
+
+\newpage
+## Déploiement via Docker

tutorial/devops/tools-drone-runner-cmd.md

@@ -1,6 +1,6 @@
 \
 
-Voici La ligne de commande permettant de démarrer notre agent :
+Voici la ligne de commande permettant de démarrer notre agent :
 
 <div lang="en-US">
 ```shell

tutorial/devops/what-gistre-see-srs.md

@@ -1,6 +1,6 @@
 ### Pour aller plus loin
 
-Le mouvement DevOps tend à utiliser mettre en avant la CI/CD, ce ne leur est
+Le mouvement DevOps tend à utiliser massivement la CI/CD, mais ce ne leur est
 évidemment pas exclusivement réservé. Toute entreprise ayant une méthodologie
 de développement saine dispose d'outils automatisés de construction et de
 tests.

tutorial/devops/what-gistre.md

@@ -42,8 +42,8 @@ qui arrive sur le marché.
 L'entreprise utilise principalement de nombreux équipements de la *Raspberry Pi
 fundation*, notamment les [Compute Module 3 et
 4](https://www.raspberrypi.com/products/compute-module-4/) et les [Raspberry Pi
-Zero W](https://www.raspberrypi.com/products/raspberry-pi-zero-w/), ainsi que
+Zero 2 W](https://www.raspberrypi.com/products/raspberry-pi-zero-2-w/), ainsi
-de nombreux PCB fait par l'entreprise, à base de micro-contrôleurs AVR,
+que de nombreux PCB fait par l'entreprise, à base de micro-contrôleurs AVR,
 lorsqu'il est nécessaire de pour s'interfacer avec des équipements
 propriétaires non prévu pour l'immotique.
 
@@ -51,11 +51,11 @@ Une grosse partie des travaux est donc réalisé avec un noyau Linux, sur du
 matériel très performant, pour de l'embarqué.
 \
 
-Tous les modules logiciels qui interagissent avec les capteurs sont
+Tous les modules logiciels qui interagissent avec les capteurs sont aujourd'hui
-aujourd'hui intégrés dans un système construit à l'aide de
+intégrés dans un système construit à l'aide de
-[`bitbake`](https://www.yoctoproject.org/). L'entreprise grossissant à vue d'œil,
+[`bitbake`](https://www.yoctoproject.org/). L'entreprise grossissant à vue
-il devient de plus en plus difficile de synchroniser les équipes concilier la
+d'œil, il devient de plus en plus difficile de synchroniser les équipes pour
-stabilité des *releases* avec le besoin de déployer de nouvelles
+concilier la stabilité des *releases* avec le besoin de déployer de nouvelles
 fonctionnalités chaque semaine.
 
 Vous avez été chargés d'étudier la meilleure façon de déployer les différents