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è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 !).