Vous êtes sur la page 1sur 103

CULTURE

DEV PS VOL •
O3

THERE IS A BETTER WAY


octo.com I blog.octo.com

PYRAMIDE DE DEVOPS :
À LA DÉCOUVERTE DES PRATIQUES DE QUALITÉ POUR UNE
INFRASTRUCTURE À L’ÉPREUVE DU TEMPS.
Pyramide de Devops :
à la découverte des
pratiques de qualité
pour une infrastructure
à l’épreuve du temps.

Jaloux des développeurs, nous souhaitons nous aussi


fiabiliser notre code et aspirer à l’excellence. Nous
devons copier sans honte leurs bonnes pratiques
et y appliquer les spécificités de la production.
Hautement disponible, scalable, observable et sécurisée :
l’infrastructure sera de qualité ou ne sera pas !
O C T O > C U LT U R E D E V O P S V O L . 3

INTRODUCTION À LA TRILOGIE

Les trois histoires de DevOps :


Organisation, Technologie et Qualité

Si vous êtes resté caché dans une caverne ces huit dernières années, vous êtes peut-être
passé à côté de la mouvance DevOps. Aujourd’hui, c’est un fait : le mot est sur toutes les
3 lèvres de notre milieu IT. Mais le terme est souvent galvaudé, chacun y allant de sa définition,
et il devient urgent de converger sur un concept partagé pour éviter que DevOps ne demeure
qu’un buzzword de plus. Ainsi, il est de notre devoir d’apporter une pierre à l’édifice de
cette convergence en vous livrant, en toute humilité, notre vision1 de DevOps : celle qui nous
passionne et qui berce notre quotidien.
Nous définissons DevOps comme un ensemble de pratiques qui visent à réduire le Time
to Market2 et à améliorer la qualité des produits logiciels, en réinventant la coopération
entre DEV et OPS. DevOps, c’est un modèle d’organisation, une culture, un assemblage
de processus, d’outils et de patterns3 d’architecture. Pour nous, c’est aussi un métier, une
passion. Et c’est la nature même de cette passion que nous désirons vous partager ici.
Nous avons pour habitude de regrouper ces pratiques DevOps en quatre piliers :
1. Culture, méthodes et organisation : on y retrouve les ingrédients secrets d’une organisation
IT équitable et durable.
2. Infrastructure as Code et les pratiques de qualité qui l’accompagnent : ce pilier détaille
les techniques d’automatisation du déploiement des applications et des infrastructures
(réseaux, stockages, serveurs). Il vise à appliquer au monde des opérations informatiques,
des outils et des pratiques issus du monde de l’ingénierie logicielle (gestion de versions du
code source, tests automatisés, répétabilité des opérations, etc.)
 atterns d’architecture Cloud Ready Apps4 : on regroupe ici les modèles d’architectures
3. P
techniques qui permettent de tirer parti du Cloud Computing pour offrir davantage de
résilience, de sécurité, d’exploitabilité et de scalabilité5 aux applications.
O C T O > C U LT U R E D E V O P S V O L . 3

4. P
 rocessus d’intégration et de déploiement continus : dans ce pilier, on industrialise la
production logicielle et son processus de validation de la qualité. En se reposant sur l’usine
d’intégration et de déploiement continus (CI/CD6), on automatise toutes les étapes de la
chaîne de production : tests fonctionnels, tests de performance, tests de sécurité, tests de
recette, déploiement de l’application sur un environnement, etc.
Quatre piliers donc, avec le choix éditorial de les traiter en trois volumes. C’est bien à
vous que cette trilogie s’adresse, vous qui êtes informaticien, développeur, administrateur
système, architecte, responsable des études ou de la production, CTO, CIO, CDO, CEO,
CxO, DevOps amateur ou confirmé, ou juste curieux. Vous y trouverez notre vision, certes
optimiste, de cette discipline sous trois angles complémentaires et indissociables :
• la culture et les modèles d’organisation équitables,
• la passion pour les technologies ouvertes,
• l’amour du travail de qualité et le software craftsmanship7 appliqué à DevOps.

 Notre vision est celle d’OCTO Technology et de sa Tribu OPS qui œuvre depuis plus de sept ans à la transformation DevOps de belles et grandes entreprises de
France et de Navarre.
 Time to Market est le temps moyen écoulé entre l’émergence d’une idée et sa commercialisation. Dans cet ouvrage, on utilisera cette notion dans un sens plus
large de Time to Value : le temps écoulé entre l’idée et sa mise à disposition pour l’utilisateur (dans notre contexte, il s’agira du temps de mise à disposition d’une
fonctionnalité logicielle).
 Un pattern est une solution répétable et réutilisable pour un problème identifié.
 Voir notre publication sur ces architectures : https://www.octo.com/fr/publications/23-cloud-ready-applications
 “La scalabilité (scalability, en anglais) désigne la capacité d’un logiciel à s’adapter à la montée en charge, en particulier sa capacité à maintenir ses fonctionnalités
et ses performances en cas de forte demande” - source : Wikipedia.
 CI/CD : Continuous Integration / Continuous Delivery.
 Voir le manifeste Software Craftsmanship : http://manifesto.softwarecraftsmanship.org/
O C T O > C U LT U R E D E V O P S V O L . 3

Voici donc le troisième volet de la trilogie. Il présente


notre vision de la qualité, adaptée aux contraintes
de la production. Nous avons choisi de le découper
en quatre parties représentant les différents acteurs
dans l’émergence des bonnes pratiques. Dans une
première partie, nous mettrons en relief ce que cela
signifie de “tester” une infrastructure et les limites que
5 nous y voyons. Nous présenterons ensuite comment
instaurer au sein d’une équipe une atmosphère
propice à l’amélioration continue qui devrait rappeler
l’ouvrage Culture Code à nos fidèles lecteurs. Enfin,
nous contextualiserons les pratiques DevOps au sein de
l’entreprise et les moyens de faire émerger une culture
de la qualité.

Asseyez-vous confortablement et préparez-vous pour


un voyage au pays des pyramides !
O C T O > C U LT U R E D E V O P S V O L . 3

S mmaire
O1 Introduction 07-08

O2 L’Individu 09-46
Automatisation 13
Infra as Code 15
TDD : de nouveaux outils de tests d’infrastructure 17
Idempotence comme indicateur de qualité 29
Limites et stratégie 35
Les outils de nos rêves 42

O3 L’Équipe 47-66
6
Collective Code Ownership 50
Clean Code 54
La nécessité d’une approche continue de la qualité 57
Pilotage de dette : Principes d’archi 65

O4 L’Entreprise 67-90
Continuous Delivery 70
Prod-awareness : ça veut dire quoi d’avoir bien fait son travail ? 76
Le rôle du management : accompagner plutôt qu’imposer 87

O5 Annexes 91-96
Exemple : plateforme de conteneurs 92

O6 Conclusion 97-100
O C T O > C U LT U R E D E V O P S V O L . 3

Introduction
Les changements de ces dernières années changements quelques années plus tôt
n’ont pas épargné le métier de sysadmin1. avec l’arrivée de l’agile. Ne pas réinventer
Pourtant, la nouveauté n’a pas été accueillie la roue étant l’un des principes de base de
à bras ouverts. Rien à faire. “La prod2” est l’informatique, l’infrastructure s’y est essayée
devenue quelque chose de changeant, là et a adopté les “bonnes” pratiques des “bons”
où régnait la stabilité de développeurs. Quel gain de
l’inamovible. Tout va bien, "Dans une temps ! Des décennies de
tant que l’on n’y touche pas.
organisation produit, try and fail applicables à ce
domaine !
7
Pour mesurer la qualité la qualité doit être
d’une production, le premier Grâce aux épaules de ces
indicateur qui vient en tête l’affaire de tous pionniers de l’agilité, le travail
est l’uptime . Pour garantir
3
et de toutes." d’évangélisation est plus facile.
que cet indicateur soit L’incompréhension autour du
élevé, la règle d’or consiste à ne pas toucher à DevOps, souvent réduit à l’automatisation,
quelque chose qui fonctionne. Ou en tout cas, rend néanmoins ce mouvement incomplet.
à y toucher le moins souvent. Et quand on y On peut (on doit !) faire de la qualité avec
touche, on s’attend à ce que cela se passe mal. l’automatisation. Mais si nos contraintes orga-
nisationnelles demeurent, comment livrer plus
C’est souvent de cette manière que les souvent ? Comment prendre en main la sécu-
infrastructures ont été gérées ces dernières rité de son application ? Si nous ne maîtrisons
années. Puis est arrivé le DevOps, avec cette pas les patterns liés à l’architecture, si nous
drôle d’idée selon laquelle il faut “livrer souvent” ; souhaitons livrer plus souvent et avec le moins
que notre infrastructure ne doit plus être d’interventions humaines possibles, comment
seulement solide, mais également élastique ; s'assurer que notre service sera toujours haute-
que l’on ne doit plus être chêne mais roseau. ment disponible ?
Heureusement pour les acteurs de la production,
les développeurs ont aussi eu à subir ces

 Sysadmin : contraction de “system” et de “administrator”. En Français “Adminsys”, pour "administrateur système". Personne en charge de gérer l’infrastructure
informatique au sein d’une organisation.  La production : environnement sur lequel évoluent les application à destination des utilisateurs finaux.  Uptime, ou
durée de fonctionnement, en français désigne le temps depuis lequel un système tourne sans interruption.
O C T O > C U LT U R E D E V O P S V O L . 3

Le coût de la non-qualité

UN COÛT UN COÛT UN COÛT


FINANCIER HUMAIN STRATÉGIQUE
8

Des évolutions Des développeurs Des difficultés


de plus en plus démotivés à répondre au
chères à et désengagés. "time to market".
produire.
Les meilleurs Une perte
Des clients démissionnent. de confiance
insatisfaits qui dans la marque.
ne payent plus.
Des risques
d’échec ou
de retard élevé.
O C T O > C U LT U R E D E V O P S V O L . 3

9 L’Individu
Thot : Doté d’une grande intelligence, il était considéré comme le dieu de la science, de
l’écriture, de l’art et de la sagesse. Il est l'inventeur de l'écriture, du langage et des chiffres.
O C T O > C U LT U R E D E V O P S V O L . 3

Depuis quelques années, les notre infra “bare metal” au tout virtuel. Exit les
développeurs ne travaillent plus progiciels, bonjour l’open-source. Nous avons
qu’en agile. Cela se passe bien, même pris le chemin de l’automatisation grâce
et nous avons bien moins de à des scripts qui orchestrent désormais nos
bugs en production. Une fois par mois, nous déploiements ! Même si nos environnements
devons livrer leur code sur les serveurs, pour ne sont pas totalement identiques, on s’en
intégrer les évolutions. approche.

En tant qu’administrateur système, j’ai été Malheureusement, ces travaux ont un coût :
attaché à l’une de ces équipes, pour les aider nous passons beaucoup de temps à faire
à développer des applications qui se sentiront évoluer notre infrastructure. À cela s’ajoutent
bien sur nos serveurs. Je suis également les soucis liés aux applications que l’on gère. La
en charge des déploiements et des scripts morning checklist occupe souvent le reste de
d’automatisation que je développe avec la journée : disques trop pleins, scripts qui ne
Ansible. Petit à petit, je leur marchent plus, conséquences
laisse la main sur ces scripts "Tout au bout de la imprévues de nos travaux…
11 et je pense que, dans
quelques mois, ils pourront chaîne de valeur, Revers de la médaille : le tra-
se passer de moi. l’agile a marqué un vail à fournir pour faire évoluer
notre infrastructure se com-
Je sais qu’ils aimeraient que tournant dans notre plexifie avec le temps. Notre
nous fassions des livraisons façon de travailler, base de code d’infrastructure
plus souvent, mais c’est est de plus en plus grosse et il
compliqué sur notre infra.
pour nous, les est difficile de tout maîtriser !
Quand nous déployons, “OPS”." Surtout avec les problèmes
nous devons rester tard habituels, comme les docu-
le soir, afin de nous assurer que le moins mentations obsolètes ou notre PIC (Plateforme
d’utilisateurs possible seront impactés en cas d'Intégration Continue) “constamment en carafe”.
de pépin. Je dis “en cas de pépin”, mais pour
être honnête, nous en avons la plupart du Heureusement, Jean est toujours capable de
temps. Souvent, nos scripts de déploiements nous dépanner. C’est lui qui est à l’origine
ne sont plus à jour, ou créent des effets de bord de toutes nos automatisations : d’abord
que nous n’avons pas su déceler plus tôt. J’ai en installant un Jenkins, afin de piloter nos
quand même l’impression que cela s’améliore scripts de monitoring, puis en automatisant
avec le temps... la création de notre infrastructure (via d’autres
scripts, en bash). Alors quand on a un souci,
Pendant leur transformation agile, nous n’avons il est fort probable qu’il ait la solution ! Par
pas chômé non plus de notre côté. Passage de contre, quand il n’est pas là...
O C T O > C U LT U R E D E V O P S V O L . 3

Il faut avouer que je me sens un peu “à la


ramasse” parmi les développeurs. J’ai
l’impression que de leur côté, quand ces
problèmes se posent, ils ont rapidement la
solution. Ils parlent de “software craftsmanship4”
et quand j’assiste à leurs points, leur base de
code semble vraiment clean et maîtrisée ! J’ai
longtemps pensé que ces principes, aussi
séduisants soient-ils, étaient pour beaucoup
des “buzz-words” ou tout simplement pas
applicables au contexte de l’infrastructure.

Après tout, bien souvent, nos tests consistent à


déployer une topologie complète d’infrastructure.
Chez nous, tout n’est pas automatisable.
Comment faire du test unitaire là-dessus ? De
12 même, mocker5 une API de cloud privé ? Cela
n’aurait tout simplement aucun sens…

 Le “software craftsmanship”, en français artisanat logiciel, est une approche du développement logiciel qui met en avant les pratiques de développement pour
réaliser des logiciels de qualité, arguant qu’il ne suffit pas qu’un logiciel fonctionne, il faut également qu’il soit bien conçu. Voir notre ouvrage Culture Code : https://
www.octo.com/fr/publications/20-culture-code.
 En programmation, on utilise des mocks afin de reproduire de manière simulée le comportement d’une dépendance.
O C T O > C U LT U R E D E V O P S V O L . 3

Automatisation

La première étape vers la qualité pour votre spécifiques à l’infrastructure qu’ils doivent gérer,
code d’infrastructure consiste à automatiser. dans un enchevêtrement d’appels et de contre-
Le succès de l’informatique vient de ces deux appels, se perdant dans une complexité
constats : les ordinateurs sont rapides et ne cyclomatique6 tendant vers l’infini. Mais ne
font des erreurs que très rarement. Un humain, soyons pas ingrats. Ces scripts, bien souvent,
pour une tâche algorithmique, a de grandes fonctionnent et répondent de façon pragmatique
chances d’être plus lent qu’un ordinateur et aux problématiques de l’équipe qui les a
d’avoir un taux d’erreur supérieur. En “scriptant” développés. Même s’ils sont le cauchemar de
13 des tâches récurrentes, l’opérateur d’infrastructure tout “archéologue de l’infra”, ils rendent bien
se prémunit contre les erreurs liées à des souvent service à ceux qui savent les utiliser.
actions manuelles et, au prix d’un investissement
initial, se dégage du temps pour d’autres tâches. Mais voilà, ceux qui les ont développés ont bien
souvent quitté l’entreprise depuis longtemps
Du fond de la mémoire de nos lecteurs aux et comprendre ce que font ces scripts devient
cheveux grisonnants ressurgissent les angoisses aussi compliqué que de trouver un développeur
des scripts d’exploitation en bash ou en Perl. Perl...
Ces scripts prennent en compte tous les cas

 Le nombre cyclomatique, la complexité cyclomatique ou la mesure de McCabe est un outil de métrologie logicielle développé par Thomas McCabe en 1976
pour mesurer la complexité d'un programme informatique. Cette mesure reflète le nombre de décisions d'un algorithme en comptabilisant le nombre de “chemins”
linéairement indépendants au travers d'un programme représenté sous la forme d'un graphe - source : Wikipedia.
O C T O > C U LT U R E D E V O P S V O L . 3

Les geeks et les tâches répétitives


TEMPS

Perd
NON-GEEK
Lance les scripts

GEEK
Automatise
à l’aide de scripts

14 Gagne

Trouve ça inefficace
Se moque en voyant
Fait manuellement la méthode compliquée
du geek

Fait manuellement

COMPLÉXITÉ DE LA TÂCHE
O C T O > C U LT U R E D E V O P S V O L . 3

Infra as Code
Un pas vers un code d’infra plus compréhensible Ce n’est plus des “scripts”, faits à la va-vite
peut venir de “l’Infrastructure as Code”. Pour sur le coin d’une table, mais du code choyé
l’expliquer simplement, il s’agit de passer et imbibé de software craftsmanship. Les
d’une approche impérative (ou algorithmique) modifications à apporter à ce code sont plus
à une approche déclarative7. Cela permet facilement atomiques et nos procédures de
de comprendre facilement l’état dans lequel qualité de code s’en accommodent donc plus
on souhaite arriver et ainsi ne plus se soucier facilement : clean code, refactoring, revue de
des détails d’implémentation mais plutôt du code… On peut ainsi appliquer nos méthodes
résultat final, le résultat voulu. Le code est d’intégration continue, de travail en équipe
15 intelligible et peut s’appréhender par briques et de suivi des changements. Le code, on le
logiques. Grâce à ces abstractions8, le code sait, doit porter la qualité de notre travail. Et la
d’infrastructure gagne ses lettres de noblesse. qualité, ça se teste !

APPROCHE IMPÉRATIVE APPROCHE DÉCLARATIVE


O C T O > C U LT U R E D E V O P S V O L . 3

Exemple de code utilisant Terraform

Approche impérative

$ gcloud compute \
firewall-rules create allow-http-from-lb \
--allow tcp:80 \
--source-tags ln_network \
--description "allow HTTP from lB_network"

Load-balancer

Approche Déclarative
16

ressource "google_compute_firewall" "http" {


name = "allow-http-from-lb"
:80 network = "${google_compute_network.lb_network.name}"
Web server
allow {
protocol = "tcp"
ports = ["80"]
}

source_tags = "lb_network"
}

 Voir la partie Approche déclarative vs. impérative de l’ouvrage Culture Devops, Vol.02
 Voir l’article Bonne nouvelle : L’Infra As Code c’est du code ! sur notre blog OCTO Talks : https://blog.octo.com/bonne-nouvelle-linfra-as-code-cest-du-code/
O C T O > C U LT U R E D E V O P S V O L . 3

TDD : de nouveaux outils


de tests d’infrastructure
À chaque fois que l’on évoque un nouveau précise d’un programme appelée “unité” ou
langage de programmation ou un nouveau “module”. Du fait de la difficulté de réduire
logiciel, une petite musique résonne inélucta- au maximum cette “unité”, les tests unitaires
blement dans nos cerveaux “piquousés“ aux sont à ce jour le parent pauvre de l’outillage
pratiques crafts : comment le tester ? L’Infrastructure de tests pour l’Infrastructure as Code (ou IaC).
as Code ne déroge pas à la règle.
Le seul client sérieux est rspec-puppet9 qui,
17 Du code testé est aujourd’hui un gage de comme son nom l’indique, offre un cadre de
qualité (encore faut-il que les tests aient une TU pour Puppet10. Il permet de bouchonner11
valeur). Posons les bases : tester pour avoir un très largement le moteur de Puppet, d’y
feedback sur le code écrit. Lancer une interface injecter des situations, d’invoquer la logique
et simuler un parcours utilisateur, est une forme que nous avons codée dans nos modules et
de test : un feedback est donné sur la manière d’appliquer un ensemble d’assertions pour
dont notre code fonctionne. valider leur comportement.

En tentant d’appliquer cette stratégie à Cette mécanique est rendue possible par
notre code d’infrastructure, deux tendances l’architecture de Puppet, du fait de son
se dégagent ; les tests unitaires et les tests fonctionnement de type purement déclaratif.
d'intégration en isolation. Le principe d’une exécution se décompose
suivant 4 étapes :
Tests unitaires
1. Collecte de faits (ou facts) : la machine sur
Un test unitaire (ou TU) est une procédure laquelle est installé l’agent Puppet effectue
(manuelle ou automatisée) permettant de un travail d’inventaire local à l’aide de l’outil
vérifier le bon fonctionnement d’une partie facter. Celui-ci capture des caractéristiques

 http://rspec-puppet.com/
 Puppet est un outil permettant d’automatiser la configuration de serveurs : https://puppet.com/fr
 Un bouchon est un bout de code qui permet de remplacer une dépendance, dans le cadre d’un test. Si les paramètres entrants sont identiques, il enverra toujours
le même résultat.
O C T O > C U LT U R E D E V O P S V O L . 3

de la machine : CPU, mémoire, interfaces à atteindre (type de ressources, états attendus)


réseau, adresses IP, disques, volumes, types de dans un catalogue complet.
système d’exploitation… De plus, il est possible
d’ajouter ses propres facts en étendant le 3. Application locale du catalogue : l’agent
comportement par défaut de facter. Les faits applique le catalogue.
sont ensuite envoyés au serveur Puppet : le 4. Remontée du rapport : l’agent remonte
Puppet master. au serveur le résultat de l’exécution de
2. Élaboration et envoi du catalogue : en l’application du catalogue.
appliquant l’IaC (modules, classes) définie En mode rspec-puppet, seule l’étape 2 est
par le développeur Puppet, le Puppet master réalisée localement, c’est à dire sans même
envoie à l’agent l’ensemble des états désirés solliciter un Puppet master.

18 3. APPLICATION
DU CHANGEMENT
L’agent exécute les actions
conformément au catalogue.

Puppet Agent

1. FAITS 2. CATALOGUE 4. RAPPORT


Le nœud collecte Le Puppet master utilise Le nœud retourne un
et renvoie ses faits les faits, le code et les rapport du résultat de
(caractéristiques). hieradata pour déterminer l’exécution du catalogue.
le catalogue des tâches
qui sont attendues de
l’agent.

Puppet Master

Code
Puppet
O C T O > C U LT U R E D E V O P S V O L . 3

Vérification
Set inputs du catalogue
RSPEC-PUPPET

Code
Puppet

CATALOG COMPILATION
Le Puppet master utilise les faits,
le code et les hieradata pour
compiler un catalogue qui définit
à l’agent l’état attendu.
Catalogue
19 Faits Puppet

En entrée, des facts virtuels sont injectés à En quelques lignes, cela consiste à coder
côté du code Puppet que l’on souhaite tester. d’abord le test exprimant le comportement
En sortie, des assertions s’appliquent sur le que l’on cherche à atteindre, avant de coder
catalogue généré. la fonction qui implémente ce comportement.

La capacité à réaliser ces opérations en Voici un exemple simple pour montrer


local combinée à un temps d’exécution concrètement ce principe. L’objectif : coder
très court (quelques secondes maximum) une classe Puppet qui installe deux paquets.
rendent ce processus tout à fait utilisable
dans une approche de type TDD (Test Driven • Étape 1
Development). Si vous n’avez jamais entendu Écrire le test en rspec-puppet et vérifier qu’il
parler de cette approche, pourquoi ne pas est bien en erreur. Puisque nous n’avons pas
aller faire un tour sur notre blog12 ? implémenté le code correspondant, c’est bien
le comportement que nous recherchons.

 Voir l’article TDD contre les montagnes russes sur notre blog OCTO Talks.
O C T O > C U LT U R E D E V O P S V O L . 3

# Code RSpec-Puppet
describe 'base_packages' do
context 'default params' do
let(:params) { {} }
it { is_expected.to compile }
it { is_expected.to contain_package('vim') }
it { is_expected.to contain_package('curl') }
end
end

Le test propose un scénario dans lequel nous invoquons la classe Puppet base_packages sans
paramètre. On s’attend à ce que le catalogue compile correctement (cela va sans dire, mais mérite
toujours d’être dit) et à ce que les paquets vim et curl soient installés.

20 Faisons une première implémentation vide de la classe base_packages :

# Code Puppet
class base_packages () {
}

Lançons une première fois rspec-puppet pour constater le résultat des choses :

base_packages
default params
should contain compile into a catalogue without dependency
cycles
should contain Package[vim] (FAILED - 1)
should contain Package[curl] (FAILED - 2)
Finished in 0.62943 seconds (files took 0.42828 seconds to load)
3 examples, 2 failures

Patatra ! Les lignes jaunes sont sans appel : le test ne passe pas. Plus exactement, la compilation
du catalogue a réussi (première ligne blanche), mais les deux assertions suivantes sont en échec.
Logique, le code n’a pas encore été implémenté dans la classe Puppet.
O C T O > C U LT U R E D E V O P S V O L . 3

• Étape 2

Implémenter le code pour faire passer les tests.

C’est à vous de jouer, vous pouvez implémenter la classe. Cet exemple, parfaitement trivial ne
demande que très peu d’énergie. Mais vous pouvez imaginer mettre beaucoup plus de logique
dans votre code.

# Code Puppet
class base_packages () {
package { 'vim':
ensure => present
}
package { 'curl' :
ensure => present
}
21 }

Vérifions que les tests passent alors en vert (soit blanc dans ce livre) :

base_packages
default params
should contain compile into a catalogue without dependency
cycles
should contain Package[vim]
should contain Package[curl]
Finished in 0.82657 seconds (files took 0.41641 seconds to load)
3 examples, 0 failures

Bravo, votre code est couvert d’un test, fantastique. Notez au passage que le feedback a mis un
peu moins d’une seconde pour revenir.
O C T O > C U LT U R E D E V O P S V O L . 3

Prise
de décision

Observation Conception
du résultat du changement

22

Déroulement
du test

La boucle de feedback représente le qu’amplifier la confiance que vous aurez en


quadriptyque “prise de décision” / “conception votre code.
du changement” / “déroulement du test” /
“observation du résultat”. Coder consistant Faire de petits changements atomiques vous
essentiellement à prendre une succession permettra de raccourcir chaque étape de votre
de décisions, il est impératif de travailler à boucle de feedback.
avoir une boucle de feedback la plus rapide La phase de “déroulement des tests” est celle
possible. sur laquelle la manière de concevoir vos tests
Travailler à rendre la boucle de feedback aura le plus d’impact.
plus rapide rendra vos tests utiles, et ne fera
O C T O > C U LT U R E D E V O P S V O L . 3

• Étape 3

Refactoring, action de modifier la structure d’un code sans en modifier le comportement. Pas
de refactoring sans tests “au vert” (blanc dans ce livre).

Le code fonctionne, il a un premier test. Nous pouvons à présent le refactorer pour le rendre plus
clair. Nous allons simplement factoriser l’appel à la ressource package en lui passant un tableau
en paramètre :

# Code Puppet
class base_packages () {
package { ['vim', 'curl'] :
ensure => present
}
}

23
Nous avons ici appliqué le principe DRY (Don’t Repeat Yourself). Vérifions à présent que les tests
sont toujours verts (blancs dans ce livre) :

base_packages
default params
should contain compile into a catalogue without dependency
cycles
should contain Package[vim]
should contain Package[curl]
Finished in 0.76547 seconds (files took 0.54689 seconds to load)
3 examples, 0 failures

• Étape 4

Same player, shoot again. Nous souhaiterions pouvoir invoquer notre classe en lui précisant en
paramètre (optionnel) une liste des paquets à installer :
O C T O > C U LT U R E D E V O P S V O L . 3

# Code RSpec-Puppet
describe 'base_packages' do
context 'default params' do
let(:params) { {} }
it { is_expected.to compile }
it { is_expected.to contain_package('vim') }
it { is_expected.to contain_package('curl') }
end
context 'override params' do
let(:params) { { 'packages' => ['wget'], } }
it { is_expected.to compile }
it { is_expected.to contain_package('wget') }
it { is_expected.to_not contain_package('vim') }
it { is_expected.to_not contain_package('curl') }
end
end

24

Deux tests sont désormais déclarés. Le premier garantit la non-régression du comportement par
défaut : invocation de la classe sans paramètre conduisant à l’installation de vim et curl. Le
second est introduit pour répondre à notre nouvelle exigence.

À nouveau, si l’on lance les tests à ce moment de l’histoire, la sanction est sans appel :

base_packages
default params
should contain compile into a catalogue without dependency
cycles
should contain Package[vim]
should contain Package[curl]
override params
should contain compile into a catalogue without dependency
cycles (FAILED - 1)
should contain Package[wget] (FAILED - 2)
should not contain Package[vim] (FAILED - 3)
should not contain Package[curl] (FAILED - 4)
Finished in 0.91724 seconds (files took 0.39541 seconds to load)
7 examples, 4 failures
O C T O > C U LT U R E D E V O P S V O L . 3

Reste alors à adapter le code Puppet pour faire passer tous les tests au vert. À nouveau, “grosse
difficulté” puisque l’utilisation d’une variable par défaut dans la déclaration d’une classe Puppet
fait partie des changements les plus triviaux :

# Code Puppet
class base_packages (
$packages = ['vim', 'curl'],
) {
package { $packages :
ensure => present,
}
}

Et voilà, les tests rspec-puppet nous confirment que la modification n’a pas déclenché un chaos
interstellaire :
25

base_packages
default params
should contain compile into a catalogue without dependency
cycles
should contain Package[vim]
should contain Package[curl]
override params
should contain compile into a catalogue without dependency
cycles
should contain Package[wget]
should not contain Package[vim]
should not contain Package[curl]
Finished in 0.93594 seconds (files took 0.46291 seconds to load)
7 examples, 0 failures

Même si l’exercice présenté peut paraître simpliste, la démarche n’en demeure pas moins
primordiale. Refactorer permet de se poser des questions de lisibilité, de standard de code, de
portabilité, de performance… Tout est permis désormais que l’on a un moyen simple de savoir si
nos modifications ne vont pas engendrer un dysfonctionnement : notre test.
O C T O > C U LT U R E D E V O P S V O L . 3

S’assurer que d’un SI. Le principe de fonctionnement repose


l’on implémente sur une fusée à 4 étages :

correctement des 1. Approvisionnement d’un environnement


cas de plus en plus minimaliste (serveurs, conteneurs, réseau,
stockage…).
complexes sans
casser les précédents 2. Application d’une portion d’IaC.

est un des premiers 3. Outil de tests effectuant des assertions sur


bénéfices du TDD. l’environnement déployé.

4. Nettoyage de l’environnement (destruction).

Plusieurs outils ont adopté ce principe de


fonctionnement : Test Kitchen13, Molecule14,
Beaker15. Leur force principale se trouve dans
Tests d’intégration en la versatilité de leur usage. Pour chacune des 4
26
isolation étapes, des connecteurs permettent d’adapter
le comportement souhaité :
Un test d’intégration est une procédure
permettant de valider la bonne intégration de Étapes 1 & 4 : Utilisation au choix d’AWS,
plusieures “unités” ou “modules”. Les tests Docker, VirtualBox…
unitaires ne dispensent pas de réaliser des
tests d’intégration. Étape 2 : Application de code d’infrastructure
(Ansible, Chef, Puppet, Saltstack…).
Dans ce modèle de tests d’intégration en
isolation, on ne parle pas de tests unitaires Étape 3 : Validation d’assertions (Bats, server-
puisqu’on veut tester le bon fonctionnement spec, TestInfra…).
entre plusieurs modules. Souvent il est
nécessaire d’avoir une machine (ou un
conteneur) où déployer une partie de notre
code. Effectivement, là où un test unitaire
sera “autosuffisant”, une infrastructure est
nécessaire à notre “code infra” pour y réaliser
des tests d’intégration. En revanche, leur portée
est limitée pour ne pas tirer toute la complexité

 Pour tester ses cookbook Chef : https://github.com/test-kitchen/test-kitchen.  Pour tester ses rôles Ansible : https://github.com/metacloud/molecule.  Pour
tester son code Puppet : https://github.com/puppetlabs/beaker.
O C T O > C U LT U R E D E V O P S V O L . 3

Ces tests n’étant par définition que sur une seule machine (“en isolation”), ils ne sont bien entendu pas
idéaux pour tester l’état d’un cluster réparti sur plusieurs machines. Prenons l’exemple de Zookeeper,
un outil de gestion de configuration pour systèmes distribués. En fonctionnement nominal, un des
nœuds Zookeeper est leader :

# sur le leader
Mode: leader

Les autres sont followers :

# sur tous les autres nœuds


Mode: follower

Avoir avec certitude une idée de l’état de santé du cluster demande donc d’avoir une vision
transverse sur toutes les machines du cluster car il n’est pas possible a priori de connaître l’identité
27 du nœud leader.

Tests d’intégration et TDD réalisation effective ou non de cette création


d’utilisateur.
Dans le monde de l’infrastructure, nous utilisons
principalement des outils d’abstraction (tels Ces tests que nous écrirons, et qui ressemblent
qu’Ansible, Puppet, Terraform…). Ces outils à des tests unitaires, n’en sont plus vraiment :
nous permettent souvent d’atteindre plus ils portent sur la manière dont nous utilisons
rapidement nos cibles, tout en nous reposant le module, dont nous l’implémentons. Si
sur une communauté active dans la détection la terminologie n’est qu’un détail, il est
et résolution de bugs. Ces outils sont la plupart néanmoins important de bien comprendre
du temps, couverts par des tests unitaires l’intention avec laquelle nous écrivons un test :
(sinon : fuyez !). Dans une démarche TDD nous
• Les tests écrits lors de notre phase de TDD,
en viendrons à tester la manière dont nous
nous permettent de documenter le résultat
les implémentons : nous testons l’intention.
attendu, de nous assurer des non-régressions,
Par exemple, si votre outil de configuration
de notre bonne utilisation de l’outil choisi…
management vous propose un module16 pour
créer un utilisateur, votre test portera sur la • Les tests d’intégration à proprement parler,

 “Modules” : terminologie que l’on retrouve dans Ansible (https://docs.ansible.com/ansible/2.7/modules/list_of_all_modules.html) ou encore dans TestInfra
(https://testinfra.readthedocs.io/en/latest/modules.html).
O C T O > C U LT U R E D E V O P S V O L . 3

portent sur un ensemble cohérent de fonctions • Une qualité accrue : en testant le code, non
successives. seulement vous diminuez le nombre de bugs,
mais vous assurez également la production
Le développement d’infrastructure, aujourd’hui, d’une documentation via votre code de test.
ressemble de plus en plus à un travail d’intégrateur Si l’on se demande quel résultat est censée
: nous prenons des outils existants, et nous produire telle ou telle partie, les tests, en
étendons leurs capacités afin de répondre au utilisant des cas et des valeurs concrètes, nous
besoin du client. Il est tout à fait normal – et apporterons une réponse plus fiable qu’un
rassurant – qu’une partie de nos efforts portent document Word ou PDF obsolète.
sur la qualité de ce travail.
• Un prérequis pour aller vers le déploiement
L’objectif est de réussir à découper le code continu : le déploiement continu n’est pas
de votre infrastructure de manière à rendre le Graal d’une organisation DevOps, mais il
testable des parties logiques de votre système y ressemble. Personne ne peut décemment
d’information. Là encore, no silver bullet17 : pas penser déployer en continu du code qui ne
d’outil miracle qui s'impose à vous. Comme vu serait pas suffisamment testé.
précédemment, à chaque outil son framework
28
de tests (Test Kitchen, Molecule, Beaker…)
auquel nous pourrons éventuellement en
ajouter d’autres comme Cucumber18, Gauntlt19,
voire TestCafé20 pour les plus énervés.

En intégrant des outils de tests pertinents dans


notre routine de développement (qu’elle soit
test driven, en intégration continue, ou autre),
nous nous offrons de nombreux avantages :

• Une boucle de feedback plus courte : on


n’attend pas de déployer sur un environnement
pour connaître les actions que notre code va
engendrer. Le développement se fait “par
petits pas”, ce qui permet de détecter plus
tôt les bugs, et surtout, de diminuer la portion
de code dans laquelle ils peuvent avoir été
introduits.

 https://fr.wikipedia.org/wiki/Pas_de_balle_en_argent.  Tests d’acceptance : https://cucumber.io/.  Tests d’acceptance pour les principes de sécurité : http://
gauntlt.org/.  Automatisation de navigation web : https://devexpress.github.io/testcafe/.
O C T O > C U LT U R E D E V O P S V O L . 3

Idempotence comme
indicateur de qualité
Dans le monde du code d’infrastructure, tester cette idempotence, comme par exemple,
l’idempotence est très recherchée. Une opération Molecule21. Nous allons regarder de quelle
est idempotente si elle donne toujours le manière utiliser Molecule pour vérifier l’idem-
même résultat quel que soit le nombre de fois potence de nos rôles Ansible. Par défaut, son
où elle est exécutée. C’est très important, car exécution se décompose comme ceci, en 11
nous cherchons à décrire un état souhaité. phases :
Certains frameworks de tests permettent de
29

--> Test matrix

default : nom du scénario


lint : linter de code
destroy : supprimer les instances en cours s’il y en a
dependency : installer les dépendances depuis les fichiers requirements
syntax : vérifier la syntax du playbook
create : créer l’environnement d’exécution (Docker, Vagrant…)
prepare : jouer le playbook “prepare.yml” (vide par défaut)
converge : lancer les tâches du rôle cible
idempotence : tester l’idempotence
side_effect22 : lancer des événements perturbateurs avant les tests
verify : lancer les tests unitaires
destroy : supprimer les instances en cours
O C T O > C U LT U R E D E V O P S V O L . 3

Sans entrer dans les détails du TDD avec lequel rôle Ansible (molecule init role --role-
vous êtes désormais familier, nous souhaitons name disable-weak-ssh-ciphers). Dans
réaliser un rôle pour désactiver les algorithmes notre configuration, l’environnement de tests
de chiffrement trop faibles23. Depuis le sera composé d’une image Docker, et les tests
répertoire “roles” de notre projet, initions notre réalisés via Testinfra24 :

# roles/disable-weak-ssh-ciphers/molecule/default/molecule.yml
---
dependency:
name: galaxy
driver:
name: docker
lint:
name: yamllint
platforms:
30 - name: disable-weak-ssh-ciphers
image: centos_with_ssh:latest
privileged: true
command: /sbin/init
provisioner:
name: ansible
options:
vv: "True"
lint:
name: ansible-lint
scenario:
name: default
verifier:
name: testinfra
options:
v: true
lint:
name: flake8

 The Wizard: Ansible, Molecule and Test Driven Development : https://blog.octo.com/en/the-wizard-ansible-molecule-and-test-driven-development/.


 The Wizard: Side effects : https://blog.octo.com/en/the-wizard-side-effects/.  Quelques sources : https://infosec.mozilla.org/guidelines/openssh ;
https://stribika.github.io/2015/01/04/secure-secure-shell.html ; https://en.wikipedia.org/wiki/Cipher_security_summary.  Testinfra permet de faire des assertions sur
l’état de vos serveurs : https://github.com/philpep/testinfra.
O C T O > C U LT U R E D E V O P S V O L . 3

Éditons désormais notre test, qui ressemblera à ceci :

#roles/disable-weak-ssh-ciphers/molecule/default/tests/test_integra
tion.py

import os

import testinfra.utils.ansible_runner

testinfra_hosts = testinfra.utils.ansible_runner.AnsibleRunner(
os.environ['MOLECULE_INVENTORY_FILE']).get_hosts('all')

def test_ssh_weak_ciphers(host):
cmd = host.run("ssh -o
Ciphers=3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc \
31
-o StrictHostKeyChecking=no \
-o UserKnownHostsFile=/dev/null \
localhost")
assert cmd.rc == 255
assert “no matching cipher found” in cmd.stderr

Ce code permet de demander à Testinfra d'exécuter une connexion SSH en utilisant des
algorithmes de chiffrement (“ciphers”) considérés comme “faibles”. Si aucun de ces algorithmes
de chiffrement n’est accepté par le serveur, alors nous estimons que le comportement est celui
recherché.

Sans le code Ansible associé, l'exécution de notre test d’intégration va échouer lors de la phase
de “verify” (la phase lors de laquelle seront exécutés les tests Testinfra) :
O C T O > C U LT U R E D E V O P S V O L . 3

> molecule converge


--> Test matrix

default
dependency
create
prepare
converge
[...]

> molecule verify


--> Test matrix

default
32
verify
[...]

============================ FAILURES ========================


____test_ssh_ciphers[ansible://disable-weak-ssh-ciphers] ____

host = <testinfra.host.Host object at 0x111c72690>

def test_ssh_ciphers(host):
cmd = host.run("ssh -o
Ciphers=3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc \
-o StrictHostKeyChecking=no \
-o UserKnownHostsFile=/dev/null \
> localhost")

tests/test_default.py:13:

[...]
==================== 1 failed in 1.27 seconds ================
O C T O > C U LT U R E D E V O P S V O L . 3

Le plus court chemin pour faire “passer ce test au vert” est d’ajouter les tâches suivantes :

# roles/disable-weak-ssh-ciphers/tasks/main.yml
---
- name: Enable strong ciphers only
lineinfile:
dest: /etc/ssh/sshd_config
regexp: "^#?Ciphers"
line: "Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.
com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr"
state: present

- name: Restart sshd


service:
name: sshd
state: restarted
33

Ansible va éditer le fichier de configuration du service SSH, afin de n’autoriser qu’une liste
restreinte d’algorithmes de chiffrement, et redémarrer ledit service, pour appliquer la nouvelle
configuration.

$ molecule verify
--> Test matrix

default
verify

--> Scenario: 'default'


--> Action: 'verify'

[...]
tests/test_default.py::test_ssh_ciphers[ansible://disable-weak-ssh
ciphers] PASSED [100%]

==================1 passed in 1.50 seconds =================


Verifier completed successfully.
O C T O > C U LT U R E D E V O P S V O L . 3

Nos tests passent ! Pourtant… Nous n’avons pas fini. Comme nous pouvons le vérifier en lançant
la commande “molecule idempotence”, notre code n’est pas idempotent. Effectivement,
notre seconde tâche, qui consiste à redémarrer le service sshd, se jouera à chaque fois, même
si la configuration n’a pas été changée. Nous ne sommes plus dans une approche qui permet de
définir un état, mais une approche impérative.

Ansible couvre ce cas grâce à la notion de “handlers25”, qui sont des opérations qui ne s’exécutent
qu’à la suite d’un changement. Voici notre code après refactoring :

# roles/disable-weak-ssh-ciphers/tasks/main.yml
---
- name: Enable strong ciphers only
lineinfile:
dest: /etc/ssh/sshd_config
regexp: "^#?Ciphers"
34 line: "Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh
.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr"
state: present
notify: Restart sshd

# roles/disable-weak-ssh-ciphers/handlers/main.yml
---
- name: Restart sshd
service:
name: sshd
state: restarted

Et voilà !

Lançons désormais la cinématique complète via :

$ molecule test --all


It works!

 https://docs.ansible.com/ansible/2.6/user_guide/playbooks_intro.html#handlers-running-operations-on-change
O C T O > C U LT U R E D E V O P S V O L . 3

Limites et stratégie
Ces dernières années, les pratiques et les outils le téléchargement de paquets logiciels,
autour de la testabilité du code d’infrastructure ou encore la communication avec les API
ont commencé à faire leur apparition sur distantes. Une part non-négligeable de nos
certains projets. Mais nous partons de très loin. tests nécessitent de démarrer un conteneur,
Le sujet est complexe, et avance à petits pas : une machine virtuelle...
mais il avance. Malgré tout, peu nombreuses
sont les infrastructures qui n’ont pas à rougir De nombreux sujets restent encore à
de leur couverture de tests. Et beaucoup “craquer”.
mentiraient s’ils se prétendaient sereins à Alors, en tant qu’OPS, comment choisir notre
35
chaque déploiement. Nous avons réussi la stratégie de tests ? En tant que dev, nous nous
plupart du temps à sécuriser les déploiements aidons de la pyramide des tests.
des applicatifs, mais nos socles d’infrastructure
sont encore trop fragiles.

Aujourd’hui, encore de nombreux cas d’usage


ne sont pas couverts par les outillages de tests,
dont voici quelques exemples :

• Les problèmes liés à un provider cloud.


Des disques qui ne sont pas dans le bon ordre,
une configuration d’OS exotique, une API trop
souvent en erreur… Attention à l’intention.

• Les problèmes liés à l’intégration d’outils. L’intention d’un test : la raison pour laquelle
Implémentation douteuse de standards, nous l’avons écrit.
utilisation de dépendances dépréciées…
Un test écrit lors d’un développement piloté
• La lenteur de la boucle de feedback. par le test unitaire, pour assurer une boucle
Encore une fois : cela s’est amélioré, mais de feedback rapide et qui fournira un harnais
nous sommes encore loin de quelque de non-régression, n’a pas la même intention
chose d’indolore. En cause, entre autre, qu’un test d’intégration (cf. tableau ci-contre).
O C T O > C U LT U R E D E V O P S V O L . 3

TEST UNITAIRE

INTENTION • Fournir sa boucle de feedback sur un périmètre de travail


restreint, pour permettre de piloter son développement par
les tests.
• Mitiger les régressions :
Changement de comportement de l’outil testé.
Évolution dans notre code qui met le test en échec.
• Documentation du code lié.

LIMITATIONS Peut faire doublon avec les tests mis en place par le
fournisseur de l’outil d’IaC.

TEST D'INTÉGRATION

INTENTION • Raccourcir la boucle de feedback.


• Documentation du résultat lié à une ou plusieurs étapes en
dépendances.
• Peut tester une topologie complexe (cluster…).

36
LIMITATIONS • Complexe à écrire et à maintenir.
• Plus long à exécuter qu’un test unitaire.

TEST END-TO-END

INTENTION • Assurer qu’un changement n’ait pas un effet de bord


quelque part dans la chaîne de bout en bout.
• Monitorer son service.

LIMITATIONS • Très complexe à écrire et à maintenir.


• Long à exécuter.
• Vision trop bout en bout : si le test échoue, cela peut venir
de très nombreux paramètres.
• L’investigation sera longue.
• Instabilité : en raison de leur complexité, certains tests end-
to-end auront tendance à bagoter (ça marche 99 fois sur
100, mais de temps en temps, on a un timeout).

D’autres tests enfin, viendront en complément :


Tests de sécurité, Tests de charge, Tests de résilience, Nightly builds...
O C T O > C U LT U R E D E V O P S V O L . 3

Pyramide
Comme décrite et portée dans de nombreuses tests unitaires sont majoritairement gérés par
publications OCTO (notamment Culture Code26 l’outil qui fournit l’abstraction (Ansible teste
et nos articles de blog27), la pyramide de tests son code Python, Terraform son code Go...). Ils
est construite comme ci-dessous. sont donc nombreux, mais nous n’en avons pas
la responsabilité. De plus, nous ne les lancerons que
Comment l’adapter à notre travail sur le code très rarement nous-même, voire jamais. En tant
d’infrastructure ? L’approche déclarative du qu’utilisateur de ces outils, nous nous devons
code d’infrastructure ne nous permet pas de de nous assurer de leur bonne intégration.
retranscrire directement cette pyramide. Les

PLUS CHER
PLUS LENT

37
Sécurité,
charge,
tests métier

Interface graphique,
de bout en bout,
tests fonctionnels

Intégration,
tests d’API

MOINS CHER
PLUS RAPIDE Tests
Plus d’investissement unitaires
du développeur

 https://www.octo.com/fr/publications/20-culture-code.  https://blog.octo.com/.
O C T O > C U LT U R E D E V O P S V O L . 3

PLUS CHER
PLUS LENT

38

MOINS CHER
PLUS RAPIDE
Plus d’investissement
du développeur

Mais au final, la dénomination des tests n’a Écrire un test, c’est faire un investissement en
que peu d’importance. Dans le cas de nos temps. Cet investissement se rentabilise un
développements de code d’infrastructure, peu plus à chaque fois que le test est lancé.
“l’espace-temps” est différent. Nos tests Un test dont le retour est rapide, sera indolore
d’infrastructure sont plus lents que les tests pour le développeur et donc lancé souvent.
applicatifs du fait que les assertions de nos tests Ainsi, il y a une corrélation très forte entre
doivent valider un état d’infrastructure plutôt ces deux facteurs. Plus un test est rapide
qu’un état en mémoire. Mais les outils cités (à développer et à exécuter), plus il sera
plus haut permettent de raccourcir la boucle exécuté souvent, plus il aura de la valeur.
de feedback en automatisant les assertions et
en isolant une partie de l’infrastructure.
O C T O > C U LT U R E D E V O P S V O L . 3

Accentuer l’effort sur les tests : est longue, plus la complexité à concevoir et
maintenir est élevée, moins vous devez investir
• qui sont rapides à exécuter, sur les tests.
• qui ne coûtent pas cher à
Pour vous aider à classifier les tests et les
développer ET à maintenir, placer dans la pyramide, posez-vous les
• qui expliquent/documentent questions suivantes28 :

pourquoi une ligne de code Qui exécute les tests ?


existe. Où sont-ils exécutés ?
Comment les tests sont-ils exécutés ?
Quand sont-ils exécutés ?
Combien de temps la boucle de feedback
prend-elle ?
Quels sont les tests qui doivent alors Qui est le principal intéressé par les tests ?
composer la base de notre pyramide ? Et pourquoi ?
39
• Les smoke-tests, qui permettent de déceler
Par exemple, pour un test unitaire :
si notre infrastructure est fonctionnelle ou s’il
y a un problème critique, rendant tout test Qui exécute les tests ? Le développeur.
complémentaire inutile tant qu’il n’est pas résolu. Où sont-ils exécutés ? Sur sa machine.
• Les health-checks, qui permettent de savoir Comment les tests sont-ils exécutés ? En
si des briques d’infrastructure ou applicatives lançant l’outil de test unitaire.
sont opérationnelles ou si elles ont besoin uand sont-ils exécutés ? À chaque
Q
d’être remises en service. modification de code par le développeur.
• Les readiness tests, qui permettent de Combien de temps la boucle de feedback
savoir si les services nécessaires au bon prend-elle ? Quelques millisecondes.
fonctionnement d’une brique applicative ou Qui est le principal intéressé par les tests ? Le
d’infrastructure sont opérationnels. Chacun développeur.
des services est alors lui-même conscient que Et pourquoi ? Pour vérifier que le code produit
son environnement n’est pas opérationnel et répond bien à l’intention du développeur.
va attendre la fin de leurs mise en place.
Cet exercice est intéressant à refaire pour
Pour continuer à construire votre pyramide, chaque typologie de tests que vous voulez
plus vous montez, plus la boucle de feedback mettre en place sur votre produit.

 Inspiré de l’article de Sébastien Douche, Nomenclature des tests logiciels : http://douche.name/blog/nomenclature-des-tests-logiciels/


O C T O > C U LT U R E D E V O P S V O L . 3

Plus de capacités pour plus d’une application. En intégrant des éléments


destinés à générer le chaos, et sous condition
de tests
d’avoir des tests/sondes qui nous assurent que
Une approche continue de la qualité implique la plateforme fonctionne, nous sommes alors
d’avoir de la capacité supplémentaire disponible obligés de prévoir dans nos développements
(calcul, stockage, mémoire) pour construire les éléments permettant une continuité de
et tester le plus possible. Alors qu’avec des service.
approches classiques, nous avons tendance
à dimensionner au plus juste les capacités Tests de performance
utilisées par les projets, l’approche continue Deux approches complémentaires sont possibles.
impose de garder en permanence une marge
Pour ceux qui peuvent accéder à des
suffisante pour gérer les aléas des projets et
infrastructures éphémères (cloud privé ou
jouer en plus les tests d’infrastructure. L’idéal,
public), la première approche consiste à
bien sûr, est de s’appuyer sur le cloud : ses
construire une plateforme iso-production en
ressources sont virtuellement infinies !
termes de dimensionnement. Après une
40 Une fois cette contrainte libérée, le champ des alimentation d’un jeu de données suffisant, un
possibles s’ouvre. Parmi les nouvelles familles injecteur de charge (type Gatling33) passe sur la
de tests possibles, la plupart exécutables plateforme et affiche les résultats dans votre
automatiquement toutes les nuits, citons : intégration continue.

Tests de déploiement d’infrastructure L’autre approche complémentaire consiste


(neutral builds29, nightly builds30). Certaines à mesurer une dérive de performance. Ici,
stratégies de tests d’IaC imposent de disposer peu importe la valeur absolue du temps de
de plateformes pour des durées de vie très réponse, mais le procédé permet de détecter
courtes (quelques minutes voire heures en si une nouvelle version est plus lente ou plus
moyenne). rapide que la précédente. Il ne s’agit pas
d’une vision complète de la performance mais
Tests de résilience d’une première tendance, très rapidement
(design for failure31, chaos engineering32) Que disponible.
se passe-t-il si telle ou telle pièce d’infrastructure
tombe en erreur, d’un coup ? Nous devons Tests de sécurité
admettre la panne comme faisant partie Scan de vulnérabilités, logiciel de pentesting
intégrante du cycle de vie d’une infrastructure, (tentative d’intrusion), tout est possible à partir

 Construction de l’infrastructure pour refléter l’état courant de la base de code, réalisée dans un environnement neutre (c’est-à-dire qui ne servira qu’à cela) -
source : Wikipedia.  Construction “de nuit” de notre infrastructure, de bout en bout, afin de vérifier que l’on en est capable, à n’importe quel moment, de zéro.
 “Conçu pour supporter la défaillance” : une application informatique doit être capable de supporter la panne de n’importe quel composant logiciel ou matériel
sous-jacent - source : https://blog.octo.com/design-for-failure/.  Simuler des pannes en environnement réel et vérifier que le système informatique continue à
fonctionner - source : Wikipedia.  https://gatling.io/.
O C T O > C U LT U R E D E V O P S V O L . 3

du moment où c’est automatisable34. Comme Tests d’opération des infrastructures


il est aisé de reconstruire les plateformes, Pour les équipes très matures qui sont prêtes
lancer des tests même destructifs sur un à aller très loin dans l’intégration continue, il
environnement n’est plus un problème. Vous est tout à fait possible de tester en continu
pouvez vous lancer en (presque) toute sérénité. des fonctions du SI “Opérations” : intégration
Toutefois, cet outillage ne dispense de réaliser avec la supervision (tests de collecte de
des campagnes de tests de pénétration métriques, tests de seuils et de remontées
(qui pour l’heure restent manuelles, non- d’alertes…), les fonctions de sauvegarde et
automatisables). surtout de restauration. La restauration n’est
en général testée que lors d’un désastre, il est
Tests de montée de version pourtant assez simple de jouer tous les jours
Comme il n’y a rien de plus fastidieux que une restauration (éventuellement partielle,
de tester les montées de version, autant anonymisée) des sauvegardes de la veille.
demander à l’intégration continue de faire
le travail. Nous allons donc commencer par
un re-déploiement d’une version iso-prod
41 sur une nouvelle plateforme, enchaîner sur
la récupération de données anonymisées,
l’application de la procédure de montée de
version en cours de mise au point, passer un
non-régression générale sur la plateforme avant
de la détruire si on le souhaite. Les opérations
de provisionnement d’infrastructure étant
particulièrement longues dans un contexte
bare-metal ou serveur virtuel, on réalise
généralement ce type de test en nightly build.

Parcours général d’une application Web


Si elle est tournée vers la publication de
contenu éditorial, cette approche peut s’avérer
très pertinente. Faire un crawling de tout le site
permet de détecter les pages problématiques
(qui déclenchent une erreur 500 par exemple)
ou les liens cassés.

 Liste des outils présents sur le site OWASP : https://www.owasp.org/index.php/Appendix_A:_Testing_Tools.


O C T O > C U LT U R E D E V O P S V O L . 3

Les outils
de nos rêves

42
O C T O > C U LT U R E D E V O P S V O L . 3

Est-ce que l’outil d’Infra as configuration, à la limite de la documentation


d’infrastructure. Le revers de la médaille est
Code idéal existe ?
qu’il est très compliqué d’écrire des tests
N’y allons pas par quatre chemins, l’histoire réellement unitaires en YAML pour Ansible.
reste encore à écrire et aucun outil d’Infrastructure
Chef a choisi l’approche inverse en ce basant
as Code n’est aujourd’hui parfaitement
sur le langage Ruby qui est directement
satisfaisant. Probablement est-ce parce que
utilisable avec toute sa puissance. Il en résulte
l’écosystème des solutions d’Infra as Code est
une courbe d’apprentissage plus laborieuse
bien plus récent et pauvre que celui des
et du code qui peut avoir de très fortes
langages de programmation “classiques”. S’il
abstractions, pour le pire et le meilleur.
fallait faire sa liste au Père Noël de ce que l’on
attend d’une solution d’IaC, nous devrions À mi-chemin entre ces deux approches se
répondre à plusieurs questions. Et pour trouve Puppet qui a pris le parti de définir un
chacune d’entre elles, les avis divergent, même DSL (Domain Specific Language). Il reprend
chez OCTO. certains des principes de langages de
programmation, notamment des mécanismes
YAML ? DSL ? Vrai langage ?
43
d’abstraction au travers de “classes”.

Dans l’histoire, différents choix ont été faits sur Dans tous les cas, la puissance de ces solutions,
cette question : quelles que soient les limites de leur syntaxe,
réside dans leur capacité à écrire de façon ad
Ansible peut paraître rassurant pour les non-
hoc des nouveaux types de ressources dans
initiés aux langages de programmation. Il ne
des vrais langages de programmation. Ils sont,
se compose que d’une syntaxe en YAML, ce
par construction, testables de façon unitaire car
qui finalement colle assez bien à des besoins
ils peuvent sans problème faire appel à toute la
déclaratifs triviaux (90 % du temps en général).
puissance de Python ou Ruby par exemple, qui
C’est lorsqu’il faut sortir de ces 90 % que les
disposent de nombreux frameworks de tests.
limites du YAML se font vite ressentir : il ne
s’agit en aucun cas d’un vrai langage structuré, Déclaratif ? Impératif ?
avec des vraies structures (conditions, blocs,
mais aussi gestion d’erreur, fonctions...). Le
Hybride ?
paradoxe est pourtant bien là : si Ansible La plupart du temps, une approche purement
fait l’objet d’un tel succès, c’est notamment déclarative convient parfaitement pour les
parce que sa syntaxe ne ressemble pas à un parties d’IaC relatives aux installations et
langage de développement et ne provoque configuration système et middleware. C’est au
pas de réactions épidermiques auprès des moment où il faut commencer à orchestrer des
plus “OPS” d’entre nous. Elle permet de déploiements applicatifs (sans interruption de
décrire très simplement l’infrastructure et sa service qui plus est) que l’approche hybride
O C T O > C U LT U R E D E V O P S V O L . 3

devient pertinente. Elle permet de séquentialiser peuvent servir pour le déploiement : un poste
précisément des étapes, ce qui est nécessaire de développement en phase de mise au point,
lorsqu’il faut jongler avec plusieurs machines. puis une brique de CI/CD une fois le code
L’exemple classique pour représenter ce versionné.
besoin est la chorégraphie de rolling-upgrade
entre un load-balancer et des serveurs applicatifs. Quel niveau de testabilité ?
C’est surtout sur cette dernière question que
Push ou Pull ? l’essentiel du travail est à produire. Là où les
La question du push ou du pull est finalement langages de programmation classiques sont
moins impactante que le fait de devoir installer désormais très bien équipés dans leur capacité
un agent sur les machines. Et c’est souvent ce à rendre le code testable à tout niveau, l’IaC
dernier argument qui nous fait pencher pour est bien mal lotie.
une approche push.
 Tester unitairement de la logique cachée
L’approche pull est séduisante car elle permet dans de l’IaC
à un système de converger à partir d’un serveur
44 de référence (Chef server, Puppet master), Le besoin se décrit simplement : en fonctionnement
qui certes est un SPOF35, mais également un normal, notre code d’infrastructure invoque, via
point de passage et donc de journalisation des modules, des ressources d’infrastructure.
de toutes les exécutions d’une solution d’IaC. Prenons l’exemple d’une API permettant
On apprécie également sa capacité à lisser et de créer des VM. Cette API est fournie par
répéter son exécution dans le temps en lançant un cloud provider tiers et un module fourni
régulièrement des travaux de convergence par la solution d’IaC implémente la logique
vers un état attendu. de comparaison / convergence vers un état
attendu et les mécanismes d’idempotence.
L’approche push a pour vertu de permettre Problème : cette tâche de création de vraies
de décider précisément le début, le ressources sur le cloud est coûteuse en argent
périmètre (en termes de machines) et la fin de et en temps.
l’exécution d’un travail de déploiement ou de
configuration. Généralement peu intrusive sur
les systèmes (Ansible ne requiert qu’un service
sshd activé et Python installé), cette approche
ne demande pas d’infrastructure centrale,
complexe à mettre en haute disponibilité.
Plusieurs machines avec peu de prérequis

 Un point unique de défaillance (Single Point of Failure ou SPOF en anglais) est un point d'un système informatique dont le reste du
système est dépendant et dont une panne entraîne l'arrêt complet du système - source : Wikipedia.
O C T O > C U LT U R E D E V O P S V O L . 3

Outil Infra as
Code
Mon Code Module
de déploiement DEMANDE DEMANDE
de mon API Cloud
Module
application provider
RÉPONSE RÉPONSE
(Infra as Code) ...

Module

45

Notre souhait est donc de gagner du temps Plusieurs stratégies sont possibles, mais dans
et de tester le plus rapidement possible notre l’idéal, on aimerait pouvoir tester en isolation
code d’infrastructure, à gauche du schéma. notre code de la façon suivante :

Outil Infra as
Code
Mon Code Module
de déploiement DEMANDE DEMANDE
API Cloud
BOUCHON

de mon Module
application provider
RÉPONSE RÉPONSE
(Infra as Code) ...

Module
O C T O > C U LT U R E D E V O P S V O L . 3

Exit l’appel à la vraie API, et bienvenue au de pouvoir se baser sur le contexte utilisé lors
feedback le plus rapide possible. Nous restons du passage de l’IaC pour déterminer les tests
ici volontairement flou sur l’implémentation de à faire : autrement dit les inventaires, les faits
ce bouchon et son emplacement précis, car (facts) et les variables de chaque machine
elle dépend en grande partie de la technologie (host_vars, group_vars pour Ansible,
retenue. Focalisons-nous simplement sur hieradata pour Puppet).
l’intention. La plupart du temps, l’IaC que l’on
est amenée à écrire est parfaitement triviale, mais Pour illustrer ce besoin, prenons l’exemple d’une
dans certains cas, la logique embarquée peut être application Web qui est déployée sous une URL
beaucoup plus complexe : particulière et avec un certificat TLS spécifique. Le
• Invoquer un premier module pour récupérer une code d’IaC utilisé est toujours le même quelque
liste d’objets. soit l’environnement, mais les paramètres (l’URL
• Pour chacun des objets retournés par le premier et le certificat présenté par l’application dans le
appel, invoquer un autre module uniquement si cas présent) sont probablement différents d’un
l’objet listé répond à une règle métier spécifique. environnement à l’autre. Nous aimerions que notre
outillage de tests soit donc simplement capable,
46 Cet exemple décrit un cas très fréquent que nous moyennant un inventaire fourni, de récupérer tout
voulons absolument tester unitairement car de le contexte d’exécution pour éviter de devoir re-
la logique (cette fameuse règle métier) se cache déclarer les méthodes d’accès aux machines (s’il
au milieu d’IaC inoffensive. S’il fallait donner un faut passer par des rebonds sur un bastion par
coup de baguette magique, nous aimerions exemple), et surtout les variables spécifiques à
qu’il soit donné dans cette direction : tester le chaque environnement.
code métier caché, très rapidement.
La mauvaise testabilité de
 Écrireet exécuter simplement des tests l’IaC est-elle une fatalité ?
d’intégration
On pourrait être tenté de penser que l’on ne
Derrière cette seconde typologie de tests se parviendra jamais à correctement tester le code
cache un second besoin complémentaire : d’infrastructure. Pourtant, la plupart des outils qui
valider simplement que des ensembles de voient le jour prennent de plus en plus en compte
rôles / modules / recettes / classes ont été cette problématique de la testabilité. Notre
convenablement appliqués sur tout un système attention est particulièrement portée dans cette
(qui peut être constitué de plusieurs machines). direction sur des outils comme Pulumi36, Testinfra,
Test Kitchen, Molecule, pytest-ansible…
Les tests d’intégration n’ont ni besoin d’être lancés
localement, ni unitairement, mais il est primordial

 Pulumi permet de créer, déployer et gérer une application cloud native et son infrastructure en utilisant un langage de programmation tel que Node.js, Go ou
encore Python - source : https://blog.octo.com/decouvrir-les-cloud-native-languages-avec-pulumi/
L’Équipe
Ptah : dieu des artisans et des architectes, il est le patron de la construction, des chantiers
navals et des charpentiers en général. Il joue également un rôle dans la préservation de
l'univers.
O C T O > C U LT U R E D E V O P S V O L . 3

Non seulement je fais des Nous aimerions leur donner plus d’indépen-
tests, mais je pilote mon dance pour le déploiement de leurs applications,
développement par les tests. mais les vieux réflexes ont la vie dure. Déjà, au
Ma boucle de feedback sein de l’équipe infra, tout le monde n’est pas
est rapide, et surtout, elle est sûre : aucunconvaincu par l’utilité de faire différemment et
environnement n’est maltraité pendant mes les périmètres de chacun demeurent cloisonnés.
développements. Les problèmes de régression Mon code Chef n’est pas forcément compris
que je rencontrais auparavant sont plus limités,
par tout le monde et si je m’absente plusieurs
puisque mon harnai de tests me permet d’en jours, je peux être sûr que personne n’osera y
détecter la plupart dans mon pipeline, sur matoucher. Ceci est problématique, car s’il se met
plateforme d’intégration à dysfonctionner ou si une
continue. évolution est demandée, per-
"Personne ne vous sonne ne pourra avancer avant
En appliquant à mon code
croit quand vous mon retour.
d’infrastructure certaines pra-
tiques issues du software dites que vous faites Certes, le problème n’est pas
49 craftsmanship, j’ai aujourd’hui du craft sur de nouveau. La connaissance ne
quelque chose dont je peux circule jamais à 100 % lorsque
être fier : un code testé. L’in-
l’infra." chacun est sur son écran.
frastructure qui supporte Même avant d’avoir introduit
mon application est désormais automatisée, l’Infrastructure As Code, il fallait souvent passer
grâce à du code facilement compréhensible, par “les anciens” pour essayer de comprendre
qui décrit l’état dans lequel je souhaite me les différents scripts, avec leurs variables
trouver plutôt qu’une suite incompréhensible magiques, leurs paramètres ésotériques…
d’instructions bash. Bon, il en reste, mais nos “Heureusement”, nous sommes souvent
nouveaux développements ne se font pas sans capables de déterminer qui est l’auteur d’un
test, au moins. script en faisant un peu attention à la manière
dont il est écrit.
J’ai commencé à montrer un peu comment
tout cela marchait à d’autres équipes qui sont
curieuses. Les développeurs se sont un peu
moqués de nous au début : “personne ne vous
croit quand vous dites que vous faites du craft
sur de l’infra”. Mais ils ne peuvent pas nier que
notre approche est plus qualitative qu’avant.
O C T O > C U LT U R E D E V O P S V O L . 3

Collective Code
Ownership
On parle souvent de “s’approprier” le code du suffisamment clair pour qu’une modification
projet. En utilisant cette expression, on tient n'entraîne pas un crash serveur à cause d’une
à accentuer le fait de comprendre le code : obscure commande à lancer, documentée
la manière dont celui-ci est rédigé, dont il uniquement sur un post-it collé sur le bureau
va interagir avec les autres applications, ou de l’OPS qui est en congé ? Évidemment.
encore son environnement d’exécution. Mais il
faut voir encore plus loin. En tant que membre Revue de code
du projet, je partage ma La revue de code consiste à
50
base de code avec le reste faire relire son code par une
de l’équipe, et je dois être à "Le code n'appartient personne tierce, afin de
même de modifier n’importe pas à son auteur, relever au plus tôt “ce qui ne
quelle ligne sans demander
avant à son auteur si cela est mais au produit et aux va pas”. Si les tâches sont
divisées en user stories, c’est
“bon pour lui“. Ce n’est pas membres de l'équipe." l’unité de relecture que nous
“son code” mais celui du utiliserons. Les discussions
produit et des membres pourront porter tant sur le
de l’équipe. fond que sur la forme. Aucune question n’est
Bien sûr, le collective code ownership (propriété interdite, puisque le but est de construire un
collective du code) s’articule autour de code de qualité supérieure et compréhensible
l’egoless programming, de la Boy Scout Rule à la lecture.
(voir plus loin) et de bien d’autres pratiques C’est pour nous l'une des pratiques les plus
décrites ici. Pouvoir modifier le code de importantes dans un projet. Elle évite le
n’importe qui, n’importe quand, est un bon silotage et permet d’assurer un contrôle
indicateur de la qualité d’un code. Après qualité37 du code qui va ensuite être déployé
tout, le projet n’a-t-il pas des tests de non- en production. Flexible, elle peut se faire en
régression pour s’assurer que l’on ne déploiera asynchrone, seul ou à plusieurs.
pas un bug en production ? Le code est-il

 Un article à lire sur la code review par Jeff Atwood : https://blog.codinghorror.com/code-reviews-just-do-it/.


O C T O > C U LT U R E D E V O P S V O L . 3

Le mieux restant tout de même une revue de • Comment ce fichier est-il généré ?
code à plusieurs, en synchrone. • Pourquoi son contenu doit-il être dynamique ?
• Quelle est la syntaxe du moteur de templating
Qu’est-ce qui pourrait différencier les éléments utilisé ?
d’une revue de code d’infrastructure, au sein • Où se trouvent les variables qui seront
d’une équipe composée d’OPS, de celles menées utilisées lors de la génération dudit fichier ?
sur du code applicatif ? Une attention particulière
sera portée au partage des connaissances Une fois éclairé, chaque membre de l’équipe
propres à une expertise : pourquoi avoir utilisé pourra, en autonomie, faire évoluer ces
telle ou telle classe de disque dur pour fichiers de configuration, au même rythme que
supporter cette application ? Pourquoi laisser l’application en aura besoin.
ces ports ouverts sur notre base de données ?
Pourquoi utiliser ce port exotique ? Egoless programming
“Cette application est très gourmande en IO/s.”, Les métiers de l’infrastructure amènent à de
“Notre provider cloud utilise ce port pour son nombreux travers. Une erreur et c’est la pro-
monitoring.”,“Le port stan- duction qui tombe. On se re-
51 dard est fermé sur le réseau.”. trouve en war room, un week-
Une relecture de code
"Le baptême de end, à restaurer les backups.
L’impact d’une “coquille” est
d’infrastructure d’un OPS la prod, c’est de énorme. Pointer du doigt est
en feature team (c’est-à-
dire, un OPS au sein d’une la faire tomber." un réflexe courant surtout
équipe de développeurs) dans le cas d’une nuit gâchée
aura plutôt vocation à par un “rm -rf”.
diffuser une partie de la connaissance. Toutes Il y a beaucoup d’affect dans le travail et c’est
les stories ne sont pas forcément éligibles à normal, mais avec les enjeux que nous venons
être relues par l’équipe de développement, de citer, il serait mal avisé d’en mettre plus que
il faut trouver le bon niveau de complexité. nécessaire. Oui, des erreurs seront commises,
Quelque chose d’actionnable, que le et par tout le monde. Le “baptême de la prod”,
développeur pourra facilement s’approprier. c’est de la faire tomber. Certains d’entre nous
Par exemple, la relecture pourra porter sur le avons subi ce difficile baptême. Nous avons
code de configuration des serveurs devant écrit du code d’infrastructure qui a planté la
supporter son application. Il est classique production. Nous savons combien cela peut
que le code d’infrastructure génère des être dramatique et savons que le code que
fichiers de configuration pour les applications nous avons produit ne reflète pas ce que nous
qu’il déploie. Transférer le savoir permet de sommes.
répondre à ces questions :
O C T O > C U LT U R E D E V O P S V O L . 3

Pour limiter les erreurs, nous devons éviter il y aura toujours quelqu’un qui en saura plus
l’effet tunnel, communiquer sur ce que l’on que vous. No matter how much "karate" you
fait, et le faire passer par des étapes de know, someone else will always know more.
validation. Les développeurs, encore une fois,
ont eu les mêmes problématiques, et ont su 4. Réécrire du code doit se décider à plusieurs.
trouver les solutions. Au-delà des pratiques que Don't rewrite code without consultation.
nous allons lister, il est nécessaire d’adopter 5. Soyez humble, patient et respectueux avec
une manière de penser le code : l’egoless les autres. Treat people who know less than
programming ou “programmer en laissant son you with respect, deference, and patience.
ego de côté”.
6. La seule constante dans le monde est le
En pensant de cette manière, nous essayons changement. The only constant in the world is
de nous détacher un peu plus de ce que change.
l’on a produit. Le code est jugé, et non notre
personne. Tout le monde sait qu'on ne voit 7. L’autorité engendrée par la connaissance
pas forcément la meilleure solution du premier force le respect, plus que le grade. The only
52 coup, qu’il y a des contraintes ou encore, que true authority stems from knowledge, not from
parfois, par manque de temps, le code n’est position.
pas “parfait”.
8. Défendez vos idées, mais acceptez la défaite
Le refactoring est l’un des garants les plus avec humilité. Fight for what you believe, but
importants d’un code de qualité. Si le code gracefully accept defeat.
est sanctuarisé, l’amélioration continue est
9. Soyez une personne avec qui il fait bon
impossible.
travailler. Don't be "the guy in the room."
Voici les 10 commandements de l’egoless
10. Soyez dur avec le code, doux avec les gens.
programming, tels que décrits sur le blog de
Critique code instead of people – be kind to
Jeff Atwood38.
the coder, not to the code.
1. Intégrer et accepter que vous allez faire des
erreurs. Understand and accept that you will Pair & Mob Programming
make mistakes. Le pair programming est l’étape suivante.
Il est indispensable pour faire monter en
2. Vous n’êtes pas votre code. You are not your
compétence un nouvel arrivant sur le projet.
code.
Ce n’est pas du shadowing (qui consiste à se
3. Qu’importe l’ampleur de vos connaissances, placer en observateur du travail de quelqu’un)

 Source: https://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/
O C T O > C U LT U R E D E V O P S V O L . 3

mais réellement une coopération entre deux


personnes face à une problématique. Il permet
de partager des connaissances, des méthodes
de travail, et tout simplement de créer un
moment d'échange qui tisse des liens.

Surtout, cela permet la revue de code en même


temps que son écriture. En effet, on ne fait pas
travailler les mêmes zones cognitives lorsqu’on
écrit ou lorsqu’on lit du code. L’équipier qui n’a
pas le clavier pourra donner un feedback rapide
sur la qualité du code produit. Il est d’ailleurs
conseillé d’échanger le clavier régulièrement
lors d’une séance de pair programming pour
alterner les deux postures.

Le mob programming pousse la pratique


53
encore plus loin. Toute l’équipe se retrouve
devant un grand écran et travaille sur une
même tâche. Celui qui a le clavier (le driver)
ne réfléchit pas. Les autres (les navigateurs)
indiquent ce qu’il faut faire. Cela a pour
bénéfice de faciliter les discussions et prises
de décision par l’équipe. La connaissance et
les apprentissages sont aussi diffusés en même
temps à toute l’équipe.

D'expérience, le mob programming est très


bénéfique en début de projet lorsqu’on doit
constamment prendre des décisions sur les
conventions de l’équipe, les choix de design et
les apprentissages fonctionnels et techniques.
Il facilite l'amorce des sujets complexes et
structurants, qui nécessitent un alignement
des convictions et de l’expertise technique.
O C T O > C U LT U R E D E V O P S V O L . 3

Clean Code

Broken Window
Un tableau de bord dont les indicateurs restent
constamment en alerte. Des tests qui ne
passent jamais totalement. Un service externe
54
qui tombe régulièrement. Un démon que l’on
doit redémarrer occasionnellement, sans trop
comprendre pourquoi. Les “erreurs normales”
dans les logs... Ce ne sont là que quelques
exemples pour illustrer ce qu’il se passe quand
on laisse un problème s’installer. Cela témoigne
Au commencement, le code source est écrit.
d’une mauvaise qualité du code exécuté, et
Entre ce moment, et jusqu’à sa suppression, ce
surtout, d’un mauvais état d’esprit.
code sera souvent lu ; lorsque nous voudrons
S’habituer à passer tous les matins devant une
résoudre un bug, lorsque nous voudrons le
fenêtre cassée ne nous fera pas remarquer la
faire évoluer, ou juste pour le comprendre.
seconde fenêtre qui commence à se fissurer. Et
Chacune de ces étapes sera facilitée par un
si elle se fissure, après tout, ça ne doit pas être
code propre.
grave, puisque le bâtiment a l’air de tenir
Passer du temps à écrire du code de qualité debout alors qu’il a déjà une fenêtre cassée. Et
est un investissement, qui, s’il n’est pas réalisé, d’ailleurs, si personne n’y prête attention, c’est
se paie tôt ou tard. La non-qualité a un coût, que ce n’est pas si important.
technique, humain, et stratégique. Notre but
Par exemple, si les erreurs dans le linter sont
ici n’est pas de vous décrire l’ensemble des
“normales”, à quoi sert-il finalement  ? Plus
pratiques permettant d’améliorer la qualité
aucune attention ne lui sera portée, jusqu’au
de votre code, mais de présenter quelques
jour où, une erreur de typographie sera
pistes, afin de planter les graines d’une culture
envoyée jusqu’en production...
durable de la qualité.
O C T O > C U LT U R E D E V O P S V O L . 3

Un bon moyen de se prémunir contre ces pro- Cette règle vient d’une citation de Baden-
blèmes est de les rendre bloquants pour le dé- Powell, père fondateur du scoutisme : “Essayez
ploiement de nouvelles versions. Un déploie- de laisser le monde dans un meilleur état que
ment ne doit pas se faire si l’on n’est pas celui dans lequel vous l’avez trouvé [...]”40.
capables d’être un minimum serein sur son
bon fonctionnement, via des Concrètement, cela peut aller
tests (unitaires, d’intégration, de corriger une simple faute de
typographie, jusqu’au refacto-
bout en bout…). Et si notre ta- "Un bon moyen ring d’un module de code en-
bleau de bord ne remonte que
des erreurs, il ne servira à rien,
de se prémunir tier. Le moment où l’on lit du
et ne nous permettra pas de dé- de ces problèmes code pour la première fois, où
l’on s’interroge sur son fonc-
tecter un dysfonctionnement au est de les rendre tionnement et ses interactions
plus tôt comme il le devrait.
bloquants pour avec d’autres services, est un
Ce n’est pas nécessairement le déploiement moment privilégié. Prendre du
propre au Broken Window, mais temps pour retravailler un mor-
55 le turn-over dans une équipe de nouvelles ceau de ce code aide aussi à sa
est une occasion de se poser les versions." compréhension.
bonnes questions et d'éviter
ainsi le syndrome de la gre- La Boy Scout Rule n’a pas de
nouille dans la casserole d’eau chaude39. Les fin  : elle s’applique de façon opportuniste, à
nouveaux arrivants sont-ils surpris par certaines l’occasion d’une revue de code, de l’ajout
pratiques ? Se retrouve-t-on à leur expliquer le d’une nouvelle fonctionnalité, de la résolution
contexte pour justifier que l’on ne regarde plus d’un bug...
tel test ? Tel indicateur ? Il faut en profiter pour
échanger sur les sujets, et trouver des solutions
KISS − Keep It Simple,
satisfaisantes dans l’idéal et appliquées à notre Stupid!
contexte. Faites les choses de manière simple. Un code
non-optimisé, mais facilement compréhensible
BSR − Boy Scout Rule est souvent préférable à un code spaghetti,
qui fera gagner quelques temps de cycles
La Boy Scout Rule (loi du scout) consiste à processeur. L’équipe perdra beaucoup de
toujours laisser un endroit plus propre qu’on temps à relire ce code, à le maintenir, à le
ne l’a trouvé. Appliqué au code, cela consiste à réécrire…
laisser le code plus propre qu’on ne l’a trouvé.

 https://fr.wikipedia.org/wiki/Fable_de_la_grenouille.  "Try and leave this world a little better than you found it, and when your turn comes to die, you can die
happy in feeling that at any rate, you have not wasted your time but have done your best." - Lord Robert Baden-Powell, 1941.
O C T O > C U LT U R E D E V O P S V O L . 3

L’architecture d’une stack applicative doit suivre


les mêmes règles, et réussir à faire la part entre
simplicité et efficacité. Ajouter des briques,
aussi efficaces soient-elles, ajoute de la charge
en maintenance, en compréhension, et rend
plus compliquée la reprise de la plateforme.

YAGNI − You Ain’t Gonna


Need It
Développez seulement ce qui est nécessaire
aujourd’hui pour répondre aux besoins des
utilisateurs et du métier. Gardez les “peut être
Single responsibility
que l’on en aura besoin” pour demain ! On a
souvent tendance à vouloir faire des choses dans Évitez de vous retrouver avec un module, une
l’hypothèse où en aura peut être besoin un jour. classe, une méthode ou une fonction de plusieurs
En plus de générer du code inutile, ça nous fait centaines de lignes. C’est le symptôme d’une
56
perdre du temps et nous empêche de délivrer du mauvaise modularisation du code. Le principe
code qui apporte réellement de la valeur au de “single responsability” est de dire qu’un
projet. "Le mieux est l’ennemi du bien". module ne devrait avoir qu’une et une seule
raison de changer. N’hésitez donc pas à
DRY − Don’t Repeat Yourself extraire des méthodes, découper des fichiers
trop gros. Cela peut paraître paradoxale mais
Faites la chasse au code dupliqué en utilisant
mieux vaut une multitude de petits modules
tous les mécanismes de factorisation à votre
qu’un seul qui regroupe toutes les fonctionnalités :
disposition : modules, classes, méthodes, fonc-
cela facilitera la lecture, la compréhension et
tions. Pour chaque traitement, ne conservez
l’évolutivité de votre code.
qu’une représentation unique. Utilisez-la à
chaque fois que cela est nécessaire. Le code
s’en trouve d’autant plus limité en taille et donc
maintenable. Des outils d’analyse de code pro-
duisent des indicateurs sur le taux de duplica-
tion du code, taux que l’on cherche à garder le
plus bas possible. De plus, les IDE sont généra-
lement équipés de fonctionnalités permettant
de repérer facilement les doublons de code41.

 Sous la forme d’un plugin pour Visual Studio Code. (https://marketplace.visualstudio.com/items?itemName=paulhoughton.vscode-jscpd) ou dans la version
ultimate d’IntelliJ IDEA (https://www.jetbrains.com/help/idea/duplicates-tool-window.html)
O C T O > C U LT U R E D E V O P S V O L . 3

Continuous Integration :
la nécessité d’une
approche continue
de la qualité
Il est délicat de mesurer les impacts de la pas doués pour la répétition. Il est donc naturel
57 modification d’une grande quantité de code. de déléguer ces opérations fastidieuses à des
On pourrait penser que cette démarche ne automates qui ne feront pas de faute de frappe
s’applique qu’aux applications et/ou que les et ne peuvent pas “oublier” une étape de la
infrastructures et les systèmes, procédure d'installation. Nous
sont stables et ne courent pas devons laisser à l'humain ce
ce risque ! Rien n’est plus faux. "Nous devons que la machine ne peut pas
Pour tout ce qui est codé, laisser à l'humain remplacer : la compréhension
configuré, paramétré, un seul
changement peut casser quelque
ce que la machine des besoins et la conception.
chose. ne peut pas Les ingénieurs en mécanique
en rêvent : imaginez ce monde
Quels que soient le soin et la
remplacer : la merveilleux où la chaîne de
qualité que l'on porte à nos compréhension construction de votre voiture
travaux, une faute d’inattention des besoins et la est entièrement automatisée ;
finit toujours par arriver. Un quelles que soient les évolutions
espace en trop dans une conception." que vous lui apportiez, vous
commande que l'on joue tous avez un contrôle technique
les jours qui vide le serveur plutôt que de quasi instantané. Et si c'était possible pour
supprimer quelques fichiers. Un oubli dans notre infrastructure ?
l'installation du serveur de production que l'on
ne détecte qu'à la mise en prod un mercredi soir
à 20h. Un constat s'impose : les humains ne sont
O C T O > C U LT U R E D E V O P S V O L . 3

La genèse : généralement sous le nom de Plateforme


d’Intégration Continue (PIC). Vous pourrez
faire du neuf avec du vieux
trouver également le terme Software Factory
Les équipes qui font du développement ou Usine De Développement (UDD).
logiciel, en mode agile en particulier, ont la
solution depuis longtemps. Elles utilisent Les fonctions classiques d’une PIC peuvent se
quotidiennement des outils que l’on regroupe schématiser ainsi :

PIC
Récupérer
les dépendances
58
Gestionnaire Serveur Build
Compiler
de sources d’intégration
Build
continue
local
Vérifier la qualité Référentiel
du code de binaires

Packager

Publier

Référentiel Déployer
de tâches
et anomalies Env.
Exécuter les tests d’intégration

Documenter
et rendre compte

Notifications
BUILD
Documentation
et indicateurs
O C T O > C U LT U R E D E V O P S V O L . 3

59

Si nous laissons de côté le rôle de référentiel L’idée est toujours la même : à chaque fois que
d’une PIC (code source / tickets / artefacts), quelqu’un propose une modification dans le
son rôle d’automate se résume ainsi : code d’une application, la PIC exécute et essaye
• Tester de mettre en défaut ledit code. Dit autrement,
• Construire la PIC essaye par tous les moyens possibles de
• Tester faire planter l’application au travers des tests
• Déployer qui lui sont fournis. Si l’application résiste à
• Tester toute cette somme de maltraitances, c’est
• Produire des indicateurs de qualité de code qu’elle mérite de la considération et pourrait
• Tester... même partir en prod, qui sait.
O C T O > C U LT U R E D E V O P S V O L . 3

Code applicatif

Artéfact applicatif Degré de confiance


PIC déployable avec dans l’artéfact
60
Tests applicatifs de la valeur métier applicatif

En entrée de l’usine, on trouve du code code doivent être maintenues en cohérence.


applicatif et des tests, en sortie, un artefact Si l’application évolue, les tests évoluent. Si
construit et des indicateurs de qualité de ce les tests évoluent, c’est soit pour préparer
dernier, voire un environnement d’intégration un changement dans l’application, soit pour
directement mis à jour. En cas d’erreur, on ajouter un cas de test qui n’était pas couvert et
obtient un rapport d’erreur détaillé sur les a donné lieu à un bug.
causes de cette dernière.

Ce principe implique donc que l’activité


d’écriture de code s’accompagne d’une
activité miroir d’écriture de code de tests. Votre
patrimoine est composé des deux familles de
code : application et tests. Ces deux familles de
O C T O > C U LT U R E D E V O P S V O L . 3

Importance de la vision
pipeline
Pour modéliser l’activité d’une PIC, il est
habituel d’utiliser une représentation sous
forme d’un pipeline :

Analyse Tests Tests


Commit Syntaxe Compilation unitaires Packaging Publication ... d’intégration

v390
61

v389

v388

v387

v386

v385
TEMPS

v384
O C T O > C U LT U R E D E V O P S V O L . 3

7 versions candidates sont fournies au


pipeline. La v384 est la plus ancienne à avoir
été soumise, la v390 la plus récente. Parmi Un pipeline qui
les 7 tentatives, 2 seulement (v387 et v390)
ont traversé l’intégralité du pipeline et sont
n’exécute (presque)
donc théoriquement éligibles à partir en aucun test perd
production. Les différentes étapes de tests
sont automatiquement parvenues à mettre les
environ 99 % de son
5 autres versions en défaut. Elles sont donc intérêt. Il permet juste
rejetées et n’iront pas plus loin. d’envoyer plus vite
Grâce à la mise en œuvre de ce genre de des bugs en
workflows, toutes les tâches manuelles et
répétitives sont automatisées. Les tâches
production. Pas de
exécutées et leur ordre sont ici donnés à titre tests, pas de qualité.
d’exemple sachant que quelques principes
62 régissent leur mise en place :
Pas de qualité, pas de
confiance. Pas de
• Optimiser la boucle de feedback en exécutant
les tests les plus rapides en premier. “Quitte à confiance, pas de
échouer, autant échouer le plus vite possible”. prod.
• Ne pas voir le pipeline comme un objet
sacré, inaltérable. Il est normal, voire sain, de
le réorganiser régulièrement : changement
d’ordre de certaines étapes, ajout / retrait
d’étapes, parallélisation…

• Adapter le pipeline au projet concerné. Rares


sont les projets qui sont suffisamment similaires
pour utiliser exactement le même.
O C T O > C U LT U R E D E V O P S V O L . 3

ANNEXE

Palmarès des plus


beaux effets de bord
liés à un changement
de configuration
63

Pour cette année 2019, voici notre classement des 10 meilleurs


effets de bord. Comme chaque année, ce sont des changements en
apparence innocents qui déclenchent les plus beaux loupés.

Merci à tous les participants pour cette moisson très prolifique.


De l’engagement, de la détermination, du mental et du collectif.
O C T O > C U LT U R E D E V O P S V O L . 3

10e place : une règle de firewall qui quand la sauvegarde mal planifiée ralentit
bloque un flux NTP. Classique parmi les tout le SAN aux heures de pointe.
classiques, cette perle est pernicieuse car
4e place : montée de version d’une
elle peut ne montrer son visage sadique
librairie système qui était utilisée dans une
qu’après plusieurs heures, jours voire
version spécifique d’un binaire installé à
semaines le temps que les horloges
la main en partant du tar.gz de l’éditeur.
internes des machines se désynchronisent
Ne se voit qu’au redémarrage suivant de
au point de gêner les applications.
l’application et fait toujours son petit effet.
9e place : passage en mode verbose
3e place : reconfiguration sauvage d’un
d’une application : saturation des I/O et
pool de connexions SQL vers un serveur.
du système de fichiers, toujours une valeur
sûre. 2de place : reparamétrage du nombre
de workers d’une application qui écroule
8e place : changement de la locale d’un
la mémoire de la machine. Note artistique
OS ou d’un SGBD. Un must qui peut avoir
64 majorée quand l’application n’est pas
des effets dramatiques comme casser la
simplement tuée par l’OOM killer mais
fonction de recherche full-text en français
mange tellement de swap que les I/O
d’un SGBD. Toujours sympathique de faire
mettent à genoux les disques.
le rapprochement entre une recherche qui
retourne 0 résultat et un tel changement 1ère place : encore cette année, les
de configuration. durcissements de sécurité remportent la
palme. Toujours motivés par une bonne
7e place : changement de la timezone
intention, les impacts sont souvent difficiles
d’un OS ou d’une application. Rien de plus joli
à identifier au premier coup d’œil à tel
que de voir des logs avec la mauvaise heure,
point qu’on les considère potentiellement
ou une application qui se trompe de jour.
infinis. Cette année, citons simplement
6e place : renommage d’un fichier de le changement de l’umask par défaut
log, qui n’est alors plus pris en compte par (022 ou 002) vers 077 plus restrictif. Entre
l’outil de rotation de logs : le système de l’application qui ne démarre plus ou
fichier va alors se remplir jusqu’à saturer. le déploiement qui échoue, vous avez
l’embarras du choix et toujours un mal de
5e place : une replanification d’un job chien à investiguer. "strace" reste votre
cron. Classique mais toujours appréciée meilleur ami dans ce genre de situations.
par les connaisseurs. Mot compte double
O C T O > C U LT U R E D E V O P S V O L . 3

Pilotage de dette :
Principes d’archi

Dette technique ? Comment maîtriser sa dette


La dette technique fait référence aux raccourcis technique ?
que l’on s’autorise parfois en diminuant la qua- Une équipe qui s’endette (même consciemment)
65 lité pour pouvoir livrer certaines fonctionnalités sans planifier son remboursement est vouée à
rapidement. C’est un mal nécessaire, une dette une fuite en avant vers la non-qualité.
que l’on contracte et qu’il faudra rembourser
plus tard. Une équipe qui cherche à être agile, créera
tactiquement de la dette technique à un
Par exemple, lorsqu’un projet commence, un moment ou un autre. Et c’est parce qu’elle
OPS va rapidement mettre à disposition de son recherche l’excellence autant que l’agilité que
équipe une UDD sans l’avoir complètement cette équipe utilise ce pattern.
automatisée, sans avoir géré les backups ni
le monitoring. Il devra dans la suite du projet À quoi reconnaît-on qu’une équipe fait des
planifier des tâches avec le Tech Lead et/ou “emprunts techniques” temporaires pour
le Product Owner pour palier ces manques s’assurer un avantage (également temporaire)
et rembourser la dette technique qu’il a plutôt que s’endetter jusqu’au cou ?
contractée.
Il suffit d’observer ses pratiques, et d’écouter
La dette technique, pour respecter la comment elle répond aux questions suivantes :
métaphore, est un expédient temporaire
• Avez-vous un standard et des principes
pour lequel une solution de recouvrement
d’architecture documentés que vous pouvez
est non seulement identifiée, mais aussi
afficher, ou expliquer via une session en binôme ?
programmée dans le temps. C’est un
investissement, dans le sens où cela permet de
s’acheter du temps.
O C T O > C U LT U R E D E V O P S V O L . 3

• Avez-vous des tâches de remboursement


prévues pour les “emprunts techniques” en
cours ?

• Les tâches de remboursement de la dette


s’écoulent-elles au même rythme que les
tâches standards ?

Si ces questions amènent une ou plusieurs


réponses négatives, voici les actions à mettre
en place :

• Provoquer un temps d’arrêt pour établir


un dialogue autour de ce problème de non-
qualité. Tout commence par une prise de
conscience de l’équipe.
66
• Décider quels standards (d’Infra as Code) et
quels principes d’architecture (exploitabilité,
haute disponibilité…) l’équipe veut appliquer
dans son travail.

• Confronter régulièrement les écarts à


ces standards, via des revues de code ou
du pair programming, et programmer leur
remboursement.

• Mettre en place des formations visant à mieux


connaître et mettre en œuvre les pratiques de
qualité.
L’Entreprise
Horus : dieu protecteur, il incarne l'ordre et l'harmonie universelle
O C T O > C U LT U R E D E V O P S V O L . 3

Nous avons passé le cap de la vraiment besoin, et surtout, la typologie


transformation DevOps ; chaque d’application supportée par leur solution ne
équipe est indépendamment correspondait à celle d’aucun produit ! Autant
constituée selon les expertises vous dire que la licence payée à prix d’or est
nécessaires à sa tâche, et est capable de restée dans son carton. Dans les différentes
prendre des décisions structurantes sans en équipes, les OPS et les Tech-Leads ont organisé
référer à 8 étages de management. La des ateliers pour démontrer par A+B que le
cohérence et le socle commun sont assurés par produit n’était pas adapté. Et heureusement,
des entités transverses. ils ont été écoutés.

Nous avons encore un peu de mal à tout Gâchis d’argent, peut-être, mais beaucoup
assembler, mais nous pensons tenir le “bon de positif en est ressorti : les OPS et les Tech-
bout”. Malgré nos pratiques communes, Leads des différentes équipes ont commencé
et nos rituels d’amélioration continue, les à se parler, et à échanger autour d’intérêts
passages entre les différents processus communs...
peuvent créer de la friction, du stock, et donc,
69 des ralentissements. Mais rien à voir avec ce
que nous avions précédemment ! Bon, on
n’est pas encore Facebook, mais l’équipe
d’industrialisation a fait un plutôt bon boulot.

Nous subissons encore les reliquats de notre


ancienne manière de faire. Nous manquons
d’harmonisation entre les équipes, et
même si elles ont fait des efforts, les équipes
d’infrastructure sont encore trop dans leur
monde : elles gèrent le run comme si c’était de
leur unique responsabilité. Tant que l’on reste
“dans les clous” de ce qu’ils proposent, tout
va bien, mais si l’on souhaite qu’ils gèrent une
nouvelle base de données par exemple, on se
retrouve face à un mur. C’est dommage, nous
sommes leurs clients, après tout.

Nous avons tout de même évité quelques


catastrophes quand une équipe d’architectes
d’entreprise a voulu nous imposer une solution
de PaaS “sur étagère”. Personne n’en avait
O C T O > C U LT U R E D E V O P S V O L . 3

Continuous Delivery
N’importe quel changement doit être testé, et •  Confiance dans les processus, car ils sont
ce en continu. Progressivement, ce que l’on joués souvent.
appelait intégration continue peut être étendu • Déploiements plus fréquents, donc avec des
vers de la livraison continue voire le Saint- changements plus petits.
Graal : le déploiement continu.
• MTTR (Mean Time To Repair) réduit car
Les gains de cette approche peuvent se résumer changements tracés, versionnés et de petite
ainsi : taille.
• Visibilité permanente du niveau de qualité de • Une preuve de la capacité à reconstruire
chaque version de code (quel qu’il soit, toute une plateforme, un premier pas vers un
infrastructure ou applicatif). modèle de DRP / PRA42.
70
• Filtrage très tôt des versions buggées, qui ne
pourront pas fonctionner.

PLAN CODE BUILD TEST RELEASE DEPLOY OPERATE

Intégration continue

Livraison continue

Déploiement continue

 Disaster Recovery Plan / Plan de Reprise d’Activité.


O C T O > C U LT U R E D E V O P S V O L . 3

Un cercle vertueux peut alors apparaître :

Plus petits
changements Moins
qui apportent d’impact
de la valeur unitaire
métier

71

Meilleure
Changements confiance
plus dans les
fréquents changements
O C T O > C U LT U R E D E V O P S V O L . 3

Pour que ces principes s’appliquent, il faut capacité (VM, conteneur…) à la place d’une
changer sa façon de penser les interactions ressource existante et non en modifiant une
avec les machines. Si un changement doit ressource existante.
avoir lieu sur une machine, c’est au travers
d’une portion de code testé et déclenché Dans les deux cas, les corrections auront
automatiquement qu’il doit intervenir. C’est préalablement été testées via la PIC avant de
la fin des changements de configuration à la donner le “Go”.
main. En poussant à l'extrême, deux tendances
peuvent émerger :
Principe
• Proscrire toute modification manuelle sur L’idée assez simple consiste donc à faire grossir
les machines. Seules les opérations en lecture le travail de la PIC pour qu’elle prenne en
seule sont autorisées et c’est au travers d’Infra- charge de nouveaux types de travaux plutôt
as-Code que les corrections seront déployées. tournés vers l’infrastructure. Provisioning43,
déploiement, configuration et bien entendu
• Proscrire toute modification d’une machine,
nouveaux tests sont au programme. Nouveaux
principe que l’on appelle également le rebuild
outils, nouvelles technologies, mais le principe
72 vs. upgrade. Si un changement doit être
reste identique.
opéré, c’est en reconstruisant une nouvelle

Code applicatif
Code d’infra

Solution déployée Degré de confiance


PIC avec de la valeur dans l’ensemble
Tests applicatifs métier de la solution
Tests d’infra

 Instanciation des éléments d’infrastructure nécessaires à notre application.


O C T O > C U LT U R E D E V O P S V O L . 3

En entrée, toujours du code, toujours des métriques et de supervision.


tests, simplement sur un périmètre plus large. • Backup  : intégration des services dans les
En augmentant ce périmètre, le degré de fonctions de sauvegarde (et de restauration).
confiance de l’objet produit augmente. L’objet
• Remontée de logs  : capacité à mettre en
produit augmente également, ce n’est plus
œuvre une centralisation des journaux sur des
une application, mais tout un système.
machines nouvellement créées.
La mise en place de ce genre de stratégie • etc.
gagne en efficacité si l’on est capable de
détruire et (re)construire des environnements, L’accès aux outils n’implique absolument
dynamiquement. Le cloud, les API et toutes pas un accès open-bar à ces ressources. Il ne
les technologies as-code sont alors d’un s’agit pas de remettre en questions les droits,
grand secours. Citons quelques services permissions, quotas. Il s’agit plutôt de donner
d’infrastructures que l’on aime pouvoir piloter un accès sur un contexte limité (dev, recette
programmatiquement : par exemple) aux équipes produits. Elles
deviennent alors autonomes pour manipuler
• IPAM44 : allocation de réseaux, d’adresses IP
toutes les ressources qu’elles souhaitent
73 pour de nouvelles plateformes.
dans la limite de quotas clairement exprimés
• DNS45  : gestion des enregistrements des (nombre de VMs, de vCPU, de stockage, de
machines, des services. sous-réseaux, d’adresses IP, de sous-domaines
• Règles de filtrage réseau entre réseaux et/ou DNS…).
entre machines.
En fonction des capacités disponibles dans
• Load-balancers : matériels ou logiciels, la
votre contexte, il est possible d’envisager
capacité à les configurer dynamiquement
différentes “profondeurs” de reconstruction :
permet de s’assurer de leur configuration, en
phase avec les applications gérées. • Les machines sont statiques, il faut
les réutiliser. Niveau très moyennement
• PKI  : j’ai un fournisseur de certificats qui
satisfaisant, vous devez mettre en œuvre des
est sollicitable à la demande pour gérer les
purges efficaces, ce qui est toujours compliqué
terminaisons SSL des services exposés.
pour s’assurer que l’on n’a bien tout nettoyé.
• Stockage : volumes, buckets. Niveau de confiance : 2/10.
• Machines  : allocation de capacités CPU et • Il est possible de reconstruire des VMs,
RAM (virtuelles voire physiques avec un peu volumes... en revanche nous ne disposons pas
d’entraînement). de levier simple pour reconfigurer le réseau,
• Monitoring  : intégration des machines, les règles de pare-feu (pas d’outil simple, pas
services avec les solutions de collectes de d’expertise, pas de droit). La purge des VMs

 IP Address Management.  Domain Name System, permet de traduire le nom d’un serveur (google.com) en son IP (216.58.201.206).
O C T O > C U LT U R E D E V O P S V O L . 3

permet une réelle remise à blanc des systèmes de travailler. Si vous adaptez un outil, vous
d’exploitation. C’est déjà mieux, mais ne permet serez infiniment plus efficace que si vous
toujours pas de prouver la maîtrise de la adaptez votre organisation en fonction de
configuration réseau, des load-balancers et du l’outil. Prenons comme exemple les workflows
filtrage de flux. Dommage, c’est souvent lors de d'intégration continue. Le pipeline d’un Git
l’intégration de ces composants que les difficultés Flow46 n’aura pas la même tête qu’un Trunk
se présentent et que le temps se perd. Niveau Based. De même, une équipe peut choisir de
de confiance dans le procédé : 5/10. livrer par tag, alors qu’une autre choisira de
livrer par branche.
Il est possible de tout reconstruire, du sol au
plafond. Que les machines soient à domicile C’est pour cela que nous privilégions les
(on-premise) ou sur le cloud, le procédé de outils qui permettent à votre dépôt de
construction est intégralement rejouable à code, de déclarer lui-même la structure de
loisir. Niveau de confiance : 10/10. son pipeline. Par cela, nous entendons par
exemple, les fichiers “.gitlab-ci.yml47” ou
Laisser de la liberté aux projets “.circleci/config.yml48”.
74
Attention néanmoins, à ne pas tomber dans Un exemple de pipeline sur Gitlab-ci consistant
le piège du “pipeline universel”. La vision en la création d’une bucket S3 via du code
pipeline d’un produit doit être construite par Terraform, en utilisant le nom de la branche :
l’équipe produit, et adaptée à leur manière

Pipeline Jobs 3

Validate Deploy Clean

validate create_bucket delate_bucket

 Comparaison des git workflows : https://fr.atlassian.com/git/tutorials/comparing-workflows.  Configuration d’un pipeline via un fichier
.gitlab-ci.yml https://docs.gitlab.com/ce/ci/yaml/.  Exemple de configuration Circle CI : https://circleci.com/docs/2.0/sample-config/.
O C T O > C U LT U R E D E V O P S V O L . 3

image:
name: hashicorp/terraform:0.11.11
entrypoint:
- '/usr/bin/env'
- 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'

variables:
TF_VAR_fqdn: "example.com"
TF_VAR_subdomain: "${CI_COMMIT_REF_SLUG}"

stages:
- validate
- deploy
- clean

before_script:
- terraform version
- terraform init

validate:
stage: validate
script:
75
- terraform validate
- terraform fmt -check=true

create_bucket:
stage: deploy
script:
- echo ${TF_VAR_subdomain}.${TF_VAR_fqdn}
- terraform workspace select ${TF_VAR_subdomain} ||
terraform workspace new ${TF_VAR_subdomain}
- terraform plan
- terraform apply -auto-approve
only:
- branches
except:
- master

delete_bucket:
stage: clean
script:
- echo ${TF_VAR_subdomain}.${TF_VAR_fqdn}
- terraform workspace select ${TF_VAR_subdomain}
- terraform destroy -auto-approve
- terraform workspace select default
- terraform workspace delete ${TF_VAR_subdomain}
only:
- branches
except:
- master
when: manual
O C T O > C U LT U R E D E V O P S V O L . 3

Prod-awareness :
ça veut dire quoi d’avoir
bien fait son travail ?
L’opérateur d’infrastructure est aujourd’hui C’est le métier de l’OPS, d’aller vers ce qui
un développeur à part entière. Oui, mais la causera le moins d’incidents sur sa plateforme.
production n’est pas un environnement local Il est responsabilisé à ce niveau, et se fera
de développement. C’est la vraie vie. Le mode réveiller la nuit en cas de dysfonctionnement.
difficile. On ne peut pas dire “c’est bizarre Au grand dam des développeurs, qui eux,
76
que ça ne marche pas sur les serveurs, sur ma doivent innover.
machine, ça marche”. Non. Les
infrastructures que notre code Et développeur doit lui aussi
construit doivent répondre aux "La stabilité, évoluer vers le DevOps. Ce
n’est pas un chemin à sens
contraintes “de la prod”. c’est aller contre unique. Prenons un exemple :
Être prod-aware, c’est avoir le changement. une application fonctionnant
conscience de ces contraintes à l’aide d’un gestionnaire
et de ce que les gens qui s’y
La simplicité, de processus, chargé de la
confrontent - les OPS - vivent c’est assurer la redémarrer à chaque fois que
au quotidien. Connaître cette maintenabilité." celle-ci est en erreur.
sueur froide lorsque l’on se
rend compte que l’action que Si l’application en question
l’on a réalisée a cassé la prod. Adopter une rencontre une erreur fatale
posture “chapeau noir” à la moindre demande non gérée, cette erreur la fait planter, et
d’évolution49. le watchdog mis en place se charge de
50

la redémarrer, à l’infini. La consommation


La stabilité, c’est aller contre le changement. de ressources s’envole, et l’application est
La simplicité, c’est assurer la maintenabilité. indisponible le temps de son redémarrage.

 https://fr.wikipedia.org/wiki/M%C3%A9thode_des_six_chapeaux.  Un chien de garde, en anglais watchdog, est [...] un logiciel utilisé en électronique
numérique pour s'assurer qu'un automate ou un ordinateur ne reste pas bloqué à une étape particulière du traitement qu'il effectue - source : Wikipedia..
O C T O > C U LT U R E D E V O P S V O L . 3

Peu de temps certes, mais, manque de chance, réalisé avec parcimonie voire crainte.
cette application est critique.
Nous voulons des applications observables : qui
L’alerting se met en marche, et la personne sont conçues pour faciliter les diagnostiques.
qui assure la permanence est prévenue, et Nous voulons des logs, des métriques, nous
priée de rétablir le service. Il se connecte à la voulons exposer des données sur leur état de
machine, et voit que l’application se comporte santé. L’état d’incertitude est le pire. De même,
normalement. Les logs ne sont d’aucune nous souhaitons comprendre "pourquoi ça ne
aide : une stack-trace de plusieurs dizaines marche pas" et non pas "pourquoi ça marche”.
de lignes. Dans le doute, il peut tenter un
redémarrage du serveur. Rendant l’application L’infrastructure a sa part de responsabilité ; le
encore plus indisponible. Mais il ne réussira à “delta surprise” entre l’environnement de pré-
diagnostiquer le problème qu’au prix d’une production et de production, les plateformes
longue investigation. Ce qu’il ne fera d’ailleurs branlantes sujettes aux micro-coupures, avec
sûrement pas, et préférera faire un roll-back pur des pics de congestions… Bref, “la prod”.
et simple, restaurant l’application à une version Il faut adopter ce nouveau paradigme dans
77 antérieure. Le développeur, le lendemain, ne le Definition Of Done d’une application
pourra que constater, et attendre la prochaine “prod-ready”. L’entreprise doit offrir aux
mise en production, six mois plus tard… concepteurs des applications un background
Nous ne voulons pas cela. Avoir conscience de pratiques communes afin de parvenir à
de la production, c’est se demander ce qui va ce résultat.
casser en premier, et comment le limiter, ainsi Pêle-mêle, voici quelques principes, dont certains
que comment aller plus vite pour diagnostiquer sont une redite des fameux “12 factor app51” et
et rétablir le service. de notre livre blanc sur les applications cloud-
Alors, que voulons-nous ? ready52.

Nous voulons comprendre ce que l’on fait : les Mon application est conçue
déploiements doivent être autant que possible
pour être scalable
standards, indépendants de l’environnement.
Un déploiement ne doit pas contenir de valeur Notre application doit être conçue dès le
ajoutée. Il doit être réalisable facilement départ pour absorber une charge grandissante.
et automatisable. Cela va de pair avec des Nous ne parlons pas ici de prévoir dès le
déploiements rapides. Un déploiement “lent” départ l’auto-scalabilité de l’application, mais
est vécu comme un événement, et donc, est de ne pas fermer définitivement cette porte.

 https://12factor.net/ : douze principes à respecter lorsque l’on souhaite concevoir une web-application moderne.  Voir notre publication sur le sujet : Cloud
Ready Applications : Concevoir vos applications pour tirer parti du Cloud - https://www.octo.com/fr/publications/23-cloud-ready-applications.
O C T O > C U LT U R E D E V O P S V O L . 3

Concevoir, par exemple, une application Si vous livrez plusieurs fois par semaine (ou,
stateful nous rendra la tâche plus compliquée. soyons fous, par jour !), vos clients ne doivent
pas s’en rendre compte : pour eux aussi, la
Nous avions pris pour habitude de mutualiser livraison doit être un non-événement.
nos infrastructures, pour des raisons de
simplicité, et de coût. Si provisionner un “Everything fails all the time53 “
serveur prend trois mois, c’est être agile que
de profiter d’un serveur existant pour y installer Et pourtant, “tout dysfonctionne, tout le
notre application. Et si en plus, vous devez temps”. Nous ne prenons plus les incidents
payer des frais de licences… comme des événements ponctuels et
aléatoires, mais comme un axiome. Notre
Exit les serveurs “fourre-tout”, sur lesquels infrastructure va subir des incidents. C’est
votre application cohabite avec son reverse- comme cela, pas autrement. C’est un pré-
proxy, sa base de données, et pourquoi pas, requis, qui doit influencer notre façon de
d’autres applications. Nous concevoir nos architectures : c’est
devons la diviser en petits le principe de design for failure54,
78
services ayant chacun une "Everything ou, “conçu pour supporter la
responsabilité bien bornée. défaillance”.
Grâce à cela, nous scalerons fails all the
C’est la suite de nos fameux
horizontalement (c’est-à-dire
en augmentant le nombre
53
time. " “plans de reprise d’activité55” et
de nœuds) le service en “plans de continuité d’activité56”
souffrance. La rapidité de notre provisionning (PRA/PCA). Avec eux, nous prévoyions que
et la mise à profit de l’écosystème gratuit nous quelque chose se passera mal, et un plan à
permettent cette élasticité à moindre coût. suivre dans ce cas. Malheureusement, cette
approche “tout ou rien” demande trop d’effort,
et est donc coûteuse à tester. Nombreux sont
Mon application est prévue les PRA/PCA, qui ne le sont que rarement
pour être hautement disponible (voire jamais). Et le jour tant attendu où votre
datacenter prend feu, ils se révèlent inefficaces.
Un système indisponible coûte de l’argent,
mais n’en rapporte pas. On ne peut plus Ce changement de paradigme transforme le
se permettre, aujourd’hui, de traiter principe même d’incident en business as usual.
l’indisponibilité d’un service comme étant un Plusieurs niveaux sont bien sûr possibles. Votre
état normal. Une application moderne n’est pas infrastructure peut être prévue pour résister à
censée afficher un message de maintenance. la panne d’un élément isolé, ou de plusieurs

 Werner Vogels, CTO d’Amazon.  Voir le chapitre : “Plus de capacités pour plus de tests” de cet ouvrage.
 https://fr.wikipedia.org/wiki/Plan_de_reprise_d%27activit%C3%A9.  https://fr.wikipedia.org/wiki/Plan_de_continuit%C3%A9_d%27activit%C3%A9_(informatique).
O C T O > C U LT U R E D E V O P S V O L . 3

en même temps, dans différentes couches. capacité à mitiger les dysfonctionnements, à


Quand un réel problème arrive, une fois celui-ci alerter en avance de phase et à se guérir tout
résolu, du temps doit être alloué à comprendre seul. Se rapprocher des conditions d’une vraie
comment faire en sorte que cela n’arrive plus. production est très dur. C’est d’ailleurs une
Et si cela arrive quand même, comment faire grande part du travail d’Ops : dérisquer les
en sorte que le service ne soit pas ou que peu passages en production en diminuant au
perturbé. maximum le différentiel avec vos environnements
“ante-prod”. Mais quoi qu’il arrive, vos
Le chaos engineering57 est le nom de cette utilisateurs, eux, ne seront toujours qu’en prod.
discipline, qui vous permet d’expérimenter Il faut donc bien s’outiller : une stack
la résilience de vos systèmes distribués. L’un d’observabilité efficace, pourquoi pas du
des exemples les plus connu est celui des chaos canary-release. Pensez dès le départ qu’il
monkeys  : introduit par Netflix, cet automate faudra créer des comptes “de tests”. Une
se charge de simuler (ou de déclencher) des approche DevOps de déploiement continu
pannes d’équipements au hasard, afin de vous mènera forcément à cela.
s’assurer de la résistance du système global.
79 Qui que soient vos utilisateurs, ceux-ci
L’approche du Testing in Production est même attendront de votre produit une qualité de
possible, pour peu que vous ayez une confiance service irréprochable.
suffisamment grande en votre système : en sa

Twitter is over capacity.


Please wait a moment and try again. For more information, check out Twitter status.

La page de maintenance de Twitter, tristement célèbre il y a quelques années.

 “Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent
conditions in production.” - http://principlesofchaos.org/.
O C T O > C U LT U R E D E V O P S V O L . 3

Mon application sait me Un log (technique ou métier) est une mine d’or
d’informations : c’est également la première
parler58
étape de la plupart des corrections de bug.
“L'observabilité est la capacité du système à Attention toutefois, à ne pas mettre n’importe
être appréhendé par l'homme afin qu'il puisse quoi dans vos logs, et surtout, à ne pas donner
le comprendre, le modifier et le corriger.59” accès à n’importe qui à ceux-ci. Les récentes
avancées en matière de respect de la vie privée
Une application passe, en général, plus de
des utilisateurs d’un système informatique (est-
temps en run qu’en build. Afin que celui qui en
il nécessaire de présenter le fameux RGPD ?60)
assure son bon fonctionnement puisse le faire
nous imposent d’être très vigilants quand à ce
dans les meilleures conditions possibles, celle-
que nous conservons : il sera par exemple sage
ci doit exposer son fonctionnement de manière
de chiffrer les données personnelles d’un
compréhensible. Cela s'appelle l’observabilité.
utilisateur avant de les conserver sur disque.
Elle se présentera sous plusieurs aspects :
• le monitoring, En dehors des logs, un autre moyen d’expression
indispensable est d’exposer de manière simple
• l’alerting et la visualisation,
80 des données critiques, permettant de comprendre
• tracing des système distribués, rapidement l’origine des dysfonctionnements
• l'agrégation de logs ou de métriques. les plus courants, via une URL de health-check61.

[ops@dev-api ~]$ curl https://app.com/api/v2/status


{"version":"3.0.1","sha1":"6c0bc125da5d78bb756d 11d01e78aa6e822da
eb","databaseStatus":"up","redisStatus":"up","currentDate":"2018-
11-26T16:44:59+00:00","backendStatus":"up"}

Ou encore, pourquoi pas, témoigner de sa charge (ici un exemple avec NGINX) :

[ops@dev-rp ~]$ curl localhost:81/basic_status


Active connections: 1
server accepts handled requests
316945 316945 317598
Reading: 0 Writing: 1 Waiting: 0

 Observabilité – compte-rendu du talk de Fabien Arcellier à La Duck Conf 2019 :


(https://blog.octo.com/observabilite-compte-rendu-du-talk-de-fabien-arcellier-a-la-duck-conf-2019/).
 Décommissionner sans paniquer (https://blog.octo.com/decommissionner-sans-paniquer/).  Règlement général sur la protection des données, texte de loi
européen visant à harmoniser les lois des différents pays de l’Union Européenne.  Un appel sur une URL de health check va exécuter un test pour s’assurer qu’un
composant rend correctement le service qu’il est censé remplir - source : Cloud Ready Applications https://www.octo.com/fr/publications/23-cloud-ready-applications).
O C T O > C U LT U R E D E V O P S V O L . 3

Ces indicateurs, health-checks, et autres routes pas très photogénique : des documents de
d’observabilité rendent votre application plusieurs dizaines, voire centaines de pages
exploitable, mais vous permettront également d’une “politique de sécurité informatique”.
de rendre vos futurs développements plus Laconiquement y sont décrits des principes
rapides : l’application n’est pas une boîte noire, abstraits et irréfragables que tout projet doit
mais elle témoigne de son fonctionnement ou respecter.
de ces dysfonctionnements. Grâce à cela, un
Site Reliability Engineer62 sera plus rapide à Avant l’ouverture au public, les équipes de la
prononcer un diagnostic. “Sécurité” mandateront un audit indépendant.
Cet audit arrive souvent “trop tard”, et les
Plus les indicateurs seront fins, plus nous serons préconisations, sont parfois trop structurantes
à même de monitorer notre application : via pour être facilement applicables. Le projet
des deltas de performance par exemple, mais prend du retard, ou se voit carrément remis en
également via des données “métiers” : une baisse question.
des commandes sur un site de e-commerce
peut tout à fait être la conséquence d’une
81 régression introduite au niveau infra (une
nouvelle règle firewall qui empêche de contacter
l’API de paiement ?)

L’observabilité n’est pas un luxe, ni quelque


chose qui doit intervenir “juste avant une mise
en prod”. Vous devez traiter cela comme un
first-class citizen63, au fur et à mesure de vos
développements.

Mon infrastructure est


sécurisée by design
Lorsque que l’on parle de sécurité, souvent, les
esprits se crispent. Cinéma, séries télévisées,
actualités… La sécurité informatique semble
nourrir plus de fictions que de projets
informatiques. Étrangement, la réalité n’est

 Le SRE, concept apporté par Google qui consiste à une implémentation du DevOps en rendant les développeurs responsables des opérations et de
l’infrastructure.  “Objet de première classe”, un élément important qui a une place de premier choix - source : Wikipedia https://en.wikipedia.org/wiki/First-class citizen.
O C T O > C U LT U R E D E V O P S V O L . 3

Un cycle DevOps classique

PLAN PROVISION

CODE SETUP

REVIEW DEV OPS DEPLOY

TEST OPERATE

RELEASE MONITOR

82

Un cycle DevOps perturbé par un audit sur la sécurité des infrastructures

PLAN PROVISION

CODE SETUP

REVIEW DEV AUDIT DE


SÉCURITÉ
OPS DEPLOY

TEST OPERATE

RELEASE MONITOR

STOCK DE
FEATURES
O C T O > C U LT U R E D E V O P S V O L . 3

La mouvance DevSecOps propose d’intégrer un projet sont pleinement compétentes pour


la sécurité dans votre processus de livraison créer une architecture respectant les principes
continue. Comme l’agile l’a fait avec les cahiers de sécurité généraux, et prendre les décisions
des charges rigides et à rallonge, comme le spécifiques à leur projet.
DevOps l’a fait avec les délais de livraison et
les accidents en production, le DevSecOps Les outils permettant de réaliser des scans de
veut le faire avec la sécurité. vulnérabilités en mode “audit”, type Nessus64,
OWASP ZAP65, ou encore Wapiti66 ont encore
Les pratiques DevSecOps reposent sur 4 leur place. Mais leur exécution, trop lente,
piliers : ne permet pas de les intégrer à notre chaîne
• placer les compétences sécurité au cœur des d’intégration continue. Ils interviendront de
projets, manière régulière, en nightly par exemple.
• faire de la sécurité plus tôt dans la chaîne de Seront préférés des outils avec des temps
développement, en continu, d'exécution plus adaptés : scan des vulnérabilités
• avoir une sécurité orientée business, dans les dépendances, avec npm audit67
• piloter par la donnée et des tests réels. par exemple pour nodejs, indispensable de
83
nos jours68. Nous pouvons aussi utiliser des
Concrètement, cela signifie que la politique de outils comme Gauntlt69, qui permet d’écrire
sécurité ne se passent plus via un document des tests de sécurité en BDD (Behaviour
Word, mais via des communautés de pratique Driven Development), comme pour des tests
et des formations : les personnes qui réalisent Cucumber.

# nmap-simple.attack
Feature: simple nmap attack to check for open ports

Background:
Given "nmap" is installed
And the following profile:
| name | value |
| hostname | example.com |

 https://www.tenable.com/products/nessus/nessus-professional.  https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project.  http://wapiti.


sourceforge.net/.  https://docs.npmjs.com/cli/audit.  https://docs.npmjs.com/cli/audit.  Dernière histoire en date où nous écrivons ces lignes, une librairie nodejs
qui, suite à un transfert de propriétaire, a commencé à inclure un malware visant à voler les portefeuilles de bitcoin
https://www.nextinpact.com/brief/node-js---une-bibliotheque-populaire-verolee-vise-un-portefeuille-de-crypto-monnaies-6747.htm.  http://gauntlt.org/.
O C T O > C U LT U R E D E V O P S V O L . 3

Scenario: Check standard web ports


When I launch an "nmap" attack with:
"""
nmap -F <hostname>
"""
Then the output should match /80.tcp\s+open/
Then the output should not match:
"""
25\/tcp\s+open
"""

Exemple issu de la documentation de http://gauntlt.org.

de plus, ce genre de scripts peut très facilement Le pattern de “l’OPS dans la feature
84 être réutilisé et partagé au sein d’une même team70”, qui consiste à avoir une personne
DSI, via des communautés de pratique. dédiée à construire l’infrastructure n’est pas
Ces outils ne sont que quelques exemples, incompatible avec ce principe. Tant que
expliquant comment injecter de la sécurité au votre bus factor71 n’est pas égal à “1”, c’est-
plus tôt, dans vos pipelines de développement. à-dire, tant que la compétence pour gérer
Les principes d’automatisation du DevOps l’infrastructure n’est pas concentrée en une
s’appliquent ici comme ailleurs : plutôt que seule personne, votre risque est dilué.
de faire des tests manuels pour vérifier que
votre application n’est pas sujette à des failles,
automatisez ces tests.

La feature team partage la


connaissance de la production
L’organisation de l’équipe doit être telle, que
l’infrastructure est collective. Il ne doit pas y
avoir un OPS responsable de l’infrastructure.

 Voir le chapitre “DevOps : vers l’autonomie et la responsabilisation des équipes” de notre publication Culture DevOps Vol.01 - https://www.octo.com/fr/
publications/30-culture-devops-vol-01.  Le “bus factor” est la mesure du risque encouru en cas de non-partage des connaissances et des capacités des membres
d’une équipe, venant de la phrase “si je me fais renverser par un bus”.
O C T O > C U LT U R E D E V O P S V O L . 3

Les anti-patterns et les façons d’en mitiger les effets néfastes72

Le super héros Le moine codeur


Résout vos problèmes mais… casse tout Implémente tout ce que vous voulez mais…
autour pour le faire. dans son coin.

85

Le grand architecte
Fait un dossier d’architecture pour chaque évolution mais …
il se retrouve périmé après chaque implémentation.

Le critique L’archiviste
A des convictions sur tout mais … Refactore le code tout le temps mais …
n’a jamais rien implémenté de concret. ne fait rien de nouveau.

Ces anti-patterns peuvent être limités grâce à certaines pratiques. Voici la liste des mieux
adaptées :
Le super héros : Tests automatisés
Le moine codeur : Revue de code, Pair programing...
Le grand architecte : Documentation As Code.
Le critique : Retrospectives, atelier d’archi, mob programming.
L’archiviste : Definition Of Done & tests d’acceptance automatisés.
O C T O > C U LT U R E D E V O P S V O L . 3

Il y a différentes manières d’éviter les anti- • Exercices incendie infra - Chaos Katas
patterns de silotage des compétences. En plus Ludiques et didactiques, les “exercices incendie
de l’évidente co-localisation des équipes, dans infra” consistent à créer artificiellement un
le cadre d’une feature team, nous privilégions problème, et de simuler une réunion de crise
bien souvent les suivantes : pour résoudre ce problème. Bien évidemment,
le mieux est de trouver un dysfonctionnement
• La présentation informelle - Show me your bloquant (ou déclenchant une alerte) sur un
stack environnement à faible enjeux business (a.k.a.,
Au détour d’un couloir, pendant un déjeuner, pas la prod), et de surtout, s’arranger pour ne
prendre le temps d’expliquer son architecture, pas avoir le temps d’aider. Vous pouvez tout au
et les principes avec lesquels on a conçu son plus donner quelques indices.
application. C’est le niveau 1 du partage, qui s’il
se ritualise, peut aboutir à des communautés Pêle-mêle, voici quelques pistes :
de pratique. • Remplir un disque
• Arrêter une base de données
• Vis-ma-vie d’OPS •sudo iptables -A OUTPUT -o eth0
86
Pendant une journée, ou plus, un membre -m owner --uid-owner nodejs -j
de l’équipe de développement jouera le rôle DROP
d’un “OPS débutant”, mentoré par l’OPS = interdire une interface réseau à un
titulaire. Cette pratique lui permettra de se utilisateur spécifique
rendre compte des contraintes inhérentes à ce
métier et du rythme qui est différent. En faisant Ces Chaos Katas73 permettent aux développeurs
travailler ensemble des personnes qui n’en ont de prendre conscience de l’importance
pas l’habitude, vous amènerez de l’empathie d’éléments que nous avons cités plus haut :
en plus d’un mélange des savoirs. lorsque l’on se retrouve à devoir debugger
une application muette, on se rend très vite
• Peer review et pair/mob programming compte de l’importance de produire des logs !
Plus compliqué à mettre en place, car il faut
bien choisir les éléments sur lesquels on
souhaite “pairer”, ou “mober”. Néanmoins,
cela permet de donner efficacement des clefs
pour mieux comprendre les problématiques
d’infrastructure.

 Alexandre Raoul, Un peu de craft dans votre infra, 2018 - https://www.youtube.com/watch?v=CapWzdjYF5I.  Apparu en 2018 dans le Technology Radar Volume 19
de ThoughtWorks - https://www.thoughtworks.com/radar/techniques/chaos-katas.
O C T O > C U LT U R E D E V O P S V O L . 3

Le rôle du management :
accompagner plutôt
qu’imposer
Être le terreau vers les pratiques que nous décrivons dans cet
ouvrage ? Notre premier réflexe sera de former
et non le jardinier
ces équipes. Les former aux pratiques DevOps
Une transformation DevOps est quelque chose et à l’importance de la qualité. Automatiser
87
de délicat à réaliser. Ce n’est pas simple (et sans qualité, n’est que ruine de la prod. L’auto-
souvent coûteux) pour les équipes d’infrastruc- matisation, et le DevOps, nous permettent de
ture et de développement de changer de mo- manager efficacement des tailles d’infrastruc-
dèle. D’autant que pendant ture toujours plus impression-
que tout cela se déroule, la nantes. Mais en inventant l’avion,
prod elle, continue de tourner Inventer le train, nous avons inventé le crash aérien.
(ou parfois, de ne plus tourner !). c'est inventer le Là où l’action manuelle a cela de
Il n’est pas raisonnable de rassurant qu’elle a bien souvent
penser, après la lecture d’un
déraillement, une portée limitée, l’action auto-
article (ou d’une publication), inventer l'avion matisée, elle est de portée in-
dustrielle by design. Une erreur
que la qualité dans le DevOps c'est inventer le
est quelque chose de simple. dans un déploiement manuel et
Permettez-nous d’insister sur crash74 votre serveur est cassé. Cette
ce point : la qualité dans le même erreur appliquée au code
code d’infrastructure est quelque chose de d’automatisation, et c’est toute votre
récent et de complexe. infrastructure qui est indisponible.

“Inventer le train, c'est inventer le déraillement, Investir dans un “harnais de tests” efficace
inventer l'avion c'est inventer le crash74” dans le sens où celui-ci permet de détecter les
défauts de qualité le plus en amont possible
Alors comment le “management” d’une entreprise de la chaîne de production est une nécessité
peut-il encourager ses équipes à ses tourner
O C T O > C U LT U R E D E V O P S V O L . 3

pour profiter sereinement (et donc pleinement) Quelques exemples de discussions :


des gains d’une organisation DevOps. • Retours d'expérience sur une solution logicielle
ou un prestataire.
L’un des freins classiques à la transformation en
entreprise est le “trop occupé pour • Présentation et mise à disposition de
s’améliorer”. Appliqué à des équipes de “morceaux de code”.
production, cela veut dire être constamment • Mob-Programming pour tester une nouvelle
en train de gérer des urgences : c’est ce qu’on technologie prometteuse.
appelle le “mode pompier”. Le nez dans le • Passage en revue des supports de l’OSSIR75.
guidon, les équipes ne pourront pas d’elles-
• Construction et généralisation de KPI de
même demander un temps mort. Il faudra que
qualité d’infrastructure.
quelqu’un, dans l’organisation,
le fasse pour elles. Quelqu’un Ce cercle vertueux pourra
qui puisse aller jusqu’à leur "On n’inflige pas décider d’action d’évangélisation,
imposer de prendre le temps. une transformation afin de diffuser largement une
vision de la qualité taillée pour
Formez-les au développement, DevOps : on
88 votre entreprise. Grâce à ces
au Software Craftsmanship. l’accompagne."
rituels, identifiez et promouvez
Mettez-leur les mains dans le
des “champions” de la qualité,
cambouis d’outils magiques.
capables de faire référence sur
Une équipe qui revient d’une formation Ansible
certaines expertises pointues, comme la
ou Docker, voudra absolument tester ces
sécurité, le réseau...
produits dans son environnement !
Le tout est de co-construire. Une direction
Encouragez l’émergence d’une organisation
efficace ne doit pas infliger de l’aide.
apprenante : faites du partage des bonnes
pratiques une valeur centrale de votre Dans le même esprit, attention à ne pas
organisation, en créant des espaces d’échanges. succomber au chant des sirènes des “solutions”
Une “Communauté de Pratiques DevOps” qui DevOps. Certains éditeurs savent se montrer
se réunit toutes les semaines, à entrée libre, très convaincants quand il s’agit de présenter
permettra de créer des synergies dans vos leur nouveau produit, capable de rendre votre
équipes. Au sein de ces rassemblements, pas entreprise “DevOps ready”, “DevOps
de sujets imposés. compatible”... Allant même jusqu’à présenter
des KPI : gain en rapidité, baisse d’effectifs des
opérateurs...

 Paul Virilio (1932-2018), urbaniste et essayiste français.


 Observatoire de la Sécurité des Systèmes d'Information et des Réseaux https://www.ossir.org/paris/supports/liste.shtml
O C T O > C U LT U R E D E V O P S V O L . 3

DevOps est d’abord une philosophie. Une former aux bonnes pratiques de code, il existe
remise à plat permettant de donner plus de une multitude de sites internets que l’on peut
responsabilités aux équipes. Si la direction utiliser : Kata-log76, codewars77 ou encore
cherche à leur imposer une solution qu’ils n’ont exercism78 pour ne citer qu’eux. Le point
pas choisi, il y a de très forte chance que cette d’attention ici sera à porter sur l’état d’esprit
entreprise ne soit absolument pas “DevOps de votre candidat au DevOps : est-il capable
ready”. de travailler en pair-programming ? Trop
d’années passées à travailler en mode “moine”
Former les bon profils (dans son coin) peut rendre complexe la
transition à un mode plus collaboratif.
Les profils DevOps sont rares sur le marché et
suffisamment chers pour que la solution de les Vous l’aurez compris, le DevOps demande un
former soi-même soit viable. Au-delà du sujet panel de compétences compliqué à trouver. Il
largement traité du “comment attirer les bons est donc plus facile de ne pas “partir de zéro”.
profils”, via le cadre de travail et en utilisant Mais quel que soit d’où l’on part, le chemin ne
des technologies en vogue, nous souhaitons sera pas de tout repos et nécessitera un
89 présenter les différentes stratégies possibles. candidat prêt à remettre en question ses
connaissances autant que son savoir-être.
• Recruter un développeur, et le former à la
prod-awareness (approche SRE) : Traiter l’infrastructure comme
Un développeur fera un bon candidat au poste un produit à part entière
de DevOps. Il connaît déjà l’algorithmique et
les besoins des développeurs d’applications. Il Tout comme l’Agile pousse à migrer d’un
ne manquera plus qu’à le former à la mode projet à un mode produit79, l’infrastructure
production, à lui faire ressentir ces petits tracas doit s’extirper de son run. Votre infrastructure
du quotidien des OPS. Attention néanmoins, doit être traitée comme un produit : elle a ses
s’il lui faut rattraper un retard sur l’adminsys à clients, qui sont, au final, les équipes produits :
proprement parler. C’est un champ de des POs, des développeurs, d’autres OPS…
compétences complexes mêlant réseau, L’infra en tant que produit se doit d’adopter,
sécurité, stockage, connaissances Linux et entre-autres, une vision, une roadmap
Windows… Et la mauvaise nouvelle, c’est qu’à dynamique et un Product Owner.
l’heure actuelle, acquérir ces connaissances est
compliqué. Maintenant produit, l’infrastructure va devoir
conquérir ses utilisateurs :
• Recruter un OPS et le former au Software • La qualité sera un critère de choix.
Craftsmanship :
• La satisfaction devra être mesurée.
Un opérateur d’infrastructure que l’on forme à
• Happy Employees, Happy Customers.
la qualité est une autre possibilité. Car pour se
O C T O > C U LT U R E D E V O P S V O L . 3

Paré de ces atours, le socle d’infrastructure capable de répondre positivement ou


sera plus à même de séduire les équipes de négativement aux demandes. Grâce à ce
développement, et de répondre à leurs changement de paradigme, nous pourrons
attentes. Elles pourront désormais compter sur enfin mettre l’infrastructure au service des
une interface unique, le Product Owner, projets et des métiers.

90

 http://kata-log.rocks/.  https://www.codewars.com/.  https://exercism.io/.


 Passer du mode projet au mode produit : https://blog.octo.com/passer-du-mode-projet-au-mode-produit/.
O C T O > C U LT U R E D E V O P S V O L . 3

Annexes
91

Exemple :
platef rme
de c nteneurs
O C T O > C U LT U R E D E V O P S V O L . 3

Contexte initial Les limites


Dans cet exemple, l’entreprise bidibule met en Plusieurs types de limites sont actuellement
œuvre une plateforme d’exécution pour atteintes.
conteneurs ou CaaS80 pour ses projets à l’aide
de Kubernetes. Une approche on-premise sur Supervision laborieuse : les métriques remontées
3 datacenters bien interconnectés. Après un par le cluster et ses applications sont rares ou
POC81 plutôt convaincant, l’entreprise a difficilement exploitables car elles se transposent
déployé manuellement un cluster, l’a intégré à mal dans l’outil de supervision historique
une solution de stockage (Ceph) également (Centreon). Ce dernier est en effet peu adapté
distribuée sur les 3 DC et montée à la main. à des systèmes distribués, dynamiques, utilisant
Elle a également mis en œuvre un dépôt privé des conteneurs à durée de vie très limitée.
d’images Docker (Registry). Les deux Journalisation délicate. Il est toujours compliqué
composants (Kubernetes et la Registry) ont été de suivre les événements sur Kibana. Difficile
intégrés à la gestion d’identité de l’entreprise. de donner du sens à un imbroglio de traces qui
92
La mise en œuvre de cette architecture, même s’enchaînent sans réelle cohérence.
si elle donne désormais de très bons résultats a
été longue à stabiliser : jeunesse des solutions Des changements de version des clusters
retenues, méconnaissance des technologies Ceph et Kubernetes à prévoir. Ces montées
tant côté de la production de la plateforme de version, même si théoriquement possibles
que côté applicatif où l’on mesure difficilement sans interruption de service font craindre des
les impacts sur les patterns logiciels à mettre ondes de choc douloureuses. Il suffit de
en œuvre. Une pile E/F/K (ElasticSearch, regarder la première mise en place de la
Fluentd, Kibana) a été mise en œuvre pour solution pour s’attendre au pire.
centraliser les journaux.
Peu de suivi de l’obsolescence des images
Les applications qui sont déployées dans le construites et déployées. Même si
cluster ont des degrés de maturité très mécaniquement, les images exposent une
hétérogènes. Les projets construisent des surface réduite face aux risques d’attaque, le
images sans réels guides de bonnes pratiques. RSSI continue à suivre les CVE sur les souches
Certains construisent une image par plateforme, systèmes qui servent de socle aux images avec
d’autres créent des images qui tirent du code une certaine anxiété.
source au démarrage.

 CaaS : Container as a Service.  POC, Proof Of Concept : preuve de concept.


O C T O > C U LT U R E D E V O P S V O L . 3

ANNEXE > Exemple : plateforme de conteneurs

Les promesses de l’approche La plateforme est constituée des composants


principaux : Ceph, Etcd, Kubernetes. En fonction
continue
des instances, sa géométrie est variable :
À l’identique de l’exemple 1, la mise en place instance simple, représentative de toutes les
d’une approche continue de la qualité doit exigences en termes de haute-disponibilité :
permettre de contrôler les risques et limites simulation de 3 DC. Elle s’accompagne en
évoqués. Au travers d’un feedback permanent, outre d’au moins une application blanche pour
il est possible d’avoir une vision claire sur la prouver le déploiement correct dans le cluster.
situation, les tests qui passent, ceux qui Il est possible d’utiliser une application Web
échouent, les scénarios qui sont validés et ceux par exemple utilisation un volume RBD82,
qui ne le sont pas. CephFS, et/ou un stockage objet si ces trois
têtes sont exposées sur Ceph. L’opérateur du
Les changements à opérer service CaaS est en charge d’écrire des tests
d’infrastructure (avec pytest-ansible) pour
 Double intégration continue valider que la plateforme répond aux attentes :
93
La première chose à concevoir est une intégration • Configuration de base des composants
à deux niveaux. techniques : présents en nombre suffisant,
configurés pour écouter uniquement sur des
Une première intégration continue valide la
ports en HTTPS, sans accès anonyme.
plateforme. L’objectif est de prouver la
capacité à reconstruire la plateforme (plusieurs • Création des espaces de travail pour les
instances), dans sa version actuelle et de tester projets (namespaces Kubernetes) suivant les
rapidement les scénarios de montée de version principes d’isolation et de nomenclature
des différents composants. Avec une telle attendus (pose de labels, ségrégation des
visibilité, la procédure (ou les procédures si en permissions entre projets…).
définitive plusieurs étapes successives sont
nécessaires) est jouée en automatique de • Tests des procédures de backup et de
nombreuses fois avant le jour J. restauration fournies par la plateforme (avec
Ark).
Les utilisateurs de la plateforme sont les
opérateurs de service en charge de fournir la • Validation de versions des composants dans
fonction de CaaS aux équipes produits (centrées le cas où des CVE ont été identifiées.
sur les applications).

 RBD : Rados Block Device. Mode d’exposition de Ceph au travers d’un périphérique de type block (comme un disque) distant. Une fois mappé sur une machine, il
peut être formaté puis monté comme un système de fichiers classique (en ext4 par exemple).
O C T O > C U LT U R E D E V O P S V O L . 3

Pour chaque évolution, un test accompagne le  Ajout d’un outil d’analyse de


code d’infrastructure fourni : soit pour identifier vulnérabilités
que des mauvaises configurations sont bien
corrigées, soit pour tester une nouvelle Un outil d’analyse de vulnérabilités est inséré
fonctionnalité qui n’existait pas. dans les pipelines de construction des images
des applications. Son principe : grâce aux
Une seconde intégration continue valide les bases de vulnérabilités connues dans les
applications. Suivant le modèle classique paquets des distributions standards d’images
d’intégration continue d’une application Docker (Centos, Ubuntu, Debian, Alpine Linux),
Docker, un pipeline standard (même s’il peut cet outil permet de vérifier que les images
et doit être adapté par projet) est utilisé sur les Docker n’ont a priori pas de faille connue. Clair
applications : de CoreOS est une implémentation open source
qui convient pour réaliser ce travail. Notez
1. Compilation et tests unitaires du code.
toutefois qu’il s’agit là d’un outil d’analyse
2. Construction des images Docker à partir statique qui n’est en mesure d’analyser que
94 d’un dépôt de code et d’un Dockerfile en les paquets standards des distributions
mode “build once, run everywhere83”. supportées. Les logiciels déployés autrement
(recompilés ou via une archive décompressée
3. Tests “live” des images en mode unitaire manuellement) ne seront pas analysés. Il ne
pour vérifier au minimum leur bon démarrage. s’agit donc que d’un élément de réponse partiel à
tous les enjeux de sécurité de l’entreprise.
4. Tests d’intégration.
Cet outil a donc vocation à être utilisé à deux
5. Publication des images sur un registre privé
occasions : systématiquement lors de la
après analyse des vulnérabilités (voir ci-dessous).
construction des images, et périodiquement.
6. Déploiement sur les environnements suivant Dans ce second mode d’utilisation, cet outil
une stratégie de tests spécifique au projet. Les est également lancé régulièrement sur toutes
environnements sont modélisés au travers de les images en cours d’utilisation sur Kubernetes.
namespaces Kubernetes. Ils permettent d’assurer Une menace peut en effet être référencée sur
le cas échéant l’isolation des projets, des les sites publics (CVE84) à tout moment donc
instances de plateformes et d’une éventuelle (par définition) après la construction des images.
ségrégation des permissions entre les intervenants Il est nécessaire de détecter les failles de
sur le pipeline. sécurité réellement présentes sur le SI.

 “Build once, run everywhere” : principe de construction des artefacts qui les veut indépendants de la plateforme sur laquelle il seront déployés. Les bienfaits de ce
principe : les images construites une seule fois dans la P.I.C. sont transportées d’un environnement à un autre sans subir d’altération ou de reconstruction.
 Common Vulnerabilities and Exposures ou CVE est un dictionnaire des informations publiques relatives aux vulnérabilités de sécurité. Le dictionnaire est maintenu par
l'organisme MITRE, soutenu par le département de la Sécurité intérieure des États-Unis - source : Wikipedia.
O C T O > C U LT U R E D E V O P S V O L . 3

ANNEXE > Exemple : plateforme de conteneurs

 Repenser le modèles de supervision outils comme Prometheus sont capables de


collecter des métriques très diverses, bien au-
L’utilisation de cluster de gestion de conteneurs delà du monde des conteneurs : compteurs du
comme Kubernetes impose de repenser le système, applicatifs spécifiques. Si vous êtes
modèle de supervision historique. Les spécificités prêts à faire le deuil d’une solution comme
du modèle d’exécution de conteneurs (très Centreon, vous pourrez vous y retrouver avec
grand nombre d’objets, durée de vie courte, des fonctions de visualisation de graphes bien
déplacement d’une machine à l’autre, nouveaux plus avancées, au détriment des fonctions de
concepts) rendent les outils historiques peu remontées d’alertes (alerting) plus pauvres.
adaptés en standard.
• Avoir une approche hybride : garder
Une nouvelle génération d’outils (citons à titre Centreon pour les serveurs et leurs indicateurs
d’exemple Prometheus, InfluxDB, Thanos, traditionnels (CPU, RAM, Disque…) de nœuds
Grafana…) sont donc apparus avec comme et utiliser le nouvel écosystème pour les
objectif de répondre à ces nouveaux enjeux métriques spécifiques aux conteneurs. Le
95 (découverte, inventaire dynamique, scalabilité). meilleur des deux mondes, au détriment d’une
Ils sont nativement capables de collecter, stocker cohérence de l’ensemble si vous ne faites pas
et grapher des indicateurs liés aux conteneurs. le fastidieux travail d’intégration.

Plusieurs orientations peuvent être envisagées :


 Adaptation des applications
• Coder des connecteurs et agrégateurs pour
Les applications ne sont pas en reste puisque
remonter des indicateurs dans Centreon.
plusieurs types de transformations sont proposées.
Compatible avec le format de plugins Nagios,
Centreon est tout à fait capable de s’interfacer Architecture Cloud-ready. Les équipes des
avec des scripts shell qui réalisent la glue entre applications doivent être accompagnées pour
les modèles de Kubernetes et de Centreon. De les aider à percevoir les avantages et les
nombreuses limites apparaissent dans cette contraintes des architectures dites cloud,
approche : difficulté de modéliser les concepts naturellement disponibles et scalables. La
de haut niveau de Kubernetes (namespaces, présentation des 12-factor apps et leur
replicasets, deployments, pods…), difficulté à implémentation constitue un conducteur, en
agréger des indicateurs distribués (et mobiles) insistant sur certains éléments majeurs :
sur plusieurs nœuds, mais offre l’avantage de ne
• Séparation des composants à état “stateful”
pas trop changer les pratiques…
et des composants sans état “stateless”.
• Oublier l’outillage historique et basculer • Injection des données d’environnement dans
intégralement dans le nouvel écosystème. Les les applications (variables d’environnement ou
O C T O > C U LT U R E D E V O P S V O L . 3

fichiers de configuration montés dans les Conclusion


conteneurs).
• Contraintes sur le démarrage et l’arrêt des Dans ce cas, une architecture ambitieuse est
applications. utilisée. Malgré les nombreuses promesses de
ces technologies, elles ne peuvent être maîtrisées
• Etc.
sans une approche continue de la qualité et un
Gestion des métriques applicatives. En feedback permanent prouvant que le cluster et
fonction des choix sur le modèle de supervision, les applications qu’il héberge font bon ménage.
l’exposition d’une URL de monitoring peut très
simplement ajouter de la valeur en exposant
des métriques applicatives. L’utilisation de
Prometheus côté serveur combinée à la
librairie client Prometheus côté application
(disponible pour tous les langages standards)
permet d’exposer et de collecter très
96
rapidement des indicateurs. Un pas de plus
vers une meilleure observabilité.

Corrélation des journaux. La normalisation


des journaux doit être prise en compte pour
permettre de suivre l’intégralité du parcours
d’une demande cliente. Si un message entre
dans le système et qu’il n’a pas encore
d’identifiant de corrélation, un lui est
aléatoirement attribué. Tous les appels à des
sous-systèmes doivent par la suite propager
cet identifiant (dans les entêtes HTTP par
exemple). Les composants suivants, si
l’identifiant est déjà présent, doivent le
propager. Dans tous les cas, l’identifiant doit
être mentionné dans les traces (journaux). Il
pourra être utilisé par la suite comme un filtre
dans Kibana.
O C T O > C U LT U R E D E V O P S V O L . 3

97 C nclusi n
O C T O > C U LT U R E D E V O P S V O L . 3

98

Apophis : dieu des forces mauvaises et de la nuit, personnification du chaos, du mal,


de l'obscurité, cherchant à anéantir la création divine.
Loi de Murphy : tout ce qui est susceptible d'aller mal, ira mal. Ou, comme
l'a exprimé Werner Vogels (CTO d'amazon), « Everything fails all the time ».
Règle de conception, on ne considère pas la loi de Murphy comme vraie, mais on conçoit tout
système comme si elle l'était. Une application doit être à l'épreuve non seulement des accidents les
plus improbables, mais aussi des manipulations les plus inappropriées de la part de l'utilisateur.
O C T O > C U LT U R E D E V O P S V O L . 3

Les applications évoluent en territoire hostile : et ce n’est pas en isolant la connaissance ou en


l’infrastructure. Ici, la seule loi est celle de semant la terreur qu'émergera un produit
Murphy. Longtemps, le plan a été simple pour d’exception. Individuellement, la qualité ne
éviter les vagues : ne pas y toucher. Ou alors le doit faire aucun doute. On ne “croit pas en les
moins possible. Mais les méthodologies tests” : ceux-ci sont indiscutables. Il est de la
agiles sont arrivées, obligeant ce monde si responsabilité collective de bâtir la qualité,
stable à se réinventer. chacun doit y participer.

DevOps a forcé les équipes d’infrastructure Les nouvelles pratiques de qualité sont encore
à se réorganiser : ils doivent désormais parler jeunes, mais progressent vite. Nous construisons
avec les développeurs d’application autrement encore nos manières de faire et il y a fort à
que par tickets interposés. Ce contact prolongé parier que dans dix ans, tout ce que nous avons
a amené de la porosité dans les pratiques : décrit ici aura été remplacé, obsolète : c’est ce
chacun a pu apprendre de l’autre. Les OPS ont qui fait la beauté de notre métier.
alors eu la douloureuse surprise de se rendre
compte que leur manière de faire relevait de
99 l’amateurisme, voire de l’inconscience.

Seule mesure de la qualité : l’uptime. Seuls


tests : un environnement plus ou moins
semblable à celui de production sans données
utilisateurs, sur lequel sont testés les scripts de
déploiement. Comment l’informatique a-t-
elle fait durant toutes ces années pour ne
pas totalement s'effondrer ? La révolution
numérique est au coeur de la transformation
de nos sociétés et pourtant soyons honnêtes :
la plupart du temps ce n’est que bricolage. Il
devient de plus en plus critique de mettre
en place des filets de sécurité.

L’entreprise doit absolument ne plus succomber


à la tentation du run au profit du build, et
encourager l’émergence des bonnes manières
de faire : s’améliorer est un investissement
qui rapporte. Au sein d’une équipe, l'émulation
est la meilleure des dynamiques. Les plus
belles infrastructures se construisent à plusieurs
O C T O > C U LT U R E D E V O P S V O L . 3

Nous appelons DevOps ces


organisations agiles jusqu’en
production. Nous appelons
DevOps ces technologies
100

en rupture qui accélèrent


l’innovations. Nous appelons
DevOps ces infrastructures
scalables, hautement disponibles,
observables et sécurisées.
O C T O > C U LT U R E D E V O P S V O L . 3

Le mot de la fin :
Remerciements :
Un grand merci à tous les contributeurs et relecteurs : Adrien Boulay,
Alexandre Raoul, Antoine Tanzilli, Arnaud Jacob-Mathon, Arnaud
Mazin, Aurélien Gabet, Aurore Bonnin, Christian Faure, Edouard Perret,
Frédéric Petit, Joy Boswell, Laurent Dutheil, Ludovic Cinquin, Meriem
Berkane, Nelly Grellier, Nicolas Carron, Salim Boulkour, Tanguy Patte,
Victor Mignot et Yohan Lascombe.

La réalisation de ce livre est le fruit d’une dynamique collective incroyable


qui dure depuis plusieurs années et qui perdure pour donner vie à ces
trois volumes de la trilogie. Ce projet n’aurait pas pu voir le jour sans le
101 soutien actif d’Eric Fredj, ni sans l’inspiration et la solidarité dont font
preuve chacun des membres de la Tribu OPS d’OCTO Technology :
ADBO, ALR, AMZ, ANTA, ARJA, ARP, ASC, ASI, AUB, AUG, BBR, BGA,
BOJE, BONI, CANI, CHL, CQU, CYPA, DABA, DUE, EDE, EFR, EPE,
ETC, FRP, FXV, GLE, GLEP, HVLE, JGU, JOJE, KSZ, LBO, LCH, LDU,
MAMI, MAT, MBO, MBU, MCY, MDI, MHE, NBO, PYN, RAL, RRE, SBO,
SCA, SOUF, TPA, TWE, TWI, VMI, YATI et YOL.

À propos de l’auteur :
Ce dernier volume de la trilogie a été écrit par Arnaud Mazin, Laurent
Dutheil et Victor Mignot, consultants DevOps chez OCTO Technology.

La direction artistique et les illustrations sont l’œuvre de Caroline


Bretagne.

"DevOps is a human problem"


Patrick Debois
O C T O > C U LT U R E D E V O P S V O L . 3

OCTO Technology
CABINET DE CONSEIL ET DE RÉALISATION IT

«  Nous croyons que l’informatique transforme


nos sociétés. Nous savons que les réalisations
marquantes sont le fruit du partage des savoirs et
du plaisir à travailler ensemble. Nous recherchons
en permanence de meilleures façons de faire.
THERE IS A BETTER WAY ! »
– Manifeste OCTO Technology

600
OCTO EN TÊTE 3 PRODUITS
102

DU PALMARÈS

COLLABORATEURS

5x
2 CONFÉRENCES

IMPLANTATIONS

FRANCE 1er 2011


Paris • Provence • 1er
2012 La conférence tech par OCTO
Toulouse •
Hauts de France 2 e
2013
MAROC
2e 2015 FORMATION

2 e
2018
Dépôt légal : Décembre 2019
Conçu, réalisé et édité par OCTO Technology.
Imprimé par IMPRO
98 Rue Alexis Pesnon, 93100 Montreuil

© OCTO Technology 2019


Les informations contenues dans ce document présentent le point de vue actuel
d'OCTO Technology sur les sujets évoqués, à la date de publication. Tout
extrait ou diffusion partielle est interdit sans l'autorisation préalable d'OCTO
Technology.
Les noms de produits ou de sociétés cités dans ce document peuvent être les
marques déposées par leurs propriétaires respectifs.