Bienvenue chers compagnons sur Radio DevOps, la ballade aux diffusions des compagnons du DevOps.
Dans chaque épisode, nous étudions l'actualité de notre mouvement ou du cloud en général.
Puis, nous débattons sur un sujet de fond.
Si c'est la première fois que tu nous écoutes, abonne-toi pour ne pas rater les futurs épisodes.
C'est parti !
Bienvenue dans ce troisième épisode de Radio DevOps.
Aujourd'hui, on va vous parler d'un sujet qu'on entend souvent associé au DevOps, qui est l'infrastructure Ascode.
Et avec moi aujourd'hui, j'ai Damir et Erwan qui sont les habitués maintenant du podcast.
Je vais quand même laisser se présenter.
Si tout le monde n'est pas venu au précédent numéro.
Erwan, est-ce que tu peux te présenter ?
Je suis un chef de Radio DevOps dans une petite start-up qui s'appelle Toukantoko.
Et ça fait à peu près dix ans que j'ai voulu dans ce domaine.
Du coup, moi, Damir, je suis ingénieur cloud, je préfère appeler ça réparateur de nuages, du coup dans une petite SN Parisienne.
Moi, c'est Christophe.
Je suis consultant indépendant au sein du collectif qui s'appelle Lidra.
Et on aide les entreprises du numérique à des players application web sans couper leur service ou à faire leur transition DevOps.
Et cette fois-ci, vous avez préparé quelques actus et notamment une très très fraîche puisque Damir nous revient du FOSDEM.
Damir, je suis sûr que tu as plein de choses à nous raconter.
Alors oui, effectivement, j'ai eu la chance cette année de me rendre au FOSDEM, donc c'était le week-end dernier.
Donc tout d'abord, je vais rappeler ce qu'est le FOSDEM, peut-être certains d'entre vous qui ne connaissent pas.
Donc le FOSDEM, c'est un événement qui a été créé dans les années 2000,
qui a pour but de réunir toutes les communautés de développement open source et de lociel libre par extension en Europe.
Donc ça a lieu tous les premiers week-ends de février à l'université libre de Bruxelles.
Donc c'est un événement qui est très important pour l'open source qui regroupe un grand nombre de personnes.
Cette année, on a été un peu plus de 8000 personnes, ce qui fait quand même un bon nombre de personnes pour un tel événement.
Donc globalement, c'est un événement dans lequel vous allez avoir des conférences d'un côté,
appeler les Devroom sur plusieurs thématiques, donc soit de l'automatisation, du test, des libertés numériques et d'autres choses.
Et du coup, vous allez pouvoir voir différents personnes qui participent à la communauté de certains produits,
comme Nextcloud, comme LibreOffice, ou des gens de chez Google, ou autre.
Donc c'est assez intéressant de pouvoir échanger directement avec eux.
Et vous allez avoir encore d'autres petits événements à gauche et à droite, donc surtout le campus.
Donc c'est un événement que je suivais depuis quelques années en live entre guillemets.
J'ai jamais eu l'occasion de me rendre physiquement là-bas.
J'ai eu la chance de me rendre stanné qui était en plus pile poil pour les 20 ans de l'événement.
C'est une expérience qui était vraiment intéressante.
J'ai fait plusieurs Devroom, j'ai essayé un peu de passer d'une Devroom à l'autre.
Il faut avouer que l'événement est entièrement bénévole et l'organisation est assez impressionnante.
Et globalement, c'était vraiment très bien organisé, les confétais tout très sympa.
Il n'y a pas eu de soucis majeur.
Parfois, on a un peu de mal à trouver de la place dans une salle, donc on va sur une autre conférence.
Mais vu qu'il y a en permanence au moins une dizaine, une quinzaine de conférences en parallèle,
on trouve toujours quelque chose un peu à notre source.
Donc c'est vraiment un événement cool.
Donc moi je sais que R1 y a été.
R1, est-ce que tu serais tenté d'y retourner ?
Oui, d'ailleurs il a été pas mal question avec l'équipe technique à laquelle j'appartiens d'y aller cette année.
Et en fait, pour tout un tas de raisons logistiques, ça ne s'est pas fait.
Mais effectivement, la dernière fois que j'y suis allé, ça a commencé à dater, c'était en 2012.
Et j'avais trouvé ça hyper intéressant avec beaucoup de monde à rencontrer, pas mal de confes qui donnent des idées
ou qui permettent d'en apprendre plus avec des speakers qui sont dans un niveau technique relativement pointu.
Et du coup, moi je recommande chaudement d'y aller.
Moi je n'y suis jamais allé, je vais dire.
Peut-être qu'on ira faire un tour avec Lydra un jour là-bas.
Je l'avoue que ce qui m'ennuie un peu, c'est mon niveau d'onglet qui n'est peut-être pas assez suffisant.
Qu'est-ce que vous me pensez, il faut être plutôt calé en anglais ?
Ou est-ce qu'on peut suivre les confes sans avoir un niveau de quoi tenir une conversation tous les jours ?
C'est vrai que je n'ai pas précisé, mais effectivement les conférences sont en anglais.
La plupart des gens sur le campus parlent en anglais, même s'il y a beaucoup de francophones.
Globalement, je n'ai pas un niveau d'angle extraordinaire, mais il faut quand même avoir une bonne compréhension pour les conférences.
Après, ça reste souvent du technique, même si, comme je l'ai dit, il y a des thématiques qui vont un peu au-delà du technique.
Mais après, c'est un niveau de compréhension qui est correct et que tu ne souhaites pas spécialement échanger avec les communautés pendant des heures
ou participer à des discussions ouvertes, c'est ce qu'il y a aussi dans certaines salles.
Globalement, ça se passe bien.
Et après, en cas de doute, on peut regarder quelques replays sur le site du FOSDEM,
sans que toutes les conférences sont enregistrées, et disponibles en replays pour voir si la compréhension suffit ou pas.
Si je trouve le lien des vidéos, je les mettrai en description.
Est-ce que tu nous as ramené une petite exclu ?
Ou est-ce qu'il n'y avait pas vraiment de grandes exclues là-bas ?
Il n'y avait pas vraiment de grandes exclues, peut-être une chose qui se ressent beaucoup, en tout cas,
à travers toutes les conférences sur les KGTA, ça fait que j'en avais fait de beaucoup de thématiques différentes.
C'est que Docker, clairement, est un peu sur une phase où il n'est plus la coqueluche de l'Open Source au niveau des conteneurs.
Il y a énormément de podman, mais je n'ai pas vu une personne parler de Docker quand il abordait la thématique des conteneurs.
Donc c'est assez intéressant de voir que l'entreprise qui a choisi un modèle Open Source,
qui a été critiqué par certains d'avoir un corps qui est totalement fermé,
a un peu sûrement attaché leur réputation au niveau de l'Open Source,
mais il n'y a pas de grosses nouveautés ou de choses à annoncer de ce côté-là.
Ok, Erwin, tu voulais nous parler d'un sujet un peu délicat.
Je te laisse marcher sur des œufs et nous en parler.
Oui, le 3 février, en fait, la plateforme Microsoft Team,
qui est l'équivalent de la plateforme Slack fournie par Microsoft,
en fait, est tombée.
Et en fait, ce n'est pas vraiment qu'elle est tombée,
elle était inaccessible, pardon,
ingoignable pour l'ensemble des utilisateurs.
Et très vite, donc c'était le 3 février,
il y a les 8h30 heures US Quotest.
Et en fait, ce qui est intéressant,
ils ont fait preuve de pas mal de transparence,
puisqu'il y a, dès qu'ils sont aperçus du problème,
ils ont commencé à en parler sur leur compte Twitter
qui est dédié au statut de leur service.
Et donc ils ont commencé à dire qu'ils ont investigué, etc.
Et en fait, un peu plus d'une heure après avoir découvert le problème,
ils ont compris qu'il y avait le renouvellement de leur certificat SSL
qui n'avait pas été fait.
Et donc forcément, on sait tous ce que ça produit comme problème.
Donc une heure après avoir trouvé la source,
ils ont su redéployer ce qu'il fallait,
et le service était de nouveau up pour l'ensemble des utilisateurs.
Ce qui est rigolo dans cette histoire,
c'est que le service a quand même été un joignable
pendant à peu près deux heures,
en tout cas sur les chiffres que TechCrouch fournit,
il y a 20 millions d'utilisateurs qui étaient impactés.
Dans un cas où il y a beaucoup de concurrence avec Slack,
ça l'a fait un peu mal.
Et puis ce que moi je retiens plus basiquement,
c'est que ça reste un problème assez,
on va dire, que tout le monde a, quelle que soit la taille de l'entreprise,
quelle que soit son type d'organisation,
renouveler les certificats, c'est un vrai sujet.
C'est d'ailleurs pour ça que des solutions comme Let's sign cryptes
peuvent être intéressantes, puisque le renew est automatique.
Et c'est toujours cocasse de voir que des structures comme ça,
avec probablement 12 millions de personnes qui sont dédiées à ce genre de sujet,
peuvent avoir des failles aussi bénives.
Et vous, vous en pensez quoi ?
Alors moi pour avoir fait pas mal de runs à une époque
qui avait eu la délicate question de la gestion des certificats,
hors Let's sign cryptes, qui étaient un peu un quotidien,
c'est vrai que les certificats, ça toujours est un point assez complexe,
parce que le process de renouvellement auprès de l'autorité,
et là je parle vraiment hors Let's sign cryptes,
et quelque chose d'assez lourd, assez long, assez casse-gueule aussi,
parce que suffit qu'une information soit pas bonne dans les infos du domaine,
ou quelque chose comme ça, ça peut prendre du retard.
Donc c'est vrai que c'est malheureusement quelque chose qui arrive,
qui est assez facile en fait, au final de se foirer dans son renouvellement
et de planter son site à cause de ça.
Après que c'est vrai que ça arrive à Microsoft, c'est quand même symptomatique,
c'est vraiment un gros souci à gérer certificat,
et c'est là qu'on voit, et qu'on comprend aussi, comme tu disais,
le succès d'outils comme Let's sign cryptes, qui demain sont gratuits,
mais surtout de deux vont te fournir un tas d'outils avec la PII, avec ACME, etc.,
pour gérer le renouvellement de manière automatique.
Donc c'est vrai que c'est assez intéressant de ce point de vue-là.
Ça m'est aussi arrivé en effet d'avoir un client qui n'avait pas renouvelé son certificat,
ou plutôt qu'il n'avait pas prévenu qu'il fallait le renouveler,
notamment parce que souvent les informations arrivent par mail,
et si ça arrive dans le mail d'une personne qui est partie,
ce qui était le cas en l'occurrence de mon client,
et bien personne n'a vu mail.
Du coup, on s'est juste aperçu que le site ne marchait plus,
et il a fallu chercher pourquoi, on a très vite compris,
et il a fallu le renouveler, et le renouveler, ça a pris en effet...
encore on a eu de la chance, ça n'a pris que 48 heures,
parce que ça peut prendre plus longtemps.
Là, je me dis justement qu'il y a peut-être des choses à faire.
Alors je sais que certains font de la supervision,
justement pour voir à quelle fréquence, plutôt à quelle échéance,
il va falloir qu'on renouvelle notre certificat.
Donc là, je pense que c'est des choses qui sont intéressantes,
dans le cas où on a des certificats qui ne sont pas générés par l'aide sans script.
Mais il faut rappeler, pour l'aide sans script, c'est super,
à moi j'adore l'aide sans script, je le mets un peu de partout.
Par contre, dès qu'il y a du paiement en ligne,
moi je mets pas de certificat de l'aide sans script,
et je conseille à mes clients d'acheter un certificat
qui contient des assurances évidemment,
parce que dès qu'il y a du paiement,
ou ce genre d'information un peu sensible,
c'est toujours intéressant d'avoir une assurance liée aux certificats.
Je ne sais pas si vous, ça vous est déjà arrivé,
ou si vous vous posez cette question-là avant.
Alors moi c'est vrai que ça ne m'était pas...
je ne m'étais jamais posé la question d'assurance,
je ne sais pas que ça existait, mais c'est intéressant à savoir.
Je ne peux pas juste rebondir ça, que le monitoring c'est intéressant,
mais à mon avis pour les procès à l'ancienne,
ça ne répond qu'à une partie de la chose,
d'être informé que le certificat va expirer,
et pour moi le vrai souci c'est en fait de suivre le dossier de renouvellement
qui parfois peut être bloqué à cause de quelque chose,
et justement pas oublier le poser dans un coin,
dire que c'est un mail, j'y répondrais plus tard,
et du coup laisser son certificat expirer.
Après bon, on digresse un petit peu.
Mais du coup effectivement je ne connaissais pas cette assurance,
je ne sais pas si Yara One, tu en as déjà entendu parler ?
Si si, quand je travaillais chez 10h,
c'est pour ça qu'il y a plusieurs niveaux et types de certificats que tu peux prendre,
et pour la partie paiement on avait pris le certificat de la mort,
je me suis en plus du thermotechnique associé,
mais qui fait que ton tabard de navigation allait verte, etc.
et c'était dédié pour la partie paiement.
Et je me souviens qu'effectivement obtenir ce certificat,
c'était vraiment, c'est un process très très très long et très coûteux,
et donc j'étais plus là quand il y a eu le renouvellement de ce certificat,
mais j'imagine que c'était de la même façon.
Et au sujet du monitoring,
moi je... on va en parler dans le reste du podcast,
sur l'automatisation, etc.
Mais j'ai fait un petit module pour Ansible avec Statue Cake,
dont le travail, c'est de créer justement des tests
pour aider les notifications côté Statue Cake
quand un certificat arrive à expération au bout de X, XJ,
enfin avant XJ,
et c'est un moyen pas cher qu'on a mis en place
pour avoir des notifications justement
sur l'expérience des certificats
pour ne pas se retrouver dans le cas de...
dans le même cas que Microsoft.
Donc même si effectivement ça répond pas à tout, au moins on a l'info.
Bon bah super.
De mon côté, moi je vais vous parler un petit peu d'IBM,
alors ça sort un peu de mes... de mes sujets habituels,
mais pas tellement, vous avez compris pourquoi.
Donc la patronne d'IBM, Jeannie Rometti, démissionne.
En effet, en avril prochain,
elle sera remplacée au poste de CEO par Arvind Krishnach,
j'espère que je le prononce bien,
qui va dirige... qui va... qui dirigeait jusque-là,
la division Cloud Computing.
Ce qu'il faut savoir, c'est que depuis 8 ans,
en gros les vente d'IBM tombaient et ont régressé de 25%.
Et ce qu'on sait sur Arvind Krishnach,
c'est que c'est l'architecte qui est derrière le rachat de Red Hat.
On en a beaucoup parlé l'an dernier, je sais pas si je vais vous rappeler,
mais le coût considérable de l'acquisition,
faisait que c'était l'acquisition la plus importante
d'une des entreprises d'Open Source,
puisque Red Hat a été racheté 34 milliards de dollars.
Du coup, l'activité de l'éditeur Open Source a eu un effet
en fait immédiat sur les résultats d'IBM,
puisque au dernier trimestre, la division du coup Red Hat
a fait progresser le chiffre d'affaires de 24% en un an.
Donc la dynamique de Red Hat est tellement importante
que la nouvelle direction d'IBM sera en plus la première fois bicephale,
ça veut dire qu'avec Arvind Krishnach,
va être nommée comme second, Jim Whitehurst,
qui est l'actuel dirigeant de Red Hat.
Il sera promu au poste de président en avril toujours.
Du coup, c'est l'équivalent du directeur général chez nous.
Et suite à cet annonce,
l'action d'IBM a directement grimper de 5% à la bourse de New York.
Alors, se pose aussi la question de la culture,
puisque ce qui est aussi là derrière,
c'est pas uniquement un objectif financier,
c'est aussi un objectif culturel,
c'est de faire émerger au sein d'IBM
une culture liée à l'Open Source,
parce que IBM jusqu'à présent était plutôt réfractaire,
ils ont même perdu plusieurs personnes
suite à cette absence de culture Open Source,
jusqu'à présent.
Donc, bon, tout n'est pas perdu,
mais c'est vraiment qu'un début,
parce que la culture des actionnaires n'est vraiment pas là,
et elle est pour l'instant plutôt à chercher une marge élevée
qu'à aller vers l'Open Source.
Du coup, on peut aussi se demander,
parce que c'est vraiment un serpent de merge et l'impression,
c'est le business model YELL Open Source,
puisque on rédate, on sait, ils vendent des licences,
ils vendent du support,
mais à part la licence et le support,
est-ce que vraiment on peut s'en sortir,
et est-ce qu'on peut avoir des solutions ?
Moi, je me pose encore la question,
puisque je suis en train de travailler sur un SASS,
justement basé sur des briques Open Source,
mais vous,
avez-vous déjà réfléchi à ce genre de choses ?
Comment est-ce qu'on peut mettre en place un business
qui est basé sur l'Open Source
et à reverser des sources à la communauté ?
Effectivement, le modèle du service,
je pense que c'est le modèle le plus courant,
à offrir une expertise et du support sur la solution,
c'est globalement ce qui marche,
je pense, le plus.
Après, il y a les systèmes un peu de subventions messénins
qui permettent de financer des features
ou de maintien de tels ou tels modules dans une solution,
mais les modèles autour de l'Open Source,
je crois qu'il y a un économie,
en tout cas comme ça, je n'en vois pas 12 milliards.
C'est assez marrant,
parce que justement, au FOSSDEM,
j'étais à une conférence
qui parlait des différents modèles dans l'Open Source,
j'essaie de vous retrouver le lien
pour vous l'envoyer en-dessous du podcast,
mais le modèle dans l'Open Source,
comme c'est un serpent de mer,
c'est une question qu'on se pose tout le temps,
que ce soit des différents types de modèles,
en fait il y a le support,
il y a le développement personnalisé,
il y a l'avance de phase,
c'est-à-dire que la version payante
a une version d'avance sur la version Open Source,
il y a vraiment un tas de modèles différents,
après, il y en a qui marchent vraiment beaucoup mieux que l'autre,
il faut voir, je pense que celui de Red Hat,
il marche globalement assez bien,
vu que l'entreprise est réussi,
comme tu l'as dit, et comme on le voit avec des chiffres,
donc il n'y a pas de modèle miracle,
je pense, il faut un bon produit,
après, il y a encore peut-être un modèle
à Miracle à trouver,
mais ça je ne saurais pas le dire
lequel est le plus adapté.
Bon, on va continuer à chercher alors.
Bon, en tout cas, en parlant de chercher,
on va parler de quelque chose
qui nous empêchera de chercher,
en tout cas de chercher des paquets
dans une ligne de commande,
c'est l'infrastructure Ascode.
Alors, l'infrastructure Ascode,
on entend beaucoup parler quand on s'intéresse au DevOps,
puisque c'est l'un des piliers
au DevOps et de l'automatisation,
et du coup, on automatise les infrastructures.
Avant de vraiment
rentrer dans le sujet, j'aimerais bien
connaître un petit peu votre définition
à chacun de ce qu'est l'infrastructure Ascode
pour vous.
On va commencer par Damir.
Alors, pour moi, l'infrastructure Ascode,
ça va être de,
on va dire, traduire tout ce qu'on a fait,
ce qu'on faisait avant en clic-clique, en script, etc.
et de le centraliser dans
une syntaxe, un langage,
pour pouvoir l'appliquer.
Donc, traduire tout notre infra-physique
ou virtuel, ou etc.
vers des défis de configuration
ou un langage.
Ça, ce serait ma définition.
Je rejoins pas mal,
enfin, j'ai exactement la même définition en tête
que ce que vient de Damir.
Moi, je rajouterai juste
la notion
d'un d'empotence
pour s'assurer
qu'à chaque fois qu'on rejoue ses scripts,
on obtient le même résultat,
quel que soit le contexte
dans lequel on se trouvait.
Je crois qu'on va s'entendre,
parce que ma définition est assez proche.
Pour moi, dès qu'on fait du code d'infrastructure,
en fait, on décrit
dans du code informatique,
et qu'on peut versionner Damir, évidemment,
puisque c'est le but,
toute notre infrastructure,
ce qui nous assure qu'une fois qu'on a fait ça,
on n'a plus besoin d'aller
tripattouiller nos petits serveurs,
et que notre code
nous permet de lancer
n'importe quel outil,
et ces outils-là vont gérer notre infrastructure,
que ce soit les réseaux,
les disques, les machines,
ou même les paquets,
ou la configuration qui est installée sur les machines.
Pour moi, c'est ça la phrase code,
et c'est en plus vraiment s'assurer
qu'on puisse versionner
les différentes versions
de notre infrastructure.
Une fois qu'on a un petit peu défini tout ça,
peut-être qu'on peut raconter
un peu comment on est venu
à l'infrastructure.
C'était quoi, en fait,
qui vous a poussé à faire de l'infrastructure ?
Comment vous avez entendu parler du code
d'infrastructure ?
Racontez-nous un peu cette histoire.
Erwan, est-ce que tu veux bien commencer ?
Oui, il y a un fort longtemps
lorsque je travaillais pas mal
dans les datacenters, etc.
La gestion
des confs et l'installation de nos machines,
en fait, on pensait qu'on était assez avancés,
puisqu'on avait tout un tas
d'ensemble de scripts
et d'archives
qui contenaient des fichiers
de confs,
des scripts qui se jouaient
sur les machines et qui déployaient
ces fameuses archives de confs
et qui faisaient tout ce qu'il fallait
pour installer les machines.
On était assez contents avec ça à l'époque.
Ça marchait plutôt bien.
On essayait de faire des scripts un peu malins
et c'était cool.
Et en fait, le temps passant
justement,
ce côté de rejouabilité,
ce côté
d'indopentes d'identpotence
qui s'est arrivé
fait que
les scripts qu'on avait
étaient bien, mais bon,
c'était pas super en termes de suivi.
C'était pas super
il manquait tout un tas de choses.
Moi, personnellement,
c'est comme ça que je me suis mis
à travailler
avec d'abord
Antibol et Chef.
Puisque
l'idée, c'était de dire,
tiens, ça fait comme mes scripts,
sauf qu'il y a tout un tas de modules
qui fait que je peux faire ça
plus facilement,
dans une sorte de framework
beaucoup plus lisible.
Et c'est à partir de là,
je ne sais plus trop
en quelle année c'était, mais
c'est à partir de ce moment-là
que je suis totalement laissé
tomber
mon ancienne méthode avec mes scripts
et que je suis passé sur ce genre d'outils.
Moi, du coup,
ça va être un peu
moins vieux que vous
vu mon expérience.
Du coup, c'était dans une petite PME
et il faut...
J'aime bien automatiser des choses, j'aime pas
refaire des tâches répétitives qui n'ont pas de valeur ajoutée
et globalement, il n'y avait pas
de vraies gestions internes, il n'y avait pas d'outils.
À un moment où on m'a demandé de faire plusieurs tâches
qui étaient assez répétitives,
j'ai commencé à me poser la question de comment le faire,
est-ce que je faisais qu'un script
et je m'étais un peu renseigné, je suis un peu tombé
par hasard, à l'époque, c'était sur du Peupet
donc ça remonte quelque peu quand même
et j'ai commencé à
mettre en place Peupet, à voir comment ça marchait
et à essayer d'automatiser un maximum de choses avec
et donc ça, c'est plus pour la partie
pour moi, je dirais,
industrialisation et après, pour ce qui est vraiment
l'infrastructure Ascot, c'est-à-dire gérer son infrastructure
de base, donc c'est Brick, Elementer, c'est VM, etc.
J'ai vraiment découvert le plein potentiel
de ça quand je suis chez un
infogéreur français
et que AWS a explosé
en fait, c'est là qu'on sait que si le tooling
a côté à exploser, on peut dire
ce qu'on veut d'AWS ou du cloud public,
ils ont quand même provoqué un gros mouvement
d'avancée au niveau des outils de gestion
aussi et des choses comme ça
donc c'est là que j'ai commencé à découvrir
Terraform, j'ai découvert assez
assez tôt du coup et j'ai
petit à petit découvert plus en plus son potentiel.
Alors moi, c'était entre
je crois que c'était
aux alentours 2010-2012
à l'époque
moi je géré des applications
donc ça veut dire que je n'ai pas
des infrastructures mais je géré le déploiement
des applications, puisque j'étais dans
une grosse multinationale
et du coup, les services, en fait
il y avait plusieurs services, hop, il n'y en avait pas qu'à, il y en avait plusieurs
et
petite parenthèse, même entre services, hop,
il peut y avoir des frictions et à l'époque
je faisais vraiment du script
du shell pour installer
pour installer mes applications
et je trainais beaucoup
avec un développeur Ruby
et on avait entendu parler de Chef
et c'est là
où j'ai commencé avec lui
sur mes heures perdues, à essayer de
comprendre et d'apprendre Chef
spoiler, au bout de 3 mois, je n'y suis pas arrivé
et finalement, j'ai fini par abandonner
mais c'était une expérience assez intéressante
puisque on voulait faire
justement, on voulait apprendre tous les 2
lui, à manipuler
cet outil de gestion de configuration
et faire du code et surtout testé le code
et moi, apprendre à installer des machines
mais pas en instant des paquets
parce que j'ai toujours trouvé ça un peu pénible
et puis plus tard, quand je suis devenu freelance
tout de suite, je me suis intéressé
à Ransible, notamment parce que
mon premier client, c'est ce qu'il voulait
de coup, je suis allé voir Ransible
j'ai un peu gratté et j'ai vu que c'était beaucoup plus simple
que Chef, que la courbe d'apprentissage
était beaucoup plus courte
et c'est comme ça que j'ai commencé et que je suis resté
à Ransible pour gérer la configuration
c'est à dire, en gros, installer
mes serveurs, la config de mes serveurs
et faire des images immuables
avec mes serveurs et puis un tout petit peu après
j'ai découvert Terraform pour gérer tout ce qui est en effet
l'infrastructure et puis Packer
pour PackerG, mes images
parce que moi, je suis assez fan des images immuables
et dès que je peux en mettre quelque part
ben, j'en mets. Alors la question que j'ai envie
de vous poser c'est, notamment après avoir
écouté le DevOps
le dernier DevOps qui durait 3h30
quand même avec Contain 1 an
c'est pour vous, est-ce que
un docker file c'est
de la gestion de configuration ou est-ce que c'est de l'infrastructure ?
La question un peu épineuse
de où tu places le conteneur, est-ce que c'est
de l'infrastructure ou est-ce que c'est du code
c'est vrai
pour moi, j'aurais maintenant tendance
c'est pas du tout par rapport à des histoires de la IORG
ou je suis comme ça, plus c'est des histoires de logique
de gestion à le placer du côté du code
donc je le blasserai plus
dans de la config
de l'infrastructure en tant que tel
parce que c'est quelque chose pour moi qui est maintenant
plus haut niveau qui est vraiment plus lié à l'application
et au paramètre des librairies etc
donc ouais j'aurais plutôt tendance
pour le coup à le mettre
côté de gestion de configuration
voire même code directement
l'infrastructure je mettrai plus le Kubernetes
ou le
système, l'orchestrateur en fait qui va le lancer
qui va gérer son cycle de vie, après je sais pas ce qu'on pense à Erwin
pareil, d'ailleurs
où je travaille actuellement
c'est clairement comme ça que c'est vu
c'est
finalement Docker, c'est
anciennement
le package de targes et des
applications qu'on faisait
donc moi je le vois aussi
plus côté
d'aide
c'est marrant parce que
j'ai tendance à penser qu'en fait tout ce qui
touche au serveur
du coup comme dans un conteneur
on installe pas mal de choses qui sont en rapport avec le serveur
et on tue pas mal de choses
c'est quand même quelque chose qui doit
rester
pas entre les mains de l'ops mais qui doit
au moins avoir, que l'ops doit avoir un regard
là dessus parce que finalement on peut mettre
tout et n'importe quoi dans son conteneur et si on n'a pas
l'habitude du système on peut
faire des trucs qui peuvent sortir un peu
l'ordinaire et peut-être pas forcément
faire les meilleurs choix
je sais pas
donc ça c'était la question un peu troll
et du coup
quand on veut
s'y mettre un affrare à ce code
par où est-ce qu'on commence
et pourquoi est-ce qu'on doit
faire de l'infrascode rapidement quand on veut
commencer à faire de l'automatisation
je pense que Damir a quelques pistes
qui va nous exposer
merci pour la balle
du coup
c'est vrai que c'est une question épineuse
quand est-ce qu'on commence à faire ?
moi de mon point de vue j'ai envie de dire au plus tôt
parce que là je parle vraiment
au niveau de quand on crée une infrastructure
éviter un maximum de faire des choses qui sont pas en infrascode
parce qu'on sait tout ce qu'on sait comment ça se passe
un projet ça avance, ça aura toujours du retard
et on va toujours finir par se dire
ouais on le fera plus tard on aura plus le temps
donc pour moi c'est le faire dès le début
le prévoir
si possible l'infrastructure comme ça
en pensant à cette approche
et après ta deuxième partie ta question
c'était du coup comment le faire il me semble
c'est pourquoi le faire rapidement
pourquoi le faire rapidement ?
simplement pour réutiliser les choses
c'est vrai que c'est le but de l'infrascode
on n'est pas trop revenu dessus
mais vraiment le principe au but c'est déjà
d'adversion et son infrastructure
de pouvoir éviter la duplication
de code donc de faire
de la standardisation
d'infrastructure donc demain par exemple
vous déployez une base de données c'est intéressant
d'en faire un module par exemple sous terraform
et de se dire après je vais créer une base de données
je vais pas me retaper tout le code je vais juste appeler ma fonction
qui le crée et du coup gagner du temps
donc c'est pour ça que je dis de le faire au plus vite
pour standardiser un maximum
et du coup voilà c'est pour moi
c'est essentiel de le faire de cette manière là
après je pense qu'il y a différentes approches possibles
mais oui moi je
je penserais plutôt comme ça
après je sais pas ce que Air One en pense
à ce niveau là
oui bah
comme
faire des choses à la main c'est cool
mais après faut les expliquer
du coup
les faire directement en code
ça a la garantie
d'être rejouable
par quelqu'un d'autre
sans avoir à poser de questions
et la notion de standardisation
elle est hyper forte
parce que c'est
plutôt tu commences à avoir
ce genre d'approche et plutôt tu t'assures
que justement tu pourrais
l'exemple de créer une base de données
sur AWS par exemple
bah tu t'assures que tout le monde la crée de la même façon
avec
la même typologie de
je sais pas
de tags, les mêmes trucs
par défaut etc
et sans dupliquer
quoi que ce soit
et forcément en évitant
les erreurs qui seraient potentiellement
jouées à la main si tu devais suivre
je sais pas un tuto ou un outou
qui dit voilà maintenant tu choisis la taille
de ton instance ou quoi que ce soit
en tout cas
dans aujourd'hui
tel que on travaille là où je suis
c'est quelque chose qu'on démarre
dès le début
des projets à chaque fois
si je peux me permettre juste de rebondir
comme je dis c'est même intéressant de le voir
dès la conception du projet
et de se dire quelle partie on va pouvoir
pas externaliser mais peut-être
mettre dans un repo à part pour utiliser sur d'autres projets
etc je pense et même capitaliser
c'est des choses qui existe déjà c'est intéressant
aujourd'hui en entreprise d'avoir un repo transvers
avec différents modules on reprend l'exemple de la base
de données et se dire je l'ai fait pour le projet A
quand je travaille sur le projet B
je vais essayer de réutiliser le même module
et du coup gagner du temps
donc je pense que c'est vrai que c'est vraiment la conception
qui a à prendre en place ce concept
pour moi il y a un intérêt
à le faire rapidement pour plusieurs choses
la première c'est que ça va plus vite
en fait j'étais
chez un client
avant d'être dépendant
et je connaissais
j'avais déjà frauté à cheve comme je vous ai dit
et chez ce client là
c'était l'une de mes premières fois
où j'étais vraiment administrateur système
et quand on mettait à disposition
des environnements de test et de formation
ça prenait mais au bas mot 5 jours
5 jours pour mettre à disposition
les serveurs, les réseaux
la configuration et c'était
et encore on avait des images des serveurs
on lancait des serveurs depuis des images
mais c'était tellement long de faire
fallait lire une doc, fallait lancer plein de commences
sur plein de serveurs etc
et je vous promets 5 jours
et encore je me souviens
d'une expérience traumatisante
c'est la première fois que je l'ai fait
j'étais à tout jeune
pas tout junior
mais
ça fonctionnait pas
et je peux vous dire que au bout de 5 jours
ça fonctionnait toujours pas, je balisais un peu
je savais pas ce qui se passait
les autres étaient tellement occupés qu'ils pouvaient pas m'aider
s'il y avait eu de l'infra à squad
et que tout avait été écrit
dans du code informatique
déjà je n'aurais pas mis 5 jours
mais j'aurais peut-être mis une demi journée
mais en plus
les erreurs on les aura peut-être vu et corrigé avant
donc là pour moi c'est vraiment
c'est vraiment important
de faire de la fraise code pour ça
et aussi pour aller
bien plus vite quand on reprend
à nouveau des choses qu'on a déjà fait
et on peut alors du coup
se demander mais ok c'est bien
la fraise code je veux m'y mettre mais par quoi je commence
moi petite perso je vais donner
mon avis avant vous
excusez les gars je vais prendre
la priorité
pour moi si on veut commencer quelque part
la première chose à faire c'est
de commencer par ce qu'on appelle provisioner
un serveur c'est à dire écrire du code
qui installe et configure
un serveur informatique
ça peut être soit un serveur complet
soit installé par exemple à n jinx
pour voir comment ça fonctionne
et commencer à coder ça
est-ce que vous voyez d'autres idées pour commencer
pour des gens qui auraient jamais fait d'un fraise code
c'est vrai que je vais peut-être
être un peu embêtant et toujours digressé
mais il est important aussi de
on a tendance un peu parler
de deux choses qui sont du coup
l'industrialisation, le configuration de management
et l'infrascode en tant que tel
moi j'aurais tendance à dire de commencer
peut-être plus par
l'industrialisation comme tu dis
sur des VM assez simples
pour installe n jinx, installe base
l'exemple classique c'est d'installer
deux frontaux avec une base de données
qu'un WordPress
c'est un grand classique mais ça marche toujours plutôt bien
je trouve et après justement
de passer ça en infrascode donc pour la partie plus basse
donc le networking
l'EVM, le load balancing
donc ça c'est une chose qu'on peut faire après
justement commencer comme ça sur un exemple concret
donc un WordPress c'est un truc très classique
vous pouvez mettre ce que vous voulez
et du coup à chaque fois d'aller un peu plus loin
de pousser le concept, d'ajouter des serveurs
de variabiliser, d'externiser
donc je pense que c'est une bonne idée d'avoir
quelque chose de concret moi c'est quelque chose qui mette beaucoup
d'avoir un exercice et dire
l'exercice est fait c'est d'avoir quelque chose qui puisse s'afficher et marcher
donc je pense
à mon point de vue ça serait de faire quelque chose comme ça
de donner un petit projet
et de
l'itérer tout simplement
pour mettre de l'infrascode, de l'industrialisation
de l'automatisme etc
ça c'est un peu mon point de vue là-dessus
oui oui bah je ne peux que
que aller dans votre sens
commencer par quelque chose
de simple
et être plus ambitieux
au fur et à mesure
en créant des modules
en variabilisant un maximum de choses etc
c'est la meilleure approche
commence à bien savoir marcher
avant de courir
ça me paraît effectivement une bonne idée
et pareil
effectivement on a tendance
enfin depuis le début
à mettre un peu dans le même sac
le provisioning de machines
déploiements de configuration
et le management de package par exemple
mais moi
parce que par exemple
quand j'ai commencé à me mettre sur terraform
j'ai juste commencé
je suis juste mis dans la situation
de me dire bon bah chaque fois que j'ai besoin d'une vm
j'aimerais que ça se joue vite
et puis j'aimerais ne pas avoir
à les délettes
et on allant cliquer sur 12 millions de trucs
dans l'interface
et c'est comme ça que je me suis mis dans terraform
avant de faire des choses plus ambitieuses
et je pense que c'est un bon début aussi
je vous propose qu'on parle de terraform
un tout petit peu plus tard
parce que Damir a cité un terme
qui est la gestion de configuration
Damir est ce que tu veux bien l'expliquer à nos auditeurs
ce que c'est que la gestion de configuration
et ce qu'on entend par là
en tout cas je vais donner ma définition et ma vision de la chose
je dis pas qu'il y a des plus parfaits que d'autres
pour moi la gestion de configuration
ça a de simplement de
on a du matériel
ou du matériel
mais en tout cas on a des systèmes
que ce soit des vm, que ce soit des machines physiques
ou que ce soit des switches même
qui vont avoir des configurations
et c'est vrai que très rapidement dans une entreprise
quand vous avez 2000 serveurs
et que vous devez mettre à jour un paquet
sur tous les serveurs ou que vous devez gérer
une config sur tous les serveurs
vous en doutez bien qu'on fait pas du SSH
sur chacun des serveurs, même si avec un fort en bâche
pour les plus trolls d'entre vous ça pourrait se faire
on va utiliser ce qu'on appelle
la configuration de management
ou de l'industrialisation
ça va être d'automater toutes ces actions
sur un certain nombre de serveurs
pour automater vraiment la configuration
soit du serveur et de ce qu'elle soit le serveur donc des middleware
donc voilà sur le switch par exemple
pousser une configuration de routage
sur une machine de pouvoir installer un genic
c'est de configurer pour avoir un certificat
avec Let's Un Crypt
plus
un config d'un VEus voilà
pour moi c'est des choses comme ça
après je sais pas s'il y a des choses à rajouter
je vous laisse me dire du coup
si vous voulez rajouter quelque chose là dessus
moi je suis d'accord
et je rajouterai là dedans
tout ce qu'on fait
pour déployer une application par exemple
une application
qui nous est propre
je sais pas par exemple
justement
si
on doit déployer
un nGenics qui fait un reverse proxy
sur un petit
service node
par exemple
et que le service node
c'est l'application
de notre entreprise
qui est sur un autre repo
tout ce qui va permettre
de mettre
en place
ce type
de configuration
et de système
moi je mets ça dans le même paquet
ou même
déployer des conteneurs
moi je mets ça
dans le même paquet
c'est étonnant parce que tu parles de déploiement
ce que j'aime bien faire
c'est toujours en utilisant un outil de gestion de configuration
de provisionner le serveur
dans un premier temps sans l'application
donc d'installer tout ce qu'il faut pour que le serveur
tourne donc tu parles de notre JS
d'installer toutes les dépendances
système
et faire un autre
code qui ne sert qu'à déployer l'application
et uniquement l'application et pas tout ce qu'il y a autour
je sais pas si ça
c'est quelque chose que vous faites
mais moi j'aime vraiment séparer les choses
pour que justement le déploiement soit plus simple
et comme je vous l'ai dit, comme j'adore les images immuables
j'ai tendance justement après avoir tout installé
toutes les dépendances de créer
une image et puis de lancer les serveurs
après directement depuis cette image
et puis de déployer l'application
avec en effet un outil de gestion de configuration
ce sont des outils souvent
qui permettent d'automatiser pas mal de choses
c'est vrai que j'ai tendance
à faire un peu pareil
de mettre un peu l'application
de manière séparée
c'est aussi plus simple quand on met en place de la CIA
de pouvoir du coup
c'est déjà séparé, il y a juste à l'automatiser cette partie-là
et du coup c'est plus simple
de séparer les deux cycles de vie
parce que cycle vie des middleware
et pas forcément le même que l'application
surtout quand on est dans un approche de DevOps
on veut faire plusieurs déploiements par jour
on n'a pas besoin de mettre
à jour généralement son nginx
ou autre plusieurs fois par jour
donc c'est vrai que j'ai tendance aussi à se séparer
pour mettre dans la CIA dans le meilleur des cas
mais mettre les deux dans la CIA dans le meilleur des cas
donc là-dessus je te rejoins plutôt pas mal
je pense que je me suis mal exprimé
je disais pas de forcément
tout mettre comme ça
et je suis assez d'accord
de plutôt, enfin par exemple pour Ansible
typiquement
tu fais des playboots qui appellent
plusieurs roles
et tu as
tes roles
qui sont dédiées
aux déploiements de ton application
par exemple
et que tu ne peux jouer
que dans certains cas
je voulais juste préciser ça
il n'y a pas de soucis
il y a plein de solutions
puisqu'on en a cité quand même quelques-unes
alors on peut répéter
mais on a cité Chef, on a cité Peupet
on a Salt aussi
je crois qu'il y en a d'autres
alors il y a si Fnjang qui est assez vieux
maintenant, enfin assez ancien
et Ansible
quand on arrive on a tous ces outils là
bon à part le fait de pouvoir choisir l'un ou l'autre
parce que c'est du piton
ou parce que c'est du rubis
ou je sais même pas s'il y en a on l'aide
qu'est ce qu'il nous permet de choisir
entre ces solutions là
et vous quelle solution vous avez choisi et pourquoi
j'espère déjà ne pas avoir un jour
un jeu de configuration en nod
ça c'est peut-être pour le petit troll
c'est vrai que pour le choix
moi j'aurais tendance à me fier de la communauté
surtout si on débute
c'est vrai que c'est toujours important
la communauté dans l'open source
un produit qui n'a pas de communauté c'est un produit qui se meurt
globalement je ne pense pas me tromper
et vous serez assez d'accord
pour dire que le produit qui a la meilleure communauté
la communauté qui marche le mieux
c'est Antsibel notamment parce que c'est du piton
piton et à la mode avec le mouvement DevOps
donc je pense que Antsibel est un bon choix là-dessus
ça repose sur des standards
ça marche plutôt bien il y a une bonne communauté
je pense que le produit va vivre assez longtemps
et assez bien même si les autres
choix sont pas mauvais en soi je sais que
Antsibel peut être un peu lent si on a vraiment
des parcs de serveurs qui sont vraiment énormes
on va plutôt aller peut-être sur quelque chose comme Salt
mais la communauté est plus renfermée le produit
un peu moins populaire
je ne sais pas ce que t'en penses à Roan sur ce choix
oui oui
moi j'aime bien Antsibel
parce qu'il y a le côté Easy to learn
Art to master
même pour des gens qui n'ont jamais trop touché
à tout ça lire du Antsibel
c'est quand même assez facile
pour pouvoir
permettre les gens de contribuer
moi par exemple dans la boîte où je suis
c'était assez important puisque j'étais
pendant longtemps le seul à m'occuper
de toute cette partie
et pour ne pas être bloquant le fait d'avoir
un outil facile à prendre en main
c'était quand même assez
assez crucial
comme
je suis d'accord aussi sur
les questions de
comment s'appelle de performance
quand on a des très très gros parcs
moi je ne suis pas dans ce cas là
donc c'est
effectivement un problème
auquel je n'ai pas à me confronter
et historiquement j'ai fait un peu de chef aussi
que je trouve que globalement
ça ressemble pas mal à du Antsibel
mais par contre je pense que
la force d'Antsibel c'est effectivement
le côté
communauté avec le Antsibel Galaxy
qui est quand même hyper fourni
alors les
les rôles qui sont proposés sont de
qualité hyper
hyper diverse mais
mine de rien
il y a toujours des gens
qui ont fait des rôles
de plutôt bonne qualité à disposition
et
surtout ce que je trouve intéressant
dans Antsibel c'est que c'est hyper facile
à
comment direz-je
à pimper entre guillemets
parce que créer un module pour Antsibel
c'est quand même hyper facile
créer son propre ingénieur
d'inventaire dans Antsibel
c'est pas compliqué non plus
et du coup
moi je suis assez fan
de cette solution
et quand je vois que mes collègues
qui sont pas forcément
liés à l'infra ou quoi que ce soit
arrivent à faire des
pour le request sur notre hippo pour proposer
des améliorations
ou de nouvelles tâches
sans problème et que c'est des gens qui viennent
par exemple qui sont développés par Fountain
je trouve que c'est vraiment cool
moi aussi j'ai choisi Antsibel
c'est
moi j'ai essayé que Chef et Antsibel
ce que je trouve
difficile avec Chef c'est la courbe d'apprentissage
alors si vous voulez
avoir des résultats rapidement
choisissez un outil qui est une courbe d'apprentissage
assez courte et Antsibel fait partie de cela
la différence que moi
je vois entre Chef et Antsibel
c'est que Chef en écrit vraiment du code ruby
pour le coup c'est un DSL
mais ça reste quand même du code ruby alors qu'Antsibel
c'est du yaml c'est pas vraiment du code
du code piton
en effet on peut le tuner comme tu dis
à Roi en faisant du code piton ou autre
même d'ailleurs mais c'est assez facile
à l'ailleurs c'est assez facile à mettre en place
et c'est vraiment très rapide et
en effet la communauté
qui fournit des rôles qui nous permet
soit d'installer à engin, soit d'installer
à chaproxi, soit
configurer des règles de routage sur repeatable
il y a vraiment tout et n'importe quoi
alors du coup se pose la question du choix
mais on va peut-être pas l'aborder aujourd'hui
on pourra peut-être faire un deuxième
un deuxième podcast
si ça vous intéresse
aller plus en détail dans Ansible
on voulait parler de service manager
donc service manager en gros
si je me trompe pas
Airwands c'est parler des services
du cloud provider donc
des VM, des disques, des réseaux etc
et justement
Ansible
permet de faire ça
est-ce que vous vous utilisez Ansible
pour gérer
toute l'infrastructure ou est-ce que vous
gardez en cible juste pour la gestion
de la configuration, de l'automatisation
ou est-ce que vous utilisez un autre outil
pour ma part
là où je suis on différencie vraiment
la partie
de conf
de la partie service manager
et enfin
VM, network etc
donc du coup on a le terrain form de
un côté et on va dire
le Ansible de l'autre
et je sais que par exemple
avec Ansible il y a tout un tas
de modules pour parler
à AWS par exemple
mais vu qu'il n'y a pas
le même système que terraform
avec les states etc je sais pas trop
comment, j'ai jamais été sté pour être franc
mais je sais pas trop comment
il se débrouille
par exemple si un moment tu provisionne
5 machines et que t'en as
besoin de 6
est-ce que c'est à toi
de faire la logique
qui dit ah bah tiens j'en ai besoin
de 6, y'en a déjà 5 qui sont présentes
alors j'en recréque une seule ou est-ce que
comme dans terraform
il fait la différence avec les états
et il se débrouille tout seul
si vous êtes plus expert
je suis preneur de vos retours
alors moi je devous que je suis pas du tout expert
Ansible, moi je me retournerais la question
de l'autre côté parce que je pense
à beaucoup plus peut-être utiliser de provider
cloud public
qui ont des offres très complètes au niveau des services manager
et je me
j'attends ça à faire du coup
on est dans un chemin un peu inverse
dans mes situations généralement
où on va plus utiliser terraform
pour gérer le service manager
donc au final directement la configuration
du middleware
quand on crée une base de données
du coup je n'ai pas de recette Ansible pour le faire
c'est juste mon terraform
qui va appeler par exemple sur AWS
mon RDS
et qui va me créer des différents paramètres
et les choses là
donc moi du coup c'est vrai que c'est assez marrant
je suis dans le chemin inverse
où je cherche pas à faire l'infra
avec l'outil de configuration
de management
le configuration management
sur du coup
des services manager à partir de mon infrasco
terraform
donc c'est là que je suis un peu plus dans le chemin
donc c'est intéressant de voir qu'il y a les deux points de vue
je sais pas si tu as testé
Christophe
ce point de vue que ce soit sur OVH
ou autre
j'ai fait de la AWS
j'ai commencé par ça aussi
je vais juste rappeler un petit peu
pour nos auditeurs qui ne sont pas forcément faits
puisque là on s'adresse vraiment au Neofeed
qui découvre l'infrasco
comment ça marche un petit peu terraform
on va décrire dans un langage
sémantique
descriptif
notre infrastructure
et en fait terraform va nous permettre
avec plusieurs commandes de 1
interroger le fournisseur cloud
pour voir dans quel état il est
planifier
donc on lance une autre commande
pour que terraform nous dise
dans ton code il y a ça qui a changé
mais c'est pas encore sur le fournisseur cloud
donc je vais créer telle machine
je vais créer tel réseau et je vais ajouter tel disque
et enfin il y a une dernière commande
qui nous permet d'appliquer vraiment la configuration
ce qui permet aussi d'avoir
un schéma de ce qu'on va faire
et d'être sûr de ce qu'on va faire
et puis aussi on peut appliquer certaines parties
du code, ce qui nous permet
terraform
je sais pas si en cible fait ça
moi aussi je préfère dédire en cible
à la gestion de configuration
à la création des images de mes serveurs
avec packer mais utiliser terraform
pour gérer tout ce qui est
les services manager
ou non manager d'ailleurs
mais pour répondre à la question
oui j'utilise terraform avec open stack
et j'utilise que ça
ce que je fais souvent
comme je vous l'ai dit c'est je crée une image
qui est la même dans tous les environnements
et je m'arrange pour
configurer cette image là avec des variables d'environnement
à travers
terraform
c'est à dire que je mets un
script d'initialisation
de la machine par exemple
c'est souvent les machines en tout cas qu'on démarre comme ça
et je crée des variables d'environnement
avec des valeurs spécifiques
dans chaque environnement est ce que c'est ça que t'avais en tête Damir ?
alors ma question c'était peut-être un peu plus
par exemple chez kovh
parce que chez qui travaille pas mal avec kovh
ils ont un service de base de données
du coup relationnel
qui est du coup manager
donc c'était ma question c'était est ce que t'as déjà essayé
en fait de monter une base de données manager
avec du terraform
du coup pour ne pas avoir
à installer un maïsql
un post grec ou whatever
et du coup je dirais directement que chose qui est manager
pas avec kovh non
j'avoue que là pour le coup j'ai fait des briques pure VM
par contre je l'ai fait avec Amazon Web Services
au début
j'ai lancé en effet des rds
et autres des load balançeurs
directement
mais pas chez kovh
après je sais que la base de données
à zservice chez kovh elle est assez récente
puisqu'à l'époque je m'étais intéressé à ça elle était encore en beta
je crois
oui elle est assez récente c'est comme chez scalOS
c'est des choses qui sont assez récentes
mais qui sont intéressantes
pour ça je dirais si t'avais un retour dessus
je n'en ai pas encore mais on pourra aller gratter
du coup on a beaucoup parlé de terraform
mais au final je m'aperçois
qu'il n'y a pas vraiment d'alternatives
à part terraform finalement
il n'y a pas d'autres
enfin il y en a peut-être d'autres mais un peu plus confidentielles
ces terraforms ont vraiment trosté
à troster les outils
d'automatisation d'infrastructure
en tout cas
en Cible ils veulent se positionner
là dessus
puisqu'il y a tout un tas
de modules qui sont considérés
comme des modules
certifiés
qui tapent dans
du AWS
j'imagine que globalement
c'est la même chose pour les autres cloud providers
mais il y a clairement une volonté
de tout faire
avec en Cible
c'est vrai que terraform
ils ont un peu pris le marché
ils sont arrivés je pense au bon moment
aussi et il faut voir
qu'il existe des autres solutions comme cloud formation
souvent ils ne sont plus limités
par le nombre de providers
c'est vrai que terraform
au final si on prend
ça fait essayer d'un peu vulgariser
mais terraform c'est un outil
qui regroupe un outil un langage d'un système de fonctionnement
mais après il va y avoir
une partie qui est importante
c'est la partie provider
et en fait vous avez des centaines de providers
sur le site de terraform
et vous pouvez lier votre code terraform
à l'open stack, AWS, AWS
vous avez vraiment un tas de choix différents
ça je pense que ça fait une grosse partie
de sa réussite
et après il y a aussi la boîte qui est derrière
qui s'appelle Hitchhikorp
qui est une entreprise qui a bien réussi
à s'implémenter dans les outillages
un peu qui sont à la mode avec le mouvement DevOps
donc que ce soit vaut, packer
comme tu le citais tout à l'heure
c'est un ensemble d'outils qui fonctionnent très bien
qui sont réputés et je pense que c'est facile
aujourd'hui quand on a une stack avec du packer
il y a des choses comme ça de se dire
je connais quand même l'entreprise
qui soutient ce produit là
c'est un produit solide on a hâte
de se retourner vers eux en fait
vu qu'on est satisfait
tout à fait alors justement
j'étais un peu curieux je suis allé
sur la page alternative2
je sais pas si vous connaissez alternative2.net
et j'ai regardé les alternatives
à terraform et bon le premier
qui sort en effet c'est en cible
il y en a un autre que je vois régulièrement
sortir sur les pub twitter
c'est Pouloumi
j'ai jamais essayé
ça remplace en fait le yaml par un dsl
en code pur ça s'adresse à AWS
Azure, Google Cloud Platform, Kubernetes
et autre
je sais pas si vous l'avez déjà essayé
il y en a d'autres qui, d'autres comme
ClouDifi aussi
les deux Pouloumi et ClouDifi sont
open source
et GiroTools
GiroTools je connais pas du tout
ce que c'est je sais pas
j'ai jamais entendu parler
est-ce que vous êtes intéressé
à ces 3 autres outils ?
non pas du tout
moi je suis pas intéressé
ClouDifi j'en ai déjà entendu parler
après c'est vrai qu'avoir un outil
peut-être scancible je le trouve un peu limité
dans certains cas notamment
au niveau de la gestion du conditionnel
je trouve que c'est très vite
on arrive là je vois sur un projet où j'ai des règles
clairement j'ai obligé de mettre un commentaire
pour expliquer comment fonctionnent les 3 lignes
de code que j'ai mis parce que sinon
ça demande des heures à vraiment être bien compris
donc ça m'intéresserait bien de
voir un bon
remplacé de terraformes
ou une bonne alternative plutôt
qui soit plus poussée sur ces aspects-là
et que soit tout aussi efficace mais
ça demande du temps à tester
il faut voir ce qui sort
de ça
Pouloumi c'est apparemment un
DSL basé sur du piton j'ai l'impression
et
par contre sur leur site
je vois anycloud mais je vois que
AWS Azure et Google Cloud
platform donc déjà IBM on oublie
et puis surtout
OpenStack on oublie
ce qu'elle ou est on oublie enfin bon
du coup si on veut faire du multi-cloud
vraiment poussé
ou même digital ocean je ne sais
quoi c'est un peu dommage
pour les autres je les connais pas
alors moi je voulais juste racheter un petit
point qui peut dérouter et chez qui déroute pas mal
c'est que là tu sais pour faire du multi-cloud
et il y a une confusion que je vois souvent
si vous demain vous faites une application
sur AWS ou autre et que vous voulez
vous l'avez fait avec votre terraformes c'est très propre etc
et vous voulez passer sur un autre fournisseur
comme Scalweb par exemple
ça demandera quand même de redevelopper votre code
votre code ne sera pas agnostique du cloud provider
vous allez interroger des services
qui sont
les services qui correspondent
à votre cloud provider donc c'est pas
totalement transparent là dessus
moi je sais qu'il y a certaines personnes qui pourraient croire ça
donc je préfère préciser ce point quand même
ouais c'est le point que je voulais
aborder justement c'est que terraformes
c'est un super outil c'est un super produit
mais en fait
chaque fournisseur
chaque provider que ce soit cloud
ou autre a son propre formalisme
et pour moi ça c'est un des
points qui sera vraiment à améliorer
c'est d'avoir une agnosticité
du provider derrière
c'est à dire une VM c'est une VM
donc quand on la lance chez Amazon
quand on la lance chez OpenStack
quand on la lance chez Azure ça reste une VM
elle a besoin d'une taille disque
elle a besoin de cpu
de fréquence elle a besoin
je ne sais quoi mais finalement
il n'y a rien qui justifie d'avoir
une description différenciée
en fonction des cloud provider
et moi pour moi c'est un vrai rêve
c'est d'avoir justement un terraformes
qui me permet de m'adresser à n'importe quel cloud provider
avec le même formalisme
et du coup de ne pas retoucher mon code
pour passer de l'un à l'autre
récemment j'ai fait une migration
de cloudwat vers ovh
on pourrait se dire
cloudwat c'est de l'open stack
ovh c'est de l'open stack il n'y a rien à toucher
et bah même là j'ai dû toucher des choses
parce que comme vous le savez peut-être
chez ovh le réseau
open stack il n'est pas supporté
et il faut passer par leur réseau spécifique
et du coup j'ai dû faire des mises à jour
alors qu'en fait si mon
comment dire si mon code est agnostique
j'aurais juste dû à lancer mon code
chez le nouveau cloud provider et il n'y aura pas eu de souci
est-ce que ça c'est un truc qui vous ferait rêver ?
en tout cas
c'est sûr que les cloud provider
ils sont aucun intérêt à pousser
ce genre d'initiative j'imagine
si ça
impliquerait que ça serait encore plus facile
de changer de cloud provider
et donc du coup
du coup j'imagine
qu'il faudrait
que
dans terraformes il y ait
des espèces de conditionnels
pour savoir
suivant le provider
pour traduire à chaque fois avec les bons paramètres
en tout cas dans l'immédiat ça me semble
compliqué comme combat
c'est vrai qu'on y pense pas mal
moi sur une mission
on voudrait faire globalement
un cloud interne
de fournisseurs externes
à français et américains
et c'est une question qu'on s'est posé
est-ce que ce serait pas bien d'avoir un outil qui soit agnostique
c'est vrai que les fournisseurs n'ont pas intérêt à la voir
on va pas se mentir là-dessus
et il y a aussi autre chose
qui est pour moi
un logo qui va empêcher ça
c'est tout simplement que
tu vas niveler vers le bas
en fait si tu vas faire une fonctionnalité agnostique
comme vous avez pour les VM par exemple
quand tu vas vouloir faire ta fonction pour appeler ta VM
tu vas lui donner un certain nombre de paramètres
mais tu vas lui donner le nombre de paramètres que tout le monde a
si par exemple demain un fournisseur
A par exemple à AWS te propose
de sélectionner une option en plus mais que l'autre ne le fait pas
tu ne pourras pas l'implémenter
parce que ce ne sera pas totalement agnostique du cloud
donc tu vas équilibrer tout vers le bas
et c'est un peu dommage surtout que
si tu comparais avec
les fournisseurs cloud majeurs
qui ont beaucoup d'avance
surtout ce qui est service manager
c'est-à-dire que tu vas te priver de toute cette partie là
donc globalement à part ce que tu le fais
sur deux cloud qui ont
à peu près un niveau de service
et de service manager qui sont équivalents
je prends toujours l'exemple français de OVH et SkyLway
qui ont à peu près un niveau de service manager
à peu près ego
là ça serait peut-être possible mais dans le cas
où tu vas ajouter quelqu'un d'autre dans l'indéquation
qui a un peu plus d'avance au service manager
comme on va dire GCP
pour changer
pour moi tu vas niverer tout de suite vers le bas
et malheureusement c'est un peu dommage
c'est une bonne remarque
pour moi c'est pas aussi automatique
parce qu'on pourrait très bien imaginer
que Terraform
alors déjà pour tout ce qui est
lock-in c'est-à-dire ne pas pouvoir changer
de fournisseurs et autres
j'ai envie de dire ils ont tous des API
donc ce serait plutôt à Terraform de s'adapter
à chaque API tout en gardant
un langage de configuration qui soit identique
puis après c'est à lui
c'est lui tout seul qui va s'adapter
à chaque cloud provider mais pour moi il n'y a pas forcément
de nivellement par le bas
si tu justement si tu codes
dans Terraform toutes les fonctionnalités
et que en fait le client
soit assez intelligent pour savoir
je m'adresse à tel cloud provider
ces fonctionnalités-là ne sont pas possibles
donc du coup je vais désactiver
grâce au figure flag tout ce qui est
décrit ici ici ici et puis je vais
m'en informer l'utilisateur évidemment
mais du fait
ça ne nivelle pas par le bas
mais en effet si tu vas chez un cloud provider
qui n'a pas ces fonctionnalités-là bah t'en profites pas
en tout cas moi c'est
quelque chose comme ça
ça me ferait vraiment
ça me s'influifierait la vie tout simplement
si je peux rebondir dessus
ok tu pourrais gérer avec du conditionnel
mais ça marche
pour des petits cas de choses un peu optionnelles
comme de la gestion
d'alertings
ou vraiment des options de bord
mais si tu prends une infra
relativement simple avec un load balancer
avec du l check sur AWS
qui porte un certificat automatique
avec ASM
qui a du coup derrière
on va être gentil on va mettre des VM
on va mettre deux EC2
qui sont chiffrés avec du KMS
qui va chercher une clé sur HSM
et qui derrière a une base de données
managé à RDS et un elastic source managé
bah demain tu veux migrer ça sur AWS
soit tu finis avec un conditionnel
qui va te demander plus de temps de développement
que toute ton application ou quelqu'un
c'est pas rentable parce que si tu veux changer de cloud
t'as autant de tours développés
et à maintenir ça va être pour moi une horreur
mais ça va juste pas être possible en fait
parce que t'as trop d'options et de services managés
qui sont pas à gauche ou à droite
et ça veut dire aussi que si tu dis
que tu gères du conditionnel
tu vas de tous les cas te limiter un certain nombre de cloud
tu vas devoir te dire bah je vais programmer mon truc
et je vais mettre des conditions pour que je suis compatible avec lui
lui et lui mais je pourrais pas faire
un truc totalement agnostique je pourrais pas dire
j'ai fait du conditionnel pour deux cloud ça marchera sur le reste
non tu vas toujours te limiter une liste
donc pour moi dans ce cas là autant limite
faire un double développement parrain d'infrastructures
et d'un côté t'as un code pour un cloud provider
et un pour l'autre mais là je vois pas autrement
comment faire proprement
alors quand j'avais, quand je disais conditionnel
dans ma tête c'était Terraform lui-même
qui savait quelle fonctionnalité activée ou pas
mais pas l'utilisateur
l'utilisateur lui décrit son afra
tel qu'il doit la décrire
en tout cas
c'est je pense
quelque chose qui pourrait être intéressant
au moins pour les bribes communes
après pour en effet les services manager
parce que ce que tu cites c'est des services manager
qui sont très très spécifiques
à certains fournisseurs et en effet
ils s'arrangeraient pour être ultra spécifiques
après oui je cite les services manager
parce que je vois bon à mon avis personnel
mais si c'est pour aller sur du cloud
comme AWS, Azure ou autre
je parle des gros cloud et faire que de la VM
on va pas sur des cloud comme ça
tu vas payer plus cher pour le même niveau de service
et peut-être même des perres fort moins que chez d'autres
donc l'intérêt c'est du service manager
c'est tout l'intérêt du cloud
du cas le public en tout cas
sinon bah pour moi non il n'y en a pas
c'est le principal intérêt
je crois qu'on a
on a dépassé l'heure
là du coup je vois sur mon timecode
je sais pas si vous l'aborder
un dernier petit point avant qu'on se quitte
non pas spécialement mais il y a
après on a parlé
vite fait donc d'infrastructure Ascot
mais il y a plein de questions sous la centre
qui sont intéressantes sur
comment on la teste
comment
comment on travaille
sur repo avec
ce type d'approche etc
comment on fait vivre
ce genre de projet
qui sont des sujets intéressants
mais qu'on importe peut-être plus tard
c'est vrai que c'est une bonne remarque
d'appart d'airwann
on a abordé un peu le sujet de manière globale
du coup comment on débute
c'est vrai que l'infrastructure Ascot
il faut aussi se poser la question de comment on organise son code
comment on organise son travail en équipe
donc à Aigit
ça dépasse un peu comment on le teste
comment on va
versionner des choses comme ça
donc c'est plein de problématiques qui s'ajoutent
et qui sont tout aussi intéressantes et complexes
donc je pense que c'est
des bons sujets pour des prochains épisodes
autrement
je rajouterai juste un petit mot pour la news du début
sur le FOSSDEM
je vais vous faire un article avec notamment
des liens vers toutes les vidéos
qui sont intéressantes
notamment celles
sur les licences dont on parlait en début
sera peut-être plus simple
oui et puis j'en profiterai pour mettre
le lien vers ton blog
comme ça les gens pourront cliquer directement
et obtenir l'article quand tu leur as écrit
je pense en effet
que c'est un sujet qu'on a ouvert et qu'on a pas
encore fini de faire le tour
d'ailleurs j'en profite pour vous dire
que si vous avez des questions à nous poser
ou si vous avez des sujets que vous voulez qu'on aborde
on a maintenant un questionnaire
que vous pouvez nous envoyer des questions
le lien en description
mais si vous voulez
ça nous en verra directement les questions
et on pourra les traiter dans les prochains épisodes
si vous voulez qu'on continue à discuter
nafras, code, un peu plus en détail
de sujets un peu particuliers
n'hésitez pas à nous le dire
et si vous voulez qu'on aborde d'autres sujets
je vous encourage aussi à nous le faire savoir
et là messieurs je vous remercie
et je vous dis peut-être à la prochaine fois
voire sûrement
merci à bientôt
merci à vous à bientôt
au revoir
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 as envie de discuter du mouvement
le plus simple c'est que tu rejoins la communauté
des compagnons du DevOps
le lien est en description
à bientôt