Là, c'est à la fois la livraison continue, la petite soeur de l'ACI, et le déploiement
continue, le petit frère de l'ACI.
Alors, tu te demandes peut-être ce que c'est et à quoi ça sert, et comme d'habitude,
tu es au bon endroit car on va tenter d'y répondre.
Bienvenue sur Radio DevOps, la balade aux diffusions des compagnons du DevOps.
Si c'est la première fois que tu nous écoutes, abonne-toi pour ne pas rater les futurs épisodes.
C'est parti !
Bonjour à toi, chers compagnons.
Et bienvenue dans ce nouvel épisode de Radio DevOps, ton émission de vulgarisation DevOps
et Cloud.
On va tenter de répondre à la question de c'est quoi la livraison continue et c'est
quoi le déploiement continue.
Et pour en parler aujourd'hui avec moi, j'ai Tamir.
Bonsoir, Tamir.
Bonsoir, bonjour à vous.
Et j'ai aussi Mathieu.
Bonsoir, Mathieu.
Bonsoir à tous.
Et enfin, j'ai René.
Bonsoir, René.
Bonsoir ou bonjour à tous.
Mais avant qu'on commence, toi-même tu sais, je vais faire un appel à l'abonnement
classique.
Abonne-toi au podcast, abonne-toi à la chaîne YouTube si tu préfères nous voir plutôt
que de nous écouter, enfin en plus de nous écouter.
Et surtout, tu pourras être notifié parce que près de 40% des abonnés à YouTube ne
sont pas abonnés à la chaîne YouTube et il se passe pas mal de choses sur YouTube.
Alors, petit disclaimer avant qu'on commence, ce podcast, c'est une suite directe de Radio
DevOps n°11 sur les bases de l'intégration continue.
Donc si tu t'apprêtes à écouter ce podcast et que tu n'as pas écouté celui-là ou que
tu veux te rafraîchir la mémoire, on te conseille très fortement d'aller l'écouter
avant celui-ci.
Parce qu'il y a certains concepts qu'on va pas réexpliquer dans ce podcast.
Et surtout, reste bien jusqu'à la fin parce que tu en apprendras plus sur comment on
fait le déploiement et la livraison continue dans nos entreprises.
Alors, la première chose qu'on va faire, déjà, c'est on va dire, c'est quoi finalement
la livraison continue, le déploiement continue.
La livraison continue, si ça ne vous embête pas, moi je vais dire ce que je pense.
La livraison, souvent, c'est l'art de mettre à disposition un livrable.
On le construit et on le met à disposition d'une équipe qui va l'installer ou d'un
projet open source.
Donc, on va faire une release et puis on va mettre à disposition un binaire, un artefact,
un contenant de cœur.
Je ne sais quoi.
Est-ce que vous êtes au cas avec cette petite définition ?
Moi, je suis au cas et ce que je rajouterai pour moi dans ma vision de la livraison continue,
c'est aussi le fait de pouvoir déployer ce livrable via une action manuelle.
Bien sûr, c'est nous humains qui cliquons sur le bouton pour le déployer.
Mais voilà, il y a aussi cette notion de j'ai mon livrable et je peux à tout moment,
c'est mon soi à moi, d'opérateur, à tout moment je peux le mettre en production.
Facilement, via une action très simple, je clique quelque part et ça part.
C'est un artefact qui est déployable.
Si je prends un exemple un peu plus système pour prendre l'exemple, ça serait typiquement
si vous faites une application pour les distributions de des biens, vous bullez votre
DPKG et votre DPKG les bullez.
Vous n'avez pas pu sur les ripos, mais vous l'avez construit en tout cas.
Donc vous pouvez le pousser d'un coup et il sera installé par vos clients.
Merci pour cette précision, c'est très clair.
C'est aussi ça que j'avais en tête, son effet d'avoir un livrable déployable et qu'on
peut déployer à la demande.
Et surtout, il faut le mettre à disposition du public.
C'est aussi ça, enfin du public, du public cible.
Ce ne sera pas forcément public.
Du coup, juste après vient l'autre cidi, le déploiement continu.
Le déploiement continu, comme vous l'avez dit, c'est pour moi l'art de déployer
un livrable, mais en continu.
Le continu veut dire de manière automatisée, etc.
Et là, c'est plus manuellement, mais c'est en continu.
C'est-à-dire qu'on fait sans se poser de questions, c'est automatisé.
Et l'un de vous voulait justement nous décrire un petit peu les types de déploiements,
parce qu'il n'y a pas forcément quels types de déploiements possibles.
En effet, aujourd'hui quand on parle de déploiement, on parle souvent de rolling upgrade.
C'est-à-dire qu'on a généralement plusieurs instances d'une application, même une seule
finalement qui tourne, mais c'est-à-dire qu'on va essayer de faire un déploiement
sans intérution de service.
C'est ça l'important finalement, c'est-à-dire que j'ai pas d'autres instances de mon application
qui tourne en production.
D'ailleurs, un low balancer, je vais en enlever une par exemple, mettre la nouvelle version
en la place, enlever la deuxième, mettre la nouvelle version en la place.
Donc ça va se faire progressivement.
Alors après, il y a plein de stratégies sur ça, sur comment faire ça proprement,
notamment au niveau du réseau, parce qu'il ne faut pas couper les anciennes instances
trop vite de votre application, parce que ce sont peut-être encore en train de travailler.
Donc ça serait dommage que les interrompes prennent plein traitement.
Et donc que le client soit une erreur, ou qu'un job soit tué dans ce déploiement.
Mais voilà, il y a vraiment cette logique de « je déploie » en faisant un rolling restart,
un rolling au cadre de l'application, ou « peu à peu, ma nouvelle version va se mettre à jour ».
Et bien sûr, ça demande aussi une compatibilité entre l'ancienne et la nouvelle version.
Si votre nouvelle version est complètement incompatible avec l'ancienne, c'est-à-dire
que pendant cette transition, les clients, ils ont un problème, parce qu'ils peuvent
tomber soit sur l'ancienne, soit sur la nouvelle version, et donc peut-être planter
une fois sur deux s'il y a des problèmes d'accompatibilité, par exemple de schéma,
de base de données ou ce genre de choses.
Donc le rolling restart, c'est tout un sujet.
Mais il y a beaucoup de littérature sur le sujet, n'hésitez pas à rechercher de la
doc sur ça, mais c'est assez complexe à mettre en place.
On ne croirait pas comme ça, mais il y a beaucoup de problématiques autour de ça.
Mais c'est très important dans son fait du déploiement continu.
Je ne sais pas si quelqu'un veut ajouter quelque chose sur.
J'ai une petite question, tu sais, une fois, c'est quoi le différence avec le
progressif déploiement ou c'est la même chose ?
Pour moi, ça va être pareil.
Il y a plusieurs termes.
Pour moi, c'est un peu la même chose après ce que quelqu'un voit une différence.
Parce que pour si je pousse le truc, le progressif déploiement, ça va être si
tu as plusieurs instances de l'application, tu vas commencer par ton premier serveur.
Tu vas le mettre à jour.
Une fois que c'est mis à jour, tu vas passer au deuxième serveur, etc.
Et ça va se faire de manière progressive jusqu'à ce que tous les serveurs soient
à jour avec la version N plus 1 de ton application.
Du coup, ce n'est pas très différent du rolling.
C'est un peu pareil pour moi.
Parce qu'il y a aussi une version, j'ai un petit doute.
Je ne sais plus si c'est le progressif ou une autre.
Il y a une version où tu fais globalement, je le dirais peut-être à la fin.
On va passer les autres et on n'aura pas à la fin parce que je vais faire un mix
des notions.
Moi, j'avais un point aussi assez important aujourd'hui, surtout dans le
monde de conteneurs, c'est que déployer n'est pas activer.
C'est une autre stratégie, mais vous pouvez très bien déployer une application.
Mais en fait, en parallèle de votre version existante,
bien sûr, déployer une nouvelle version, mais le faire en sorte qu'elle ne
reçoive pas de trafic.
C'est-à-dire qu'elle est déployée, très bien.
C'est-à-dire qu'elle tourne, il y a un check qui tape dessus qui dit elle est
elle-ci, etc.
Mais vous n'avez pas encore configuré votre lobane sur ou votre serveur
dessus pour router le trafic vers cette application.
Donc il y a plein de patern différents autour de ça.
Mais vous êtes très bien, il y a d'avoir une application qui tourne, mais qui ne
reçoit rien.
Et ensuite, c'est un logiciel ou je ne sais pas, un outil qui va peu à peu
incorporer, enfin commencer à router du trafic vers ses nouvelles instances.
Ça, c'est assez intéressant, c'est-à-dire, j'ai des applications, mais qui ne
reçoivent pas de trafic.
Je l'ai peu vu celui-là, sur YouTube.
La France.
Par exemple, sur QBatis, très rapidement, QBatis
utilise, on peut utiliser des services pour router vers des applications, vers des
pod et les services sont des sélecteurs.
Pour sélectionner les pod à router, rien n'empêche de déployer une nouvelle
relation de ton application sans les sélecteurs de ton service.
Donc l'application tourne, mais de ressort pas de trafic et ensuite mettre à jour le
service pour basculer le trafic dessus.
Donc c'est des choses qui peuvent également se faire assez facilement.
Juste pour, ça permet en fait de déployer l'application et voir si elle tourne.
Alors la laisser tourner, par exemple, cinq minutes, dix minutes, un quart d'heure et
voir auquel ressort pas de trafic.
On voit qu'il y a ça à l'air stable, ça crache pas.
Le schéma d'abasonner, c'est bien mis à jour, etc.
Et ensuite, on va déclencher un réunis d'upgrade ou qu'on sert au télétratique dessus.
Alors si je peux me permettre, moi, j'ai déjà écrit des procès de déploiement,
mais on sort un petit peu du cadre.
Mais du coup, on déploie l'application en effet sur un nouveau serveur et on attendait
genre en effet une minute.
On testait si l'application était montée, était up dans le process de déploiement.
Et seulement si elle répondait correctement, on la mettait dans le bloc de balancer pour
qu'elle reçoive du trafic.
C'est ça que tu avais en tête.
En quelque sorte, et sur Cublattis, finalement, savoir est-ce que l'application est up, ça
va être ta probe, finalement, déclenché par Cublet dans le cas de Cublattis.
Et voilà, il y a des patterns très intéressants sur tout ça.
La note procès de déploiement que René va nous décrire, qui est un process que
j'aime beaucoup aussi.
Oui, je vais tenter ces blougren des poignettes.
Donc l'idée, en fait, c'est de...
ça ressemble un peu à ce que vous disiez avant, c'est d'avoir une autre version actuelle qui
tourne sur un bout d'infrastructure, de préparer sur un autre bout d'infrastructure
la nouvelle version.
Et donc ensuite de faire souvent pointer les utilisateurs vers cette nouvelle version.
Et donc de conserver, entre guillemets, l'ancienne en état, ce qui va permettre de
parrainement faciliter si on a besoin, si on constate un problème, le retoit arrière.
Voilà.
Est-ce que tu veux ajouter quelque chose, Christophe ?
Non, c'est bien.
Mais en fait, c'est en effet, il y a vraiment les deux versions qui tournent en parallèle
et on passe de l'une à l'autre assez facilement avec les autres balançeurs ou les équivalents.
Et si on sait perso qui a un problème, on peut revenir sur la précédente version.
Et du fait, c'est quelque chose qui ouvre vers le dernier, en tout cas le dernier que moi je
connais, que René va nous décrire aussi.
Ouais, c'est Canary Release.
Donc pour moi, c'est un peu...
C'est aussi une variante aussi du rolling update, plus ou moins.
Et du blue-green, l'idée, c'est de prendre, de mettre un échantillon, donc un certain
pourcentage de la nouvelle version en ligne et donc de voir comment ça se passe pour
les utilisateurs qui vont...
Pas tous les utilisateurs vont l'utiliser, mais le petit pourcentage d'utilisateurs qui
vont utiliser cette nouvelle version, on va pouvoir s'assurer que ça marche bien
pour eux et si c'est le cas à ce moment-là, on va basculer l'intégralité de l'application
vers la nouvelle version.
Et si c'est pas le cas, on a entre guillemets eu des cobayes qui ont testé la nouvelle
version, il y a eu un échec et ça nous a permis de le détecter et de corriger en fonction.
Ouais, du coup, moi, j'ai assemblé, on va dire, je voulais séparer le progressif du
Canary.
Mais le Canary OS, c'est ça, c'est...
Vous avez les deux versions et vous mettez du trafic dessus, petit à petit, en fait,
vous en mettez de plus en plus.
C'est notamment ce qu'utilise aussi dans les cas de software matériel souvent.
Quand vous avez des...
Des téléphones, par exemple, on met pas à jour tous les nouvelles versions d'IOS
ou d'Android en même temps.
Ils le mettent généralement région par région, secteur par secteur, pour pouvoir
avoir des retours et voir si ils continuent à déployer ou pas.
C'est le genre de choses qui se fait beaucoup.
Et il y en a aussi un autre qui est un peu une dérivé de ça, qui est un peu plus rare
à voir mais qui existe.
Moi, j'ai déjà eu le cas dans une entreprise qui est le...
Je crois que...
Ça, on s'appelle le Ring Baset Development, j'essaie de chercher le nom, mais il me semble
que c'est ça.
Qui est du coup un peu le même système sauf que là, vous allez catégoriser en fait
les personnes et vous allez avoir des personnes qui auront des comptes de beta globalement
qui seront des insiders.
C'est comme ça que ça a appelé notamment chez Microsoft.
Mais en tout cas, vous allez avoir des personnes qui vont avoir des versions qui vont être
par défaut, mit de source la version plus récente.
C'est ce que vous avez notamment avec des choses comme Firefox Nightly ou d'autres
qui vous permettent en fait si vous êtes volontaires pour tester une nouvelle version et tester
surtout les nouveaux bugs, de l'avoir la dernière version avant tout le monde, mais
du coup, potentiellement de devoir remonter des bugs avant tout le monde.
Alors ça, je l'ai vu au Ducanaris justement, la population que t'en vois, tu peux avoir
l'identifier comme ça, tu peux l'identifier sur un usage, tu peux l'identifier sur plein
de trucs et du coup en effet, c'est un dérivé.
Mais après, c'est un dérivé, mais c'est un dérivé qui est beaucoup utilisé par les
grosses entreprises parce que du coup, on peut vraiment cibler des personnes qui seront
plus à même de qualifier les bugs.
Je digresse deux secondes là-dessus, mais typiquement il y a un retour de quelqu'un
sur Reddit, Frigio Redouf qui est super intéressant, qui expliquait que sous Linux en fait, il
avait beaucoup plus de reports de bugs parce que les gens savaient reporter des bugs déjà
et parce que surtout les gens savaient les qualifier, il a dit, il a donné un tas
d'infos alors que les gens qui ne sont pas sous Linux donnaient au moins beaucoup moins
d'infos.
C'est un exemple, mais souvent du coup, avoir des insiders, c'est aussi avoir des personnes
qui ont fait les bétas, des personnes qui potentiellement sont volontaires et surtout
sont peut-être plus qualifiées pour remonter des bugs et donner des informations que demandaient
Hollanda avec des pourcentages.
C'est très lié pour moi aussi aux features Flags finalement, c'est-à-dire pour activer
des features en fonction de critères sur certains utilisateurs.
Moi, j'avais ça dans ma boîte précédente, j'étais, je travaillais pour l'entreprise,
donc j'avais un flag private beta où j'avais accès à tous les super trucs qui n'étaient
pas ouvert au public.
Et finalement, entre toutes ces méthodes, pour moi ensuite, c'est vraiment à chacun de
choisir sa granularité, c'est-à-dire de dire, moi, je fais un peu du bluegrine, par exemple,
je déploie mon appli x2 et ensuite je gère comme je veux le trafic ou les rollbacks ou
je mixe du bluegrine avec du canari ou bien je déploie une version qui ne reçoit pas
la trafic pour faire pourquoi pas des tests internes comme tu disais.
Donc seulement des utilisateurs très spécifiques pourront aller sur ces versions pour se
rouler vers ces versions ou des problèmes de test pour qualifier la release.
Enfin bref, ensuite, c'est vraiment à chacun de choisir.
Ce que je veux dire, c'est qu'il n'y a pas de tout faite en fait, il y a plein de granularité
dans tous ces méthodes.
Justement, tu parlais des features Flags, c'est intéressant, mais souvent moi, les features
Flags, les voix pas en canari, je les vois vraiment en rolling parce qu'en fait, tu
vas déployer une nouvelle version de l'application avec du code mais qui n'est pas activé et
on va pouvoir l'activer soit avec de la config dans la base de données, soit avec le redeploiement
d'une nouvelle version.
C'est quelque chose que je vois régulièrement ça.
Mais du coup, on est passé un peu vite sur le canari.
Qui peut me dire pourquoi est-ce qu'on appelle ça canari déploiement ?
C'est à cause des canari dans les mines si je me sens bien des petits oiseaux, non ?
C'était ça.
Souvent, les mineurs embarquaient un canari pour savoir si, pour prémunir du grisou, des
gaz toxiques et le canari est en plus petit que l'homme, souvent il...
Il succomber avant.
Il décédé avant.
Voilà, c'est pas très joli mais ça indiquait qu'il y avait un problème et que l'ambiance
était toxique et donc ça permettait aux mineurs de s'enfuir.
C'était des solutions l'OTEC avant qu'on ait des capteurs ou des choses un peu plus
avancées on va dire.
C'était écologique au moins.
Exactement.
Et un petit bout sur le feature fly, il y a une autre option aussi, des fois l'activer
en fonction des profits d'utilisateurs.
Ça se fait aussi.
Et justement, puisqu'on parle de déploiement continu et livraison continue, est-ce qu'on
peut faire un lien avec le GitOps qui est venu après le Everifin continue ? C'est quoi
finalement le lien entre le déploiement continu et le GitOps ?
Alors je sais que Mathieu voulait nous parler de quelque chose d'autre.
Oui, en effet, déjà il y a un lien très fort où généralement on n'en reparlera beaucoup
après, on ne se reparle des outils, votre... déjà la version de votre application, etc.
peut être stockée dans Git, bien sûr.
Mais le déploiement continue ne se limite pas aux applications en elles-mêmes.
On peut faire du déploiement continu sur la configuration par exemple.
Sur Humanities, des fausses comme les Roles ou les Cluster Roles ou les services accounts
peuvent être déployées automatiquement, qu'il y a des outils de déploiement continu,
dont on parlera après.
De la même façon, peut-être que vous travaillez avec des outils un peu plus traditionnels,
je veux dire installés sur des serveurs ou des machines virtuelles comme je ne sais
pas, Cassandra, Astix Search ou autre.
Et là aussi, peut-être une mise à jour de configuration sur un outil là va, par exemple,
je vais changer la HIP dans Astix Search ou je vais Cassandra modifier un réglage.
Je merge ma modification et automatiquement, je aurai un rolling restart peut-être dans
mon cluster pour appliquer cette configuration.
Alors bien sûr, ça peut être un peu sensible, surtout quand on a de la donnée derrière.
Mais voilà, le point important, c'est que le déploiement continue ne s'applique pas
aux applications et aujourd'hui on peut traiter de la configuration au sens large,
comme une application et même faire des tests sur vos configurations.
Alors on peut en se faire sur des linters, des choses comme ça, on reparlera de tests
après.
Mais on peut aussi aller très loin sur le déploiement continue de configuration.
Oui, c'est important de rappeler que le déploiement continue, en effet, ça ne concerne pas que
les applications et du coup le GitOps, c'est venu après parce qu'on le déploiement continue
et la livraison continue, c'est tout basé sur l'automatisation et qui dit automatisation
dix codes, qui dit code, dit Git aujourd'hui.
Et donc GitOps, ça veut évidemment dire qu'on va tout stocker dans Git et Git et notre référence.
Je vous renvoie à l'épisode de podcast justement là-dessus où on parlait de GitOps, enfin
où je parlais tout seul, de GitOps.
Et GitOps est venu un peu plus tard, notamment avec l'avènement de Kubernetes, j'ai commencé
en entendre parler, je ne sais pas si vous, c'était pareil, de cette méthode là de déploiement
avec Kubernetes.
Je ne sais pas si on en parlait un petit peu avant.
On en parlait déjà un peu avant, je pense, moi j'en entends déjà un peu.
C'est vrai que c'est beaucoup plus démocratisé maintenant, mais déjà à l'époque, entre
qui m'est, quand j'ai commencé à travailler, c'était les choses qu'on faisait déjà
avec des outils en Kubernetes, on parlera tout à l'heure, mais notamment en Cible où
on avait un fichier Yamel qui décrivait l'état des versions de chaque composant,
et on se basait là-dessus pour faire nos pas pleines de déploiement continu par exemple.
Mais Kubernetes a vraiment démocratisé la fausse en effet.
Je parlais vraiment du flug GitOps qui a été décrit par, je ne sais plus quelle société.
NX, non ?
Non, ce n'est pas NX, mais c'est pas grave, je retrouverai ça et je le mettrai dans les
liens de l'épisode.
Tout ça pour dire que le GitOps, on parle souvent de GitOps en mode push ou en mode pool,
ce qui fait qu'en fait, quand on déploie, on a deux méthodes.
On a la méthode traditionnelle où on va pousser nos applications,
nos configurations sur nos serveurs, sur nos plateformes, sur ce qu'on veut.
Où on a une méthode qui, selon moi, un peu plus récente, où c'est le serveur lui-même,
on va parler du serveur ou le service lui-même, qui va chercher tout ce qui doit mettre
à jour.
Et ça, c'est en fonction de ce qu'on veut faire, on peut prendre l'une ou l'autre
des méthodes.
On y reviendra peut-être plus tard dans les retours d'expérience, justement pour
dire ce qu'on en pense, à moins que vous ayez quelque chose à rajouter juste sur ces
deux méthodes-là.
Des fois, elles peuvent se combiner.
Pour moi, en fait, c'est-à-dire que ça peut être quelque chose qui pool régulièrement
l'état voulu et en fonction de ce qui est détecté, va pousser ensuite du changement.
En fait, des fois, il y a un peu à mix des fausses.
C'est-à-dire que je surveille un état, je surveille, par exemple, la version de mon
application et quand je détecte un changement, je déclenche un push, par exemple.
Sur un push, on l'en sert déploiement du manière ordine d'autre, taper une API pour
déguster.
Des fois, la frontière, selon les outils, la frontière est un peu ténue, finalement,
entre poule et push parce que des fois, les deux sont mixés dans la même vie.
Du moment qu'on observe quelque chose, on fait du pool.
Mais pour déployer, des fois, on a du push aussi.
Je vais peut-être dire une bêtise, mais il me semble que le pool, ça ne se rapproche
plus justement dans des idées de non-déviation de la configuration et donc de regarder très
régulièrement où on en est.
Et si on n'a pas des vies.
Ça peut être fait en mode push, je pense notamment à quoi que je ne sais pas.
A Rodeur, qui est un outil de mise en conformité permanente, mais il se base sur un agent.
Je ne sais pas si c'est le mode push ou pool qu'il est utilisé, mais en tout cas, il
y a un serveur qui regarde régulièrement ce qui se passe et puis il met à jour.
Enfin, il envoie très certainement des actions au agent et les agents peuvent se mettre à
jour.
Et quand on va faire du déploiement continu, puisqu'on ne va pas être déploiement continu,
la livraison continue, c'est plutôt qu'autant intégration continue.
Est-ce qu'on a des pré-requis?
C'est de ça dont on va parler.
Et Damir, tu as quelques pré-requis à nous proposer.
Oui, j'ai deux pré-requis qui me reviennent un peu en tête.
On va dire, première, c'est qu'il y a un enjeu de confiance dans sa chaîne CSID.
Pourquoi un enjeu de confiance?
Au-delà de vous et de la tech, il faut que techniquement, vous soyez sûr que votre
chaîne va fonctionner, elle ne va pas engendre l'erreur.
Mais ça, globalement, on ne va pas se mentir, on sait faire.
Et ce n'est pas ce qu'il y a de plus dur aujourd'hui.
Le plus dur, souvent, c'est aussi que le métier est confiance dans cette chaîne-là et puisse
avoir, on va dire, accepter que le code puisse être poussé automatiquement dans l'application,
que l'application puisse changer automatiquement.
Donc ça, c'est quelque chose qui est souvent un peu plus dur à faire accepter, surtout
sur des enjeux ou des boîtes un peu historiques, notamment par les non-techs.
Soit c'est les non-techs qui ont un peu plus bloqué là-dessus, moi, en tout cas de mon
expérience.
Donc ça, c'est une première chose, c'est vraiment vraiment confiance dans ce fonctionnement-là.
Et pour avoir confiance dans cet élément-là, en fait, il y a une chose qu'il faut savoir
faire depuis tout à l'heure.
On parle de déploiement continu, mais le déploiement continu, avant de pouvoir le faire,
ça implique une autre chose, c'est de pouvoir faire du rollback continu, si j'ose dire.
C'est-à-dire savoir rollback facilement, de manière propre, sans tout péter.
Et de manière rapide, en fait, il ne faut pas que ça soit, oui, il y a un process manuel,
alors que notre CD est automatique.
Dans l'idéal, il faut vraiment que vous avez un numéro de version.
Le rollback, c'est juste de changer le numéro de version vers une précédente.
Ça, c'est dans l'idéal et que ça fonctionne mal transparent.
Donc ça, redépose la version précédente et qu'il n'y ait aucun impact.
Bien sûr, ce n'est pas toujours possible.
Des fois, il y a des changements en base de données, etc.
Mais pour moi, pour moi, c'est deux choses importantes.
C'est si on ne sait pas rollback, on n'aura jamais de taffé confiance dans le déploiement,
parce qu'on sait, même malgré tout nos tests, il y a toujours quelque chose qui peut foirer.
On peut aussi avoir très bien un truc.
On a des sétro de libertés à l'utilisateur et des utilisateurs qui ont commencé à se
pasmer certaines choses.
Donc c'est important de savoir rollback pour avoir confiance.
Je sais pas si vous êtes d'accord là-dessus.
C'est bien, mais je pense que ce n'est pas forcément nécessaire si on a justement
un process de retour arrière qui peut être mis en place.
Alors, je m'entends parce que moi, c'est vrai que je ne fais pas de déploiement continu en production.
C'est-à-dire que, on va rappeler le déploiement continu,
parce que ça se fait sans intervention humaine.
Donc ça veut dire qu'on pousse, donc il y a un déploiement.
Ce qui est un peu différent du déploiement automatisé.
Donc en effet, si on veut quand même pouvoir être sécurisé, il faut avoir un rollback.
Moi, je fais du déploiement continu dans tous mes environnements à reprod.
Et si je vais en prod, c'est une action manuelle qui déclenche un déploiement automatisé.
Mais du coup, j'ai tout testé avant.
Donc c'est pour ça que je me permets de faire du déploiement sans rollback.
Et puis on n'est pas assez nombreux pour pouvoir déclencher du rollback continu chez nous.
C'est pour moi, je comprends le fait que vous ne savez pas nombre etc.
Mais le rollback, c'est quand même pour moi très important.
Parce qu'en fait, il y a une très bonne série d'articles sur ça.
D'ailleurs, je pourrais éventuellement, un link de Cindy Syriedarhan.
J'espère que je vais écorcher son nom.
Copie construite sur Twitter, qui est une ingénieur que je respecte beaucoup.
J'adore ce qu'elle écrit.
C'est une série d'articles qui a fait beaucoup de bruit à l'époque.
Ça s'appelait Testé en production, Testing in production,
quelque chose comme ça, une très grosse série d'articles.
Et elle disait qu'il faut se d'assez juste sur ça.
C'est que finalement, il n'y a qu'en production qu'on peut tester vraiment.
C'est-à-dire qu'en les environnements avant, il n'y a pas de charge,
il n'y a pas d'utilisateur généralement,
ou même quand on fait des tests de charge, ce n'est pas toujours pertinent.
Enfin bref, quoi qu'on fasse, le vrai test, c'est le passage en prod.
Et donc, le rollback est quand même très souvent important.
Ce n'est pas simple, surtout quand il y a de la donnée,
quand il y a des migrations de schéma ou de données,
on va dire dans le basse donnée, etc.
Le rollback, ça peut être compliqué.
Mais, c'est reste un point important parce qu'il faut se rappeler que pour moi,
moi je pense ça aussi, la prod, en fait, la prod, c'est là que le vrai test se fait.
Ailleurs, on essaie de faire des tests pour limiter la casse, etc.
Bien sûr, mais tant qu'on n'est pas en prod, on ne teste pas jusqu'au bout.
Après, il y a aussi un autre truc pour donner un exemple de tests
qu'on ne peut que faire en prod.
Et Véret dit que je l'ai connu, il y a longtemps certes,
je l'ai connu de lui, qui s'est changé de place,
les boutons, ils ont notamment inversé de menus.
On a du rollback là-dessus parce que les personnes qui étaient de l'administration
assez ancienne, qui étaient de ces habitudes, étaient totalement perdues.
Et en fait, il y a plein de gens qui faisaient des fausses manipulations
et ça débordait le support.
Et ça, on n'aurait pu prévoir avec aucun réel test, en réalité,
parce que c'était de l'humain derrière.
Et moi, je vois vraiment, et c'est pour ça que je pense qu'effectivement,
au final, même si on dit, il ne faut pas tester en production,
on teste dans un certain sens, en production, il faut juste pas envoyer n'importe quoi en production.
Mais soit on teste un minimum en production.
Et là où je trouve, moi, où j'insiste sur le rollback,
c'est que j'ai vu beaucoup moins de stress chez les personnes
et beaucoup plus de confiance quand il y avait un rollback.
Quand le process de rollback était automatisé, était clair,
il y a beaucoup moins de stress.
Et souvent, c'est des personnes qui vont te dire,
bah ça peut déployer automatiquement,
ça peut même déployer le vendredi, il n'y aura pas de soucis,
parce qu'on sait revenir en arrière.
Tandis que généralement, quand tu ne l'as pas, il y a toujours un peu une hésitation en mode.
Ouais, il faut quand même qu'il y ait un ops qui surveille
que le job ou que le trigger se passe bien, parce qu'on sait jamais.
Il y a aussi deux choses là-dedans, c'est qu'on peut déployer en continu
des applications, des configurations et l'infrastructure.
C'est beaucoup plus compliqué, parce que moi,
tout à l'heure, je pensais à l'infrastructure,
je l'ai pas précisé, mais c'est beaucoup plus compliqué
de faire d'un rollback sur de l'infrastructure,
que sur de l'application en effet, sur de l'application.
Il faut s'assurer que les versions qui se suivent,
la version n'est plus compatible avec la version n-1,
on peut faire un rollback comme ça assez facilement.
Pour l'infrastructure, c'est un peu plus touchy, je trouve.
Je ne sais pas vous, mais nous, c'est un peu plus touchy.
C'est compliqué en effet,
les briques ne sont pas toujours compatibles entre elles, de base.
Je ne sais pas si vous faites une grête majeure de...
Ça dépend des briques, mais les applications en cluster,
parfois, des choses comme ça,
un grê de majeure, ça peut être compliqué.
Dès qu'à la donnée, c'est compliqué de base,
de la réplication, des choses comme ça,
on sait que ça va être la foire.
Alors généralement, les vendeurs,
les développeurs de ce type d'application prévoient quand même des choses,
mais en effet, sur l'infrastructure,
ça peut être la base de données,
ou des choses comme ça, ça peut être compliqué.
Je pense qu'au niveau infrastructure,
il y a deux choses à séparer.
Il y a ce qui peut être rollback facilement.
Par exemple, une configuration d'un service,
tu rollback le chiffre de conflits, tu le redéploies, il n'y a pas de souci.
Et il y a ce qui est effluant en plus du raw backup,
quand il y a de la potentie de la base de données, des migrations, des choses comme ça.
Et effectivement, dans les cas là, pour moi,
on rentre dans quelque chose qui...
peut potentiellement être fait dans la CIACID,
mais il faut mettre vraiment des gros warnings,
avec des sauvegards d'avant et après, etc.
Donc soit on fonctionne de cette manière-là,
soit après, il y a une manière qu'il y a un peu moins fun,
mais qui est en fait la manière qui marche le mieux dans la vraie vie.
On va pas se mentir.
Ce qui est de se dire, si la modification est trop importante,
c'est action manuelle, mais on sait comment la faire.
Mais par contre, ce n'est pas spotum automatisé.
Moi, je fais vraiment le distinguo entre les deux,
où il y a des choses qui sont des actions, on va dire,
trop spécifiques pour être automatisés à chaque fois, etc.
Et qui sont des opérations souvent d'infra,
un peu pointues, des upgrades de cluster, des migrations,
des choses comme ça, et des opérations courantes de CIACID,
par exemple, changer une valeur dans un conflème génique,
soit un truc comme ça, qui sont plus de courants.
Oui, je voulais juste dire les opérations sur les databases aussi.
Oui, vraiment pas simple de faire un rollback parfois.
Il y a des outils qui permettent de faire ça sur certaines bases de données,
mais sur d'autres, ça n'existe pas forcément si facile que ça.
Et puis, parfois, il y a un aspect,
puisque j'ai été confronté à ça il n'y a pas très longtemps,
des fois des aspects qui performent,
pour faire parfois un rollback ou certaines choses
qui peuvent rentrer en ligne de compte.
C'est un truc ?
Bref, avoir un backup est parfois la meilleure solution.
Oui, ça me fait penser à un truc très intéressant,
c'est si vous pouvez notifier vos systèmes de mesure
quand vous faites un déploiement, c'est vachement bien,
parce que comme ça, vous pourrez voir les consommations avant, après,
et voir s'il y a un impact au niveau des déploiements.
C'est un truc qu'on pense assez peu souvent, et quand même, il faut y penser.
Alors du coup, on va avancer dans les pré-requis.
Moi, j'en vois plusieurs autres,
notamment, il faut que les équipes de développement soient en mode agile.
Bon, on parle de DevOps,
mais si l'équipe de développement ou les équipes de développement
sont déjà en mode agile,
ben, c'est même pas la peine de penser à mettre en place
une intégration continue et encore moins un déploiement continu.
Évidemment, il faut des tests automatisés, des tests d'intégration,
si possible, des tests fonctionnels.
Mais bon, on sait bien comment ça se passe,
mais des tests unitaires et des tests d'intégration,
c'est quand même le minimum, selon moi.
J'ai quand même des clients parfois qui viennent me voir et qui me demandent,
et on voudrait mettre en place un déploiement continu,
et je leur demande, vous avez des tests ?
Non, ben, revenez voir quand vous en avez.
Bon, bref, j'arrête de troller.
Du coup, l'autre truc aussi, c'est,
comme on parle de package et de livraison continue,
on peut aussi parler d'anneils statiques de code
et genre de choses sur les artefacts qu'on va créer.
Mais ça, ça fait encore partie de l'intégration continue.
En gros, avoir une bonne intégration continue
avant de se lancer dans le déploiement continue.
Et Mathieu, tu as un petit point à rajouter.
Oui, parce qu'on parlait en effet d'un service
qui doit être compatible avec sa version précédente,
et ça va, pour les données, par exemple.
Mais aujourd'hui, on parle beaucoup de microservice,
et il faut aussi que ces services soient compatibles entre eux.
Et dans du déploiement continue,
ou à chaque fois qu'un, donc imaginé,
on vous avait 50 services en production,
avec plein de développeurs qui travaillent dessus,
à chaque fois que quelqu'un va marcher à partir en prod,
il faut être sûr que s'il y a des déploiements qui se font,
parce que les services parlent entre eux,
et les déploiements vont se faire en tout le temps,
qui puissent continuer à parler,
pas que d'un côté, par exemple, le service A,
mais à jour son contrat.
Par exemple, il y a un nouveau champ obligatoire
dans la requête HTTP que ce service s'attend à recevoir.
Et le service qui parle avec,
et bien, lui, il n'a pas la bonne version qui tourne.
C'est encore en cours de dev, donc comment je fais ?
Donc ça, c'est vraiment aussi un truc très, très compliqué.
C'est souvent un gros point de blocage pour moi,
dans les architectures micro-services,
notamment avec du déploiement continu,
c'est comment j'ai confiance,
finalement, que mes services parlent le même langage,
parce que je veux déployer très, très, très souvent,
mais je veux garder de la compatibilité entre mes services.
Je veux pouvoir que différentes équipes avancent à différents rites,
mais éventuellement, et pas être bloqués,
par exemple, l'équipe A n'a pas fini son pré-requis pour l'équipe B.
Enfin, après, c'est vraiment des niveaux,
enfin, des discussions d'organisation, en fin d'entreprise,
mais les micro-services ont rajouté beaucoup de ruplexité
sur ça aussi, sur le format d'échange.
Merci.
Je pense qu'on a fait le tour des pré-requis,
et on va pouvoir rentrer du coup dans le vif du sujet
sur quoi, en fait, tourner une intégration,
enfin, j'ai vendu un déploiement ou une livraison continue.
Du coup, en fait, on a parlé tout un tas d'outils
dans l'épisode d'intégration continue.
Grosse modo, dès qu'on a une gestion de pipeline,
quel que soit l'outil, à priori, on doit pouvoir faire du déploiement continue,
puisque en fait, à partir du moment où on peut faire, pour moi,
l'intégration continue, qu'on peut déclencher,
n'importe quel programme, on peut faire du déploiement continue,
au moins en mode push.
Le mode pull, on va en parler un petit peu plus précisément,
parce qu'on va aborder un petit poids Kubernetes,
on va atteindre notre poids Kubernetes,
et on va parler de quelques petits outils.
Alors récemment, chez nous, on a fait un poc,
et on a observé pas mal d'outils qui sont dédiés
au déploiement continue dans Kubernetes,
notamment Flux, Spinaker et Argo CD.
On a beaucoup joué avec Argo CD un peu moins avec les deux autres,
donc je voulais savoir ce que vous en pensez avant,
mais tous ces outils-là, grosso modo,
ce qui permet de faire, c'est vous installer quelque chose
dans votre agrégat Kubernetes,
et vous le pluguer à votre dépogit,
et ces outils-là, ils vont scruter le dépogit,
et dès qu'il y a un changement dans vos manifest,
dans vos infrastructures, etc.,
il va automatiquement l'appliquer dans votre Kubernetes.
Est-ce que j'ai dit une bêtise, les gars ?
Non, tu n'as pas dit de bêtise,
alors moi je ne connais pas non plus Flux et Spinaker,
à part les articles que j'ai d'où dessus ou pas,
mais je suis un très gros utilisateur d'Argo CD.
Dans l'écosystème Kubernetes,
il y a une brique qui change tout,
qui a vraiment changé ma vie, c'est Argo CD.
C'est vraiment un super outil,
mais si vous faites du cube, faites du Argo CD,
c'est vraiment génial,
ça vous fera garder beaucoup de temps,
et comme l'a dit Christophe,
Argo va surveiller un répot,
plein de répôts,
c'est vous qui choisissez, des dépots Git, etc.,
et dès qu'il y aura un changement,
l'appliquer,
il y a deux modes,
et là on revient sur l'hybraison continue
contre versus déploiement continue.
Argo peut vous dire,
il y a une différence,
il y a quelques fausses qui ont changé,
je dois me resynchroniser,
c'est à vous de appuyer sur le bouton,
ou de faire un appel API pour dire,
déclenche l'action,
sacronise-toi et fait le déploiement,
et il y a le mode
la synchronisation se fait automatique,
ça peut être par dépôt ou par application,
donc c'est vraiment vous qui choisissez la granularité,
ce qui est assez cool,
et comme on a dit précédemment,
Argo CD peut gérer tout type de ressources humanitises,
donc application,
configuration, clusor,
role, CRD divers,
c'est un super outil,
avec une super UI,
donc moi je suis assez fan comme vous voyez.
Je suis aussi fan que toi,
quand on a vu les autres,
et qu'on a vu Argo CD,
on a fait Argo CD, on a essayé, on a poussé,
et on est très fan aussi chez nous.
Comme tu le dis, il y a une super UI,
à tel point que pratiquement on n'utilise que cette UI,
on n'installe même plus
l'UI standard Kubernetes,
puisque avec l'Ans et ça,
on s'en sort parfaitement,
ça permet de faire beaucoup de choses,
et en plus,
c'est l'un des outils
de déploiement continue Kubernetes,
les plus utilisés, en tout cas les plus téléchargés,
il est passé devant tous les autres depuis un petit moment maintenant.
Quand pensez-vous d'Amir ou René ?
Moi perso,
je l'ai vraiment, c'est un outil que j'ai vu 2-3 fois chez des clients,
j'ai jamais vraiment bossé dessus,
il fait partie
de ce nombre incalculable d'outils
que j'ai dans ma liste d'outils
à regarder, à tester un jour,
liste qui ne finit pas de grandir,
malheureusement, ou heureusement, je ne sais pas trop.
Donc du coup, j'ai vu de loin,
je sais que beaucoup de monde en parle,
même sur le forum des compagnons de DevOps,
ça les gens en parlent,
dans mon entreprise précédente de CNU GT,
ils en parlent aussi.
Donc du coup, non,
c'est un outil qui est ultra populaire,
et il y a des raisons, ce qui fonctionne bien,
et c'est qu'il est ultra adapté à Kubernetes,
Kubernetes a changé beaucoup de choses,
il y a beaucoup de possibilités,
et de ce que je vois, Argos CD,
pour moi, c'est démis dans le package Kubernetes.
Aujourd'hui, je parle sur du Kubernetes,
j'ai l'impression que ça vient avec par défaut,
tu réfléchis même plus trop à ça au final.
Donc non, l'outil a l'air bien après,
c'est un outil qu'il faut que je teste,
il faut du temps.
En plus, il vient avec un écosystème d'autres outils,
parce qu'on n'a pas parlé de d'autres parce que ce n'est pas le sujet.
Et toi, René, est-ce que tu fais du Kubernetes ?
Non, alors je ne sais pas de...
Alors je connais Argos CD,
j'ai un peu joué avec,
mais pas dans des vrais cas,
on va dire,
d'exploitation,
ça reste plus du lab,
donc voilà, je ne fais pas grand-chose de plus à dire,
que ce que vous avez.
Après, on pourrait parler de tout un tas d'autres outils,
comme Tectron et autres,
mais moi je ne les connais pas, je ne sais pas vous,
mais il y en a plein,
donc faites-vous votre avis,
et au final, choisissez Argos CD.
Voilà, c'est tout ce qu'on peut dire avec Mathieu.
Pour du coup,
le déploiement continue,
quand est-ce qu'on va la déclencher
dans un flux de développement ?
Est-ce que l'un de vous veut nous en dire à quelques mots ?
Il y a plusieurs fois,
moi de mon expérience,
en fait, ça dépend, j'ai connu plusieurs modes,
après, il y a une partie RECS après,
je ne sais pas si je commence là-dessus,
mais au moment où vous mergez,
mergez votre branche sa part en prod,
ça fait une relise,
il y a le mode un peu
hybride,
livraison continue,
ça va être plutôt,
vous mergez, ça fait une relise,
et peut-être que vous allez devoir ensuite mettre
la nouvelle version, la référencé dans un fichier,
dans un autre dépôt,
dans le même dépôt,
je veux déployer cette version,
et ce n'est pas fait automatiquement,
là on est plus sur de la livraison continue,
après, il y a des gens qui ont
des flow-guitres
très complexes,
avec des branches par environnement,
moi, personnellement,
je ne suis pas fan de ça,
j'ai toujours détesté
tous les guides flow,
avec trop de branches,
je préfère avoir FeturBrain,
Meshmaster et c'est tout,
mais je sais qu'il y a des gens
qui travaillent très efficacement,
mais il y a plusieurs modes
finalement, pour le déclenchement.
Oui, en fait,
pour moi, dès qu'il y a un pipeline,
on peut mettre en place du
déploiement continue et de la livraison continue,
et du déploiement continue en mode push,
comme tu disais,
en effet, il peut y avoir
plusieurs étapes, on peut créer
une application avec une release,
et puis si on a un dépôt
d'infrastructure Ascode,
on peut changer la version
de la release qu'on va installer
dans le deuxième dépôt,
au choix,
mais grosso modo,
en gros, c'est déclenché, dès qu'il y a
quelque chose qui change dans GIT,
reste à choisir ce que vous voulez
déployer et où vous voulez le déployer.
Après, comme on en revient,
ce que disait Mathieu, ça dépend beaucoup
de votre workflow, parce que quand on parle
de GITOps, on parle quand même d'avoir
un fort lien entre GIT
et les différents outils ou ce que vous
déploie, que ce soit de l'infra, du code,
donc ça vous demande aussi d'avoir
une vraie structure qui fonctionne.
Pareil, moi je suis moins
en moins fan des workflow GIT avec
200 000 branches, parce que
au final, souvent ça crée plus de problèmes,
de conflits, etc.
Mais l'essentiel, c'est juste que vous soyez
cohérent avec vous-même et que vous sachiez
quel impact quoi, parce que du coup,
si jamais vous avez quelque chose un peu
d'exotique, vous avez très rapidement
fait au travers de GIT de déclencher des actions
qui ne sont pas voulues, donc c'est important
de comprendre ça.
Je crois que c'est le moment
de faire nos retours
d'expérience, alors c'est
à ce moment, on va dire ce qu'on fait, nous,
qui veut commencer, comment
est-ce qu'il fait du déploiement et de la livraison ?
Moi, ça sera rapide.
Moi, je n'en ai pas fait depuis
quelques temps pour Atonnette.
Vraiment, je veux dire,
mettre en place, entre guillemets, et gérer.
Pour le coup, moi, j'étais assez
fan de GIT Lab, il y a
quelques temps, j'aime bien
encore aujourd'hui le produit, même si
il est un peu en
perte de vitesse dans mon coeur, on va dire.
Dans les autres outils
que j'ai aimé, personnellement,
il y a Drone IO, je découverte pas longtemps, qui
permet de faire des choses assez simplement efficacement.
Tid, en l'esprit, ressent un peu
la GIT Lab CI, sauf que du coup, c'est un peu
moins lourd si vous êtes déjà
sur Github, etc. Ça a eu de faire
potentiellement une migration, notamment quand vous êtes obligé
d'être sur Github. C'est une bonne
alternative qui fonctionne bien.
Et puis autrement, moi,
j'aime pas avoir de solution, on va dire,
pas préférer,
mais ça, c'est
mon ancien vie de consultant qui parle.
J'aime bien pouvoir m'adapter
aussi au contexte, typiquement,
Gith Lab, j'aime bien, mais je sais que pour un très gros client
parce que la solution
sur laquelle je répartis, parce que je sais
que c'est assez difficile à scale
et que c'est un peu la boîte de Pandore
avec 200 000 choses dessus, et juste
pour la CI-CD, je prendrai peut-être
plus un outil qui fait que ça et qui le fait bien,
qui concentrait là-dessus.
Donc ça, c'est un peu, pour mon
point de vue, du coup,
de comment ça marche, après
j'utilise, pour mon perso,
je dis que du Gith Lab, globalement,
et en entreprise, ça dépend
encore une fois. J'ai déjà vu globalement
de l'argo. Les deux dernières fois, j'ai vu, c'était de l'argo
au CD, mais j'ai très peu touché. Et la dernière
dernière fois, c'était
du drone.
C'est, tu m'étonnes,
parce que je pensais que drone était un projet
abandonné. Il y a quelques années, j'avais
vu, avant de m'intéresser
à Gith Lab CI-I, et tu m'apprends qu'il a
repris de plus belle.
Alors ça, ça remonte
il y a, à quelques
temps, que j'ai dit des drones, et que j'avais
bien aimé, mais il me semble pas que ce soit abandonné.
Je dirais, je finirais mal ma journée,
je serais assez triste.
Moi, c'était il y a déjà, il y a déjà
trois ans, trois ou quatre ans, que j'avais
essayé de drone.
Je sais pas, il y a trois, quatre ans, j'ai essayé.
Bon, bah comme quoi. Qui veut
prendre la suite et nous faire un tour
d'expérience ?
Vous pouvez y aller.
Bon, je vous laisse réfléchir et je vais
faire le mien. Alors vas-y Mathieu.
Moi, je l'ai dit, j'ai beaucoup
utilisé AirGoCD dans mon expérience précédente
en livraison continue.
Livraison continue
pour la majorité des applications
d'éploiement continu pour
la configuration humanitice.
Dans mon expérience actuelle,
on utilise aussi AirGoCD pour le coup
en livraison,
d'éploiement continu, donc merge master, ça part en
mode.
Donc ça marche très, très bien.
AirGoCD est vraiment, vraiment,
vraiment pratique.
Voilà, je me répète.
Et d'ailleurs
sur AirGoCD, si vous voulez en savoir plus
et notamment sur la livraison,
il y a un podcast
de nos collègues
d'Electrum Monkey
qui s'offre, connaît bien.
Je pense,
qui a fait un podcast dessus avec deux personnes
de mon équipe actuelle en fait,
sur AirGoCD, ce qu'on utilise beaucoup
en interne, notamment
des AirGoCD qui, enfin des instances
AirGoCD qui gèrent jusqu'à 7000 pods.
Donc ça c'est gros et
beaucoup d'environments de développement qui sont créés à la volée etc.
Donc si vous voulez en savoir
plus vraiment sur AirGoCD en lui-même
et ça peut être intéressant je pense.
Du coup je vais prendre la suite, tu parles d'AirGoCD
que tu parles d'Electrum Monkey, oui je connais bien
parce que je suis passé deux fois chez lui,
chez Stephen. Du coup
nous aussi on utilise AirGoCD
quand on fait du Kubernetes
et du GitOps. Pour l'instant on n'est pas allé
jusqu'en prod
mais dès qu'on doit faire du cube
on utilise AirGoCD. Sauf pour
un cas que je vais vous décrire
pour la plupart de nos autres applications, nos autres
déploiements etc. Orcube
on fait, en fait on utilise
GitLab Syriq tout simplement
et on fait du GitOps en mode push
c'est à dire qu'on met tout dans Git
on chiffre tous nos secrets, on met dans Git
nous c'est tout le temps des petits projets
et en fait on utilise
dans la CI, on utilise Terraform
en cible pour déployer
l'infra et
pour provisionner les serveurs
et pour Frogit on fait pareil
on utilise GitLab
qui déploie tout avec Terraform
en cible et Elm
pour nos runners élastiques
pour le coup on n'utilise pas AirGoCD
parce qu'il n'y a pas beaucoup de choses
donc on utilise Elm à l'intérieur du pipeline
et nous au niveau de
notre philosophie
c'est dès qu'on merge dans la branche principale
ça déploie automatiquement
en staging, c'est un déploiement
continue staging. Quand on a
ce qui nous intéresse on craint un tag
ça déploie automatiquement en pré-prod
et dans le pipeline
juste après la pré-prod il y a un déclenchement
manuel sur la prod, ce qui nous fait que
on fait notre prod, elle est à chaque fois
parallèle, alors je le montre pour ceux qui sont sur Youtube
à chaque fois il y a un tag qui est associé
à un pipeline et pouf on déclenche
le tag qu'on veut
Grosse modo, voilà comment on fait chez nous
et René alors chez vous
Moi je vais dire
j'ai des choses assez classiques
un petit peu comme toi
donc des déploiements à partir de
Jenkins and Cible
beaucoup d'antiboles en fait
pas mal de clients qui ont
capitalisé beaucoup sur Antibole
et donc
soit Jenkins and Cible
soit GitLab Antibole
et j'ai une
expérience aussi avec
Sam
Serverless application model
utilisé dans le cadre de
déploiements pour des applications serverless sur AWS
une solution qui alors Sam
c'est une sur couche en fait à CloudFormation
qui est le produit
de configuration
de services AWS
pas si c'est
la bonne définition mais voilà
c'est l'idée
voilà donc un outil
assez efficace
pour paramétrer
et déployer toutes les
les lambdas AWS
voilà et déclencher
par
un
un merge
sur une branche
et en gros 5 minutes après
toutes les
toutes les
enfin toutes les rem
enfin c'est très très efficace, ça va très vite pour mettre à jour
l'environnement et la application en question
et ben merci alors je sais qu'on est
nombreux ici à utiliser en Cible
nous on a un petit souci
on a plein de déploiements
dans tous les sens qui sont vous l'aurez compris
déclenché par tout un tas de pipeline
GitLab et
au niveau des logs en Cible c'est pas la
fête et je voulais savoir est-ce que vous vous avez
utilisé en Cible Tower ou en Cible
AWS pour centraliser un petit peu
les choses
ou est-ce que vous avez utilisé ARA
j'en ai parlé dans un autre épisode de podcast
un ARA qui a un outil qui permet
d'avoir des logs
sous forme navigation
HTTP et on peut
centraliser ces logs sur un serveur
ARA et on va tout en voyer dessus
mais est-ce que vous avez utilisé des trucs
de ce genre là
alors
je vais essayer
pardon
non ben moi quand tu as
proposé ARA
en fait j'avais vu
un poste de date
sur ARA de ta part
non je connaissais pas
effectivement c'est un outil
intéressant
après
en Cible Tower
non pas j'ai pas eu
alors je connais j'ai eu un petit peu joué avec
c'est vrai que c'est assez
sympa et après
ce qu'on fait c'est pas
une centralisation
si on peut vraiment appeler ça de la centralisation
mais en fait dans tous nos builds par exemple on remonte
les logs dans Jenkins donc ça veut dire qu'on a
sur notre serveur Jenkins ça a un accès
à tous les logs
de builds et de déploiements
pardon de déploiements dans ce cas
pour savoir ce qui s'est passé
voilà donc c'est tout au même endroit
mais on a
effectivement je pense que ce qui pêche
c'est potentiellement la recherche
pour trouver
ce qui a pu mal
de manière on va dire un peu globale
trouver les raisons qui font
échouer le plus souvent
faire de la statistique etc on est
pas très bon là dessus je pense
alors
moi je suis plus trop dans le cible
pour être honnête aujourd'hui
mais j'en ai beaucoup fait à une époque
je disais ni en cible tordre ni hara ni tout ça
ça date à un style époque dans cible 1
donc ça commence à remonter
d'ailleurs j'avais mis en place
quelque chose pour remonter les logs
parce que sur un cible vous avez des plugins
les plugins callback
qui sont exécutés à chaque fois qu'une tâche
s'exécute finalement
et vous pouvez mettre en gros des hooks
sur une tâche exécute et récupérer
l'ensemble de la tâche
c'est à dire la tâche, son message
son statut
des variables, diverses variés sont en exécution
notamment ce qui peut être intéressant
en fait moi je poussais tout ça
via un callback
c'est du oncible dans cet oncible
je poussais tout ça dans Kafka et après ça partait dans les as6erche
j'avais des tâches port de déploiement
je pouvais faire de la recherche, de mes logs etc
donc même sans ces solutions là
je pense que c'est toujours supporté
les plugins callback dans oncible
c'est quand oncible 2 ça l'était
après j'ai un peu décroché sur la techno
mais vous pouvez faire du développement très facilement
et vous avez accès comme ça à l'entierté
des informations, des tâches
avec le statut, le temps etc
vous pouvez balancer ça dans n'importe quel gestionnaire de log
parce que c'est du piton et donc vous pouvez importe
je sais pas la librairie, l'as6erche
la librairie
enfin je pense que vous utilisez Splunk
des services cloud c'est très intéressant en tout cas
je te rassure
c'est exactement ce que fait Aura
il se plug là dessus
et puis après il l'envoie sur un serveur
tu peux faire tourner en local
ou tu peux faire tourner sur un vrai serveur
et puis du coup tu peux naviguer
parce qu'en oncible c'est bien mais quand ça plonte
si tu n'as pas toutes les infos
pour débuguer c'est pas facile
Damir un petit avis là dessus
moi je triche
les dernières fois que j'ai fait le dans the cibus
c'était sur le fray mutable donc du coup c'est au build de l'image
donc j'ai moins ce problème
mais c'est une manière de contourner
ce type de problématique
j'ai un collègue qui a beaucoup poussé avec AWX
et il n'y a jamais eu genre de problème
donc je pense que ça répondait plutôt bien
cette problématique et que ça fonctionnait
plutôt bien de façon de ce qu'il me disait
bon ben c'est cool alors
eh bien on arrive à la fin de cette émission
merci pour tous vos éclairages
c'était vraiment intéressant
de discuter du déploiement continu
de la livraison continue depuis le temps qu'on se disait qu'on allait faire cet épisode
du coup si chers auditeurs
tu as envie d'approfondir tout ça
le déploiement continue, la livraison continue
tu as envie même de partager avec nous
tu peux nous rejoindre et discuter
dans la communauté des compagnons du DevOps
je le rappelle à chaque épisode mais c'est une communauté en ligne
c'est gratuit, tu peux nous rejoindre
on est déjà plus de 1000
et ça bouge beaucoup en ce moment
donc tu arriveras en pleine effervescence
tu pourras aller naviguer dans les centaines de postes
voir milliers de postes
je crois il y a des milliers de sujets
je ne sais plus
il y en a beaucoup
et on parle d'ailleurs de CSEDI et cargo
si je me trompe pas
je crois oui il y a plusieurs sujets là dessus
de toute façon c'est bien angé
on peut créer des catégories
mais il y en a déjà pas mal
en effet on parle d'argot
et on va continuer
je pense à parler cargo et coup Bernadis
et ben Damir puisque tu avais la parole
je te laisse le mot de la fin
euh...
ah ben là c'est moi que tu prends
des pourvues pour une fois
pour le coup non
mon mot de la fin c'est
prenez le temps de faire les choses là
prenez le temps aussi d'avoir confiance dans notre CSEDI
à des petits à petits
encore une fois CSEDI
moi j'aime bien dire CSEDI
parce que c'est des stades de maturité très différents
et s'il faut du temps
avant d'automaser le dernier clic
du déploiement prenez le temps
pour être vraiment confiant là dessus et pas stresser en permanence
voilà c'est mon petit mot de la fin
Mathieu est ce que tu veux bien prendre la suite ?
oui je peux
je vais revenir un peu sur ce que je t'ai dit
sur les compatibilités entre services
si vous avez plusieurs services beaucoup d'équipes etc
pensez ça
très en amont
faites vraiment en sorte
d'avoir un manière de vérifier vos contrats entre services
de faire
d'avoir confiance en fait sur les compatibilités entre services
sur les features qui arrivent
dans un service ou cross service
c'est à dire qu'on a des développements qui impliquent plusieurs services etc
sinon vous allez
avoir des soucis c'est obligé
donc c'est vraiment
organisationnel là ça va pas être technique
il y a un peu de technique derrière mais ça va vraiment
être comment travailler avec plein
de services et plein d'équipes
sans ça vous ne pouvez pas faire du déplan
en continu quand vous allez escaler
eh bien merci
et René avant de te laisser la parole
je vous remercie encore une fois tous les 3
et René tu as le mot de la fin de la fin
ça va devenir une habitude ?
oui je vais revenir un tout petit peu
sur ce que tu disais au début
pensez au pouce
et aux abonnements
parce que je pense que ça nous fait plaisir
de voir si
il vous apprécie les épisodes
et puis ça fait un petit peu
ça nous donne des statistiques
et enfin surtout à Christophe
voilà je pense
c'est une belle récompense de voir
si ça progresse ou pas
donc voilà ce sera mon mot de la fin
et à bientôt
du coup je vais prendre mon mot de la fin parce que
tu fais RFAOS au statistique je rappelle
pour ceux qui ne savent pas enfin j'afforme
pour ceux qui ne savent pas que je fais un live tous les 2 mois
où je partage les statistiques
du podcast de la chaîne youtube et que c'est h
je suis assez transparent là dessus donc
si vous voulez connaître les statistiques du podcast
il suffit d'aller voir les lives
ou de me rejoindre en live
vous pourrez me poser des questions
un vendredi sur un vendredi
tous les premiers vendredis du mois y a un live
et un mois sur deux y aura un live avec moi
et un live avec René
et merci et
à bientôt pour un prochain podcast
merci d'avoir écouté Radio DevOps
n'oublie pas de noter l'épisode
plus la note sera élevée et plus il sera mis
en avant dans les applications
tu peux aussi le partager
ça nous aidera à le diffuser et à rendre le mouvement
plus visible
si tu as envie de discuter du mouvement alors rejoins nous
dans la communauté des compagnons du DevOps
à bientôt
la balade au diffusion des compagnons du DevOps
est produite par l'IDRA
1
2
3
4
5
6
7



11



12
12
13










14