virli/tutorial/devops/devops.md

\newpage

Le mouvement DevOps
===================

Jusqu'à récemment, et encore dans de nombreuses entreprises, les développeurs
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
tant bien que mal de déployer ces services avec les contraintes opérationnelles
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
**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 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è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é.\
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).
\

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.
\

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 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
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ème 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 service 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 notification).

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 : 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
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
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 !).\
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é 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
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.
\

**Basée sur les métriques** comme ELK, Prometheus, InfluxDB, ... : dans la
stack TICK que nous avons mis en place précédemment, nous avions placé un
agent sur la machine que nous souhaitions analyser. Outre les graphiques
présentés 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é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.
\

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, ...
\

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 (brutalement 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 !).