tuto 2022 5, 6

tutorial/devops/devops.md

@@ -4,7 +4,7 @@ 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 :
+et les administrateurs système faisaient partie 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
@@ -17,17 +17,17 @@ utilisé sur un système à jour, et qu'il ne tourne pas en `root`), qu'à la
 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é.
+Une guerre faisait donc rage entre les développeurs qui ne comprenaient pas que
+les administrateurs système ne pouvaient pas maintenir autant de versions d'une
+bibliothèque qu'il y avait de services : par exemple dans le cas de plusieurs
+services en PHP, on pouvait leur demander de déployer des applications
+utilisant la version 5.6, et la 7.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
+langage, mais les administrateurs système 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é.\
@@ -58,10 +58,11 @@ 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
+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
 charges, les pannes, ...
 
+::::: {.warning}
 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
@@ -71,6 +72,7 @@ généralement assez difficile à vivre. Alors qu'au contraire, la mouvance DevO
 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
@@ -92,7 +94,7 @@ 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
+compilation que les administrateurs système vont déployer sans peine, lorsque
 les développeurs considéreront avoir atteint un jalon, une version stable.
 
 
@@ -100,7 +102,7 @@ les développeurs considéreront avoir atteint un jalon, une version stable.
 
 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.
+accessible aux utilisateurs finaux le service ou les objets.
 
 Dans le cas d'un programme à télécharger
 ([Python](https://buildbot.python.org/all/#/), VLC,
@@ -111,17 +113,19 @@ 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).\
+Parfois les deux seront à faire : à la fois publier un paquet ou un
+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 à
+jour leur service en ligne.\
 
 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.
+trafic.
 
 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
@@ -143,8 +147,8 @@ 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.
+Nous avons réalisé précédemment une partie collecte de métriques, avec nos
+conteneurs TICK. Nous n'allons donc pas nous en occuper aujourd'hui.
 \
 
 Notez tout de même qu'il y a deux grandes catégories de logiciels de
@@ -167,8 +171,8 @@ 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
+métriques (combien de clients actuellement connectés, combien de
+messages/transactions traités, ...). Ce sont autant d'informations que l'on peut
 faire remonter dans sa base de données de métriques.
 \
 
@@ -185,12 +189,11 @@ un service distribuable, qui est proche de la surcharge, acheter de l'espace de
 stockage supplémentaire auprès du fournisseur, ...
 \
 
-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 !).
+Enfin, citons 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 !).