New tuto 3 done

tutorial/devops/cd.md

@@ -0,0 +1,6 @@
+\newpage
+
+Déploiement
+===========
+
+TODO il faudrait pouvoir cliquer sur le bouton pour mettre à jour l'image docker qui tourne localement ? en passant par Ansible ?

tutorial/devops/ci.md

@@ -0,0 +1,118 @@
+\newpage
+
+Intégration continue
+====================
+
+Une fois Gitea et Drone installés et configurés, nous allons pouvoir rentré
+dans le vif du sujet : faire de l'intégration continue sur notre premier projet !
+
+## `youp0m`
+
+### Créez un dépôt pour `youp0m`
+
+Reprenez les travaux réalisés au TP précédent. Nous allons notamment avoir
+besoin du `Dockerfile` dans la section suivante.
+
+Après avoir créé (ou migré pour les plus malins !) le dépôt
+[`youp0m`](https://gitea.nemunai.re/nemunaire/youp0m), dans Drone,
+synchronisez les dépôts, puis activez la surveillance de `youp0m`.
+
+Vous allez devoir rédiger un fichier `.drone.yml`, que l'on placera à la
+racine du dépôt (celui qui existe déjà dans le dépôt pourra servir
+d'inspiration, mais il ne fonctionnera pas directement sur votre
+installation). C'est ce fichier qui sera traité par DroneCI pour savoir comment
+compiler et tester le projet.
+
+
+### Définir les étapes d'intégration
+
+Toutes les informations nécessaire à 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 vous avez
+écrit lors du TP précédent.
+
+Comittez puis pousser votre travail, dès qu'il sera reçu par Gitea, vous
+devriez voir l'interface de Drone lancer les étapes décrites dans le fichier.
+
+**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](../devops/drone-run.png){height=8cm}
+
+Lorsqu'apparaît enfin la ligne `git.nemunai.re/youp0m`, le projet est compilé !
+
+
+### Inspection qualité
+
+Nous n'avons pas encore de test à proprement parlé. Nous allons utiliser
+[Sonarqube](https://www.sonarqube.org/) pour faire une revue qualité du code !
+
+Tout d'abord, il faut lancer le conteneur Sonarqube (pensez à l'ajouter à votre
+playbook !) :
+
+<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>.
+
+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.
+
+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](../devops/tag-released.png){height=8cm}
+
+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 `youp0m` pour plusieurs architecture 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 `arm`, `arm64`, `mips`, ... nous pouvons générer
+les binaires correspondant à chaque architecture et système.
+
+Ajoutez au moins 2 autres architectures à votre fichier `.drone.yml`.

tutorial/devops/devops.md

@@ -0,0 +1,196 @@
+\newpage
+
+Le mouvement DevOps
+===================
+
+Jusqu'à récemment, et encore dans de nombreuses entreprises, les développeurs
+et les administrateurs systèmes faisaient partis de deux équipes différentes :
+les uns développant sur leurs machines avec les dernières bibliothèques,
+utilisant les derniers frameworks à la mode, sans se préoccuper de la sécurité
+(ils travaillent en `root` ou avec `sudo` ;)), tandis que les autres tentaient
+tant bien que mal de déployer ces services avec les contraintes opérationnelles
+en tête.\newline
+Ces contraintes : tant liées à la **sécurité** (il faut s'assurer
+qu'un service n'utilise pas une bibliothèque vulnérable par exemple, donc soit
+utilisé sur un système à jour, et qu'il ne tourne pas en `root`), qu'à la
+**disponibilité** (si le service est mal codé est contient beaucoup de fuites
+mémoire, il ne faut pas que les autres services présents sur la même machine en
+pâtissent).
+
+Une guerre faisait donc rage entre les développeurs qui ne comprennaient pas
+que les administrateurs système ne pouvaient pas maintenir autant de version
+d'une bibliothèque qu'il y avait de service : par exemple dans le cas de
+plusieurs services en PHP, on pouvait leur demander de déployer des
+applications utilisant la version 5.1, et la 5.2 pour d'autres, ... lorsqu'il y
+avait des incompatibilités mineures et plus personne pour s'occuper de la
+maintenance d'un vieux service toujours utilisé.
+
+Le même principe est aussi valable pour Python, Ruby, ... : les développeurs
+ont toujours eu tendance à vouloir utiliser les dernières améliorations d'un
+langage, mais les administrateurs systèmes n'ont alors pas de paquets stables
+dans la distribution. En effet, les distributions stables telles que Debian,
+RedHat ou CentOS ont des cycles de vie assez long et se concentrent plus sur la
+stabilité.\newline
+Cette stabilité est obtenue grâce à l'utilisation de versions éprouvées des
+langages et des bibliothèques, qui assurent un temps de maintenance et de
+recherche de bugs réduit aux équipes opérationnelles. Si un projet fonctionne
+bien avec une version donnée d'une de ces distributions, on peut être assez
+confiant sur le fait que ce sera toujours le cas (du moins tant que la
+distribution assure le support de sa version).
+\newline
+
+Le but du DevOps est donc de retrouver une certaine fluidité entre le
+développement et l'exploitation. Il s'agit d'un mouvement qui vise à ce que les
+développeurs, sans avoir à gérer au quotidien la maintenance des serveurs de
+production, soient davantage impliqués dans les opérations de déploiement. Cela
+passe notamment par la prise en compte de l'environnement de déploiement dès la
+phase de conception du projet, puis dès les premiers développements, des tests
+automatisés sont réalisés directement dans un environnement proche de la
+production.
+
+Il en résulte moins de friction entre les deux équipes. Les développeurs étant
+par ailleurs amenés à écrire des recettes de déploiement, tels que des
+playbooks Ansible ou bien encore des conteneurs Docker.
+\newline
+
+Chez Google (et d'autres entreprises qui ont depuis repris l'idée), des équipes
+sont chargées de développer la fiabilité des systèmes d'information de
+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 des 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
+charges, les pannes, ...
+
+Attention par contre aux entreprises qui recrutent un profil DevOps, car cela a
+autant de sens que recruter un développeur Scrum ou un développeur cycle en V :
+DevOps est une méthodologie. Les entreprises qui recrutent un DevOps
+recherchent généralement quelqu'un qui fera à la fois du développement logiciel
+d'un côté et de l'administration système de l'autre : une situation
+généralement assez difficile à vivre. Alors qu'au contraire, la mouvance DevOps
+doit être prise au sérieux par l'ensemble des développeurs. Lors d'un entretien
+d'embauche pour ce genre de poste, assurez-vous bien de ne pas être le seul à
+faire du DevOps.
+
+
+## Intégration continue
+
+L'**intégration continue** est la première brique à mettre en place : le but
+est de compiler automatiquement chaque commit dans un environnement proche de
+celui de production, puis de lancer les suites de tests du logiciel.
+
+Cela permet de détecter les problèmes au plus tôt dans le cycle de
+développement, mais cela permet également d'améliorer la qualité du code sur le
+long terme, car on peut y ajouter facilement des outils qui vont se charger
+automatiquement de réaliser des analyses : cela peut aller de la couverture des
+tests, à de l'analyse statique ou dynamique de binaire, en passant par la
+recherche de vulnérabilités ou de mauvaises pratiques de programmation.
+
+À la fin du processus, il est courant d'exporter les produits de compilation
+(tarballs, paquets, ISO, conteneurs, ...) ainsi que les journaux et rapports
+vers un dossier accessible. Cela permet ainsi aux développeurs de voir les
+problèmes et de pousser les analyses avec leurs propres outils.
+
+Sans déploiement continu (la section suivante), c'est également ces produits de
+compilation que les administrateurs systèmes vont déployer sans peine, lorsque
+les développeurs considéreront avoir atteint un jalon, une version stable.
+
+
+## Déploiement continu
+
+Une fois tous les tests passés et les objets produits (on parle d'*artifact* ou
+d'*assets*), il est possible de déclencher un déploiement : il s'agit de rendre
+accessible aux utilisateurs finaux le services ou les objets.
+
+Dans le cas d'un programme à télécharger
+([Python](https://buildbot.python.org/all/#/), VLC,
+[MariaDB](https://buildbot.askmonty.org/buildbot/), ...), on va placer les
+paquets sur le site internet, éventuellement mettre à jour un fichier pointant
+vers la dernière version (pour que les utilisateurs aient la notifications).
+
+Ou bien dans le cas d'un service en ligne (GitHub, Netflix, GMail, ...), il
+s'agira de mettre à jour le service.
+
+Parfois les deux seront à faire : à la fois publier un paquet ou un conteneur
+et mettre à jour un service en ligne : [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).\newline
+
+Il existe pour cela de très nombreuses stratégies : lorsque l'on n'a pas
+beaucoup de trafic ni beaucoup de machines, on peut simplement éteindre
+l'ancien service et démarrer le nouveau, si ça prend quelques millisecondes en
+étant automatisé, cela peut être suffisant compte tenu du faible
+traffic.
+
+Lorsque l'on a un trafic élevé, de nombreux clients et donc que le service est
+réparti sur plusieurs machines, on ne peut pas se contenter de tout éteindre et
+de tout rallumer. Déjà parce que trop de visiteurs vont se retrouver avec des
+pages d'erreur, et aussi parce qu'en cas de bug logiciel qui n'aurait pas été
+vu malgré les étapes précédentes, cela pourrait créer une situation
+catastrophique (imaginez qu'on ne puisse plus valider une commande sur Amazon à
+cause d'une ligne commentée par erreur !).\newline
+On va donc privilégier un déploiement progressif de la nouvelle version (que
+l'on va étendre sur plusieurs minutes, heures ou mêmes jours), en éteignant
+tour à tour les instances, et en veillant à ce que les métriques (voir la
+section suivante !) soient constantes.
+
+
+## Monitoring et supervision
+
+Une fois déployé, le service peut avoir des ratés, alors il convient de le
+surveiller afin d'être le plus proactif possible dans la résolution des
+problèmes. La pire situation est celle dans laquelle c'est un utilisateur qui
+nous informe d'un problème... (sur Twitter !?)
+
+Nous avons réalisé durant le précédent TP, une partie collecte de métriques,
+avec nos conteneurs TICK. Nous n'allons donc pas nous en occuper aujourd'hui.
+\newline
+
+Notez tout de même qu'il y a deux grandes catégories de logiciels de
+supervision :
+
+**Basée sur des états** comme Nagios, Zabbix, ... : ces logiciels vont
+simplement réaliser des séries de tests définis, à intervalles réguliers et
+contacter l'administrateur d'astreinte dès qu'un test ne passe plus de manière
+persistante.
+
+Il y a rarement beaucoup d'intelligence ou d'anticipation automatique dans ces
+outils.
+\newline
+
+**Basée sur les métriques** comme ELK, Prometheus, InfluxDB, ... : dans la
+stack TICK que nous avons mis en place au précédent TP, nous avions placé un
+agent sur la machine que nous souhaitions analyser. Outre les graphiques
+présenté dans Chronograf, le dernier outil que l'on n'avait pas configuré était
+Kapacitor, qui permet après avoir analysé les données, d'alerter en fonction
+d'une évolution.
+
+L'instrumentation d'une application est une bonne manière de faire remonter des
+métrique (combien de clients actuellement connectés, combien de
+messages/transactions traités, ...). Ce sont autant d'information que l'on peut
+faire remonter dans sa base de données de métriques.
+\newline
+
+La différence entre les deux techniques est que nagios va vous alerter à partir
+d'un certain seuil que vous aurez préalablement défini (s'il reste moins de 10%
+d'espace disque par exemple), tandis que Kapacitor va tenter d'interpréter les
+indicateurs (et donc vous alerter seulement si la courbe représentant l'espace
+disque disponible augmente de telle sorte qu'il ne reste plus que quelques
+heures avant d'être saturé).
+
+Sur la base de ces indicateurs, il est possible d'engager des opérations
+automatiques, comme par exemple la provision de nouvelles machines pour épauler
+un service distribuable, qui est proche de la surcharge, acheter de l'espace de
+stockage supplémentaire auprès du fournisseur, ...
+\newline
+
+Enfin, citons dans cette partie le [Chaos
+Monkey](https://fr.wikipedia.org/wiki/Chaos_Monkey), conçu par Netflix, qui est
+un programme qui va casser de manière aléatoire des éléments de l'environnement
+de production. Le but est de provoquer sciemment des pannes, des latences,
+... à n'importe quel niveau du produit, afin d'en tester (brulatement certes)
+sa résilience. Cela oblige les développeurs, les opérationnels et les
+architectes à concevoir des services hautement tolérant aux pannes, ce qui fait
+que le jour où une véritable panne survient, elle n'a aucun impact sur la
+production (enfin on espère !).

tutorial/devops/drone-youp0m.yml

@@ -0,0 +1,50 @@
+---
+kind: pipeline
+type: docker
+
+steps:
+  - name: code-analysis
+    image: aosapps/drone-sonar-plugin
+    settings:
+      sonar_host: http://sonarqube:9000
+      sonar_token:
+        from_secret: sonar_token
+
+  - name: build-amd64
+    image: golang:alpine
+    commands:
+      - apk --no-cache add git go-bindata
+      - go generate -v
+      - go get -v -d
+      - go build -v -o youp0m-linux-amd64
+    environment:
+      GOOS: linux
+      GOARCH: amd64
+
+  - name: build-arm64
+    image: golang:alpine
+    commands:
+      - go build -v -o youp0m-linux-arm64
+    environment:
+      GOOS: linux
+      GOARCH: arm64
+
+  - name: gitea_release
+    image: plugins/gitea-release
+    settings:
+      api_key:
+        from_secret: gitea_token
+      base_url: http://gitea:3000
+      files: youp0m-*
+      title: ${DRONE_TAG}
+    when:
+      event: tag
+
+  - name: publish docker image
+    image: plugins/docker
+    settings:
+      repo: registry:5000/youp0m
+      registry: registry:5000
+      insecure: true
+      auto_tag: true
+      auto_tag_suffix: ${DRONE_STAGE_OS}-${DRONE_STAGE_ARCH}

tutorial/devops/publish-docker.md

@@ -0,0 +1,94 @@
+\newpage
+
+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
+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 un ligne qu'il faut déployer pour mettre à jour facilement. Pour
+simplifier le déploiement, nous utilisons des images Docker. Il faut cependant
+les générer ...
+
+
+## Mise en place du registre
+
+*Si vous avez choisi Gitlab, vous pouvez utiliser directement le registre
+Docker intégré. Si vous utilisez Gitea, continuez cette section.*
+
+Afin de disposer de notre propre registre Docker sur lequel publier nos images,
+nous allons utiliser l'image de registre fournie par Docker. Elle se lance
+comme suit :
+
+<div lang="en-US">
+```bash
+docker run --rm -d --name registry --network droneci -p 5000:5000 registry:2
+```
+</div>
+
+Vous trouverez davantage d'informations
+[ici](https://docs.docker.com/registry/deploying/).
+
+Vous pouvez tester son bon fonctionnement 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>
+
+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
+besoin de certificat TLS sur sa connexion HTTP pour être utilisé.\newline
+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/).
+
+
+## Suite du déploiement
+
+Pour aujourd'hui, nous en resterons là pour le déploiement, car nous n'avons
+pas d'environnement de production sur lequel déployer notre service.
+
+Vous pouvez néamnoins 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/tools.md

@@ -0,0 +1,197 @@
+\newpage
+
+Les bons outils
+===============
+
+## Gestionnaire de versions
+
+Avant de pouvoir commencer notre aventure, il est nécessaire d'avoir un
+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
+([gitweb](https://git.wiki.kernel.org/index.php/Gitweb)), il y a de nombreux
+projets qui offrent davantage que le simple hébergement de dépôts. Vous pouvez
+voir sur GitHub notamment qu'il est possible d'attacher à un tag un [certain
+nombre de fichiers](https://github.com/docker/compose/releases/latest).
+
+On notera également que depuis le 1er septembre, GitHub propose un [registre
+Docker](https://github.blog/2020-09-01-introducing-github-container-registry/)
+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
+les récupérer manuellement, on a vite envie de pouvoir utiliser les outils
+standards directement : `docker pull ...`, `npm install ...`, ...
+
+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 la première partie du TP, 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
+[gitlab](https://gitlab.org/) ou une autre plate-forme, mais la suite du TP
+sera moins guidée pour eux).
+
+Nous allons utiliser l'image : <https://hub.docker.com/r/gitea/gitea>.
+
+Votre playbook resemblera à quelque chose comme ça :
+
+<div lang="en-US">
+```yaml
+- name: Launch gitea container
+  docker_container:
+    name: gitea
+    image: "gitea/gitea:{{ version }}"
+    volumes:
+      - /var/lib/gitea:/data
+      - /etc/localtime:/etc/localtime:ro
+      - /etc/timezone:/etc/timezone:ro
+    state: started
+    restart_policy: unless-stopped
+    memory: 1G
+    memory_swap: 1G
+    networks:
+      - name: gitea
+    published_ports:
+      - "2222:22"
+      - "3000:3000"
+    env:
+      RUN_MODE: "prod"
+      DOMAIN: "gitea"
+      SSH_DOMAIN: "gitea"
+      INSTALL_LOCK: "true"
+      SECRET_KEY: "{{ secret_key }}"
+```
+</div>
+
+Plus d'infos sur cette page : <https://docs.gitea.io/en-us/install-with-docker/>.
+
+Une fois le conteneur lancé, vous pouvez accéder à l'interface de gitea sur le
+port 3000 de votre machine (à moins que vous n'ayez opté pour un autre port).
+
+Vous pouvez ajouter un nouvel administrateur avec la commande suivante :
+
+<div lang="en-US">
+```bash
+docker exec gitea gitea admin user create --username "${USER}" --random-password \
+    --must-change-password=false --admin --email "${USER}@epita.fr"
+```
+</div>
+
+Notez le mot de passe généré pour [vous y connecter](http://localhost:3000/user/login).
+
+
+## Logiciel d'intégration continue
+
+De nombreuses solutions sont disponibles sur Internet, la plupart du temps
+gratuite pour les projets libres ([Travis CI](https://travis-ci.org/),
+[CircleCI](https://circleci.com/), ...).
+
+Mais nous allons déployer notre propre solution, en utilisant [Drone
+CI](https://drone.io/). C'est une solution d'intégration continue libre et
+moderne, conçue tout autour de Docker. Idéale pour nous !
+
+
+### Interface de contrôle et de dispatch des tâches
+
+La documentation du projet est extrêmement bien faite, suivons la marche à
+suivre pour [relier Gitea à
+Drone](https://docs.drone.io/server/provider/gitea/).
+
+L'URL de redirection sera dans notre cas : `http://droneci/login`.
+
+
+Voici à quoi pourrait ressemble le playbook Ansible démarrant notre conteneur
+Drone :
+
+<div lang="en-US">
+```yaml
+- name: Launch drone container
+  docker_container:
+    name: droneci
+    image: drone/drone:1
+    volumes:
+      - /var/lib/drone:/data
+    state: started
+    restart_policy: unless-stopped
+    memory: 1G
+    memory_swap: 1G
+    networks:
+      - name: drone
+      - name: gitea
+    published_ports:
+      - "80:80"
+    env:
+      DRONE_GITEA_CLIENT_ID: "{{ client.id }}"
+      DRONE_GITEA_CLIENT_SECRET: "{{ client.secret }}"
+      DRONE_GITEA_SERVER: "http://gitea:3000"
+      DRONE_RPC_SECRET: "{{ shared_secret }}"
+      DRONE_SERVER_HOST: "droneci"
+      DRONE_SERVER_PROTO: "http"
+```
+</div>
+
+Une fois lancé, rendez-vous sur l'interface de DroneCI : <http://droneci/>
+
+Vous serez automatiquement redirigé vers la page d'authentification de Gitea,
+puis vers l'autorisation OAuth d'accès de Drone à Gitea. Il faut bien
+évidemment valider cette demande, afin que Drone ait accès à nos dépôts.
+
+![OAuth Drone](../devops/oauth-drone.png){width=9cm}
+
+
+### *Runner*
+
+Notre conteneur `droneci` est uniquement une interface graphique qui va
+centraliser d'un côté les nouveaux commits à traiter, et de l'autre les
+résultats retournés par les agents chargés d'exécuter le code.
+
+Il serait impensable d'exécuter arbitrairement du code en parallèle d'une
+application privilégiée (ici, notre conteneur `droneci` a accès aux dépôts
+potentiellement privés de Gitea). Les agents qui sont amenés à traiter du code
+arbitraire s'exécutent à part et peuvent être de différents types. Dans le
+vocabulaire de Drone, on les appelle des ~~blade~~*runners*.
+
+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 !)
+
+Voici à quoi pourrait ressemble le playbook Ansible démarrant notre agent Drone :
+
+<div lang="en-US">
+```yaml
+- name: Launch drone runer
+  docker_container:
+    name: droneci-runner
+    image: "drone/drone-runner-docker:1"
+    volumes:
+      - /var/run/docker.sock:/var/run/docker.sock
+    state: started
+    restart_policy: unless-stopped
+    memory: 2G
+    memory_swap: 2G
+    networks:
+      - drone
+    env:
+      DRONE_RPC_PROTO: "http"
+      DRONE_RPC_HOST: "droneci"
+      DRONE_RPC_SECRET: "{{ shared_secret }}"
+      DRONE_RUNNER_CAPACITY: 2
+      DRONE_RUNNER_NAME: "my-runner"
+      DRONE_RUNNER_NETWORKS: "drone,gitea"
+```
+</div>
+
+
+L'environnement étant prêt, il ne reste plus qu'à nous lancer dans nos projets !

tutorial/devops/what.md

@@ -0,0 +1,63 @@
+\newpage
+
+But du TP
+=========
+
+Nous allons nous mettre aujourd'hui dans la peau d'une équipe DevOps et
+réaliser une solution complète de intégration/déploiement continu (le fameux
+CI/CD, pour *Continuous Integration* et *Continuous Delivery*).
+
+Le résultat attendu d'ici la fin du TP sera de mettre en place toutes les
+briques décrite dans la section précédente.
+\newline
+
+Nous allons commencer par automatiser le projet `youp0m`, plus simple, puis la
+plate-forme du FIC dans son ensemble, ce qui représente un petit challenge.
+
+Il est également attendu que vous rendiez un playbook Ansible, permettant de
+retrouver un environnement similaire. Car on se reservira de cette installation
+dans un prochain TP.
+\newline
+
+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
+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
+automatiquement l'image Docker assocciée. C'est à partir de cette image Docker
+que l'on va commencer à déployer automatiquement...
+
+
+## Préparer le terrain
+
+Tous les déploiements sont à faire sur votre machine en utilisant des
+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 :
+
+<div lang="en-US">
+```yaml
+- name: Create virli network
+  docker_network:
+    name: virli3
+```
+</div>
+
+
+Étant donné que votre machine ne dispose pas de domaine sur Internet et que
+l'on va essayer de simplifier au maximum l'installation, vous devriez ajouter
+cette ligne à votre fichier `/etc/hosts` :
+
+<div lang="en-US">
+```conf
+127.0.0.1   gitea droneci
+```
+</div>
+
+Cette ligne va vous permettre de résoudre les noms des conteneurs. Cela
+permettra aux requêtes OAuth de se faire de manière transparente pour vous
+lorsque vous serez dans votre navigateur.