Les conteneurs et dockers sont partout.
On ne peut plus lancer de discussions cloud sans avoir quelqu'un qui va venir nous parler de dockers.
Et là, il y a plusieurs camps.
Ceux qui ne veulent pas de dockers en production,
ceux qui ne jurent que par lui, voire par Kubernetes,
et ceux qui font en fonction de l'usage.
Ici, je crois, on est un peu plutôt de cette dernière catégorie.
Alors, quelle state on doit utiliser pour héberger ses applications
avec des comptes en reproduction.
C'est ce qu'on va se voir dans cet épisode de podcast.
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.
Bienvenue à toi chers compagnons.
Dans ce nouvel épisode de Radio DevOps,
ton émission de vulgarisation cloud DevOps mensuelle.
Alors, tu l'auras compris avec mon introduction.
Aujourd'hui, on va parler des stacks de production
quand on veut faire du conteneur.
Et pour en parler avec moi, j'ai Nicolas,
monsoir Nicolas.
Salut tout le monde.
Et j'ai aussi Damir,
bonsoir Damir.
Salut à tous et à toutes et à tous.
Et j'en profite pour rappeler ce que je ne fais pas à chaque épisode
à mon grand-dame,
que si tu veux en savoir un peu plus sur nous trois,
on a chacun eu une interview
que tu peux aller écouter dans les épisodes de podcast.
Il y a les liens, sinon dans la description,
dans les crédits,
tu auras chaque personne avec ces liens
et y compris son épisode de podcast.
Tu en sauras plus sur nous.
Alors, qui dit conteneur,
dit déjà savoir pourquoi est-ce qu'on veut faire du conteneur,
pourquoi est-ce qu'on veut conteneuriser une application.
C'est la première question qu'on va se poser
avant même de partir dans les stacks.
Alors, qui veut bien commencer de pourquoi est-ce qu'on pourrait avoir envie de conteneuriser ?
Nicolas, je t'en prie, vas-y.
Déjà, le premier truc, c'est parce que c'est à la mode.
Donc, c'était un petit rôle parce que maintenant,
c'est plus vraiment une histoire de mode,
mais maintenant tout le monde en fait plus ou moins.
Donc, pourquoi ?
Parce que c'est plus facilement répétable.
Donc, vous construisez votre conteneur de cœur.
Et normalement, vous devez le construire de la même manière
à chaque fois que vous le construisez.
Et vous pouvez le déployer à chaque fois de la même manière.
Puisque vous prenez la même image et la même image avec les mêmes paramètres,
vous devez avoir le même résultat.
Ensuite, c'est plus facilement portable.
C'est le conteneur que je lance sur une redate, une Ubuntu, une Debian ou peu importe.
Normalement, on va avoir le même comportement,
quel que soit le système d'exploitation que vous avez,
puisque vous démarrer votre conteneur dans un espèce de CH-Route,
ces groupes, etc.
Les seules différences de comportement,
c'est les paramètres que vous allez mettre à votre conteneur.
Mais normalement, il est censé tourner de la même manière partout,
quel que soit l'endroit où vous le lancez.
Ensuite, comme je le dis,
c'est que vous pouvez lancer une distribution sur une autre Evis Versa.
Donc, ça vous simplifie le fait d'avoir des distributions linux différentes.
Donc, si votre entreprise vous demande d'avoir tous vos hyperviseurs en Ubuntu,
en redate ou je ne sais quoi d'autre,
vous pouvez déployer tout ça.
Et si votre application ne marche que avec une certaine version
d'une certaine distribution,
par exemple, vous avez un binaire qui est compilé pour une vieille version de Linux.
Alors, la vieille version de Kernel, ça, il n'y aura pas de magie.
Par contre, pour une vieille version de G-Lipset,
vous pouvez bidouiller des trucs.
Ce n'est pas toujours des bonnes idées,
mais quand vous avez une vieille application et que vous n'avez pas le choix,
c'est une des manières de faire.
Et pour moi, c'est peut-être un des trucs les plus importants.
Je l'en ai un petit peu parlé tout à l'heure dans le point répétable.
C'est que vous avez un artefact ou une image,
donc votre image d'au coeur de votre application.
Donc, quand vous avez votre tag, guide, votre shawan ou je ne sais quoi d'autre,
vous avez construit votre image à partir de là.
Et c'est cette image que vous allez pouvoir déployer dans vos différents environnements
de tests, intégrations, staging, etc.
Pour arriver en prod,
mais ça veut dire que vous avez utilisé normalement,
si vous faites bien les choses,
vous avez utilisé la même version de l'image dans toutes vos étapes de validation
jusqu'à la prod.
Et donc, ce qui tourne en prod est censé être exactement la même chose
que ce que vous avez dans les autres environnements.
Voilà, je pense avoir fait un truc suffisamment étoffé.
Je ne sais pas si vous avez des choses à rajouter, Christophe.
Oui, moi j'ai une question, mais tout ça on pouvait le faire avec les VM,
du coup, pourquoi est-ce qu'on a besoin des conteneurs ?
Demi, on veut peut-être répondre.
Ben moi je pense, je suis un grand défenseur d'un certain point de vue
qui est que la vraie chose qui a fait un peu exposer les conteneurs
et qui nous amène là aujourd'hui,
parce que les conteneurs, c'est assez vu.
Moi, j'ai commencé avec de l'open VZ,
donc c'est quelque chose qui n'est pas tout jeune,
et qui est assez loin quand on y réfléchit à l'utilisation de dockers,
mais qui reste du conteneur.
Mais pour le coup, ce qui a vraiment apporté,
ce qui fait aujourd'hui que beaucoup font du conteneur,
c'est que le tooling est très orienté conteneur,
et qu'il y a un tas de choses aujourd'hui
qui sont plus ou moins par design et par défaut,
prévues pour être chips sur du conteneur.
Donc souvent, c'est plus simple à intégrer,
ça va permettre d'avoir aussi, on n'a pas de la portabilité,
mais on n'en part à tout à l'heure,
de pouvoir s'intégrer à plus de solutions existantes,
et du coup, avoir un tas d'outils côté de développement
pour tester, pour build, pour avoir des métriques
et des résultats aussi sur le conteneur, son état,
je parle notamment de nombre de failles de sécurité,
si les lips sont dépassés, des choses-là.
Un tas de choses qui aujourd'hui sont intégrées
dans la plupart des CICD, qui sont vraiment très orientés conteneurs.
Donc souvent, c'est aussi un choix de la simplicité
et de l'unification des outils, parce que ces outils
vont être un peu plus unis autour d'une techno.
Moi, j'ajouterai en plus de la simplicité, comme tu l'as dit,
il y a la légèreté.
La légèreté, en effet, pour manipuler des environnements de conteneurs.
Quand on construit une image de conteneur,
c'est plus léger que de construire une image de VM.
Quand on lance une image de conteneur,
c'est plus léger que de faire une machine virtuelle,
parce qu'un conteneur, ce n'est pas une machine virtuelle,
on ne va pas émuler tout le matériel,
on va juste partager le noyau avec des processus isolés.
Et pour moi, il y a un avantage aussi au conteneur,
c'est que comme il est plus léger,
on va pouvoir mutualiser soit des VMs,
soit carrément des machines physiques,
avec tout un tas d'applications conteneurisées.
Parce que si on met des applications dans des VMs,
ça marche très bien, mais du coup, il y a le coût induit de la VM
qui va nous permettre de moins mutualiser les choses.
Et en fait, chacun, que ce soit l'AVM ou le conteneur,
a des cas d'usage un peu différents, je trouve.
Et en fonction de ce qu'on veut faire,
on peut aller vers l'AVM ou vers le conteneur.
Si on veut de la légèreté et de l'isolation,
moi, j'irai vers le conteneur.
Si on veut un peu plus de sécurité
et surtout faire des choses un peu particulières,
on peut aller vers l'AVM.
Nicolas.
Oui, alors pour compléter un petit peu ce que vous avez dit,
je vais donner l'autre côté de la lourniette
par rapport à ce que disait Damir.
Pour moi, c'est surtout le fait de vouloir cloisonner les applications.
Donc au-delà des VMs, c'est au sein d'une même application,
vous avez un Redis, une base de données, votre serveur d'application.
Et maintenant, vous avez tellement de microservice
que vous avez plein d'applications
qui tournent au sein d'une même VM avant la conteneurisation.
Et on voulait segmenter tout ça.
Donc on a inventé les conteneurs
qui nous permettaient de bien cloisonner tout ça.
À l'époque où les conteneurs sont arrivés,
tu parlais d'OpenVZ,
il y a eu quelques ancêtres avant,
mais bon, en gros, c'était d'HCH route améliorée.
Ça permettait d'avoir une VM à pas cher, entre guillemets.
La bascule, ça a été,
on va utiliser la notion de contexte,
donc les ces groupes qu'il y avait dans Linux pour dire
je ne vais mettre qu'un seul process.
Là où avant, j'avais un espèce de unit qui démarrait plusieurs process.
Là, on s'est dit, on a toute la souplesse
de pouvoir démarrer qu'un seul process.
Donc on va mettre que le process de mon application.
Alors il peut faire des threads, des forcs, etc.
Mais c'est mon application qui va se multiplier pour gérer de la charge.
Par contre, on a notre base de données qui est dans un contexte.
On a notre serveur d'application qui est dans un autre.
Et normalement, c'est des contextes séparés.
Alors on s'est aussi rendu compte avec le temps
que c'était trop compliqué d'avoir des contextes totalement séparés.
Donc maintenant, on a la possibilité de mettre des conteneurs
dans un contexte relativement partagé,
notamment au niveau du réseau.
On fait en sorte que tout le monde puisse dialoguer sur l'interface de loopback.
Et le but, c'était d'avoir de quelque chose très léger
qui peut tourner à la fois sur le poste du développeur,
mais aussi sur le serveur.
Et comme tu le disais, Christophe,
de réduire l'empreinte, mémoire, la surface d'attaque, etc.
Alors après, là où je suis moyennement d'accord, c'est toujours plus léger.
Moi, je connais des développeurs qui font des images de Texture de plusieurs gigas.
C'est comme tout.
Il y en a qui savent bien Package et il y a des applications
qui ne peuvent pas se Package correctement.
C'est un outil qui vient avec des promesses.
Et après, c'est à nous en tant que développeur d'applications
ou développeurs d'infrastructures de suivre les bonnes pratiques aussi.
Et je veux dire, tu peux faire des images de VM de plusieurs gigas aussi.
Ça dépend de quoi tu le compares.
Là, on compare à des VM.
À vrai dire, souvent dans l'utilisation qui est en effet,
ça serait plus comparable du Package, du coup, de distribution,
qui est en soi plus léger, vu qu'on n'a pas toute cette couche d'image en plus.
Juste pour bonnes choses.
Quand je dis le tooling, je parlais de ça.
Ce que je pense que c'est ça, en fait, il y a eu un écosystème
qui s'est autonouri entre le DevOps, le cloud et du coup,
tout ce qui est suivi avec le microservice, etc.
C'est vraiment le tooling qui a fait exploser le container
dans le sens où isoler des process dans des containers,
comme tu dis, on s'allait faire depuis longtemps avec CH-Route, etc.
Mais ça restait quand même souvent du bricolage.
Il n'y a pas un workflow bien complet, pas de bonne pratique.
Et en fait, je pense que Docker arrive au bon moment pour tout standardiser,
dire, nous, on a une vision des choses.
Ça se fait comme ça, c'est comme tu le dis, un process dans un container.
Ça se gère comme ça, il y aura des images,
il y aura des surcharges d'images.
Et je pense que c'est tout ça plus le DevOps en même temps qui est explosé,
etc. qui a fait que ça arrivait avec la bonne solution
en bon moment avec une guideline qui est relativement claire.
Clairement, ça a vraiment chamboulé l'état d'esprit.
Je veux dire, la simplicité de créer et de lancer des containers,
c'était sans commune mesure.
Et l'autre aspect, c'est aussi la partie support pour un développeur
qui va fournir un artefact de sa solution.
S'il fournit un zip, un point d'oeuvre,
il ne peut pas avoir la maîtrise de tout ce qui va autour.
Avec l'image Docker, il est quasi sûr que ça va marcher dans tous les contextes,
parce qu'il y a toutes les versions des libres qui sont les bonnes,
il y a tous les outils qui sont bien déployés.
Et en fait, les problématiques, ça va sortir et rentrer au niveau
réseau, mais il n'y a pas d'interaction sur la VM en elle-même.
Là où avant, oui, mais alors moi, j'ai installé telle version de tel package,
parce que j'en ai besoin aussi pour mon autre application.
Et là, on a des conflits.
On va faire un CH-MOD sur un fichier parce qu'on veut sécuriser.
Dans le conteneur Docker, tout est fait comme on veut.
Et normalement, l'image est faite de telle manière que ça simplifie le support.
Ce que tu veux dire, en fait, c'est que ton application,
elle arrive dans un conteneur avec son contexte d'exécution en plus.
Et donc ça, c'est vrai que ça nous assure que l'application,
on va être installé comme on le souhaite.
Et pas une version avec telle version de tel libre sur le poste du développeur.
Ce sera une autre version sur la prod.
En théorie, tout a été pensé pour que ce soit le même flux
du poste de dev par tous les environnements jusqu'à la production.
Et c'est vrai qu'il y a un truc dont j'ai oublié de parler.
Mais si on respecte bien les 12 facteurs,
donc je crois qu'on en avait déjà parlé,
on pourra remettre le lien dans les notes de l'épisode.
Mais en fait, si vous respectez bien tous ces facteurs-là,
Docker va parfaitement répondre à votre cas d'usage.
Parce qu'une fois que vous avez terminé de l'exécution de votre process,
vous mettez l'image à la poubelle puisque tout ce qui a besoin d'être stocké
est stocké dans quelque chose de non volatile,
mais pas sur l'AVM en tant que tel.
Vous avez de l'objet de storage, vous avez de la base de données,
vous avez des choses comme ça.
Mais le contexte d'exécution,
vous pouvez le brûler à la fin de votre utilisation,
vous en redémarrez un nouveau et vous redémarrez sur quelque chose de propre.
Et c'est aussi super intéressant en termes de sécurité
parce que si vous vous faites attaquer,
l'attaquant a verrôlé tout le contexte de votre application.
Ce n'est pas grave, Docker, Kill, Docker, Run, et hop, vous repartez de zéro.
Alors l'attaquant va réexploiter la même faille,
mais pour repartir de zéro, c'est beaucoup plus rapide.
Si vous déployez sur une VM, c'est la VM que vous allez brûler
et d'être obligé de réinstaller, donc c'est beaucoup plus lourd.
Donc pour tout ce qui est répète,
enfin, quand vous les répétez les choses, c'est plus simple et plus rapide.
Et alors on ne va pas en parler dans cet épisode de podcast,
mais je le mentionne pour les personnes qui sont curieuses.
Il y a quelque chose qui essaie de faire le lien entre les conteneurs et les VM,
qui s'appellent les micro-VM.
Il y a des réflexions là-dessus qui sont des VM qui démarquent plus vite que des VM
et qui sont aussi légères, en tout cas, ils tendent à être aussi légères que des conteneurs.
C'est une voix qui est assez intéressante, une voix médiane,
que en tout cas, moi, j'espère explorer dans les années à venir.
Et d'ailleurs, vous pouvez très bien utiliser ces micro-VM
pour démarrer un service Docker, pour démarrer vos images Docker.
Et les notions de micro-Carnel, etc.
Vous allez faire un kernel Linux vraiment au plus près de votre hypervisor pour démarrer plus vite.
Dans ce cas-là, vous n'avez même plus la possibilité de vous connecter sur votre hypervisor.
Comme Damir veut bannir l'OSSH, on n'en est pas loin.
Et je pense qu'on en paraît dans un épisode de podcast,
parce que les micro-VM, c'est un sujet passionnant
et mon avis qu'on va explorer de plus en plus dans l'avenir.
Alors ce que je vous propose maintenant, c'est d'explorer les besoins qu'on peut avoir en production
et surtout à quel stack on va pouvoir utiliser pour quel usage.
Donc ça, ça va être la grosse partie de l'émission, il va y avoir plein de petites sous-parties.
Et justement, l'idée, c'est vraiment d'explorer son besoin avant de partir.
Qui veut nous parler un petit peu du sondage des besoins
et de comment on pourrait faire ça avant même de parler de stack en fonction des usages.
Du coup, je pense que je vais essayer d'introduire le sujet, vous rajouter si il y a besoin.
Pour moi, il y a deux paramètres, voire trois qui sont assez importants.
À prendre en compte, ça va être le coup.
Qu'est-ce que vous avez comme budget, quel est le coup que vous voulez supporter ?
La scalabilité.
Donc à quel point vous allez avoir des besoins de sciding
et là, à quoi disponibilité ?
À quel point votre application est critique ?
Pour votre business, ça va être compliqué de gérer.
En cas de coupure de service,
c'est simplement est-ce que c'est grave, est-ce que c'est pas très grave, est-ce qu'on peut se le permettre ?
Typiquement, ces besoins-là vont varier les uns sur les autres.
Si on a très peu de budget et on a besoin, ils vont être un peu impliqués entre jour.
Si typiquement vous avez des gros besoins de scalabilité et d'autodisposibilité,
vous avez une solution qui va être très chère.
A l'inverse, si la scalabilité, vous n'avez pas besoin de votre boîte débute
et de la haute disponibilité, vous avez un site où on peut se permettre des coupures.
Typiquement, vous allez avoir un coup assez faible qui va être possible.
Mais c'est important d'avoir ces éléments-là en visu.
Et je dirais même dans la mesure du possible de les quantifier,
de se mettre des objectifs en termes de disponibilité,
en termes potentiellement de sciding.
Et ces choses-là, c'est important, je pense, à quantifier.
Je ne sais pas si vous avez quelque chose à rajouter là-dessus.
Je vais compléter un petit peu.
Mais globalement, quand vous êtes dans une entreprise qui bootstrape,
où vous êtes entre 1 et 10,
il y a très peu de chance pour que vous ayez des besoins de scalabilité
et d'autodisposibilité énorme, à moins que vos clients soient des banques
et que votre truc soit le système bancaire.
Mais je ne pense pas que dans ce cas-là, ce soit vous qui l'ébergiez.
Et quand vous êtes dans une boîte de la taille de Twitter,
là, oui, effectivement, vous avez des besoins de disponibilité,
sécurité, etc.
Mais il y a toujours en tête de commencer par quelque chose de très simple,
mais qui marche et vous pouvez améliorer au fur et à mesure.
Quand vous êtes dans une petite structure sur un petit projet,
il vaut mieux mettre le truc en prod très rapidement.
Et on va évoquer les différentes solutions.
Mais commencer par quelque chose de simple qui n'est pas haut de dispo,
qui n'est pas escalable, etc.
Mais ça sera installé, ça tournera dans un conteneur
et vous améliorerez au fur et à mesure.
Mais le fait de faire ça, vos développeurs vont pêquer l'application
pour tourner dans un conteneur et vont te rendre compte
des premiers problèmes de, ah oui, mais si ça marche déjà pas
dans un conteneur tout seul sur une seule machine,
ça ne marchera jamais en disponibilité et en escalable.
Oui, je vais aller dans ton sens.
Je vais rappeler quand même l'un des préceptes du DevOps qui est vraiment
qui me tient à cœur, en tout cas moi, que je rappelle à chaque fois,
c'est le retour sur investissement et l'amélioration continue.
C'est à un moment donné, vous devez faire quelque chose pour votre entreprise
et vous devez avoir un retour sur investissement.
Donc ça ne sert à rien de vous lancer dans quelque chose
qui est complexe comme Kubernetes ou de dispo, etc.
Alors même que vous commencez.
Si tu commences avec ta stack de prod,
il y a de fortes chances pour que soit, en effet,
tu sois dans une petite équipe, d'une petite entreprise,
soit tu ne connaisses pas encore Kubernetes.
Donc ne va pas vers Kubernetes parce que tu en as entendu parler.
Prends quelque chose de simple que tu vas apprendre à maîtriser
et ajoute des étapes petit à petit.
Il vaut mieux un petit conteneur qui tourne dans un coin,
mais qui fonctionne, que passer six mois à mettre en place son Kubernetes
parce que je ne vous raconte même pas le nombre de prospects qui viennent me voir
et qui nous demandent alors nous, on voudrait passer nos applications dans Kubernetes.
On a déjà un Kubernetes, on cherche quelqu'un pour nous aider à l'exploiter.
Et donc quand je pose des questions,
il y a souvent deux, trois petits services qui se courent après,
mais en fait les gens ne sont pas stafés pour faire de la haute dispo
et les gens s'exploitent parfois eux-mêmes leurs Kubernetes.
Si vous pleine, ne faites pas ça.
Allez-y petit à petit pour faire tourner à WordPress.
Non, quand même, je ne suis pas aussi caricatural,
mais parfois c'est proche de ça.
Donc en fonction de votre besoin, posez votre besoin
et vous allez trouver la stack adaptée.
C'est pas la peine de sortir le marteau piqueur
pour aller juste écraser une petite mouche fin.
Je veux dire à un moment donné, il faut rester cohérent.
Il faut rester cohérent par rapport au coût aussi que ça va induire.
Du coup, l'un des premiers usages qui va arriver,
c'est un petit service ou une petite application
où finalement il n'y a qu'un seul petit truc qui va tourner.
Alors, je dis petit, c'est souvent une base de données
et l'application front-back qui est souvent mélangée.
C'est ce que j'appelle un petit service.
C'est vraiment la plupart des trucs qu'on voit.
Qu'est-ce qu'on peut utiliser comme stack
pour faire tourner ça avec des conteneurs ?
J'ai vu qu'il y avait pas mal de choses.
Alors, il y a quelqu'un dans les notes qui a mis plateforme à ce service.
Je ne sais pas qui.
Alors qu'on parle de conteneurs,
mais je voudrais bien que tu nous expliques pourquoi.
Pour savoir ce que tu vas nous dire et ça va être très intéressant.
Alors, c'est pour le coup, c'est bien moi.
Et dans plateforme à ce service, en fait, je classe le casse.
Ce que pour moi, le casse, c'est une sous-categorie
du plateforme à ce service.
Pourquoi je n'ai mis pas ce que c'est plus général,
c'est comme tu le disais juste avant.
Pour toutes les parties, en fait, quand on a une application,
en général, on a une base de données, on va avoir des data quelque part.
Pour le coup, pour moi, une plateforme qui va gérer tes conteneurs
plus tes bases de données, c'est chose-là sans que tu aies les gérer.
Ça va être du passe.
Je voulais un truc qui soit un peu plus générique que le casse.
Donc pour moi, ça, c'est la meilleure solution quand on a un petit service.
Parce que si vous n'avez peu de moyens,
vous avez une petite équipe,
vous aurez dans tout le cas pas le temps de gérer un serveur.
Ou si vous allez gérer le serveur, il y a pire,
vous allez le faire mal.
Donc, vous allez mal configurer la sécurité,
vous n'avez pas à faire les mises à jour.
Un jour, vous n'allez pas faire pas oune votre SSH,
parce que vous étiez encore assez sache.
Continuez dans le petit troll.
Et du coup, qu'est-ce qui va arriver ?
Vous avez le fait de faire votre application.
On va se faire sauter aussi dessus,
parce qu'elle reste sur le conteneur.
Donc pour moi, c'est pas un défaut,
entre guillemets, ou quelque chose de mal d'aller sur du passe.
Si on reconnaît qu'on n'a pas les moyens pour l'instant d'investir,
on va faire un test, comme on a dit, on commence petit.
Vous allez sur des solutions qui existent.
Il y en a chez les gros cloud fournisseurs.
Il y en a aussi chez du Scadoeve.
Vous pouvez acheter du claveur cloud,
peut-être sur plein de fournisseurs,
qui vont vous fournir des solutions comme ça.
Et des solutions même des fois très basiques.
Ou si vous n'avez pas d'obs, vous en sortir.
Le claveur cloud, typiquement,
vous n'avez pas besoin d'avoir un ops pour avoir une première solution.
Et ça peut être un très bon début,
avant de réfléchir à plus en fonction de vos besoins.
Je prends la balle au bon, justement,
parce que je vais aller dans ton sens.
C'est très bien que tu aies parlé du passe.
Parce que pour moi, c'est la première question que tu dois te poser.
C'est, est-ce que j'ai besoin des conteneurs ?
Est-ce que j'ai besoin d'exploiter ma solution ?
Si en effet, tu débutes un projet, et que c'est une application,
pense à la plateforme As-de-Service,
pense au fait que toi, tu n'as pas d'obs dans ton équipe,
tu n'as que des devs, ou tu es tout seul, tu es que un dev.
Et donc du coup, aller dans une plateforme As-de-Service,
aller dans un passe, c'est l'assurance,
finalement, que quelqu'un va gérer l'infrastructure pour toi,
et toi, tu vas te concentrer sur ton code.
Souvent, on a entendu parler des recours,
mais claveur cloud ou Scalingos, ça marche très bien en France.
Tu prends ton code, tu fais un guide push souvent,
et puis eux, ils sont capables d'analyser ton code,
et de savoir ce qui va être lancé derrière,
ou alors tu vas le compléter avec un petit fichier de config,
en disant, voilà, ma base de données, c'est ça, c'est ça.
Et lui, il se débrouille pour le lancer, et toi, tu n'as rien à gérer.
Tu n'as même pas besoin de faire ton image de Cockner.
Et ils vont même en faire une image Docker à ta place,
puisque très souvent, ils déploient ça dans du Docker.
Oui, souvent, ils utilisent en plus Billkit,
mais on ne va peut-être pas en parler.
Moi, je voudrais parler justement du Cockner As-de-Service,
du CAS, et alors, c'est pas une solution que j'ai utilisée,
je ne sais pas si vous, si vous l'avez utilisée,
mais je sais qu'il y a plein de fournisseurs qui proposent ça,
où tu leur fournis une image de Cockner,
et eux, ils se débrouillent pour la faire tourner n'importe où, en fait,
et ce n'est pas ton problème.
Eux, ils te fournissent le réseau, et toi, tu fournis l'image de Cockner,
notamment chez Scalway, que je connais beaucoup,
ils ont ce qu'ils appellent le Serverless Container,
c'est une solution où tu leur fournis une image de Cockner,
et eux, ils se débrouillent pour la faire tourner dans les règles de l'art,
sauf que toi, tu es la gérée de ton serveur,
mais je sais que tous les autres Cloud Providers ont ce genre de choses.
Est-ce que vous avez déjà utilisé ça, vous, et est-ce que ça vaut le coup ?
Moi, je l'avais utilisé très rapidement sur une petite infra,
mais c'était plus, on avait des jobs un peu compliqués à l'époque,
il n'y avait pas trop de conteneurs en production,
donc du coup, on avait des jobs qui étaient compliqués,
dans le sens où ils avaient des dépendances,
c'était des petits programmes qui tournaient dedans,
et on les a mis dans des conteneurs,
et c'était ce qui avait de mieux pour le coup de faire tourner ça.
Ça lancé un exact du conteneur, ça faisait ce qu'il fallait,
et puis le conteneur a été détruit, ça relancé.
C'était plus simple que gérer une machine avec juste des crônes,
qui avait à chaque fois,
qu'il se trouvait avec une machine avec 200 dépendances, et ça a l'installé.
Et moi, jamais, mais j'expliquerai un petit peu plus tard pourquoi.
Après, on n'est pas des profils qui utilisent ce genre de
de solutions aussi, il faut dire qu'on est des ops,
donc nous on intervient plutôt après dans la chaîne.
Là, c'est plutôt vraiment pour des équipes de développement.
Tu me pliques mon discours.
Excuse-moi, excuse-moi.
Après, il y a une autre, justement, solution,
quand on a un petit service,
c'est on prend une VM ou on prend un serveur,
et on va installer directement soit un conteneur,
soit un docker compose, puisqu'on peut avoir plusieurs services,
et lui, il va s'occuper de tout lancer.
Et comme il n'y a qu'un seul service sur la machine,
le port 8080 et 443, il ne va pas diriger vers le conteneur.
C'est franchement, c'est une solution qui marche très bien,
je ne sais pas vous si vous l'avez utilisé.
Je l'utilise toujours pour des petits services
qui tournent de manière unitaire,
sur des clients qui n'ont pas besoin de beaucoup plus qu'une seule machine.
Ça permet de redéployer rapidement le service,
de le kill, resta art, faire des mises à jour, etc.
Mais en fait, ce que je voulais dire en conclusion de ces trois solutions-là,
c'est aussi réfléchissez à ce que vous avez déjà en place,
parce que, et surtout, des compétences que vous avez en interne.
Parce que là, autour de la table, que nous, on part sur un casse,
ça va coûter plus cher, il va falloir qu'on apprenne à servir du truc,
même si, Damir, t'en as fait un peu plus.
Moi, je ne partirai jamais sur un casse,
parce que ça me coûterait moins cher de prendre un serveur dédié
que j'ai déjà probablement, et puis de rajouter un nouveau conteneur,
et puis de leur mettre dans mon infrastructure déjà existante.
Et si vous avez un administrateur système dans votre équipe,
partez pas forcément sur du passe.
Par contre, si c'est un langage qui n'a jamais déployé,
étudier la solution passe, parce qu'éberger un nouveau langage,
ce n'est pas forcément aussi trivial que juste faire un apt-get install,
Ruby, Python, Java, je ne sais pas quoi.
Il peut y avoir des spécificités,
et vous pouvez vous retrouver avec des problèmes de perf hallucinants.
J'ai vu des applications qui étaient hyper lentes dans un conteneur d'auteur,
et qui tournaient à une vitesse incroyable sur les recous.
Vous pouvez avoir des surprises.
Utilisez ce que vous maîtrisez le mieux.
Pour moi, c'est mon meilleur conseil,
c'est utiliser ce que vous maîtrisez.
Après, regarde aussi de vous partez,
parce que si on a un Ops, ça dépend aussi.
Moi, typiquement, le cas où je l'ai utilisé, c'était un client.
Quand je suis en prestation, c'était un client où je n'étais pas chez lui très longtemps.
Je crois qu'il n'y avait pas d'Ops dans un team,
il avait un dev qui était un peu touché à tout, mais sans plus.
C'était le plus adapté pour le long terme,
pour gérer les mises à jour et les choses comme ça.
Il ne faut pas oublier que si jamais vous partez sur un serveur,
il ne faut prévoir si pas que le conteneur.
Si vous n'en avez pas encore, il va falloir prévoir la gestion du serveur,
les mises à jour et les choses.
C'est des choses qu'il faut penser en amont,
pour ne pas être surpris ou pas être des mauvaises surprises.
Qu'est-ce qui va se passer le jour où vous ne serez plus là pour gérer ça ?
Est-ce qu'on recrute une personne pour vous remplacer ?
Ou est-ce qu'on recrute une personne pour gérer du passe ?
Oui, c'est là justement où le cas sous le serveur est ce conteneur,
peut intervenir où on a juste à gérer notre conteneur
et pas l'environnement qui fait tourner le conteneur.
C'est super intéressant en effet,
parce qu'il faut gérer la machine qui fait tourner les conteneurs aussi.
Il ne faut pas l'oublier ça, c'est souvent un point d'achopement.
Et encore une fois, c'est répétable.
Donc ce qui tourne dans votre passe potentielle,
enfin dans votre casse, ça peut tourner sur votre serveur.
Et ce qui tourne dans votre serveur peut probablement tourner dans un casse.
Oui, puisque là on est sur le cas où on a un seul serveur
avec quelques conteneurs qui tournent dessus.
Ou même 50.
Oui, non mais là on est vraiment dans un petit service.
Justement le 50 on va en parler c'est juste après.
Mais avant, je te rappelle si tu apprécies ce podcast
et que tu veux t'assurer qu'il continue,
que tu veux être sûr qu'on continue à te parler de ces sujets passionnants.
Le meilleur moyen c'est de nous soutenir avec un petit don
si tu en as envie ou les moyens.
Tu as toutes les infos sur soutenir.com, tirer devops.fr
et ça nous fera plaisir et ça nous aidera à appeler les divers services qu'on utilise.
Et justement, maintenant si on veut mettre plusieurs services
à disposition ou plusieurs types d'applications,
mais sans forcément avoir besoin de haute disponibilité,
parce que ben voilà on est une petite équipe,
de toute façon on ne peut pas faire d'astreinte.
Et puis on n'a pas besoin de dispos parce que ce n'est pas des applications ultra critiques
ou alors les clients peuvent très bien supporter une, deux, quatre heures d'indisponibilité.
Qu'est-ce qu'on peut proposer à notre auditeur et aux nitrisses ?
Qui veut commencer ?
Alors moi j'ai remis Docker Swarm parce que même si le projet est censé être plus ou moins abandonné,
il est quand même plus ou moins maintenu.
Moi je l'utilise encore dans quelques cas,
quand j'ai pas envie d'installer un truc plus compliqué dont je parlerai tout à l'heure.
C'est compatible avec du Docker Compose et ça a l'avantage de pouvoir être lancé
sur plusieurs VM en même temps.
Donc vous allez interconnecter le réseau sur vos différentes VM.
Vous dites je veux X container de ces services-là
et il va se débrouiller pour répartir un petit peu partout.
Et encore une fois c'est compatible avec du Docker Compose.
Donc ce qui tourne sur votre machine ça peut tourner plus ou moins équivalent sur la prod.
Parce que Docker Compose vous pouvez charger les configurations sur des machines différentes,
sur des environnements différents.
Donc pour moi c'est la solution simple et rapide et qui peut se connecter avec Trayfic.
Donc Christophe va nous parler maintenant.
Exactement.
Moi je vais vous parler de la solution simple et rapide qu'on a le plus pour des petites
infrastructures comme ça.
C'est une infrastructure à base de trafic.
Donc on a un autre balan de sort trafic sur notre serveur qui va distribuer
justement le trafic réseau à tout un tas de stacks Docker Compose.
Puisqu'on peut avoir des tonnes de services.
En l'occurrence parfois on a des serveurs avec 4, 5, 6 services différents.
Et ces services sont tous décrits dans un fichier Docker Compose qu'on a variabilisé.
Et ça marche super bien.
Honnêtement quand il n'y a pas de problème ça peut rester des jours et des jours voire
des mois et des mois comme ça sans intervention.
Evidemment tu l'auras compris il faut quand même mettre un jour le serveur de temps en temps.
Mais quand le serveur tourne pas ça marche du feu de Dieu je trouve.
Et c'est pas compliqué.
C'est facile à mettre en place.
Surtout qu'en plus si on utilise un peu en cible on peut déployer tout ça avec en cible.
Et puis il n'y a pas besoin de s'embêter.
Les déploiements ils sont hyper rapides.
Je ne sais pas si vous vous utilisez des stacks comme ça aussi simples et rapides à mettre en place.
On ne peut le coup pas trop en général.
Je n'ai pas vraiment de cas.
Des petits cas je n'en ai pas trop pour Atonette.
Ça fait longtemps que je n'en ai pas rencontré.
On a des petits clients qui ont besoin de ces petits cas.
Donc on en a quelques-uns notamment.
Damir tu veux nous parler justement d'un concurrent à Docker et Docker Compose ?
Oui de Ponman.
Alors Ponman en connaît pour run des containers.
Mais on peut aussi run plusieurs containers en disant des charts qui ressemblent fortement
à QSEL de Kubernetes.
Elle est censée être compatible.
Mais je ne les appliquerai pas sans modification.
Mais ça n'a pas justement un premier pas vers l'ouverture, après vers du cube ou autre chose.
Mais en tout cas c'est possible de le faire aussi avec Ponman.
Je rajouterai aussi qu'on n'a pas reparé dans ce point.
Mais c'est tout à fait possible de rester sur du passe en fait ou du cas.
Moi je ne préfère n'appeler.
Dans les cas là on peut tout à fait rester et dire que ça nous convient très bien.
Et attendre un peu avant de passer à autre chose.
Oui évidemment on ne l'a pas dit mais qui peut le plus, peut le moins.
Qui peut le moins, peut le plus.
Mais du coup si on a un service qui tourne sur du passe, si on veut héberger plusieurs services,
on peut aller faire plusieurs passes.
Il n'y a pas de problème.
Là c'est vraiment, en tout cas la stack que je vous ai proposée.
Et vous pouvez je pense utiliser trafic avec Ponman.
Et c'est un truc vers lequel j'aimerais moi aller.
Parce que Ponman en plus a des intérêts par rapport à Docker.
Et c'est un truc vers lequel on peut lancer des conteneurs non privilégiés.
Et donc ça c'est vachement bien.
Et bien en fait, je suis perdu au secours.
Venez à mon aide.
Mais ce qu'on peut dire aussi c'est qu'on peut avancer par à passe.
Je t'ai pas beaucoup aidé là, je suis désolé.
Non non non c'est clair, tu ne m'as pas beaucoup aidé c'est encore pire.
Je ne sais plus ce que je voulais dire.
Un pass en avant, deux passes en arrière.
Exactement, oui ce que je voulais dire c'est que si évidemment vous avez plusieurs services,
vous n'êtes pas obligés d'avoir un serveur.
Mais par contre en ayant un seul serveur, en mettant plusieurs services dessus,
vous allez faire des économies très certainement.
En théorie le pass est un peu plus cher que juste exploiter votre serveur.
C'est ça que je voulais dire.
Il y a une dernière stack que j'aimerais bien aussi tester.
Mais que je n'ai pas encore testé, c'est notamment PortoNer.
PortoNer qui peut servir d'orchestrateur assez simple sur justement un seul serveur.
Alors PortoNer permet en plus d'orchestrer plusieurs serveurs.
Donc ça c'est un truc justement que j'ai encore jamais testé.
Mais j'aimerais beaucoup.
Alors j'ai déjà testé l'interface de PortoNer, j'ai déjà installé des stacks.
En plus dans PortoNer, il y a des stacks déjà préfaites.
Mais on peut nous-mêmes apporter nos stacks.
Donc des stacks qui sont à base de lockers composent.
Donc ça ça peut être aussi une solution.
En tout cas c'est une solution que j'ai déjà conseillée à des prospects.
Pour éviter d'aller vers du Kubernetes tout de suite.
Parce que PortoNer me semble quand même beaucoup plus simple que Kubernetes pour certains cas.
Notamment des cas assez simples où on reste sur un serveur.
Où on reste sur un pool de serveurs avec des besoins assez réduits.
Vous avez testé vous PortoNer ?
Eh ben moi oui.
Donc c'était une des solutions que j'avais testé au moment où je voulais commencer à faire du conteneur en prod.
Je m'en suis très rapidement écarté.
Parce que c'était un petit peu trop compliqué par rapport à ce que moi je voulais mettre en place.
Dans le sens où ça vient avec plein de choses dont j'ai pas forcément besoin.
Il y a une jolie interface graphique pour visualiser tous les conteneurs, les groupes etc.
Moi c'est pas quelque chose dont j'avais besoin.
Et je suis parti sur une autre solution dont j'ai parlé plus tard.
Mais par contre je suis intervenu chez un client qui en avait déployé.
C'est très bien quand vous avez une équipe IT réduite.
Ça peut être installé de manière quand même suffisamment sécurisée pour pouvoir être mis sur internet.
Ça permet aux gens de commencer à jouer avec des conteneurs quand ils ont pas forcément les compétences.
Je pense notamment à des gens qui ont administré des Windows.
Ils sont pas forcément à l'aise, sous l'inux, avec de la ligne de commande.
Ils peuvent installer PortoNer, ils peuvent commencer à jouer avec.
Et surtout PortoNer et MultiMachines.
Vous pouvez monter des clusters assez facilement.
Et derrière je crois que c'est du Cluster Swarm qui va vous mettre en place.
C'est effectivement une bonne solution pour des gens qui n'aîtris pas trop la partie système.
Si vous êtes un administrateur système à guéris de Linux et que vous êtes un petit peu à l'aise avec du Docker,
regardez plutôt d'autres solutions.
Oui je suis pas forcément d'accord avec toi.
Parce que moi c'est un PortoNer.
J'aimerais bien l'ajouter sur ma stack trafic Docker Compose.
Pour justement avoir l'interface graphique pour observer ce qui se passe sur mon serveur.
Justement avoir mes beaux graphiques etc.
Parce qu'en effet je pourrais me connecter sur mon serveur SSH,
tu sais pas d'avire, faire H-Top ou je ne sais quoi.
Ou faire APS, Moisaf, etc.
Mais PortoNer permet d'avoir l'interface graphique,
qui mine de rien, même si on a des ops, c'est quand même bien de voir ce qui se passe graphiquement.
Donc je me dis que ça peut compléter la stack précédente sans forcément la remplacer.
Je vais te parler d'un autre truc vachement mieux pour faire ça.
Ah d'accord bon.
Oui ça s'appelle le Monitoring Graphana non ?
On ne parle pas de la n'importe quoi mais Damir, tu apportes de la n'est ce que tu as utilisé ?
Non je n'ai pas utilisé pour le coup.
J'ai l'impression que ça peut être pas mal pour faire de l'agrégation de plusieurs solutions
quand on commence à avoir un peu de choses gauche à droite
et avoir un dashboard unique pour savoir un peu ce qui tourne et où ça tourne surtout.
Mais au-delà de ça, je me suis juste arrêté, on va dire,
à la description de la solution, 2-3 screenshots mais je n'ai pas testé.
Bon est-ce qu'on passe à la suite ?
La haute Dispo, ce que tout le monde attend.
Du coup, c'est un turbre tel quand on veut de la haute Dispo qu'on a une équipe assez complète,
plein d'ops pour pouvoir administrer des solutions à bien penser
et surtout qu'on peut mettre en place des astrates,
parce qu'il dit haute Dispo, il dit astrates.
À un moment donné, on peut faire de la haute Dispo sans astrates
mais il y a un truc qui va mal se passer à un moment donné.
À ce sujet, avant qu'on commence, on a fait un épisode complet qui s'appelle
Kubernetes est-il obligatoire ?
Donc je te renvoie vers cet épisode, tu as une fiche YouTube qui est apparue
ou si tu es dans le podcast, le lien est en description
mais on va parler quand même des solutions dont on a parlé à ce moment-là
parce que c'est des stacks qu'on va utiliser en prod.
Nicolas, je te laisse l'honneur de commencer.
Oui, alors effectivement, j'avais beaucoup parlé de Nomad dans ce fameux épisode
donc je vous invite d'abord à l'écouter ou après
puisque Nomad dans ses dernières versions a un petit peu changé par rapport à certaines choses.
Quand on voulait faire du Nomad sérieusement,
il fallait mettre un console pour faire du service Discovery
et il fallait un Volt pour gérer les secrets.
Mais en fait, dans une des versions toute récentes de Nomad,
on n'a plus besoin de ces deux composants-là.
Nomad, c'est faire un petit peu de service Discovery.
Alors de ce qui va déployer lui-même,
j'ai pas creusé peut-être qu'il sait faire un petit peu de service Discovery à l'extérieur
et il sait aussi gérer des secrets pour aller mettre
dans les services qui vont être déployés par Nomad.
Donc Nomad, c'est déployer autre chose que des conteneurs
mais aujourd'hui on parle de conteneurs.
Donc moi je trouve que c'est une excellente solution
parce qu'elle vous permet aussi de démarrer très simplement.
Tout à l'heure on parlait de Porteneurs.
En fait moi c'est ce que j'utilise pour remplacer Porteneurs
parce que Nomad fournit une interface pour voir la liste de tous les process
entre guillemets gérés par Nomad.
Donc on sait quels sont les services qui tournent sur la machine,
ceux qu'on veut skydé ou pas.
On a un joli clic au drôme pour voir l'état des ressources de la machine.
Maintenant on a même l'état du cluster.
Donc si on a un cluster d'une machine ça marche aussi.
On voit la consommation, cpu mémoire sur la machine,
combien de conteneurs prennent quel place etc.
Donc c'est une excellente solution pour pouvoir démarrer.
Et si vous démarrer avec du Nomad,
vous avez la possibilité de monter en gamme
puisque vous pouvez monter des clusters Nomad
avec des centaines de machines pour faire de l'auteuil de dispose.
Ça va gérer les mises en prod avec du Blue Green, du Canary, des machins etc.
Et après vous pourrez rajouter du console pour faire des trucs plus sérieux,
niveau, service discovery.
Vous avez la possibilité d'augmenter la sécurité avec ConsulConnect.
Vous avez la possibilité de mettre tous vos secrets
dans un vault qui va être bien sécurisé etc.
Et Nomad sait aller chercher tous ses secrets.
Et vous avez la possibilité de faire des trucs vraiment très très bien
dans tout l'écosystème Hiccorp.
Tout ces outils-là dont j'ai parlé sont compatibles avec Hiccorp.
Et si vous êtes fan de Terraform, c'est encore mieux
parce que vous pouvez faire, je sais jamais comment ça s'appelle
le manifeste Terraform pour décrire votre service.
Il y a une ressource Nomad pour créer des services dans Nomad.
Donc vous pouvez faire un Terraform Play pour déployer votre Nomad aussi.
Et ça c'est top.
Ça veut dire que si j'ai bien suivi,
ton Nomad il peut remplacer ton porteneur.
Donc tu peux installer ton Nomad sur un serveur unique
avec ta stack de trafic de cœur composé.
Il va observer tout ce qui se passe même si c'est pas lui qui l'a installé.
Non pas du tout.
Ce que fait porteneur du coup.
Oui.
Ok mais par contre ça devient une alternative
plus simple que Kubernetes pour démarrer sur de la haute-dispos
avec plusieurs serveurs.
Et le fait de pas avoir à déployer justement un vault et un mass.
Consul.
Et un consul.
C'est quand même pas mal parce que, mine d'oreille,
quand tu es une petite équipe,
tu veux commencer de la haute-dispos,
genre t4 tu peux faire des astrates,
tu veux commencer de la haute-dispos,
mais tu as d'autres trucs à faire.
Tu peux te concentrer sur ton Nomad d'abord
et puis tu te lances comme ça en fait.
Mais les solutions à Chikorps ont toujours été plus simples
que du Kubernetes.
Oui je le le le.
Oh comment ça troll.
Ça commence déjà à troller.
Je vais pas dire du balle de Chikorps,
ça ne sera jamais moi qui vais dire du balle de Chikorps.
Bah ça m'encourage à aller tester Nomad
et vraiment dans le détail je pense
qu'on va aller faire un tour là-dessus.
Mais sinon si vous n'avez pas réussi
à convaincre votre client,
peut-être que Christophe va vous parler
d'une autre solution.
Exactement, moi je vais vous parler
de la solution dont on parle beaucoup
qui est Kubernetes.
Kubernetesvania, Kubernetes OpenShift,
enfin Kubernetes, c'est un orchestrateur
de conteneurs, ça veut dire que
Kubernetes va être chargé de gérer les
conteneurs qui vont tourner, de les répartir
sur les divers machines, puisque là
on parle d'un ensemble de machines,
un pool de machines, 3, 4, 10, 20, 50.
Et donc vous allez envoyer vos services
dans Kubernetes.
Kubernetes va gérer vos services pour vous.
Alors, va gérer vos services pour vous.
C'est pas magique, à un moment donné
va falloir quand même apprendre Kubernetes
et ça ne se fait pas rapidement.
Clairement, pour apprendre Kubernetes,
j'ai mis plus de 6 mois et c'était
6 mois à temps complet en disant la doc.
Donc c'est pas non plus trivial à Kubernetes
parce qu'en plus, si vous gérez vous-même
votre Kubernetes, ce que je ne te conseille pas,
prends un Kubernetes manager si tu commences,
il y a quand même des choses à rajouter,
parce que Kubernetes c'est un produit assez complexe.
Est-ce que vous voulez réagir sur Kubernetes ?
Parce que, alors toi Nicolas, non,
mais Damir, je sais que tu utilises aussi Kubernetes peut-être ?
Oui, pour le coup je peux utiliser NoMan,
mais Kubernetes, je utilise pas mal.
Et c'est vrai que dans la plupart des cas,
prenez du manager.
Ce n'est pas forcément la peine
de vous cramer la tête,
gérer ça vous-même,
ça va ouvert la paire du temps.
Et pour ces choses-là, c'est souvent plus efficace,
on va dire, de se faire une solution manager,
surtout que souvent elles vont intégrer d'autres choses.
Donc directement, je prends un exemple très simple.
Vous allez souvent en layame qui va être totalement intégrée,
vous allez aller voir le scaling qui va être totalement intégrée,
donc toutes ces choses-là.
Donc pour moi, c'est souvent un des meilleurs choix
dans énormément de situations.
Si vous devez le faire en prem,
prenez le temps de monter en compétence dessus
et faites-le bien, mais prenez aussi,
on va dire en considération que ça va coûter
un gros investissement,
pas forcément financier directement,
mais en termes humains,
pour monter en compétence dessus et gérer ça.
C'est une solution qui se défend,
Kubernetes, a pas mal d'avantage aussi,
notamment le fait d'être très extensible
sur les CDR.
Donc oui, ça fait maintenant
une perte d'années que je dis,
Kubernetes, plus ou moins intensément.
Ce qui est intéressant, c'est qu'aujourd'hui,
on peut le dire un peu sans trop se mouiller,
c'est devenu un peu un quasi standard de facto.
Et on a beaucoup de solutions qui sont prévues
pour Kubernetes et qui sont très en retard là-dessus,
pareil pour tout ce qui est
ressources que soient de documentation,
dashboard et tout ce qui s'ensuit.
Donc je pense que là-dessus, c'est un écosystème
qui est ultra riche, peut-être des fois,
on lui reproche limite d'être trop riche plutôt que l'inverse.
Si j'en crois, les petites rolls
autour du tableau de la CNCF
qui tournent depuis quelque temps.
Mais au-delà de ça,
ça reste, on va dire,
la solution un peu
on va dire
comment dire un peu
par défaut quand on veut faire du
conteneur à l'échelle.
Ce qui est intéressant, c'est surtout
je pense de la prendre en manager la plupart du temps.
C'est-à-dire de laisser encore une fois
votre fournisseur Cloud la gérer.
Pourquoi ?
Ça va vous éviter toute la partie maintenance des nœuds,
maintenance de tout ce qui va être à pays
global.
Mine de rien qui sont des charges assez importantes.
Ça vous enlève une grosse partie.
Et au-delà de ça, ça vous permet aussi
de profiter des intégrations avec le fournisseur Cloud.
Notamment de vous connecter avec la IAM
de votre fournisseur Cloud, à votre cluster Kubernetes,
de gérer directement
des droits sur des pods,
de...
Je parle surtout là pour AWS et GCP,
les autres je vais pas tester.
Mais de tester, de faire des choses un peu plus avancées de ce type-là.
Et aussi du coup,
du scaling automatique.
Là, ça peut être intéressant, par exemple la nuit
de descendre de nombre d'instances automatiquement.
En cas de charge augmenter de nombre d'instances
voire même mettre des instances éphémères
moins chères. Donc il y a plein de choses
comme ça qui sont possibles.
Ce qui est aussi intéressant, c'est qu'il y a
deux, trois alternatives dont on parle pas beaucoup,
mais qui sont toujours là et j'ai connu des boîtes
qui s'en sortaient plutôt bien.
Qui sont des autres solutions manager un peu spécifiques au Cloud.
Donc j'en connais surtout une qui est ECS.
Et j'ai connu une entreprise qui est utilisée,
sur lesquelles ça fonctionnait très bien.
Néanmoins pour tout ce qui est manager,
si vous voulez vraiment de la haute-dispos,
je vous invite à vraiment lire bien la documentation
pour regarder que c'est de la réelle haute-dispos.
C'est-à-dire entre plusieurs data centers
ou moins plusieurs zones géographiques
sans forcément
à passer à plusieurs régions.
On pourrait éviter un petit
incident
ou un petit incendie qui pourrait
détruire votre cluster.
Il faut vraiment vérifier que ce soit bien réparti quand c'est manager.
Et j'avoue que selon les fournisseurs Cloud,
c'est pas toujours l'information la plus explicite.
Oui, parce que beaucoup ne le savent pas.
Mais beaucoup de ressources AWS,
on pense qu'elles sont
une haute-dispos.
Mais par delfo, elles sont configurées dans
une seule zone.
Donc au sein d'une seule région.
Mais si cette zone-là crame,
je vous perdais le service.
Donc regardez bien toutes les options
pour configurer sur plusieurs zones
et éventuellement sur plusieurs régions.
Mais une région, on peut la perdre aussi.
Un incendie en Californie
et puis les trois zones crames.
Je sais pas s'il y a des zones en Californie.
Mais bon, vous avez l'idée
si il y a un tremblement
de terre à un endroit, vous perdez la région
complète. Puisque les trois data centers
sont quand même relativement proches
pour pouvoir être impactés sur un
gros incident géographique.
Oui, ou
typiquement une coupure de courant.
En ce moment, on parle beaucoup de
coupure de courant et de l'estage en France.
On pourrait être très bien
avoir une coupure de courant. Alors certes,
il y a les groupes électrogènes qui viennent prendre le relais.
Mais on sait pas combien de temps ça peut durer.
Ou alors une coupure S-O.
Sans forcément aller vers le
feu, il y a plein de trucs qui peut arriver
dans un data center.
Donc ça peut être important.
Moi, j'assise, oui.
Juste pour rebondir, je parlais
de l'incendie d'OVH, que au-delà de l'incendie en soi,
ce que ça nous a appris, c'est que
ce que nous, on pensait être très séparés
pour des data centers, était en réalité collés
les uns aux autres. C'est pour ça que j'insiste là-dessus.
Faites attention à un topologie réseau.
AWS, on peut dire ce qu'on veut,
on pensait ce qu'on veut, mais c'est relativement clair
une AZ, même si, comme Nicolas
l'a dit, c'est pas magique. Il faut lire la DOG.
Il y a des options à rajouter, des choses à configurer.
Et ça, faut vraiment, j'insiste, liser
la DOG des produits que vous utilisez.
Mais dans tous les cas, c'est assez clair.
Deux AZ, c'est séparé d'un certain nombre de kilomètres
et ça constitue une région.
Deux régions, c'est séparé d'un certain nombre de kilomètres.
Et dans tous les cas,
je pense, qui est relativement
peu probable qu'une coupure de courant
mette à...
à... à...
à, comment dire, de...
Coupe totalement une région, en fait, vu que
c'est censé être sur des... des dépendants
sénégétiques qui sont très différentes.
Il y a peu de... peu de raisons que ça arrive.
Et le jour où une région tombe totalement,
parce qu'il y a une guerre ou autre chose, on aura d'autres problèmes, je pense,
la plupart du temps.
Après, il y a des sociétés où c'est plus sensible.
Et là encore, on en revient au point numéro un.
En fonction de vos besoins, bah vous allez pousser au maximum.
Si jamais vous avez besoin de notre dispose,
parce que vous êtes sur du bancaire,
vous allez clairement avoir une structure qui va être
bétonnée et qui va être redondée de partout.
Si demain vous avez une application qui vous permet,
je sais pas, moi, de...
de gérer des...
des arrosoires connectés
pour arroser Jardin automatiquement,
bah c'est pas... vous avez pas besoin d'être sur 10 régions.
Pour vous préciser très rapidement,
normalement, un data center
est connecté sur plusieurs sources d'énergie différentes.
Le problème qui a eu à Strasbourg,
c'est que la partie qui l'a brûlée,
c'était aussi la partie qui répartissait
l'électricité des 3 arrivées
dans toutes les salles.
Il me semble.
Et j'insiste sur le fait
que Kubernetes c'est un outil formidable,
moi j'aime beaucoup Kubernetes,
mais c'est un outil complexe.
Donc si vous vous lancez dans Kubernetes,
n'oubliez pas que,
encore une fois, ce n'est pas magique,
il va vous falloir un temps d'apprentissage.
Et surtout, Kubernetes tout seul,
ça ne sert pas à grand-chose,
puisqu'il y a des briques à mettre en plus.
Puisqu'il faut déployer
dans Kubernetes vos applications.
Donc il faut mettre du déploiement continu.
Et là il y a plein de solutions.
Il faut gérer votre réseau,
il faut gérer la supervision,
etc. etc.
Kubernetes c'est bien, mais c'est une brique
sur lequel il va falloir rajouter plein de choses.
J'ai tendance à dire que c'est plutôt
votre fondation
de votre futur infrastructure.
Et puis par contre, il va falloir rajouter plein de choses.
Et si vous n'avez pas écouté
l'interview que j'ai faite
sur comment ça s'appelle,
la DevOps stack,
qui est quelque chose qui va se rajouter
sur Kubernetes, qui va installer des applications.
Allez écouter
cet épisode de podcast
qui parle d'un outil open source,
qui va les déployer pas mal d'outils.
En plus, donc Kubernetes pour rendre
vos Kubernetes un peu plus prod ready.
Parce que si vous déployez un Kubernetes
Vanilla,
vous serez content, mais vous ne pourrez pas
encore aller en prod.
Sinon, donnez-vous un moment pour essayer
les différentes solutions pour prototyper
votre truc. Par exemple,
une journée pour Nomad et une semaine pour Kubernetes
et vous pourrez faire votre choix après.
Au-delà du troll,
essayez quand même
de déployer rapidement votre application.
Parce que tout le monde
veut faire du Kubernetes,
mais je pense qu'il y a assez peu de gens
qui mesurent les implications que ça a
dans toute la chaîne de production.
Entre le moment où vous développez
votre application et où elle arrive en prod,
il peut y avoir plus ou moins d'étapes.
On parlait du petit serveur tout simple
que vous prenez chez OVH.
Vous commandez votre serveur, vous faites docteur,
install, bidule.
C'est fait jusqu'à Récature
en 5 minutes. Kubernetes,
vous n'allez pas déployer en cluster
Kubernetes en une semaine. C'est pas possible.
Et après, il va falloir l'exploiter.
Parce que quand ça va tomber en panne,
votre serveur tout seul avec un service,
dans le pire des cas,
vous rebouttez, vous faites un service restart.
Quand votre Kubernetes va tomber,
il va falloir avoir les compétences pour tout débuguer.

moi, c'est une des raisons pour lesquelles
je ne veux pas faire de Kubernetes.
Je préfère m'embêter avec les outils
de la stack Hiccorp, mais c'est une question
de point de vue.
Après, on en revient toujours à la même chose.
Quand vous choisissez une solution,
c'est regarder ce que vous avez besoin
et vers quoi vous voulez aller à terme.
Je pense qu'encore une fois, quand on parle de Kubernetes,
c'est plus des technos de transition
dans le sens où on le fait, à partir du moment
où on dit que on a déjà lancé quelque chose de plus petit.
Pour moi, on est censé être un peu moins
d'enurgence.
C'est le moment où c'est un choix de société
qui doit discuter notamment avec le CTO
et des jeux perso qui sont responsables
là-dessus. Pour savoir vers où elle veut
aller, vers quel type de fonctionnement.
C'est quelque chose qui a un choix
qui est clairement important. Comme Nicole disait,
il ne faut pas le négliger, il ne faut pas
espérer que ça soit fait en deux jours.
C'est même mieux des fois de prendre plus de temps là-dessus
et de compléter avec du passe
ou quelque chose en attendant pour avoir un truc
propre, fonctionnel.
Une fois que vous serez matur là-dessus,
ce sera bon.
Parce que autant votre conteneur docker
vous allez pouvoir le lancer
sur Kubernetes du Nomad
sur un docker tout seul.
Autant le temps que vous allez passer pour intégrer
Nomad, pour intégrer Kubernetes,
pour intégrer un docker compose,
vous allez mettre tout ce boulot là à la poubelle
et vous n'allez pas changer en deux jours
d'une technique.
Oui,
et l'avantage
de Nomad et de Kubernetes
c'est que ce sont deux orchestrateurs
de conteneurs
open source et libre.
Il y a des versions SASS, mais il y a des versions
open source et libre.
Pour moi, c'est des alternatives crédibles
à du tout cloud
et du tout service manager.
Si vous voulez
ne pas être marié
à votre cloud provider.
Si
vous utilisez Kubernetes ou Nomad
l'intérêt c'est que vous allez pouvoir
migrer vers d'autres cloud providers
parce que vous utiliserez des briques libres.
Si vous utilisez des services manager
pour aller dans le cloud
ce qui est une autre solution
mais ce n'est pas celle qu'on d'abord d'aujourd'hui,
mais c'est possible, vous serez
en grande partie marié avec votre cloud provider
parce que pour changer
de cloud provider, il va faire tout redevelopper.
Alors si vous partez sur du Kubernetes
ou du Nomad,
vous allez relancer un Kubernetes et un Nomad
chez un autre cloud provider, vous allez faire
transiter vos containers etc.
Modulo, les quelques services manager
que vous utilisez typiquement, vos bases de données
manager, parce que c'est vachement
bien de mettre vos bases de données
dans un service manager.
En général, les bases de données manager
c'est quelque chose qui sont offertes
par beaucoup de cloud provider.
Vous êtes d'accord avec moi du coup ?
Dans les grandes lignes,
après, je pense que
ce n'est pas
un fantasme trop
sur une portabilité absolue.
C'est comme tout, c'est quand même
plus simple de migrer, notamment
sur tout ce qui est...
Imaginez, on fait du continuous
de livrer avec de l'argo,
du fluxidi.
Oui, vous n'aurez pas le redevelopper,
vous avez juste changé les informations dans votre nouveau cluster,
ça a fonctionné. Après, il y aura quand même
des intégrations qui vous changent, je parlais d'IA,
mais des choses comme ça, c'est des choses qui vont être
redeveloppées, pareil pour l'organisation de vos projets
où vous vous racontes. La portabilité absolue,
je...
personnellement, je pense qu'elle existe pas.
En tout cas, elle a un coup, elle est pas magique.
Mais c'est
encore une fois quelque chose qui se gère
le vendeur locking. Vous serez moins
loqué avec un Kubernetes, ou avec un
NoManManager, qu'avec
un ECS ou quelque chose comme ça, là-dessus,
on sera toujours d'accord. Mais ça veut pas dire
que vous êtes 100% portable, mais vous êtes
plus avancés là-dessus.
Eh ben merci.
On va... on va... enfin, on va
parler de la construction des images
et du build des images, puisque Nicolas
voulait nous en toucher deux mots.
Oui, puisque je me suis récemment
cassé les dents avec ma nouvelle machine,
donc je suis passé sur une architecture
ARM, puisque je suis le reposesseur
d'un Apple et main.
Eh ben je me suis rendu compte que
les conteneurs de cœur ultra
portables étaient aussi ultra longs
sur de l'ARM, notamment
quand j'ai voulu lancer
un Rondek, donc
une grosse VM j'avais bien lourde,
qui n'est déjà plusieurs secondes à démarrer
sur l'Intel, sur de l'ARM,
ça n'est encore plus de temps. Et donc
là, je suis en train de me batailler
sur la construction
de ces images là. Donc aujourd'hui
j'ai deux types
d'images que je construis, c'est
j'essaye de mettre
autant que possible la construction
de toutes mes images dans une CI,
parce que je considère que
tout ce qui est artefact doit être construit
par une CI, parce qu'il doit pas y avoir
d'intervention une même dans la construction
d'un truc qui va être déployé.
Parce que si
ma machine crame, si je quitte
la société, le projet, etc.
les images
doivent pouvoir continuer
à être construites sans moi.
Donc ça c'est le premier truc.
Après
en local, aujourd'hui
il y a certaines images que je construis encore en local
parce que faire des images
cross-platformes, c'est encore plus facile
en local. Je suis en train d'essayer
de regarder comment le faire
dans une CI pour reconstruire
en même temps les deux cibles
ARM et Intel
et potentiellement peut-être d'autres plateformes
sur la suite.
Et après il y a un autre truc
qui me paraît important
à dire, c'est
la source
que vous allez prendre pour construire votre image.
Donc au-delà
des différentes distributions,
vous pouvez prendre de la débiagne, de la Ubuntu,
des Slim, des Distrollers,
des Alpine.
Il y a des avantages et des inconvénients
à chaque solution.
Je ne rentrerai pas dans ce débat-là.
Par contre, ce que je dirais
plutôt, c'est
assurez-vous de prendre quelque chose qui est à jour.
J'ai souvent vu
et qu'il était conseillé
de reconstruire les images
que l'on utilisait pour ses propres
besoins. Donc moi
c'est ce que je fais de plus en plus dans les images
que je construis. Au minimum
je dérive les images
des images officielles. Et de plus en plus
j'essaye de reconstruire l'image
avec une base qui est différente
de celle officielle.
Donc je reconstruis
une Ubuntu
plus fraîche que celle
qui est fournie par défaut. Je reconstruis
une débiagne plus fraîche que celle qui est reconstruite
par défaut. Et je reconstruis toutes
mes sous-images sur ces nouvelles
bases. Comme ça
j'ai toujours des images qui sont fraîches.
Donc au niveau sécurité
c'est toujours mieux parce qu'on a
des images plus à jour
que certaines images officielles.
Il y en a qui font très bien leur boulot
qui font les mises à jour très régulièrement
mais on peut se retrouver avec
des vieilles versions. Et le jour où vous aurez
une faille openSSL
appachée dans tous vos contenus en dockeur
vous serez bien content d'avoir anticipé
le fait de construire vous-même vos images.
Donc c'est un gros boulot parce qu'il va falloir
faire une CIA suffisamment intelligente
pour construire d'abord
l'image de base et reconstruire
toutes les images ensuite pour pouvoir tourner
et récroyer mais c'est
un dégarrant de la sécurité.
Et le dernier truc c'est dans
quelle registrie ? C'est si vous
utilisez les images dans des
registries publiques, qu'est-ce qui
va se passer le jour où votre image a disparu
de la registrie publique
et qu'est-ce qui va se passer le jour où la
registrie publique sera chaos ?
Donc moi maintenant ce que je fais c'est
au-delà de builer mes propres images
je les déploie dans des registries privées.
Donc c'est facile
c'est d'aucœur fournir une registrie privée.
Elle est un petit peu pourrie
mais elle fait largement le boulot
pour faire des guides poules
au sein de sa propre
infrastructure. Et le gros
intérêt c'est que le jour où vous voudrez
faire quelque chose totalement
déconnecté d'internet, vous aurez votre
propre registrie qui elle
pourra être populée par une machine
sensible qui pourra faire
des poules et des pouges dans cette registrie
et surtout
vous serez résilient par rapport
à votre accès internet
et vos registries
qui pourraient ne plus être disponibles.
Je sais pas si vous avez
déjà beaucoup joué
avec cette manière de construire
les images, Damien, c'est quoi ton
expérience ?
Du coup
effectivement je pense qu'on n'a pas trop parlé
on s'est vraiment concentré sur le run
on va dire des conteneurs mais on n'a pas
parlé de tout ça. Comme je le dis
au début l'outil hash est important
et je dirais que
typiquement surtout pour les derniers stades
quand on parle de l'audispo etc.
c'est quand votre entreprise commence à atteindre
certaines tailles, en fait vous ne pouvez pas faire sans
CI CD
parce que du coup
construire les images en fait
en faire en local ça peut dépanner mais
au bout d'un moment il faut les faire dans
une chaîne que soit automatisé, que ça
permet aussi d'avoir des tags qui sont propres
et qui sont correspondants à Geet et à votre workflow
complet qui puisse être déployé
automatiquement
potentiellement dans les environnements de test
c'est en fait je pense vraiment
que typiquement aujourd'hui
j'extrapole un peu mais
la stack dont je parlais en partie à
la fin du coup une stack Kubernetes
possiblement managé etc.
c'est quelque chose qui est énormément
important mais ça demande un investissement
qui est terrible en fait
en termes de tooling et en termes
de process CI CD
mais une fois qu'on arrive à investir
là dedans petit à petit à améliorer les choses
on obtient une solution
qui est juste
top en fait mais ça demande cet investissement
et effectivement le build de l'image, le test
de l'image et moi ce que j'aime bien
typiquement dans les conteneurs on pouvait le
faire avant mais je ne sais pas pourquoi c'était
beaucoup moins fait c'est tout ce qui est check
de file de sécurité alors ça n'a pas de check
que vous avez des files dans votre code ça va check
surtout que vos dépendances sont un jour et ça
typiquement pour moi c'est des choses qui sont
aujourd'hui beaucoup plus naturelles qu'à une époque
où vous pouvez remonter ça sur un dashboard
et ça peut être remonté
possiblement si les développeurs
tous les deux semaines quand ils ont fini leur sprint
peuvent être intéressants qui remontent
et ils disent là on a une critique ou on va la
corriger etc. mais
j'insiste là dessus il faut vraiment
tout automatiser sur du conteneur
et quand vous pensez à la hachah
et ce que tu dis c'est quelque chose d'important
on pense des fois dire ouais mon cluster
il est haut de dispose je suis sur cinq régions
et tout votre registrie
redonder le aussi ou y'a plusieurs solutions
parce que effectivement
si votre registrie est mort que votre conteneur
il se fait tuer parce que un conteneur
ça peut se faire tuer, ça peut
repop, ça peut scale etc.
c'est du cattle
du coup pensez quand même
aussi aux dépendances donc ça peut être le registri
ça peut être le vault on en a parlé si votre
cluster il va chercher sur vault des secrets
il faut que le vault soit quand même
un minimum de toérance de panne etc.
si il y a d'autres API et toutes ces choses là
donc non je te rejoins totalement
faut automatiser un maximum
faites la cd aujourd'hui il y a beaucoup
de templates, des images de hocaire c'est un des trucs
des plus basiques souvent
dans les CIA et
n'hésitez pas à investir sur de l'automatisation
parce que c'est très important
à ce niveau là
moi je voudrais parler d'un truc
parce que tu as peut-être passé un peu rapidement
on en parle régulièrement
mais c'est
l'architecture du processeur
au début de l'émission on a dit
Docker c'est portable
si tenté que l'architecture
sur lequel vous faites tourner votre conteneur
soit la même
si vous construisez une image de conteneur
sur
l'AMD64
il faut idéalement
que le serveur qui va le faire tourner
soit
un serveur en AMD64
si vous voulez faire tourner ça sur
l'ARM
qui a un autre jeu d'instruction
qui est complètement différent
vous allez avoir des problèmes comme à priori
mais je ne sais pas si c'est lié à ça
mais du coup
il y a vraiment
cette notion de jeu d'instruction
que je ne sais pas si les nouvelles générations
d'Obs ou d'Ev ont vraiment
conscience de ça
mais vous avez des architectures
processeurs avec des jeux d'instruction
différentes ça veut dire que vos programmes
ne pourront pas tourner de la même manière
que ce soit sur l'AMD64
du risque 5
de l'ARM etc
ce qui veut dire aussi
que toutes les images
que tu fais tourner
sur ton M1
elles doivent être buildées pour de l'ARM
et il y a même des programmes
qui à priori ne vont pas tourner
et pour ça je vous invite à aller
écouter l'épisode de news
dans lequel on a parlé
d'Occur et WebAssembly
qui peut potentiellement résoudre
ce problème-là
puisque WebAssembly
est multi-platform
mais effectivement
après ça marche pas
d'Occur a fait un truc très malin
c'est que pour toutes les images
ARM et IQ86
elles tournent sur les deux plateformes
parce qu'en fait ils utilisent QMU
à la volée
donc ça fonctionne sur les deux plateformes
alors
de l'intest sur l'ARM
c'est très très lent
dans l'autre sens c'est
un peu plus rapide je crois
mais ça reste quand même
de l'émination qui n'est pas terrible terrible
et c'est absolument pas à utiliser en prod
c'est uniquement pour
les phases de dev et de test
j'ai pensé à ça directement
quand t'as dit que t'avais des problèmes de performance
je me suis dit c'est clairement un truc
qui doit virtualiser quelque part
c'est obligé
et c'est très marrant parce que
le conteneur que j'ai essayé de lancer c'est du Java
Java qui est censé être multi-platform
et j'ai galéré comme pas possible
et j'ai fini
par refaire moi-même
l'image de RunDeck 2.0
en m'inspirant de tout ce qu'ils avaient
fait sur l'image de base
et comme j'arrivais pas à reconstruire le jarb
je fais du
multi stage
dans la construction
d'image Docker et je fais un from run
deck je vais piquer juste le jarb
que je vais mettre dans ma nouvelle
image au bout de tout
que j'ai réutilisé en réinstallant
le jdk qui va bien et du coup
maintenant ça fonctionne avec des perves
pas mal mais si vous voulez
faire du multi-platform potentiellement
il y a pas mal de boulot à faire
c'est ce que je vais dire
Java c'est multi-platform et c'est pareil
c'est comme Docker tous les langages interprétés
avec une machine virtuelle
du coup pas une machine virtuelle
type comme on a parlé
mais un environnement d'exécution
une petite machine virtuelle Java
il y a quoi d'autre
bref vous m'avez compris c'est pareil
il faut que la JVM
là pour le coup elle tourne sur ARM
ce qui est pas gagné il faut qu'elle ait été pensée
et que si elle tourne pas
sur ARM il faut en prendre une sur ARM
balancez son programme Java dedans
donc c'est exactement pareil pour moi
en fait le langage
les programmes doivent être
pensées pour la RM
et je pense que ça nécessiterait
un épisode de podcast entier
de parler d'ARM parce que c'est un sujet
passionnant notamment pour les économies d'énergie
et autres je pense qu'il y aura beaucoup de choses à explorer
pour résumer
tout le langage
interprété
et ou multi-platform comme Java
dépend d'une machine virtuelle
au sens interprétation
et chaque machine virtuelle
donc la JVM est compilée
pour certaines plateformes
la
VM piton pareil
rubis pareil et ainsi de suite
tout doit être compilé pour une architecture précise
et tout n'est pas
totalement multi-platformes
en dépendant toujours de quelque chose
qui est compilé pour une architecture
je voudrais réagir
sur le build
en intégration continue
je vais parler de Geeklapse.i
parce que c'est l'intégration continue que je connais le plus
en fait
quand on est sur du Geeklapse.i
on peut faire du build multi-platformes
et pour ça
je vous conseille très sincèrement
de lancer des runners
directement dans l'architecture
que vous visez
vous avez un runner à RM
vous avez un runner risque 5
vous avez un runner à tel
vous les étiquetez
parce que dans Geeklapse.i vous pouvez étiqueter vos runners
et dans votre pipeline
vous dites clairement
je veux construire
telle image sur telle architecture
telle image sur telle architecture
et ça va automatiquement
Geeklapse va répartir ça sur les bons runners
et il va vous construire les images
et vous allez pouvoir les récupérer dans votre registre
moi c'est le conseil que je vous donne si vous voulez faire ça
faites comme ça
mais sinon
Docker c'est nativement utiliser QMU
pour faire du
cross compile, cross build
c'est lent mais ça fonctionne
ouais voilà c'est lent mais ça fonctionne
je suis pas d'accord mais bon
en tout cas moi je ferais pas que ça soit comme ça
je ferais ça comme je l'ai décrit
Damir je te vois faire la mou
ça dépend des besoins
si c'est une machine de temps en temps
c'est pas très grave
si il y a des besoins de rapidité
surtout avec le cloud
on peut avoir potentiellement des machines rm
à la demande ça peut être intéressant
du coup d'utiliser cette solution
c'est encore une fois ça dépend du besoin
mais d'exactement
PS on dit depuis telle heure siya mais en réalité on parle de cd
vu qu'on parle de délivrer des images
on parle de continuous délivrer
c'est pour les auditeurs qui vont râler
n'hésitez pas à mettre des commentaires là dessus ça fera du référencement
oui voilà alors
pas totalement d'accord
la partie bulle de l'image pour moi c'est de la siya
et puis souvent c'est tout mélangé
donc bon on en parlera plus tard
je pense qu'il est temps qu'on
qu'on parle
enfin qu'au clôture l'épisode
du coup tu l'as compris
si tu veux en savoir plus
ou si tu veux poursuivre
les informations
ou donner d'autres informations
tu peux venir en discuter avec nous
dans la communauté des compagnons du devops
on est déjà plus de 1000
parce que je pense qu'au moment où on enregistre
on a dépassé les 1300
sur le forum
on discute pas mal et on discute beaucoup
mais alors beaucoup vraiment beaucoup
de docker, beaucoup de conteneurs
et énormément de Kubernetes
un petit peu de nomades mais pas tant que ça
donc si tu veux venir nous parler de nomades
viens t'inscrire
c'est simple tu t'as compagnon-devops.fr
et puis tu t'inscrives
c'est hyper facile
et ben je vais laisser le mot de la fa
à mes chers co-animateurs
et cette fois si tu es commencé par nous
Cola
je vais en faire 2
si on parle pas de nomades c'est peut-être que ça marche
sinon le vrai mot de la fa
ça sera
ça dépend de vos besoins
que Danire a souvent répété
et effectivement je pense que c'est ça qu'on peut retenir
de l'épisode
vous enfermez pas dans quelque chose
parce que votre voisin fait la même chose
c'est utiliser ce que vous maîtriser
en fonction de ce que vous voulez faire
je ne peux qu'abonder
sur ce que tu dis
Danire le mot de la fa
on vole ce que je préjeteis depuis le début
donc je retiens
non, au-delà de ça
il y a un truc surtout dans les petites sociétés
je pense que c'est important de comprendre aussi
le business et la situation de votre entreprise
qu'elle vise à quelle échéance
et pour ça que nos métiers en fait
on est pas mal impliqués là dedans
il faut vraiment avoir
une vraie vision et savoir
où vous allez, quelles vont être les besoins futurs
pour pouvoir anticiper justement
et pas être dans l'urgence et créer une solution
à la rache, parce que c'est pas le but
et pour le coup que ce soit nomades ou culpernettes
ça peut très bien marcher si on prend le temps
de bien monter en compétence et de bien le faire
ça peut très mal marcher si on fait ça à la rache dans l'urgence
donc voilà prenez le temps d'échanger
de comprendre ce que votre boîte fait, quelle est la situation sur le marché
et quel sont ses futurs besoins
et je pense que c'est quelque chose qu'on oublie un peu trop souvent
Compagnons du DevOps est produit à Lidra