tutorial: Use pandoc recommanded newline

tutorial/devops/devops.md

@@ -9,7 +9,7 @@ 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
+en tête.\
 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
@@ -30,14 +30,14 @@ 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
+stabilité.\
 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
@@ -51,7 +51,7 @@ 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
@@ -115,7 +115,7 @@ 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
+[Gitlab](https://gitlab.com/gitlab-org/gitlab/-/pipelines).\
 
 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
@@ -129,7 +129,7 @@ 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
+cause d'une ligne commentée par erreur !).\
 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
@@ -145,7 +145,7 @@ 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 :
@@ -157,7 +157,7 @@ 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
@@ -170,7 +170,7 @@ 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%
@@ -183,7 +183,7 @@ 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