tuto5-srs: Done

tutorial/5/gitea-packages.png

@@ -0,0 +1 @@
+../devops/gitea-packages.png

tutorial/5/gitea-webhooks.png

@@ -0,0 +1 @@
+../devops/gitea-webhooks.png

tutorial/5/rendu-srs.md

@@ -3,51 +3,69 @@
 Rendu
 =====
 
-Modalités de rendu
+Est attendu d'ici le cours suivant :
-------------------
 
-En tant que personnes sensibilisées à la sécurité des échanges électroniques,
+- vos réponses à l'évaluation du cours,
-vous devrez m'envoyer vos rendus signés avec votre clef PGP.
+- tous les exercices de ce TP.
-
-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/13).
 
 
-Tarball
+Arborescence attendue
 -------
 
-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/
+./cicd-playbook/
-login_x-TP5/cicd-playbook/
+./cicd-playbook/cicd-setup.yml
-login_x-TP5/cicd-playbook/cicd-setup.yml
+./cicd-playbook/roles/...
-login_x-TP5/cicd-playbook/roles/...
+./youp0m/
-login_x-TP5/youp0m/
+./youp0m/.drone.yml
-login_x-TP5/youp0m/.drone.yml
+./youp0m/.ansible/...        # Pour ceux qui auraient fait le 5.4 optionnel
-login_x-TP5/youp0m/.ansible/...        # Pour ceux qui auraient fait le 5.4 optionnel
+./youp0m/Dockerfile
-login_x-TP5/youp0m/Dockerfile
+./youp0m/entrypoint.sh
-login_x-TP5/youp0m/entrypoint.sh
+./youp0m/.dockerignore
-login_x-TP5/youp0m/.dockerignore
+./youp0m/...
-login_x-TP5/youp0m/...
 ```
 </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 TP5
+sur `rendu5`, ... 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.md

@@ -3,26 +3,15 @@ title: Virtualisation légère -- TP n^o^ 5
 subtitle: DevOps, intégration et déploiement continu
 author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
 institute: EPITA
-date: Jeudi 4 novembre 2021
+date: Mercredi 16 novembre 2022
 abstract: |
   Durant ce nouveau TP, nous allons jouer les DevOps et déployer
   automatiquement des services !
 
   \vspace{1em}
 
-  À la demande de Nabih, ce TP a été raccourci
+  Les exercices de ce cours sont à rendre au plus tard le mardi 29
-
+  novembre 2022 à 23 h 42. Consultez les sections matérialisées par un
-  \vspace{1em}
+  bandeau jaunes et un engrenage pour plus d'informations sur les
-
+  éléments à rendre.
-  Tous les éléments de ce TP (exercices et projet) sont à rendre à
-  <virli@nemunai.re> au plus tard le **jeudi 18 novembre 2021 à 23 h
-  42**. Consultez la dernière section de chaque partie pour plus d'informations
-  sur les éléments à rendre. Et n'oubliez pas de répondre aux [questions de
-  cours](https://virli.nemunai.re/quiz/13).
-
-  En tant que personnes sensibilisées à la sécurité des échanges électroniques,
-  vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
-  [me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
-  votre clef et n'hésitez pas à [faire signer la
-  vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
 ...

tutorial/devops/ci.md

@@ -1,14 +1,17 @@
-\newpage
-
 ## Intégration continue
 
 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 !
 
+L'idée est qu'à chaque nouveau *commit* envoyé sur le dépôt, Drone fasse une
+série de tests, le compile et publie les produits de compilation.
+
 ### Créez un dépôt pour `youp0m`
 
-Reprenez les travaux déjà réalisés : nous allons notamment avoir besoin du
+::::: {.exercice}
-`Dockerfile` que nous avons réalisé pour ce projet `youp0m`.
+
+Reprenons les travaux déjà réalisés : nous allons notamment avoir besoin du
+`Dockerfile` que nous avons réalisé pour le projet `youp0m`.
 
 Après avoir créé (ou migré pour les plus malins !) le dépôt
 `youp0m`[^urlyoup0m] dans gitea, synchronisez les dépôts dans Drone, puis
@@ -16,6 +19,33 @@ 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.
@@ -30,9 +60,6 @@ installation.
 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/>.
@@ -40,9 +67,18 @@ trouvent dans l'excellente documentation du projet :\
 Les étapes sont sensiblement les mêmes que dans le `Dockerfile` que nous avons
 écrit précédemment.
 
-Committons puis poussons notre travail. Dès qu'il sera reçu par Gitea, nous
+::::: {.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}
@@ -58,7 +94,7 @@ Lorsqu'apparaît enfin la ligne `git.nemunai.re/youp0m`, le projet est compilé
 
 ### Inspection qualité
 
-Nous n'avons pas encore de test à proprement parler. Nous allons utiliser
+`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 :
@@ -72,14 +108,18 @@ docker run --rm -d --name sonarqube --network drone -p 9000:9000 sonarqube
 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
+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.
 
@@ -90,6 +130,8 @@ 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.
 
@@ -98,13 +140,22 @@ 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 !
+::::: {.warning}
 
-![Binaire publié automatiquement sur Gitea](tag-released.png){height=8cm}
+#### Attention à ne pas stocker votre clef d'API dans le fichier YAML ! {-}
+\
 
-::::: {.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.
+
+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/devops.md

@@ -59,7 +59,7 @@ production. Ce sont les équipes SRE, pour Site Reliability Engineering. On
 confie alors complètement la responsabilité de l'environnement de production
 aux développeurs qui sont chargés de l'automatiser. Au-delà de l'automatisation
 des déploiements de services, il s'agit ici de développer des mécanismes
-permettant au système de réagir face aux situations telles que les montées en
+permettant aux systèmes de réagir face aux situations telles que les montées en
 charges, les pannes, ...
 
 ::::: {.warning}
@@ -118,7 +118,7 @@ conteneur et mettre à jour un service en ligne : par exemple, [le
 serveur Synapse](https://buildkite.com/matrix-dot-org/synapse) du
 protocole de messagerie Matrix ou encore
 [Gitlab](https://gitlab.com/gitlab-org/gitlab/-/pipelines), tous deux
-publient des paquets à destination de leurs communautés, et mettent à
+publient des paquets à destination de leurs communautés, et ils mettent à
 jour leur service en ligne.\
 
 Il existe pour cela de très nombreuses stratégies : lorsque l'on n'a pas

tutorial/devops/publish-docker.md

@@ -1,7 +1,4 @@
-\newpage
+### Publier une image Docker
-
-Publier une image Docker
-========================
 
 Toutes les tâches de publication peuvent s'assimiler à des tâches de
 déploiement continu. C'est en particulier le cas lorsque le produit de
@@ -11,79 +8,97 @@ testés, les paquets sont envoyés sur le serveur d'où ils seront distribués
 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. Pour simplifier le
+un service qu'il faut déployer pour le mettre à jour. Afin de simplifier son
-déploiement, nous utilisons une image Docker. Il faut cependant la générer ...
+déploiement en production, nous utiliserons une image Docker.
 
 
-## Mise en place du registre
+#### Fonctionnement du registre de Gitea \
 
-::::: {.more}
+Gitea intègre un registre d'images Docker (depuis la version 1.17,
-Si vous avez choisi Gitlab, vous pouvez utiliser directement le registre
+mi-2022). Pour le moment, les images sont uniquement liées à un compte
-Docker intégré. Si vous utilisez Gitea, continuez cette section.
+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 disposer de notre propre registre Docker sur lequel publier nos images,
+Afin de pouvoir envoyer une image nous-même, nous devons nous connecter au
-nous allons utiliser l'image de registre fournie par Docker. Elle se lance
+registre :
-comme suit :
 
 <div lang="en-US">
-```bash
-docker run --rm -d --name registry --network droneci -p 5000:5000 \
-    registry:2
 ```
-</div>
+docker login localhost:3000
-
-Vous trouverez davantage d'informations pour le déploiement
-[ici](https://docs.docker.com/registry/deploying/).
-
-Nous pouvons tester le bon fonctionnement de notre registre avec la commande
-suivante :
-
-<div lang="en-US">
-```bash
-42sh$ curl http://localhost:5000/v2/
-{}
-```
-</div>
-
-
-## Publication de l'image
-
-Une fois le registre démarré, 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/>.
-
-Sans plus de configuration, le registre que nous avons démarré
-n'attend pas d'authentification. Et comme il n'a pas de certificat TLS
-pour utiliser `https`, il est nécessaire de définir l'option
-`insecure` à `true`.
-
-
-## Test de l'image
-
-Sur l'hôte, nous pouvons tester que l'image a bien été publiée grâce à la
-commande suivante :
-
-<div lang="en-US">
-```bash
-docker run --rm -p 8080:8080 localhost:5000/youp0m
 ```
 </div>
 
 ::::: {.question}
-On notera que ceci est possible exclusivement parce que le registre
+
-`localhost:5000` est considéré non-sûr par défaut. C'est-à-dire qu'il n'a pas
+#### N'a-t-on pas besoin d'un certificat TLS pour utiliser un registre Docker ? {-}
-besoin de certificat TLS 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
+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.
+
 :::::
 
 
-## Suite du déploiement
+#### Test de l'image \
 
-Nous en resterons là pour le déploiement, car nous n'avons
+Sur notre hôte, nous pouvons tester que l'image a bien été publiée grâce à la
-pas d'environnement de production sur lequel déployer notre service.
+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
@@ -92,7 +107,7 @@ une machine virtuelle avec une connexion SSH. N'hésitez pas à l'ajouter à vot
 `.droneci.yml`.
 
 
-## Profitons !
+### 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

tutorial/devops/tools-drone-runner.md

@@ -11,4 +11,4 @@ arbitraire s'exécutent à part et peuvent être de différents types.
 
 Nous allons lancer un *runner* Docker : il s'agit d'un type d'agent qui va
 exécuter nos étapes de compilation dans des conteneurs Docker (oui, quand on
-disait que Drone était conçu autour de Docker, c'était pas pour rire !)
+disait que Drone était conçu autour de Docker, ce n'était pas pour rire !)

tutorial/devops/tools-gitea-ansible.md

@@ -32,4 +32,5 @@ Votre playbook ressemblera à quelque chose comme ça :
 ```
 </div>
 
-Plus d'infos sur cette page : <https://docs.gitea.io/en-us/install-with-docker/>.
+Vous trouverez plus d'infos sur cette page :
+<https://docs.gitea.io/en-us/install-with-docker/>.

tutorial/devops/tools-gitea.md

@@ -6,17 +6,19 @@ gestionnaire de versions. Nous allons ici utiliser Git.
 
 ### Problématique du stockage des produits de compilation
 
-Outre les interfaces rudimentaires fournies au-dessus de Git
+Outre les interfaces rudimentaires fournies au-dessus de Git (gitweb[^GITWEB],
-([gitweb](https://git.wiki.kernel.org/index.php/Gitweb)), il y a de nombreux
+gitolite[^GITOLITE], ...), il y a de nombreux projets qui offrent davantage que
-projets qui offrent davantage que le simple hébergement de dépôts. Vous pouvez
+le simple hébergement de dépôts. Vous pouvez voir sur GitHub notamment qu'il
-voir sur GitHub notamment qu'il est possible d'attacher à un tag un [certain
+est possible d'attacher à un tag un [certain nombre de
-nombre de fichiers](https://github.com/docker/compose/releases/latest).
+fichiers](https://github.com/docker/compose/releases/latest).
+Mais cela ne s'arrête pas là puisque [depuis 2020 pour
+GitHub](https://github.blog/2020-09-01-introducing-github-container-registry/)
+et [2016 pour
+GitLab](https://about.gitlab.com/blog/2016/05/23/gitlab-container-registry/),
+ces gestionnaires de versions intégrent carrément un registre Docker.
 
-On notera également que depuis le 1er septembre, GitHub propose un [registre
+[^GITWEB]: <https://git.wiki.kernel.org/index.php/Gitweb>
-Docker](https://github.blog/2020-09-01-introducing-github-container-registry/)
+[^GITOLITE]: <https://github.com/sitaramc/gitolite>
-que l'on peut lier avec ses dépôts. Une fonctionnalité que GitLab propose
-[depuis
-2016](https://about.gitlab.com/blog/2016/05/23/gitlab-container-registry/).
 
 En effet, la problématique du stockage des produits de compilation est
 vaste. Si au début on peut se satisfaire d'un simple serveur web/FTP/SSH pour
@@ -27,17 +29,11 @@ Des programmes et services se sont spécialisés là-dedans, citons notamment
 [Artifactory](https://jfrog.com/artifactory/) ou [Nexus
 Repository](https://www.sonatype.com/nexus/repository-oss) et bien d'autres.
 
-Dans un premier temps, nous allons nous contenter de publier un binaire associé
-à un tag de notre projet.
-
 
 ### Installation et configuration
 
 Aller c'est parti ! première chose à faire : installer et configurer
-[Gitea](https://gitea.io/) (ceux qui le souhaitent peuvent choisir
+[Gitea](https://gitea.io/).
-[gitlab](https://gitlab.org/) ou une autre plate-forme, mais la suite sera
-moins guidée).
 
 Nous allons utiliser l'image :
-[`gitea/gitea`](https://hub.docker.com/r/gitea/gitea) (ou
+[`gitea/gitea`](https://hub.docker.com/r/gitea/gitea).
-[`gitlab/gitlab-ce`](https://hub.docker.com/r/gitlab/gitlab-ce)).

tutorial/devops/tools.md

@@ -1 +0,0 @@
-\newpage

tutorial/devops/what-ansible.md

@@ -5,7 +5,8 @@ conteneurs Docker, qui seront regroupés au sein de réseaux
 Docker. Cela vous permettra d’utiliser la résolution de noms entre vos
 conteneurs.
 
-Dans votre playbook Ansible, vous pourrez procéder ainsi :
+Dans votre playbook Ansible, vous pourrez procéder ainsi (il s'agit d'un
+exemple qu'il faut comprendre et adapter par rapport à la suite) :
 
 <div lang="en-US">
 ```yaml

tutorial/devops/what-srs.md

@@ -11,22 +11,20 @@ Le résultat attendu d’ici la fin de cette partie sera de mettre en place tout
 les briques décrites dans la section précédente.
 \
 
-Nous allons commencer par automatiser le projet `youp0m`, plus simple, ~~puis
+Nous allons pour cela automatiser le projet `youp0m`.
-la plate-forme du FIC dans son ensemble, ce qui représente un petit challenge~~
-(merci Nabih !).
 
 Il est également attendu que vous rendiez un playbook Ansible, permettant de
-retrouver un environnement similaire. Car on pourra s’en resservir par la
+retrouver un environnement similaire. Car on pourra s’en resservir au prochain
-suite.
+cours.
 \
 
 Dans un premier temps, on voudra juste compiler notre projet, pour s’assurer
-que chaque commit poussé ne contient pas d’erreur de compilation, dans
+que chaque commit poussé ne contient pas d’erreur de compilation (dans
-l’environnement défini comme étant celui de production.  Ensuite, on ajoutera
+l’environnement défini comme étant celui de production).  Ensuite, on ajoutera
 quelques tests automatiques. Puis nous publierons automatiquement le binaire
 `youp0m` comme fichier associé à un tag au sein de l’interface web du
 gestionnaire de versions.
 
-Enfin, nous mettrons en place un registre Docker qui nous permettra de publier
+Enfin, `youp0m` produisant une image Docker, en plus de publier le binaire,
-automatiquement l’image Docker associée. C’est à partir de cette image Docker
+nous publierons l'image produite sur un registre Docker. C’est à partir de
-que l’on va commencer à déployer automatiquement...
+cette image Docker que l’on va commencer à déployer automatiquement...