tutorial: Use pandoc recommanded newline
This commit is contained in:
parent
6194b507cc
commit
c9a08c6125
@ -89,7 +89,8 @@ en lecture seule et permettent de lire des statistiques instantanées sur le
|
||||
groupe ; tandis que d'autres sont des propriétés que nous pouvons modifier.
|
||||
|
||||
Nous pouvons consulter l'état de gel du groupe en affichant le contenu du
|
||||
fichier\newline `/sys/fs/cgroup/freezer/virli/freezer.state`.
|
||||
fichier\
|
||||
`/sys/fs/cgroup/freezer/virli/freezer.state`.
|
||||
|
||||
Pour plus d'information sur les différents fichiers présents dans ce *cgroup*,
|
||||
consultez
|
||||
|
@ -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
|
||||
|
@ -69,7 +69,7 @@ docker run --rm -p 8080:8080 localhost:5000/youp0m
|
||||
|
||||
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
|
||||
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
|
||||
`insecure-registries`](https://docs.docker.com/registry/insecure/).
|
||||
|
@ -9,7 +9,7 @@ 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.
|
||||
@ -17,7 +17,7 @@ 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
|
||||
|
Loading…
Reference in New Issue
Block a user