Bienvenue chers compagnons sur Radio DevOps, la ballade aux diffusions des compagnons
du DevOps.
Si c'est la première fois que tu nous écoutes, abonne-toi pour ne pas rater les futures épisodes.
C'est parti !
Catastrophe ! On est en mars 2020 et on apprend dans le monde informatique qu'il y a une
faille de sécurité dans OpenSSL 1.0.2.
Enfin toutes les versions 1.0.2.
Bon vous me direz OpenSSL 1.0.2 de toute façon est plus supporté.
Mais à chaque nouvelle faille on doit se poser cette question là.
Est-ce qu'on n'a pas des serveurs qui ont cette version d'Astalie ?
Est-ce qu'on n'a pas des serveurs de production qui tournent avec cette version-là du logiciel ?
Et pour ça on n'a pas 36 solutions.
Soit on se connecte sur les serveurs et on va vérifier.
Ok si on en a 10 ça va aller.
Et si on en a 100, 200, 300, 1000 ?
On va se connecter sur les 1000 serveurs pour aller regarder ?
C'est pas vraiment judicieux.
Ou alors on a un fichier Excel avec tous nos serveurs et toutes les dépendances logicielles installées.
C'est super ça.
Un fichier Excel à tenir à jour comme ça avec 1000 serveurs ?
Même 100 serveurs ? Même 20 serveurs ?
Enfin on va pas mettre toutes les dépendances dans un fichier Excel.
Et comment on va te le tenir à jour ?
Est-ce qu'on est sûr qu'il est à jour ce fichier Excel ?
Ah non on sait pas.
On revient à la solution de se connecter sur les serveurs et de les vérifier.
Ouais c'est long.
Bon, puis qui va faire la mise à jour ?
Et puis comment est-ce qu'on s'y prend ?
Parce que bon cette mise à jour là si on doit la faire il faut quelqu'un la face.
Plusieurs personnes la face si on est une équipe.
Bon alors comment ça se passe ?
La première chose à faire c'est de tester la file.
On prend serveur développement, on regarde la version,
on installe cette version là d'OpenSSL et puis on teste le problème.
On installe la mise à jour et puis on teste que le problème n'existe plus.
Ok, on a réglé le problème en le mettant à jour.
Bon, maintenant il faut documenter tout ça.
On écrit une belle documentation et puis une belle procédure.
Ok, on rejoue la procédure sur un serveur de Dev toujours
pour vérifier qu'elle marche bien.
Et puis là on a une super procédure pour mettre à jour nos serveurs.
Ok, mais quel serveur ?
Donc il faut lister ces serveurs là.
Bon, je renvoie au début de l'épisode.
Et une fois qu'on a l'alaisé serveurs, on peut y aller ?
Non, pas tout de suite.
Parce qu'on est pas sûr qu'en fait cette version-là
elle va pas avoir des impacts sur d'autres logiciels qui sont installés sur le serveur
ou sur certains serveurs parce qu'ils sont pas tous identiques.
Il faut faire une étude d'impact.
Ok, c'est long l'étude d'impact.
Mais il faut la faire.
Et une fois qu'on a fait tout ça, on peut y aller, on peut enfin déployer la mise à jour.
Donc on va commencer, on va prendre ces petites mimines, on va se répartir le travail
et puis on va faire le déploiement.
On commence, on en fait 1, 2, 10.
C'est long.
Je me rappelle quand j'étais chez un client, je devais mettre à jour le OpenSSH
et mettre à jour sa configuration.
Et on avait une cinquantaine de serveurs à faire.
Je peux vous dire que c'est long, ça m'a pris quelques jours quand même
parce que je devais le faire manuellement.
Je vais me connecter sur les serveurs, mettre à jour la version logicielle
et puis changer la configuration.
Je peux vous dire qu'on en prend du temps pour faire ça.
Donc du coup, une fois que tu as fait une diesel ou une vingtaine de serveurs
tu as de chec liste, là tu as procédure, tu la connais.
Tu vas moi la regarder.
Parce qu'en plus comme c'est long et fastidieux, tu vas finir vite.
Donc tu vas aller de plus en plus vite.
Donc relire ta procédure et ta chec liste, tout vérifier que t'as tout bien fait.
Tu vas plus le faire.
Donc tu vas prendre confiance en toi.
Ça fait plusieurs fois que tu fais la procédure.
Ta confiance, c'est long, c'est fastidieux.
C'est là où tu vas commencer à faire des erreurs.
Et ces erreurs là, tu ne vas pas les voir tout de suite.
Sauf si évidemment le service Nord ne marche pas.
Mais si c'est plus pernicieux, si tu as une configuration que tu as mal faite
ou que tu as oublié quelque chose,
eh ben, c'est là où on va avoir des soucis.
Peut-être pas tout de suite plus tard.
Donc comment tu fais ?
Mais surtout comment tu traces tes erreurs.
Comment tu traces ta mise à jour pour savoir à l'avenir
à quel serveur seront à jour.
Tu peux refaire ton fichier Excel.
C'est pas la meilleure solution.
Alors là, tu te dis comment est-ce qu'on peut automatiser tout ça ?
Comment est-ce qu'on peut faire pour ne pas le faire à la main tout le temps ?
Non parce que à chaque faille de sécurité,
dans n'importe quel morceau du système,
il faudra faire ça.
Donc ça va être long.
Et bien pour ça, en effet, on peut utiliser l'automatisation.
Et on va utiliser l'automatisation pour plusieurs choses.
La première, en effet, c'est pour configurer et installer les serveurs,
pour les mettre à jour.
Et puis la deuxième, c'est pour lancer les serveurs.
Parce qu'aujourd'hui, tout est dans le cloud,
au moins on peut avoir un cloud privé,
et on peut automatiser le lancement des serveurs,
leurs tailles, leurs nombres, les réseaux.
Tout ça, c'est automatisable.
Donc, et comme c'est du code,
parce qu'on parle d'infrastructure à ce code,
ou de code d'infrastructure,
comme c'est du code,
et bien on va pouvoir le versionner dans Git.
On va pouvoir le versionner, on va pouvoir faire des mises à jour,
on va pouvoir faire des demandes de merges,
et nos collègues vont pouvoir relire notre code.
Et le code va se bonifier comme ça,
à chaque nouvelle évolution.
Et comme c'est du code, évidemment on va pouvoir le tester.
On va pouvoir le tester,
et le fait qu'on puisse le tester, qu'on puisse écrire des codes pour le test,
et bien ça va nous permettre de nous assurer
que nos serveurs sont bien dans l'état dans lequel on veut qu'ils soient.
En fait, ton code d'infrastructure, c'est un peu comme Wikipedia.
Wikipedia, c'est une encyclopédie en ligne qui est participative.
Quand tu vas sur Wikipedia,
t'es sûr d'avoir la dernière version à jour.
Pas celle d'il y a un mois, pas celle d'il y a deux ans.
Non, non, la dernière, celle d'aujourd'hui.
Quand tu as une encyclopédie papier,
t'es sûr d'avoir la version du moment où elle a été imprimée.
C'était peut-être il y a cinq ans, il y a dix ans,
ou peut-être il y a deux ans.
Mais c'est pas celle d'aujourd'hui.
Et bien ton code d'infrastructure, c'est pareil.
Au moment où tu le regardes, c'est l'état actuel de tes serveurs.
Parce qu'évidemment, tu joues constamment
ton code d'infrastructure sur tes serveurs.
À chaque évolution, tu vas le lancer.
Et tes serveurs, ils seront constamment à jour.
Donc t'es sûr que ton code y correspond à tes serveurs.
On va l'aborder beaucoup plus longuement
avec Erwan et Damien dans Radio DevOps n°3.
Mais je voulais faire un épisode justement pour te parler
du pourquoi est-ce que tu dois automatiser tes serveurs.
Pourquoi est-ce que tu dois automatiser ton code?
Et pourquoi est-ce que tu dois faire du code d'infrastructure?
Parce que si jusqu'à présent, tu ne t'étais pas
encore posé la question de faire du code d'infrastructure,
c'est le moment.
C'est le moment de te poser la question
et c'est le moment de te pencher sur l'infras code.
L'infras code, c'est vraiment quelque chose qui va te permettre
d'aller beaucoup plus loin et beaucoup plus facilement.
Parce que en fait, je te raconte une histoire.
Quand j'étais chez un client, on mettait à disposition
régulièrement des environnements de tests
pour tester les nouvelles versions.
Mettre à disposition les environnements,
il y avait plusieurs serveurs.
Il y avait plusieurs serveurs de base de données,
plusieurs serveurs d'applications,
plusieurs lois de balanceurs.
C'était une grosse infrastructure.
Rien que mettre à disposition cette infrastructure,
puisqu'on le faisait manuellement,
pouvait prendre de 1 à 5 jours.
On était une équipe de 5 personnes
et imagine que sur une équipe de 5 personnes,
tu as une des personnes qui pendant 1 à 5 jours
ne fassent que ça.
Ne s'occupe pas de la production,
ne vérifie pas les erreurs,
ne supervise pas la production.
Il s'occupe juste de mettre à disposition
une nouvelle plateforme pour des tests.
Et bien, ton équipe est à moindre y.
Et puis surtout, la personne,
c'est super long ce qu'elle fait.
C'est hyper fastidieux,
parce qu'à chaque fois, tous les mois,
tu refais la même chose.
Et puis comme si tu le fais tous les mois
ou tous les 6 mois,
tu ne te souviens peut-être pas forcément
de ce que tu as fait,
donc tu dois trop langer dans la documentation.
Tu fais peut-être des erreurs,
parce qu'en fait,
il y a peut-être des évolutions qui ont eu lieu.
Et bien, si tu avais fait du code d'infrastructure,
tu aurais pu lancer ton code.
Ton code aurait lancé tes serveurs,
les aurais installés et configurés
et t'aurais mis comme ça quelques heures seulement.
Et puis surtout, tu l'aurais lancé,
tu seras allé faire autre chose
et puis plusieurs heures plus tard,
tu serais venu regarder le résultat.
Le résultat, c'est que ton infrastructure
elle aurait été là.
Ou alors, t'aurais eu un problème
mais t'aurais pu le corriger.
Bon.

si tu ne connais pas encore l'infrastructure AsCode,
on va faire dans le prochain épisode
de Radio DevOps
une longue discussion là-dessus.
Donc, n'hésite pas à venir écouter
le prochain épisode.
A bientôt.
Merci d'avoir écouté Radio DevOps.
La balle de diffusion des compagnons du DevOps
est produite par l'IDRA.
Si l'épisode t'a plu, note le,
plus la note sera élevée
et plus il sera mis en avant
dans les applications.
Tu peux aussi le partager,
cela nous aidera à le diffuser
et à rendre le mouvement beaucoup plus visible.
Si tu es envie de discuter du mouvement,
le plus simple, c'est que tu rejoins
la communauté des compagnons du DevOps.
Le lien est en description.
A bientôt.
...