C'est d'abord une culture. Quand on est en DevOps, on prend tout le monde.
DevOps et agile font effectivement partie de la même famille.
Sa virtualisation applicative, c'est très bien.
Aujourd'hui, ça nous prend 10 minutes et un café.
Ce n'est ni être dev, ni être DevOps. C'est avant tout de la communication.
Ce mouvement DevOps, c'est tout simplement rêvé par la communauté
et endorsé par les entreprises.
J'ai adopté une démarche DevOps.
Le développement agile, on a accéléré des poignements.
Ça amène une clarté sur le travail de...
Être dans une démarche d'amélioration.
On se retrouve face à des salles naturelles ensemble.
Ça donne des résultats contrées.

L'objectif individuel, ça s'atteint.
Alors qu'une ambition, ça se partage.
Bonjour à tous et à toutes.
Bienvenue dans un nouveau numéro de DevOps.
Aujourd'hui, on va avoir un numéro spécial
dédié au bout de strapping.
Qu'est-ce que c'est que le bout de strapping ?
Et comment on s'en sort avec tout ça ?
Autour la table, nous sommes 5.
Moi, c'est Mathieu Gébec, que je bosse chez SANS.
Je suis l'idée sérieuse sur les parties de bon niveau.
Le système d'exploitation, c'est au cas.
J'ai un peu matériel, en général.
C'est Sylvain Morange, je suis indépendant
dans les sujets système réseau, data center
et tout ce qui gravit de ce merveilleux univers.
Taxionnés tous, surtout terres.
Moi, c'est Loïc Blow. Je travaille chez ExoScale,
qui est un cloud provider suisse.
Je suis dans la partie plateforme et sur l'offre manager Kubernetes,
qui s'appelle SKS.
Et Bartel et mes vêtements, je suis également chez SANS.
Je suis l'équivalent d'un staff SRE lead
et en ayant travaillé sur la partie CAS, notamment.
Mais en vrai, je suis là depuis le tout début du projet.
Donc la partie bootstrap, j'y ai activement parti.
SANS, qui est une co-entreprise entre TALES et Google,
qui a l'objectif et l'ambition de construire Google Cloud
opéré sur le sol français par des équipes françaises
avec un ownership complètement français.
Et là, moi, Guillaume Le Tron,
je travaille chez Akamai, Akamai Connected Cloud,
anciennement Linux.
Et je travaille notamment sur toute la partie Kubernetes,
tout ce qu'on appelle le cloud native.
Donc les offres aussi bien publiques qu'internes.
Tour de Kubernetes.
Alors vous avez vu, autour de la table,
on a quand même pas mal de gens qui travaillent dans le monde du cloud,
aussi bien très bas niveau en construction
ou très haut niveau avec des offres déjà existantes.
Et c'est une question qui revient souvent, c'est
comment on fait pour partir de zéro
et comment on fait pour construire un cloud ?
Toujours une problématique.
Quels sont les choix du logiciel,
quels sont les choix de l'architecture disponibles et nécessaires ?
Moi, la question, en fait, un peu que je me pose,
c'est si jamais demain je vous donne un data center,
voilà, un peu jeu de rôle en fait,
voilà, ça va être un premier podcast de DevOps en jeu de rôle,
c'est demain je vous donne un data center.
Donc on va dire qu'il est au bon endroit,
il y a l'électricité, il y a la ventilation,
il y a tout ce qu'il faut dedans.
Et je vous mets des racks,
à la limite les machines, vous en mettez autant que vous voulez,
vous avez machine illimité,
et vous avez du réseau qui arrive.
Et voilà, maintenant je vous dis, à partir de ça,
comment on fait pour avoir une offre pertinente,
une offre d'eau au niveau,
à destination des clients, aussi bien internes qu'externes,
parce que voilà, ça peut être aussi pour des gens
qui se lancent dans une entreprise quelconque
et qui ont besoin d'une offre cloud interne.
De quoi vous aurez besoin ?
Quels sont les questions que vous allez vous poser
et que sans doute vous avez déjà répondu
dans votre expérience ?
Alors je vais partir le principe
qu'on va rajouter une zone, par exemple,
où les zones sont un cloud provoignant existant.
Alors chez Xosquel, chaque zone est totalement indépendante,
c'est prévu d'une contractuellement,
il n'y a pas de partage de données entre les zones.
Donc à chaque fois qu'on se ponne une zone, on repart zéro.
La première chose à monter pour moi,
au sens physique et début de logiciel,
c'est un out of band.
Parce que chez nous, l'objectif premier,
c'est d'avoir accès à distance.
On travaille tous en remote,
il n'y a personne qui bosse dans un data center directement.
Donc l'objectif, c'est d'arriver avec des premières machines
qui vont permettre d'accéder à l'ensemble du vrai cloud qui est derrière.
Donc là effectivement, on aura deux connectiques raison,
on aura la vraie connectique client,
mais on aura aussi cette fameuse connectique de secours
qui a négocié avec notre data center.
Et à partir de là, on aura quelques machines
qui vont servir à se câbler
au faits de tous les équipements physiques existants
pour pouvoir tout managé.
Ok, donc ça, c'est le logiciel là, c'est les choses qui sont préinstallées.
Vous avez donc un...
En fait, c'est presque un micro cloud,
en fait là, que vous avez besoin de toutes ces machines
qui sont sur la out-of-band.
C'est très simple. C'est vraiment très simple.
Le but, c'est que ce soit le plus rudimentaire possible
et le setup généralement, il n'est pas fait physiquement sur place.
Il est préparé au niveau d'un entité mère à Lausanne.
Et après ensuite, il est chippé au data center.
Et puis les équipes data centers montrent ce début.
Ok. Est-ce que vous voyez d'autres choses ?
Globalement, oui, c'est un peu presque ce que t'as dit.
La première étape, c'est d'avoir accès aux machines
et pour ça, la réseau d'out-of-band, il faut rester le plus simple possible,
un accès tout simple et c'est ça, et c'est bon, tant que c'est au maximum.
Il faut déjà accès aux machines, après tu peux commencer à faire la suite.
Donc il faut quand même que t'as un premier réseau d'out-of-band
qui n'est pas le réseau principal, mais qui est ton réseau secondaire.
Un réseau d'admins, on va dire, en quelque sorte,
qui servira un camp d'internes,
cause les équipes et eux vont déployer les OS,
ou les Q, ou les Dvo, enfin faire les installations des machines.
Mais il faut déjà aussi que t'as un réseau,
ça veut dire switch, routeur,
déjà une équipe réseau qui est travaillée sur le réseau d'out-of-band
avant même de travailler sur le réseau de prod
qui, lui, va où le trafic client va passer.
Et ce réseau d'out-of-band, il va servir uniquement
pour l'administration à ce moment-là,
où il sert après.
En gros, je suis branché à quoi ?
Je suis branché vraiment à la machine,
où je suis branché au Dirac,
aux logiciels de gestion de la machine.
À quoi il va me servir après ce réseau d'out-of-band ?
L'out-of-band, le principe, c'est que si ton réseau d'out-of-band y tombe,
tu es quand même backdoor entre guillemets
pour que tu aies l'âme sur le routeur et que tu puisses remonter ton réseau d'out-of-band.
Et généralement sur les out-of-band,
on va mettre les idracc, les illos des machines,
pas directement du réseau classique.
C'est vraiment juste pour accéder aux illos
et lancer la première install de ta machine
avant de faire la suite.
Donc en gros, j'ai accès par derrière un peu tout ce qui se passe.
Donc c'est un réseau quand même assez tricky.
C'est un réseau important qu'il faut quand même sécuriser un minimum,
parce que si tu fais piratiser ce réseau-là, ça devient compliqué.
Donc là, on a quelques machines qui sont déjà installées,
qui sont pré-provisionnées et mises avant.
Après, qu'est-ce que je fais ?
Qu'est-ce que je fais de tout ça ?
Ok, j'ai accès aux machines, j'ai accès aux dirac,
j'ai accès à whatever solution via cet out-of-band.
Après, là, tu as plusieurs méthodes.
Soit tu mets ton réseau, tu installes ta machine,
soit tu fais ça en mode automatisé,
un coup de PXE comme ça,
tu as des oises, il s'installe automatiquement.
Le mieux, c'est quand même de faire du PXE.
Surtout si tu as beaucoup de machines à déployer,
comme ça, tu s'installes tout seul,
on monte dans le réseau, on rend un HP pouf, c'est bon, tu as accès fini.
Tu passes à l'étape suivante, installes les cubes, installes les logiciels, tout ça.
Ça, c'est la méthode la plus automatisée possible.
Après, en parallèle, il va falloir monter le réseau de prod
qui lui va faire passer les données clientes.
Pas du coup le réseau principal, pas l'out-of-band.
C'est deux choses à faire en parallèle.
Je vois tous les ingénieurs hardware qui sont en train de crier dans leur chômière,
parce qu'on nommait complètement la partie non-boarding du matériel.
Aujourd'hui, on avait peut-être trois machines
ou suffisamment de serveurs VPN, de bastions SSH,
pour faire tourner l'out-of-band.
Mais c'est pas magique le PXE, on ne peut pas juste râquer des machines.
Il va falloir travailler un inventaire.
Alors soit l'inventaire, on connaît les machines à l'avance,
parce qu'on les a saisies.
Donc ça veut dire qu'on a un serveur d'inventaire quelque part.
D'un seul coup, on a une petite plastique qui vient d'arriver.
Ou alors on peut avoir aussi un inventaire qui est dynamique.
C'est-à-dire qu'on part du principe que les machines ne sont pas connues au démarrage
et on va les découvrir au fur et à mesure qu'elles s'allument
et les ajouter à la volée dans l'inventaire.
Mais il faut quand même un inventaire.
Ensuite, le PXE, il faut l'installer.
Mais est-ce qu'on l'installe sur le réseau out-of-band ?
Ou est-ce qu'on va l'installer à cheval entre plusieurs réseaux ?
Par exemple, l'out-of-band,
je viens de parler d'un réseau de BMC,
qui peut être différent de celui de l'out-of-band.
L'out-of-band, il peut juste exister pour accéder à certaines ressources,
en particulier pas forcément à toutes les machines du parc,
voire toutes les BMC du parc.
Et c'est revire absolument, parce qu'en plus,
on va avoir des machines qui vont potentiellement être en DMZ.
Donc on ne veut pas forcément avoir l'out-of-band
qui va être sur tous les segments de notre infrastructure en parallèle.
Donc on peut déjà segmenter le réseau d'out-of-band,
voire même plus que le segmenté,
c'est uniquement lui donner certaines prérogatives
sur les accès, les VPN,
sur cette fameuse machine qui va servir à faire du provisioning.
Et une fois qu'on a ça, le provisioning va et l'inventaire.
Et ensuite, une fois qu'on a débloqué ces deux-trois petites features,
on peut commencer à attaquer la suite.
On a parlé du service de déploiement à coups de PX, etc.
Un service minimum.
Ce qu'il y a, c'est que même avant de déployer une machine,
il y a peut-être de la préparation à faire.
La préparation, typiquement, là, on parlait de CMDB,
enfin, de CMDB, d'annuaire, d'inventaire.
Il y a une partie gestion des identités aussi.
C'est-à-dire que je vais peut-être générer des certificats,
donc une PKI, pour pouvoir authentifier mutuellement mes machines,
enfin, en configurer des TPM, etc.
Donc quelque chose qui est important aussi,
c'est avoir une solution de PKI qui marche tout de suite,
une gestion d'annuaire, une gestion d'identité,
pour pouvoir ensuite configurer le déployeur automatique
en mode PXE avec les bons assets et déployer directement.
C'est un peu ce que fait Microsoft Active Directory.
Quand on monte un data center Windows, Microsoft, entreprise,
c'est d'abord, on déploie AD.
Dans AD, il y a DNS, annuaire, DHCP, il y a identité, il y a tout.
Et ensuite, on peut déployer des choses.
Ça, c'est quelque chose qui est assez important parce que
c'est le socle de toute activité, en fait.
On voit un peu pointé du nez, là, avec ton exemple de Microsoft,
une espèce de micro-control plane,
ou de noyaux de control plane qui servirait à la base,
avant même qu'on ait des machines à gérer des identités,
à gérer éventuellement des profils des annuaires, des choses.
Et ce truc-là va nous servir peut-être à spawner
d'autres types de control planes qui vont être plus spécialisés
et qui vont s'appuyer sur ces features-là.
Et ça, c'est un modèle qui n'est pas forcément hyper répandu
et qu'on voit dans très peu de petites,
même de moyennes ou grandes entreprises qui n'est pas du tout dégout.
Ça, ça me fait penser un peu à ce qu'on a appelé undercloud,
chez certaines distributions open stack,
Steel, Red Hat, HP, Lyon à l'époque, etc.
C'est un peu ça, déployer un noyau mono-machine,
où il y a tout-dessus, un peu all-in-one,
ce qui permet ensuite de déployer des choses beaucoup plus importantes à côté.
Oui, parce qu'en plus, là, quand tu disais tout à l'heure,
bon bah il nous faut le réseau-socine, il nous faut le réseau-seul-là, etc.
Ah genre, c'est quoi, c'est un gars à la main qui va sur des interfaces Cisco,
sur tous les routeurs du parc pour configurer des routes.
Il y a déjà un énorme travail de découpage du réseau à l'avance,
avant même d'arriver dans le décès.
Il faut qu'on ait une espèce de cartographie sur ce qu'on veut faire,
comment on va le faire, et ce travail-là, il prend du temps.
Enfin, en tout cas, chez nous, il a pris du temps, je ne sais pas, chez vous.
Le côté PKI établir, c'est les différentes branches de la racine,
des racines, est-ce qu'on fait une racine par AISI, par data center,
est-ce qu'on fait une racine globale, comment on se débrouille,
tout ça, c'est des choix qui doivent être faits,
a priori, avant même de poser les pieds,
parce que quand on va commencer à créer les certificats, les SSH, les machines...
Mais ça, c'est la partie design, c'est des trucs que,
avant même que tu choisis le data center, c'est des choses que tu résilier, décider...
C'est ça, et donc c'est le pré-bootstrap, c'est...
Voilà, c'est des choix qu'il faut faire, qui sont structurants,
mais qu'il faut faire dans tous les cas avant.
Et c'est vraiment une grosse partie préalable au bout de strap,
qui est d'être un peu visionnaire sur l'utilisation, l'usage.
Et c'est là, en général, où quand on va faire une erreur,
où qu'on va se planter, où qu'on va se dire,
c'est pas si pratique que ça, ça va être assez coûte.
Donc moi, ma grande question pour exoskelle, c'est vos PKI,
comment vous gérer vos racines, et est-ce que vous avez une racine,
comme vous avez vos environnements qui sont très isolés,
comment ça s'est fichué ?
Je vais pas pouvoir beaucoup, pour en à ça, ça fait que de moi que j'y suis.
Je sais qu'on a du vault avec toute la PKI.
Pour moi, il est global à toutes les AZ.
C'est un peu particulier de partage, effectivement,
et toutes nos PKI passent pas.
D'accord.
Et sur les choix, enfin, est-ce qu'il faut faire des choix,
justement, à dire une fois pour toutes ?
Ou est-ce que tu te dis dès le début, je vais faire des erreurs,
et donc il me faut quelque chose qui soit dynamique ?
Sur la PKI, se planter, ça veut dire tout refaire.
Donc c'est assez tendu.
Vraiment ça, parce que, en théorie,
quand je réfléchis à chacune PKI,
il y a toujours des règles pensées à la rotation.
Et la rotation, c'est littéralement changer quelque chose,
en fait, c'est-à-dire que rien n'est immuable,
et je pense, dès que je le fais, à la manière dont je vais le changer,
juste parce qu'il va falloir faire une rotation.
Mais je pensais même aux machines,
on avait déjà essayé dans des contextes de boîte avant,
où les machines bougaient de contexte en haut,
c'est-à-dire qu'une machine, elle pouvait commencer sa vie
en étant un control plane de je sais pas quoi,
elle est enlevée, elle sert après à un autre contexte,
donc elle va migrer comme ça de réseau en réseau.
Et donc, est-ce qu'il y a besoin de tout raquer dès le début,
en disant, bon, cette patte-là, c'est tel VLAN, Tarte-Ampion,
ou est-ce que cette machine, elle va bouger,
et je vais pouvoir la réaffecter et se dire pourquoi pas ?
C'est une très bonne question, elle a en touche du doigt un petit peu,
la mission technique qu'on fait porter sur le masse.
Donc il y a une brique, la brique logicielle,
qui est là justement en interface avec ce qui est rentré
dans cette inventaire ou dans cette CMDB,
et qui va ensuite nous permettre de piloter les machines.
Et le masse, c'est le métal à la service,
donc c'est la stack, fameuse stack PXE,
mais en général, elle est un peu plus intelligente,
elle permet de définir des profils de machines,
de sponner des machines, de sponner des OS,
éventuellement aller jusqu'à la configuration dynamique d'OS.
Par exemple, on va pouvoir dire, cet OS-là,
je veux qu'il ait le réseau XYZ de brancher,
et on va se retrouver avec un OS directement configuré
avec les bonvéland dans son fichier, je ne sais pas,
à SystemD, NetworkD.
Ce genre de choses-là, on est capable de le faire,
on est capable de lui piloter tout le fichier CloudInit,
ou Ignition, ou peu importe, ce genre de choses-là.
Et c'est cette stack logicielle-là
qui va aller templétiser en grosso modo ces fichiers,
et au moment du bout de la machine sur le réseau,
lui passer toutes les informations.
En fait, ce qui est important, c'est qu'il faut un outil
de gestion de cycles de vie du matériel.
C'est-à-dire que je sors du carton une machine,
je la râque, je la branche, je l'allume,
il faut qu'elle soit découvrable.
Ensuite, je décide de ce que j'en fais.
Donc il faut piloter à la fois la carte contrôleur,
la fameuse BMC de la machine pour pouvoir la lumer et l'éteindre.
Mais il faut aussi être en mesure de configurer le réseau
qui est avec.
C'est-à-dire que je vais peut-être la mettre d'abord
dans une zone de quarantaine, parce que je vais faire un test de charge,
je vais voir si les aliments ne cassent pas,
si le processur est tourne bien, peut-être la faire chauffer un peu
pour être sûr qu'elle est disponible et prête à la prod.
Et ensuite, j'ai sûrement la basculer dans une zone de métier.
Mais si je la bascule dans une zone de métier,
c'est-à-dire que je vais changer l'OS qui est dessus,
pas l'irriguer de la même façon niveau réseau, niveau VLAN,
c'est peut-être à ce moment-là que je vais lui envoyer des certificats,
ce genre de choses. Donc la gestion du cycle de vie,
c'est pour le serveur, mais c'est aussi pour la fabrique réseau,
en fait, qui autour.
Exactement. Et là, tu viens de toucher un truc super important,
la fabrique réseau, si elle n'est pas pilotable,
si elle n'a pas été designée à l'origine pour être pilotable,
ça veut dire qu'on a des gens, au moment, avant même qu'on pose les pieds,
au moment où on configure les switch, les routers,
on va dire que le port X, c'est le VLAN Y.
Et ça, à partir du moment où on a un mapping statique des ports,
des VLAN, et qu'on a une carte graphique qui est trop statique,
on peut plus opérer notre décès de manière dynamique, tout simplement.
Donc ce choix-là, c'est un choix structurant.
Si tout le décès, on ne peut pas piloter le VLAN, qu'on n'a pas de SDN,
et qu'on n'est pas capable de changer dynamiquement la topologie du réseau,
on ne pourra pas être flexible dans nos opérations.
Et les solutions, parce que là, on a parlé masse, on a parlé etc.,
mais on a parlé des solutions concrètes qui existent.
Ça existe, ou pas ? Parce que si jamais, c'est juste dans le monde des idées
que ça existe que chez 3 GAFAM.
Ça existe, c'est un grand débat.
L'automatisation réseau, ça te ferait un grand débat.
Et pourquoi ? C'est quoi les problématiques, à part voir ça ?
Il faut que déjà, tu crées ton réseau,
il faut qu'il soit designé D1 pour être automatisable et pilotable.
Si tu ne levais pas D1, c'est mort.
C'est quoi, qui est automatique ?
Il faut que j'astaille un Cisco, un Juniper.
N'importe quoi qui sait parler de l'un-to-seabull,
enfin, chaque constructeur a sa petite sauce,
pour que tu puisses lui parler que ça soit de l'un-to-seabull,
ils seront plusieurs possibilités.
Mais en gros, c'est pouvoir changer dynamiquement la configuration
en un fichier, tu changes ton fichier.
Par exemple, moi je connais plutôt celui d'un-to-seabull,
où tu fais ton port, tu t'alises tes ports, tu dis c'est VDM,
tu applies ton un-to-seabull et ça change dynamiquement la configuration.
C'est ça, il faut que ça soit pilotable comme ça.
C'est pilotable, c'est pas forcément dynamique.
Moi je voulais revenir sur l'aspect dynamique,
parce que du coup, ça va dépendre de l'off-recloud qu'on a.
C'est-à-dire que si ton off-recloud, elle ne fournit pas de bar métal au client,
c'est pas forcément nécessaire.
C'est-à-dire que si tu as un command Amazon ou un exo-scale,
c'est-à-dire que tu as une machine qui est designée avec un gabarit
et que ce que tu vas donner, c'est des morceaux de cette machine,
c'est ce qu'on appelle des profils, au final, dans ces machines,
bah ton réseau sous-jacent, il ne va pas bouger,
c'est que du logiciel, qui va être sur ton hypervisor
ou sur ton stockage, qui va bouger.
Et du coup, ton réseau physique, oui, tu vas l'appliquer avec de l'ancible
ou tout autre type d'automatisation, pas importe,
mais en fait, c'est la partie intelligente,
elle sera au-dessus de ce réseau et tu ne le verras plus.
Ok, donc en gros, tu as un...
... ton, comment on appelle ça, ton underlay réseau,
il est unique, il ne bouge pas,
et l'intelligence réseau dynamique, tu l'as fait par-dessus,
c'est un petit peu encapsulé, quoi.
C'est ça, comme avec du VXLan ou d'autres technologies.
On pourrait même imaginer des zones d'ailleurs qui ne bougent pas, hein.
Enfin, tu peux...
Il y a deux manières toujours de penser quelque chose,
soit on le pense de manière dynamique et on va le mettre à jour,
sans le penser de manière mutable, quoi.
On va très bientôt te dire, bah voilà, telle zone,
elle a genre 200 serveurs,
et voilà, le jour où j'ai besoin de plus de serveurs,
bah je fais une nouvelle zone.
Ce serait même potentiellement possible,
en fait, avec un certain design, et en fait,
de se dire, bah cette zone-là, elle est au design de référence,
un, deux, trois, en fonction de l'iterration qu'on y a fait dessus,
mais ce serait tout à fait possible maintenant.
En vrai, moi là, sur le réseau, je vois, je serais déçu,
je n'ai même pas entendu parler de Sonic.
C'est vrai qu'il y a Sonic, alors je t'avoue que moi,
je n'ai jamais testé, il faut que c'est dans ma toudou de triquettes testées,
mais ça me paraît prometteur,
il faut vraiment que je le teste, que je m'exerce avec.
Sonic, on rappelle ce que c'est.
C'est un OS open source, si on peut dire ça, pour du réseau,
et du coup, on a certains hardware,
tu peux choisir ton OS et tu peux mettre Sonic dessus entre autres.
Il y a eu Cumulus qui a été racheté par Nvidia,
c'est ça, c'est Cumulus.
Oui, il y a eu ça à un moment, je crois.
Mais en fait, en gros, c'est toutes les gros switches,
slash routers, parce qu'en fait, la différence entre les deux
devient de plus en plus compliquée, monsieur.
En fait, ils arrivent avec des gros Asics,
complètement propriétaires,
sortis d'usines qui font un peu papamaman sur toutes les câbles réseaux,
et en fait, à chaque fois, ils viennent avec leur OS,
et Sonic, le but, c'est d'avoir un OS vraiment open source,
et surtout, en fait, plus que l'OS, les API,
pour faire en sorte de configurer chacun de ces Asics-là.
Et en fait, après, d'avoir une fabrique réseau,
et cette fabrique, elle va reposer sur Sonic,
donc cette fabrique tout en haut,
c'est celle où on va dire,
« telle machine, tu deviens un load balancer ».
Bon, hop, je tronque tous les ports,
et hop, tu as énormément de réseaux
pour aller de tel endroit à tel endroit.
Et donc après, le but, c'est comment piloter.
Ça, tu as parlé d'antibulles, mais voilà,
antibulles, comme disait Bart,
c'est... tu l'appelais une fois,
et puis après, bon, voilà, c'est là, c'est très très...
C'est l'instanciation, c'est pas vraiment du dynamique dedans.
Mais voilà, il y a tout le temps ce choix entre les deux,
dynamique versus sensation.
D'ailleurs, moi, je pose la question quand tu fais de l'antibull,
dans des cadres comme ça, mais c'est du cadre réseau,
mais en vrai, ça pourrait être le cadre de la configuration
de l'autofbound ou du... enfin, n'importe quoi,
qui applique?
Quel est l'élément qui...
instantie, qui lance la commande antibull?
Alors, pour l'autofbound, ça, à la main.
C'est-à-dire, c'est quelqu'un qui vient avec son laptop,
qui se branche sur un port spécifique?
Ben, à la fois, pour la première configuration,
oui, t'es obligé d'être sur place, te connecter en sérielle,
faire les premières configurations.
Tu peux pas avoir un réseau qui spawn tout seul,
une configuration qui spawnent automagiquement.
Si, c'est possible.
Tu aurais pu avoir du Laura, avec du Seekfox,
ou je sais pas.
Dans le monde de l'embarquer,
tu fournis toutes tes configurations à ton fournisseur,
à ton fabriquant, et en gros,
le switch arrive...
Ça veut dire que t'as un intégrateur, moi, je connais un intégrateur,
où littéralement, il livre les B en entière,
de pré-configuré, pré-cablé,
t'as juste à brancher ta fibre de sortie,
et tout est prêt, ça, c'est possible.
Mais ça veut dire que c'est quelqu'un d'autre qui la fait à ta place.
Mais tu as forcément,
au tout début, tu as forcément une petite main qui est passée par là
pour mettre la première configuration, la première graine
de tantres restes, ou quoi?
On a l'air sur les matériaux Cisco et autres.
On peut très bien sortir,
enfin, à l'époque, quand j'en sais,
on pouvait sortir la carte mémoire,
pré-configurer des fichets dessus,
et ensuite, bien,
recopier la carte mémoire, et puis la maître...
C'est de la clé USB aujourd'hui,
car tout le monde, à l'intérieur,
sont soudés, mais tu peux faire ça avec des clés USB,
des clés USB, fait exprès,
ou du coup, tu boutes la machine,
elle va choper ce qu'elle a de la clé USB,
et se configurer toute seule, quoi.
C'est possible.
Là, en fait, on a un mass,
les solutions de masse, on n'a pas parlé,
qu'est-ce qui existe?
Alors, en clos source, je ne sais pas trop.
En open source.
Moi, je connais Canonical Mass.
On a Tinkerbell.
On a quoi?
Ironic, des open stacks.
Je ne suis pas trop dans le...
Et puis après même, toutes les solutions
à base d'ironique, parce que Metal Cub, etc.
Metal stack,
Metal stack des Allemands,
qui font aussi ça.
Et donc, je demande, d'ailleurs, quand on parle d'ironique,
donc ironique solution de masse
dans open stack,
What's the point?
Il faut d'abord un open stack,
il me faut d'abord...
Moi, j'ai Tinkerbell, qui est ironique sur Cube.
Même combat.
C'est comme on a un premier Cube.
En fait, c'est ironique,
il a deux modes, c'est-à-dire qu'il a un mode
intégré dans open stack, où il va
consommer les API d'open stack,
Keystone, Glance, etc.
Et il a aussi un mode standalone,
c'est-à-dire qu'on l'installe tout seul,
et il est autoporté,
et on peut le configurer directement.
Ce qui permet, justement,
de faire un premier déploiement, par exemple,
sans avoir, on va dire,
à traîner toutes les brilles
qu'open stack qui sont derrière.
Ok, donc là, j'ai ce premier ironique,
on va dire, maintenant, de quoi j'ai besoin.
J'ai mon PXO,
qui marche, slash, masse, slash,
qui arrive à mettre des VLAN sur des ports.
Je sais faire ça.
Le but à la fin, c'est que j'ai des développeurs
qui arrivent à déployer leurs applications.
Est-ce que je leur donne ce PXO-là, leur donne le masse,
et je leur dis, j'ai bien peur avec,
ou qu'est-ce qu'il se passe après ?
Quelle est la deuxième étape que je vais avoir besoin
de donc ?
C'est souvent là où tu as l'oeuf et la poule,
généralement. C'est sur cette étape,
parce que quand tu vas produire ton logiciel
pour ton cloud,
tu as mieux de d'occfouder souvent.
C'est le moment où tu as produit le logiciel,
et tu n'arrives plus à revenir à cet état,
ou comment je fais quand je n'ai pas encore le logiciel.
Donc il y a plusieurs solutions.
Je n'ai pas exactement la solution que nous on utilise,
parce que je n'ai pas encore bout de strappé de zone,
mais j'ai une nouvelle idée.
La première, c'est d'utiliser une zone existante,
parce que t'existes des gens en cloud,
et tu fais une faille zone dedans,
et tu plugs ton autre zone dedans
pour commencer à bout de strappé tes hyper-viseurs.
Ton stockage, qui va se connecter
via un VPN quelconque, tu vas tricher un peu
sur les règles au début, et tu vas être obligé
à un moment,
pouvoir bout de strappé ta première stack,
où tu pourras spawner TVM.
Une sorte de clonage, en fait, un peu,
il y a une espèce de...
Oui, on va dire que c'est une sorte de clonage,
tu vas créer ta zone, mais elle ne sera pas
physiquement dans la zone au début.
Ça, c'est une technique possible,
et tu vas la consommer à distance
au travers d'un VPN entre tes deux sites
pour pouvoir justement lancer cette première phase d'init.
Ça, c'est une façon de faire.
Ce n'est pas forcément celle de tout le monde,
parce qu'il y en a qui refuse de connecter les deux sites.
Après, si vous avez d'autres solutions pour le faire,
n'hésitez pas.
Alors, chez S.A.N.S,
on utilise
plus ou moins toutes les stratégies.
Ça dépend parce qu'il y a les stratégies,
on ne peut pas en parler, mais les stratégies
qui sont utilisées en interne par Google,
où il y a un mix, un peu de tout.
Donc, comme ça, c'est très mystérieux.
Mais alors, chez nous,
donc dans notre zone, qui est la zone
manager, la zone de confiance,
on est parti du principe,
en effet, que les zones ne communiquaient pas entre elles.
On a eu l'avantage de partir de zéro.
Donc là, littéralement,
on n'avait pas une zone existante,
pour démarrer,
pour bootstraper, pour créer les racines,
pour créer plein de choses, tous les mêmes.
Pour construire les artefacts,
nous n'avions pas deux zones.
Parce que la S.A.I.,
alors c'est un choix, mais la S.A.I.
qui construit les artefacts,
qui build tous les systèmes, qui build toutes les configurations,
elle est bergée dans la zone en elle-même.
Donc, notre stratégie,
c'est de déployer, donc d'arriver en effet
avec les laptops dans les DC,
et de déployer tous les premiers composants
lors du bootstrap. Donc ça peut aller assez loin.
Ça va en effet jusqu'au IAS, je crois.
Mais ça va assez loin.
Et on déploie ces briques-là,
donc ça peut aller les VPN, les PKI,
les DNS, le IAS,
en utilisant nos laptops.
Donc c'est des laptops qui doivent être
là pour le coup intégrés
dans l'infrastructure
de sécurité. Enfin, un sécurité,
on n'est pas n'importe quel laptop, où les laptops soient validés, etc.
Mais ce sont des laptops d'admins
qu'on va utiliser pour construire
tous ces artefacts-là, les embarquer.
Alors soit on arrive avec une clé USB
ou un disque dur, parce qu'on a beaucoup, beaucoup d'artefactes,
soit on les construit à la volée
et on les pousse
sur une registrie, qui va être une registrie
l'odiponency, etc.
Et donc, une fois qu'on a tout ces artefactes-là,
on est capable de builder les premières
parties
jusqu'à arriver au point en effet
où on peut hit your own dog food
et on arrive à ne plus
se passer de... On arrive à se passer
de cette construction locale
et construire autre aire de la CIA.
Mais t'as pas des problèmes de dépendance croisée,
je sais pas, ton vault, il a besoin du DNS
mais le DNS, il a besoin du vault,
enfin, je dirais un exemple au pif.
C'est la registrie. La registrie qui a besoin d'un DNS
mais en fait, le DNS est déployé par la registrie.
Elle a besoin d'un certificat aussi.
Voilà, elle a besoin de 5 choses. Et donc là, pour le coup, c'est quoi, c'est...
Alors pour le coup, on a...
C'est très compliqué comme sujet.
C'est très compliqué parce qu'on y a
passé beaucoup, beaucoup de temps.
On avait des... On a commencé le sujet
le programme il y a 2 ans.
On dessinait des sur le tableau, des graves
de dépendance avec des bars, avec des flèches
dans tous les sens. C'était vraiment très compliqué
justement pour que ce bout de strap
là, on identifie
qu'est-ce qu'on pouvait courter
et il y a une stratégie qu'on a utilisé
qu'est-ce qu'on pouvait courter, qu'est-ce qu'il devait être fait avant
qu'est-ce qu'il devait être fait en même temps, qu'est-ce qu'on faisait à la main
qu'est-ce qu'on pouvait ne pas faire à la main
et il y a une stratégie qu'on a pu faire
et que j'aime bien, c'est des solutions étagées.
Des solutions à étage. Par exemple,
DNS, on avait une solution à étage
alors c'est pas forcément celle qu'on a retenue
2 ans après, mais elle était à l'époque
hyper séduisante. La solution
à étage c'était d'avoir un DNS low-dependency
qui ne fait quasiment rien sur lequel on va
registrer, notamment la registrie
en dur. Et ensuite
pour tout le reste, elle va aller forwarder vers
un endpoint qui n'existe pas encore, mais qui va
exister à la phase d'après. Donc c'est un DNS
qui sera hébergé dans le YAS. Et puis plus tard
une fois que les services
dynamiques de DNS avec external DNS
avec cloud DNS, enfin peu importe
le service que vous allez utiliser pour faire
l'enregistrement dynamique pour vos futurs
utilisateurs ou pour vos futurs services
ça sera dans un troisième étage.
Donc on avait un système à 2 ou 3 étages
comme ça, où on avait la stack
hyper low-dependency qui est
uniquement nécessaire lors du bootstrap low-level
une deuxième stack low-dependency
qui va aller être nécessaire pour
l'ébris, on va dire, de
un cercle 1 et puis ensuite le cercle 2
qui est pour les logiciels un petit peu plus haut niveau
et en fait tout le monde, tout le reste du DC.
Et t'as besoin de les garder à
du tam Internet ou pas ?
Il y a des cas de figure où oui,
il y a des cas de figure où non.
Par exemple le DNS,
on va le garder.
La registrie c'est
un super cas de figure parce qu'on a eu l'exemple,
on a eu l'illustration il n'y a pas très longtemps. La registrie
on est capable de sponer une registrie
juste le temps du bootstrap, avec le même
nom, un certificat qui est valide
peut-être moins longtemps parce qu'on va le
déployer à la main. Mais et ensuite
une fois que les
infrastructures sont en place, que ce soit des
infrastructures type VM ou type
conteneurs, on va pouvoir
migrer cet
en gros, c'est de la haute dispo, on va les
créer d'autres instances et puis on va les chouter
plus tard, la celles qui nous a servies
à la low-dependency. Alors
se pose la question après du disaster recovery,
c'est comment on fait, qu'est-ce qui arrive, si
le truc plus haut niveau tombe en panne
et là on a des problèmes de fait.
Par exemple la registrie qui est hébergée dans un
conteneur, elle tombe, on est
embêté, parce qu'on ne peut plus la remonter
vu qu'il n'y a plus de registrie.
Là, tu as parlé
de conteneurs,
comment faire ? Parce que là on a dit
qu'on déploie un milliard de logiciels,
sur toutes les machines, je fais
APT Get install dns,
APT Get install, c'est
quoi justement, toute cette façon
de pouvoir déployer, parce qu'en fait la stack
elle commence à devenir sympa
enfin tout déployé dans tout ce que je vais
avoir besoin, si je veux quelque chose de
sécurisé avec de la PKI, si je veux
des registries, si je veux ceci, etc.
Voilà, au niveau, au niveau, on va dire
ce que tu es en train de dire, c'est qu'il faut
un dépôt d'artefact, un dépôt de paquet
ou un dépôt d'image, enfin faut
un dépôt d'autre chose que de conteneurs.
Il y a ça et il y a même, enfin il y a même un autre point, c'est
l'orchestration. Et genre je fais ça à la main,
ça gère une orchestration manuelle au pifomètre
et je dis, machine 1 c'est
machine 1 c'est la registrie et machine 2
etc. Enfin c'est quoi justement
de quoi je vais avoir besoin justement pour
faire ces choix là.
Déjà il y a une partie orchestration
avec ma fameuse métalise de service
qui va permettre déjà de dire
bah tiens ça c'est des machines de calcul, ça c'est
des machines, enfin plus du cattle quoi, ou
des machines d'hier en botte pète
avec des choses un peu plus
rigides au-dessus on va dire.
Et déjà rien que le fait
de devoir fournir des images ou des
des artefacts, enfin
des... une description Linux
qui tourne sur les machines, c'est-à-dire
qu'il faut qu'on ait créé les images.
Enfin donc, il faut
un dépôt, entre guillemets, un dépôt d'image.
Donc option 1
qui est un peu dégueulasse et on ouvre
tout de suite par le réseau internet, on va
chercher, on va chercher sur les
dépôts, enfin nos dépôts préférés on va dire.
Option 2 c'est on fait une pré-construction
soit sur les
portables de bootstrap comme disait
le chef de la base, on va vraiment
tranquillement au bureau plusieurs semaines
avant, on crée toutes les images, toutes
les configurations un peu en mode
golden image. Et ensuite
on va déposer ça sur le stockage
du métal as de service. Et ensuite on va
pouvoir envoyer ça
sur les machines. C'est quel nom
le... le tier gap
? En fait
t'es en groupe pour que les gens puissent chercher. Cette stratégie
en fait c'est vraiment la stratégie RGAP, c'est-à-dire on
passe pas par internet, on a un flux d'air
enfin on a les deux mondes qui sont séparés
et c'est une clé USB
slash portable
slash... quelque chose en tout cas qu'on identifie
qui fait le lien entre les deux. Donc c'est souvent des stratégies en RGAP
Et l'intérêt... enfin l'intérêt du RGAP
aussi ce qui est que
qui n'arrive jamais, la double panne
mes serveurs crâment et mon axe internet avec
ben si je suis pas en RGAP
ben je suis pas capable de ressortir ma clé
USB ou mon disque dur et de réinstaller
en fait. Donc je perd du temps
à essayer de remonter mon axe internet
pour pouvoir re-télécharger mes artefacts
Donc il y a quand même une certaine sécurité
on va dire, qui peut être intéressante
Ramposé avec l'axe internet, sans tout
et cas toutes mes applications ne servent à rien.
Donc des fois... c'est
toujours le choix entre les deux stratégies
Mais il y a un gain de temps à la remonter en fait
c'est ça que on voit, c'est-à-dire
qu'on peut remonter plus vite
et donc avant une indisponibilité réduite
entre guillemets avec une solution interne
en fait.
Il y a un truc
qu'on a évoqué qu'on dessine
sans le dire
c'est qu'il y a dans cette
approche d'identification
des dépendances, on a
des choses qu'on peut faire et de choses qu'on peut pas
faire. On veut bien
que des services se dépendent entre eux
mais pas au même niveau de criticité.
On veut pas, par exemple, que tu disais
le service, je sais pas, d'installer des OS
on peut pas dépendre d'internet
parce qu'ils sont au même niveau
en termes d'installation. Donc on a des espèces
de ring, on a appelé ça des ring
mais il y a des ring dans la sécurité
il y a des ring de dépendance, c'est un peu compliqué
des fois à se comprendre, mais on a des ring
et un service à le droit de parler
de ring 1, à le droit de dépendre d'un service de ring 0
mais un service de ring 0 n'a pas le droit
de dépendre d'un autre service de ring 0. Et c'est pour ça
que déjà il faut réduire
le scope de ring 0
au minimum et il faut éviter
de mettre des trucs trop compliqués à l'intérieur
qui ont beaucoup de dépendance. Parce que
toutes ces dépendances-là dont tu vas avoir besoin
en ring 0, et c'est pas aux sargeants ce que
tu disais au début, c'est
on veut des choses extrêmement simples en DMZ
ou en DMZ sur la Out of Man
parce que ce ring 0 là, dès que vous allez avoir
une dépendance à l'intérieur, ça va être à vous de la gérer.
Vous pouvez ne compter que sur vous
et pas sur quelqu'un d'autre, et pas sur un autre service
et pas sur un autre contrat, parce que
parce qu'on est dans un stade où c'est tout est
ultra critique et il va falloir
notamment dans des scenarios disaster recovery
tout pouvoir tout reconstruire
uniquement en dépendant, enfin
en vous démerdant avec vos propres moyens.
Et donc ça dessine ces différents rings
donc on en a 2 ou 3 chez nous, je crois
on a ring 0, ring 1 et ring 2
pour différentes raisons
mais ça nous aide
à designer
cette arbre de dépendance-là.
Moi c'est bon, j'appelle ça plutôt des étages à plus t'avoir du temps
et des stages.
En fait je pense souvent au Starship, la manière dont il est fait
et le stage 0 c'est
une partie et elle bouge pas, pourtant elle reste sur place
mais le stage 0 qui va allumer les moteurs
bah voilà, c'est pour ça que j'aimais bien
cette allusion et bien sûr le stage 0
n'a pas besoin du stage 2
de la fusée qu'en fait. Et de se dire
non on a cette espèce d'étage de lancement
qui a beaucoup d'intelligence et beaucoup de choses à faire
mais en effet qui ne sert que
à démarrer dans les premiers instants
les premiers instants du lancement d'une fusée.
Voilà, j'ai plutôt cette notion
d'étage mais
Heloic, tu disais, enfin, genre
de déployer
enfin, c'est justement
vous comment vous allez essayer de
déployer tout ça, comment il tourne les services
même si au début vous avez une dépendance
à une zone entre une main
qu'elle va être, enfin c'est vraiment
c'est le choix, il se fait au hasard, il y a toujours les petits noms
Rémus Romulus pour la machine
enfin je sais pas, c'est vraiment les classiques
enfin comment va se faire le déploiement
Non, quand même pas, bon après il y a
des ID comme souvent, ça rejoint
ce qu'il était dit avant avec les Golden Image
c'est-à-dire que sur ce fameux système
de masse, nous il y a un peu plus trivial
que les masses qu'on va trouver d'habitude
on aura des Golden Image
déjà prédéfinie par rôle. On a un cloud
provider relativement simple sur la couche basse
c'est-à-dire qu'en gros, il y a du réseau
effectivement, on a du stockage
et des hyperviseurs. Donc
il y a des images pour le stockage
et pour les hyperviseurs, il y a l'OS
et pas installé dessus, ça va charger par le réseau
et ensuite via CloudInit
et du coup une interaction
avec ce système de masse
la machine connaît son rôle
et elle l'intégrerait directement
dans le data center en fait
et donc là, bon, on a une machine avec un rôle
maintenant qu'est-ce qu'on fait une fois qu'on a ce rôle
il va falloir être un peu plus intelligent
parce que c'est bien, on a des hyperviseurs mais ils font rien
et c'est là que vous avez peut-être
une réponse, moi je peux en donner mais
Non mais justement, mais ça va
là depuis tout à l'heure, j'essaye de vous faire aller vers quelque chose
et ça rejoint aussi la notion
de temps, de restauration etc.
ces machines-là, elles vont mourir
à un moment parce qu'elles n'ont pas une
vieur et vie infini donc si jamais j'ai installé
un DNS, une part, un endroit
pour un besoin, le jour
elle meurt, elle perd du le décès
en fait entre régimé, si jamais je perds
ces machines de ring 0 ou
d'étage 0, comme on dit
et donc je demande, comment je fais pour que ça n'arrive pas
ou comment je fais pour que j'ai pas ce problème
Bah déjà, il n'y a plusieurs
c'est le minimum syndical
au moins deux et après
c'est du cycle de vie matériel
peut-être que c'est cycle pour un plus s'emparer
que moi mais c'est plus classique
Oui oui mais après, bon, ton serveur
il a une durée de vie, généralement dans les entreprises
c'est 3, 5 ans en fonction des imaux
il y a plusieurs stratégies mais un des provisioning
ça se prépare autant que un provisioning
donc tu as quand même une stratégie de fin de vie
des serveurs, c'est pas juste tu vas être un de ton serveur
merci Roi, il y a quand même une vraie stratégie
de ok cette machine elle fait ça
est-ce qu'il y a des trucs importants dessus, est-ce que je dois migrer
les workloads ou ils vont se migrer tout seul
parce que j'utilise cube
enfin, on a perdu depuis un petit moment
quand même, on parlait en orchestration etc
justement, c'est genre vous
mettez les machines, vous faites Tudou APT get
install dns et puis vous prier pour le reste
de la vie du TTC
il y a un peu de ça
il y a un peu de ça malheureusement
peut-être pour un ring 0 à la limite
un ring 0 c'est un cas de composants
exactement, c'est pour ça
ok, d'accord, ring 0 à la limite
bien que je pense qu'on peut faire 100
mais bon
ça se discusent, il y a enfin des designs
il y a des designs ring 0 ou il y a du cube
mais c'est des cubes qui vont être stand alone
et tourner sur une machine qui ne seront pas clusterisés
c'est on utilise la paye cube
sur la machine parce que c'est sympa
mais uniquement sur la machine elle part pas avec ses copains
une notion
c'est un truc, on ne l'a pas fait
mais moi ça m'aurait bien plu
ok donc en gros, moi c'était tout cette notion
justement d'installation
est-ce que j'ai vraiment envie pour installer tout ça
et même pour cette notion de définition
dont on a parlé qui est
j'ai besoin d'avoir tel, tel, tel service
bah en fait cette notion de définition
de qu'est-ce qu'il doit tourner, cube c'est assez cool
donc en fait même pour ce ring 0 en fait
on peut avoir un Kubernetes qui va permettre de
définir en mononode
aller, de nodes via du déculite
c'est jamais on a envie de faire des trucs un peu marrants
des static pod n'importe quoi
oui même ça, oui des static pod
ok donc c'était ça en fait un peu vers lequel
d'essayer de vous faire aller
on peut utiliser une API déclarative
tu parles de registrie, tu m'as même pas dit comment on l'utilisait
cette registrie donc euh...
on est pas de Kubernetes
c'est Kubernetes qui va aller
tirer des choses
tu as fait docker pool à l'ancien
mais c'était aussi une chose
mais en fait c'était cette notion d'orchestration qui est dedans
si y a, bah je perds une machine
tu vois ça se prévoit à l'avant
le problème de tous ces trucs très bas niveau
c'est que les opérations sont très manuelles
les opérations d'installation sont manuelles
et puis après les opérations sont manuelles aussi
parce que bah force à forcerie
t'as installé un truc à la main, tu le manges à la main
donc c'est des trucs qui sont très coûteux
il faut les réduire à son strict minimum
c'est vraiment, et c'est un
c'est dur comme travail parce que bah y a des choix
t'as envie de mettre beaucoup de choses
mais tout ce qu'on va mettre
en ring 0 c'est un peu
comme la masse tournant dans une voiture
c'est ça fait
x10 en termes d'opération
et en termes de critisité, en termes de disaster recovery
donc l'effort de design
d'origine doit être dans
réduire au maximum ce qu'il y a là dedans
peut-être qu'on va aussi réduire le temps de parole
allouer à ce truc là mais c'est vraiment
très très très décisif
on parle de bootstrapping, c'est littéralement
exactement tout ce truc là et donc tous ces choix là
et des choses qu'on voit pas quand on est extérieur
c'est justement toutes ces choses là
sont pas visibles quand on utilise
un cloud provider
littéralement on y a passé un an quoi après ce cas c'est à définir
c'est peut-être pas un an mais pas loin
de définir ces phases là
en partant de zéro et avec un nouveau projet
et on avait pas de modèle comme on peut avoir chez Exoskel
c'est vraiment un gros travail
et donc on se dit
on a un ring 0, on a
des briques de base qui nous permettent de partir
de partir
tout à l'heure tu as parlé d'hyperviseur
genre c'est ça le truc
on a des hyperviseurs, on a des
qu'est ce qu'on va partir après
de base on parle d'hyperviseur
mais je dirais plus on a des nodes calculs
donc c'est à dire qu'on a des
nodes Kubernetes de manière
générique et ensuite
on lance
les pots de convœu
c'est à dire que
ça dépend
c'est très lié aussi à mon étude de risque
c'est à dire que
est-ce que je suis dans un environnement critique
est-ce que j'ai des workloads de confiance
entre guillemets
est-ce que je peux me permettre de les faire tourner directement
sur du matériel ou est-ce que je dois faire
l'AVM, du firecracker ou autre
donc en fait ce qu'il y a c'est que
le workload client qui va tourner
il faut qu'on décide comment on va le faire tourner
donc est-ce que on peut
est-ce qu'on
est-ce qu'on doit faire
est-ce qu'on peut par exemple faire du mutualiser
donc c'est à dire que tout mes clients
ont un niveau de sécurité équivalent
donc je suis dans une zone homogène
partir de là très bien
on va dire je peux
déclarer d'une MSpace en direct sur mes nodes
de bernet metal et puis
les clients
des pods et des pods à leurs applis
ou est-ce que je suis dans un modèle segmenté
où j'ai des applications internet
qui risquent de se faire attaquer
avec à côté des réseaux intranets
qui n'a pas vocation à aller sur internet
avec des applications un peu critiques
donc là il y a plusieurs stratégies
c'est à dire que soit je vais dédié
des nœuds physiques
donc avec des labels etc
pour déployer les bons pods
ou est-ce que je me dis que j'ai une couche
unique
à partir de là je vais lancer
par exemple dans
de la micro vm ou dans des kvm
ou des kvm
les workloads clients
donc là c'est des stratégies qui sont différentes en fait
ça dépend, ça c'est un choix structurant
qui a aussi un impact
aussi sur les coûts
parce que si on segment trop
on a un besoin en matériel
qui est plus important
donc c'est à dire qu'on aura une offre
entre guillemets haut de gamme
parce que sécurisé mais plus cher
donc après il faut voir aussi sur quel segment
on va attaquer en fait
au niveau de nos clients
il y a même ça et même le Kubernetes
bare metal c'est marrant
mais il y a plein de choses qui vont être compliquées
à implémenter aussi bien
on parle du storage, des choses comme ça
je vais être hyper convergé avec un storage
à l'intérieur du même cluster Kubernetes
mais voilà c'est ça en fait la question
et c'est pour ça que personnellement
je ne pense pas qu'à cet étage là
que Kubernetes soit un bon choix
parce que Kubernetes en fait est en fait pour être
clown native historiquement
il veut des API autour et sans que ces API
tu les as pas donc en fait là pour le coup on arrive dans les faits de fête pool
que Kubernetes a envie d'avoir des API
que Kubernetes et pas les API clown native
ça dépend
alors je dirais on a parlé tout début de
ironique qui était en mode stand alone
ou en mode open stack
l'intérêt
enfin qu'on peut faire
l'intérêt d'avoir ironique dans un environnement
open stack c'est-à-dire c'est qu'on peut
déployer les machines physiques
comme si c'était des instances virtuelles
avec driver nova
ce qui permet d'utiliser
des machines physiques comme si c'était
des DVM mais avec tout l'écosystème
OpenStack autour
donc le sider pour le storage
par exemple ou bien toute la partie
neutron pour le réseau
donc on va dire que Kubernetes seul
ça tient pas la route
on va au bouton partir sur un produit qui fait ça très bien
il y en a plein sur le marché
c'est quoi le plan justement ?
je dirais
tu mets ça un proxbox
j'aurais plutôt dixen
ça peut être du Xen
enfin xcpng
ça peut être de lincus
ou lxd
on peut toujours mettre du VMware, du Nutanix
si on aime ça
ou mettre de l'oxide directement
pour avoir un truc qui marche bien
mais ce qu'il y a c'est qu'il faut
il y a juste OpenStack
OpenStack c'est déjà bien
non mais c'était l'éléphant dans la pièce
et OpenStack parle d'oxide
si vous êtes client ou potentiel client français
de chez Oxide
contactez nous
vous plaît
on veut tester
on a envie
si on a un qui a déjà acheté du Oxide en France
et en plus on veut vous entendre
on va vous entendre
donc en gros
la conclusion c'est qu'il faut
des produits autour
là on est à l'étage
il faut construire des produits
on a besoin d'avoir cette espèce de couche intelligente
intelligente
par exemple chez Exoskelle
cette espèce de couche vous avez des services
on va tricher
pour arriver à la destination
mais c'est là où on a
cette fausse zone dans une autre zone
où on a un Kubernetes
où il y a les orchestrateurs
et donc toutes ces brides de base élémentaires
qui sont dans la nouvelle zone qu'on est en train de créer
on peut les orchestrer et lancer la hierce
donc effectivement on a pris un short cut
très violent et on arrive directement à la cible
on a une obritte qu'on s'est déjà créé dvm
et ensuite une fois qu'on s'est créé dvm
il suffit
j'ai jamais vu la création de nouvelles zones
mais d'étendre le Kubernetes
de la fausse zone de Bootstrap
vers physiquement la nouvelle zone
et du coup on migre tout là-bas directement
du coup ça va entre guillemets très vite
puisque une fois qu'on a des hyperviseurs
sur les deux zones qu'on a virtuellement mis comme une seule zone
il suffit juste de tout migrer
et puis après on a fini de terminer
il est bar métal ou c'est lui qui fait tourner les hyperviseurs
il est virtuel il est sur la hierce
donc effectivement il y a un effet de fait de bootstrap
c'est pour ça qu'on a besoin d'une autre zone
ok et donc oui parce que le yas lui il est auto portant
c'est ça
tout à fait en fait toute la couche
orchestration dans l'offre de service qu'on a
elle tourne sur Kubernetes
il y a effectivement ce phénomène de fait de pool
mais l'orchestrateur de la yas est dedans
l'orchestrateur des cubes clients est dedans
c'est le seul Kubernetes d'ailleurs
qui n'est pas en de foudé
en fait le Kubernetes c'est dans le yas mais il pilote le yas
c'est ça
ok c'est dvm ok
c'est dvm classique comme tout le monde en fait
et là où matieu parlait de
de segmentation
bah non on a pas de segmentation
donc en fait si il y a un impact sur un hyperviseur
nous aussi on peut être impacté parce qu'on est dans la même
infrastructure tout le monde en fait
on a pas cette volonté de sécurité extrême
comme vous pouvez avoir chez sens
quand même un SDN, des vpc
des choses pour isoler
alors on a pas tout à fait des vpc on est juste en dessous
en termes de réseau mais effectivement il y a du privnette
et donc on est bien isolé
virtuellement de nos clients
mais c'est le pilotage qui est fait
niveau de l'orchestrateur qui dit bon
ben tel vm t'es dans
tel réseau et isolé de tel autre
c'est globalement du vxlan
avec du privnette donc il y a une couche
un peu spécifique mais on n'est pas beaucoup
différent dans notre zone de confiance
on a un orchestrateur donc qui est bootstrappé
lors de ces phases là ring 0 ring 1
et avec la registrie
et après en effet
c'est cet orchestrateur de vm là
qu'on quai basé sur cube
c'est du cube virt
on en avait assez parlé pour ça
on est à retour mais la solution
comment ça a de venir de plus en plus matieu
ça approche de la v1 s'il n'y avait pas déjà sorti
ça fait l'amour
ça fait l'amour
ça a sorti la v1
elle est sorti c'était je crois
donc c'est en cours
une fois qu'on a ça on a notre sdn
qui est directement embarqué donc les vm on les branche
dynamiquement on utilise plus
Thunderlay en physique
on passe directement au vxlan partout
et voilà quoi
on a des vm, des vxlan
on orchestre tout, on a même une isolation physique
pour différentes raisons entre deux catégories de machine
mais qu'on fait via des labels
et c'est terminé
on a un contrôle plane de vm
sur lequel on va pouvoir déployer notre stack
de Kubernetes as a service
et donc là justement
on arrive à ce point là
donc en gros là on arrive au point où on a des vm
on arrive à se donner des vm
on fait quoi pour tous les services justement
à haute valeur ajoutée qui vont être par dessus
donc tous les db as a service
lh machin as a service
tous ces trucs là
vous les mettez dans le Kubernetes
ou est-ce qu'on va précreer d'autres Kubernetes
au dessus des Kubernetes
ça va être à quel niveau
on a fait un gros raccourci aussi on n'a pas du tout parlé du stockage
on a parlé des notes, des cut
on peut faire 5 minutes
sur le stockage
ça intéresse quand même
ça veut dire que
le stockage on le met au même niveau que le compieu
il est pour moi oui
moi aussi mais j'étais pour valider ça
j'ai presque envie de dire qu'on met avant
parce que
dans le stockage il y a le stockage block
il y a aussi le stockage object
en général c'est là où on met
nos artefacts, nos softguards
donc avant même de déployer
du serveur de calcul
il faut
déployer la solution de stockage
là où les solutions de stockage
parce que quand on ne serait-ce que de déployer un os
ça va se reposer sur un stockage
donc c'est important
de déployer le stockage
avant même les serveurs de calcul
oui on avait dit qu'on n'a pas de dépendance
au sein du même ring
c'est plutôt un stockage qui est au niveau du ring 0
donc potentiellement il y a 2 stockages, 1 ring 0
pour déployer le ring 1
pour moi en ring 0 il faut faire le maximum de choses
qui sont staites les, des ns
si ton ring 1 a besoin de stockage
il va le déployer
t'as dit qu'en ring 1
il faut pas le déployer
je suis d'accord
mais là il faut faire des exceptions
des exceptions au ring
c'est comme ça que ça commence
non mais oui bien sûr
il va y avoir des choses à faire
à ce niveau-là
et donc stockage on parle de quoi
quand on parle de stockage et qu'est-ce qu'on va mettre en place
la grande question
ça dépend
il dépend beaucoup des contextes
il dépend de quoi
il m'en limite juste de ton argent
et si t'as des coups ou pas
c'est un peu plus complexe que ça
c'est-à-dire qu'on arrive
dans une salle qui vide
moi le premier effet que j'ai
c'est je regarde combien j'ai d'arrivée électrique
comment j'ai urbanisé mon data center
t'as l'élicité que tu veux
le fiber channel
le fiber channel que tu veux
fiber channel
t'as ce que tu veux
la climatisation elle est à fond
le planter il va pas s'effondrer
vraiment t'es dans le meilleur décat
t'as pas ces contraintes là
oui donc dans le meilleur décat
on va éviter
enfin on va plutôt choisir
des solutions un peu scale out
enfin avec du stockage distribué
sur des nœuds dédiés
un peu à la cèfle par exemple
donc voilà
je vais éviter la bonne grosse
b de stockage
en réplication
plutôt partir sur du
software defined storage
pour pouvoir justement garder de la
pays, garder du pilotage, garder de la résilience
c'est vraiment un choix
parce qu'on peut reprendre l'exemple de critéo
qui se vente
d'avoir des performances
over the top
et donc du ce fait
utilise du stockage local
il n'y a pas de b de stockage
jusqu'à CTI assiste 8 ans ça peut changer
il n'y avait pas de VM donc on était sur du bère métal
c'était une stratégie
une stratégie produit liée aux objectifs de performance
oui mais c'est à dire que si on était
limité au ring 1
c'est tout
c'est parce que ton cas d'usage métier
c'était sûrement faire tourner des batchs
avec du stockage effets mère locale
et dès que le résultat était fait
ça envoyait dans la même silence
il y avait des elastic charge
il y avait des cassandres et du adoup
la réplication est applicative
exactement
donc on n'avait plus besoin
de stockage volume
volume block ou volume s3
qui était répliqué à cette échelle là
d'ailleurs on a demandé
le stockage s3
parce que justement le stockage objet
tu le fais pas
local
ça sert à rien
j'ai un fichier à tel endroit
il n'y a pas de solution
qui font du stockage s3
sous un modèle distribué
comme on peut retrouver avec cassandre
ou elastic search
nativement
mais c'était 6 ans
il y a des solutions
avec des solutions distribuées
parce que le s3f va utiliser un disque local
et après il a maniens
dont il l'expose en réseau
à d'autres
on a même pas parlé de rook
ou de choses comme ça
on arrive sur comment
on manège tous ces trucs
parce qu'on accumule
on accumule
et la complexité se fait dans le nombre de choses
qu'on doit manager
et les limites humaines
c'est un peu parfait, il y a les deux
parce que si j'ai 10 000 choses mais qui se mangent tout seul
c'est différent de avoir 10 choses
ou je suis obligé de les pieds pomponner
et encore une fois
ça prend du temps de designer ces choses
parce que non seulement faut designer la stratégie
distribuer, pas distribuer la technique
gérer les différents rignes de dependency
mais aussi gérer
les disasters recovery mais faut aussi
penser l'opérationnel
et penser l'opérationnel ça se fait en mode
je ne dois pas intervenir
ou au minimum si j'interviens
c'est que c'est déjà trop tard
sur mes infrastructures
et c'est là où on passe beaucoup de temps
et tout le monde le sait je pense parmi
autour de la table et parmi les oligeteurs
que les opérations ça prend du temps
et encore pire quand ça a mal été
industrialisé, automatisé
et c'est hyper coûteux
en temps de cerveau, en projection
et en effort, en effort de travail
et en plus un point important
c'est que tu te reposes sur les SLL
de la couche du dessous
si jamais tu as eu un problème et que tu as fait
un mauvais design de réseau de quoi que ce soit
et ben tu te le tapes sur toutes les couches
en fait qui seront au-dessus
c'est un problème de design que tu vas conserver
et qui aura un impact tout du long
de la chaîne dessus
et justement quand on commence à créer des services
ça a haute valeur à ajouter
donc c'est services à haute valeur à ajouter
on les met au même niveau, on les met au-dessus
on les met... on les fait comment
donc là maintenant on parle donc on a le stockage
on a les volumes
enfin voilà on a les volumes, on a le compute
donc je peux spawner dvm
j'ai du stockage
j'ai un réseau pilotable
magiquement, voilà
je donne ça directement au client
je fais autre chose
ça dépend de l'offre qu'on a
encore une fois l'offre typique interne, critéo
c'est pas la même que celle exostelle
qui n'est pas la même que celle que chez Sans
qui n'est pas la même que celle que Cicille
rencontre chez tous ces clients
donc on peut s'arrêter des fois ici
et c'est bien parce que les clients
on leur vend de la VM
ou on leur vend du bair metal
ou c'est ce qu'ils utilisent en interne
vendre au sens même interne
exactement, vendre au sens utilisateur
au sens client
maintenant moi je pense que si on veut
une stack qui est opérable
et qui est industrialisée
il faut qu'on ait des automatismes en place
donc il faut mettre en place par exemple
vous allez créer un cluster Cassandra
vous allez pas prendre une VM et installer
un PtGate install Cassandra
non, il va falloir mettre en place
une brique qui va aller générer
des configurations, générer des clusters
avoir un inventaire
pas un inventaire de machine cette fois-ci mais un inventaire de cluster Cassandra
les bootstraps
les suivre, les monitorer
les exploser des métriques
les suivre leur lifecycle, je sais pas générer leurs certificats
s'il y a des certificats
donc ils vont s'appuyer sur toutes les briques existantes
et c'est là où on va avoir des notions de contrat
qui vont apparaître, contrat d'API
ou des conventions, peu importe
ça dépend quand on a notre niveau de proximité
avec les équipes
une fois qu'on a ce control plane là, on le laisse tourner
en gros le travail n'est plus dans l'administration
dans la réflexion, il est dans
comment on opère ce control plane
et je pense que c'est l'approche de tous les cloud provider aujourd'hui
lié à leur taille, lié à leur dimension
et puis au nombre de personnes qui travaillent sur les sujets
c'est de tout
découpler et d'interfacer
oh là je me tourne vers mon bois
qui va pouvoir nous dire
comment les choses sont découplées
est-ce que tu as cette notion, cette approche de control plane first
chez exhaust cage
je suis pas sûr d'avoir tout suivi
parce que tu avais l'air de parler du neuf produit
pour les clients autant de Cassandra
oui par exemple, mais ça fait des clients interne
et encore une fois c'est peut-être
il est chez mon équipe de SRE à gauche
qui doit stocker des trachets de données
on n'est pas très gros, on est 80
donc effectivement il y a des équipes
plus ou moins produits on va dire
qui sont spécialisés et qui vont fournir
un différent type d'off qui sont
à la fois interne et externe dans
une bonne partie des cas
on n'a pas non plus un catalogue à la WS
donc ça va être plus simple
mais globalement
déjà tu parlais tout à l'heure de tout ce qui était
à streinte monitoring donc on a une équipe
qui est orientée sur cette partie-là
et ça c'est pas forcément un off
que tu fournis à tes clients parce que c'est celle qui va te coûter très cher
à opérer donc ça ça va dépendre de l'échelle
que tu vas avoir
et tu vas t'appuyer sur elle déjà pour
toutes les opérations courantes puisqu'il va falloir envoyer
tes logs, envoyer tes maîtrisques etc
donc c'est une des premières choses à bout de strapé
juste quand tu commences
à être mature on parle pas d'une nouvelle entreprise
dans une zone c'est de bout de strapé
toute cette partie observabilité
parce que tu vas en besoin
de voir des insights en fait
et ensuite t'as d'autres équipes donc chez nous
on a des équipes qui sont plus
orientées sur la partie AYAS
qui vont être spécialisées dans l'évolution du produit
qui vont gérer la partie data center etc
et le lifecycle en dessous
elles sont un peu hybrides sur les deux
et on a des équipes plutôt plateformes comme la mienne par exemple
où là on va fournir une off
par exemple Kubernetes à The Service
donc l'idée c'est de produire un orchestrateur
qui est basé sur du logiciel
et qui va être hébergé dans le cube de la plateforme
pour fournir ces nouveaux produits
je suis pas sûr d'avoir complètement
un cerner jusqu'où tu voulais aller mais
pour moi tu parles de découpage
produit et de comment tu montes des équipes
exactement je parlais aussi des contrôles Plane
c'est à dire comment ton
quel que soit en fait je parlais de Cassandra
mais quelle que soit la solution que tu déploies
comment tu penses l'administrer
par exemple si on reprend l'exemple
de ces sites tout à l'heure
si tu déploies avec de l'Enciple
c'est bien mais en gros ton contrôle Plane
ça devient enfin ton contrôle Plane
ton intelligence ça devient
la personne
ou la CIA qui déclenche
ce job en cible
sous quel contexte
quel est le déclenchement, quel est le trigger
de ce job en cible
parce qu'il est manuel, est-ce que c'est un déclenchement
lié à une alerte
lié à une panne
ou est-ce que c'est un déclenchement lié à un nouveau comite
et c'est ça pour mal control Plane
l'intelligence c'est à quel moment
je rétablis une situation
ou suite à une détection ou suite à n'importe quoi
qui est pas normal et je relance
cette volonté
qui est d'appliquer
ou d'avoir un résultat lié
à une base de données
ou des clusters, whatever
là tu parles de processus de remédiation
oui mais pour moi ça va te perdre avec le processus
de bootstrapping en vrai
parce que arriver à un certain niveau de manurité
quand on est sorti des couches basses
en gros il y a plus de différence
entre manager une solution day to day
remédier
aux incidents, réparer
reconstruire une réplication
et déployer un nouveau cluster
ou déployer une nouvelle instance de la solution
que tu manges
alors là je pense qu'il n'y a pas forcément de solution idéale
il va falloir cumuler à la fois
l'automatique
avec pour un analogie au réconciliore
Kubernetes ou tu implémente une logique logicielle
qui va dire, sur toute situation
que je connais, je dois aller de l'état A
à l'état B, C etc
donc là c'est toute la partie automatique
pour éviter d'être embêté etc
les systèmes converges et ils arrivent à autoraisous de les problèmes
néanmoins
c'est du logiciel produit par demain, c'est pas infaillible
et il y a des cas à la marge
et c'est là où tu vas mettre en place des runbooks
dans ces runbooks tu dois
que t'acquires souvent par l'expérience
tu peux pas day one dire
il nous faut tous ces runbooks
si tu le sais day one c'est que théoriquement
tu arrives à le produire de manière logicielle
les runbooks c'est plutôt
j'étais embêté telle nuit, il y a eu tel cas
et ça me coûte tant à l'implémentant
de logiciel où je ne peux pas
soit tu l'automatises, soit ça fait partie
d'un process que tu vas mettre en place
donc je pense que c'est plutôt vers ça
que tu voulais aller c'est ça
moi je suis intéressé
de la vie de Cécile parce que là on parle
vraiment de manière
de manière très haut niveau
très un peu ésotérique de tous ces trucs-là
quand tu vas chez des clients qui ne sont pas forcément
de la taille d'exoskelle
ou des petites infrastructures
est-ce que tu sens qu'ils vont
cette volonté d'approcher la problématique
du contrôle plein ou alors
ils s'en fichent, ils sont arrivés par le résultat
et peu importe la manière, peu importe
l'intelligence ou la non-intelligence
il faut le résultat
je vais te raconter un de mes clients
c'est le plus simple que je peux montrer, le client que j'ai sur cube
et grâce à lui j'apprends le cube
en gros c'est un client qui fait de liaille
et il m'a demandé de lui
trouver un ATASENTER pour mettre des machines
avec des cartes graphiques, donc
grosse consommation, enfin voilà
des machines dji qui consomment
3000W d'unité
donc il fallait trouver 2B
donc grosse consommation, donc 10W
au total
il avait déjà son logiciel, il tournait sur Azure
Azure c'était trop cher, il voulait se mettre en propre
c'était un peu seul contexte
donc bref on a fait le choix des machines
donc choisir les points de cartes graphiques pour le bon utilisation
choisir le bon ATASENTER
qui n'est pas autorisé d'avoir des grosses cautions
parce que c'est pas de la consommation standard
c'est bien au dessus de ce qui se fait classiquement
au niveau de consommation par B
bref je vous passe l'installation
le râcage, la configuration réseau
je vais passer mes quelques journées là-bas
et en fait lui sa philosophie c'est
du serveur jetable entre guillemets
en gros il a son control plane
ouai, sur AWS
quand on rentre les machines moi j'installe
Ubuntu et on a un script
qui est répété en salle tel scale
4-3s et ça va le script
il va rejoindre le cluster directement tout seul
et la philosophie de lui
c'est que même si il perd le serveur
c'est pas super grave
le workload il va aller ailleurs
c'est vraiment ça la philosophie
c'est vraiment très très simple juste on installe
cette philosophie là en fait elle a un nom
c'est ledge, c'est littéralement ledge computing
dessus c'est en fait t'as ton control plane
dans un endroit un peu managé
tranquille et qui va pas trop bouger
puis le jour où tu changes de provider
tu prends ton rack, tu le mets ailleurs
ça va marcher pareil, tant que t'as un accès interroger
justement le but c'est de pouvoir rajouter des machines
à la voler super facilement
parce qu'en connait le process on commence à les voler
on a essayé de faire le même déploiement
que je n'ai pas géré qu'ils ont essayé de les aller tout seul
ils ont mal maché ma chose des machines
le pressataire réseau il a fait n'importe quoi
et du coup on a des clusters qui ne marchent pas
et qui s'envraquent à 24
surtout s'il est besoin de la base des pavones
ce sont pas classiques
et c'est vrai que dès qu'on parle d'être computing
parce que là vous êtes dans le cas extrêmement bien
où les flux réseaux sont pas très importants
c'est pour ça que tu fais un fait de scale
on s'en fiche complètement
c'est le run local parce que tes jobs vont mettre
plusieurs heures consommer je sais pas combien
je sais pas mais quelques minutes
ça veut dire que c'est le run local qui coûte cher
et pas tellement le réseau alors que
dans d'autres cas
ça c'est un cas classique
assez cool avec l'edge où tu vas pouvoir choisir
un endroit où c'est pas cher
que ce soit chez ton CSP donc cloud provider
ou si tu le fais
même quand ils ont testé le logiciel leur premier développement
c'était DPC à la maison
reliant Telscale et ils faisaient le progrès
c'est comme ça que ça commençait leur logiciel en fait
c'était DPC reliant Telscale avec des 9090
et puis ils tournaient ça commençait comme ça
c'est une quoi qui devrait être content les premiers
sur le toit Telscale natif
parce que c'était du Schlag network
j'aime bien parler de Schlag network
en Telscale c'est le roi pour ça
pour faire des trucs
c'est génial pour connecter
tous tes meurtres de Nities ensemble
c'est super simple
tu n'as pas de question de réseau
ça peut être n'importe quel réseau
ça pourrait être ton e-fi à la maison
ça pourrait être une connexion wifi pourrie dans un aéroport
ça passe tout par Telscale
le processus c'est le même de partout
c'est vraiment reproductible et c'est ça que j'adore dans ce cas-là
depuis que j'ai découvert Telscale
je suis un peu accro
j'en rêve d'en mettre partout
dès que je suis en archi je vais en mettre
enfin c'est vrai que c'est vraiment
l'overlay network qui chiffre
et c'est super médiat
on pourrait interroger
n'importe quelle technoréa
qui va dire à Telscale c'est juste du wireguard
non la force de Telscale
c'est pas juste wireguard
c'est le contrôle plane
qui est derrière
c'est vraiment
le noeud centralisateur
qui permet de
manager les gens
et les gens ne communiquent
ensuite plus avec ce machin-là
mais communique entre eux ça fait un réseau méché
mais lui c'est le coordinateur
oui c'est un wireguard
c'est tout le service qui fait que Telscale c'est bien
ça ne faut pas juste se dire
on va faire 3 tunnels wireguard
ça va marcher, si vous avez que 3 machines
mais le but du jeu
3 machines qui ne vont pas bouger
puis aussi la simplicité
de rajouter un oeuf à Telscale
même wireguard c'est un peu...
on va faire Telscale login
il faut enlever l'expiration
il y a des petites subtilités
ce qui est intéressant aussi c'est que c'est relié
à tous les providers d'identité du marché
donc ça veut dire que nominativement
déjà je peux me connecter
avec mon petit portable
mais nominativement je peux
déclarer une machine un serveur
donc il y a aussi un peu le côté zéro trust
avec on sait qui a fait quoi
où et quand et on connait la machine
on connait l'identité de la machine
donc là on s'approche un peu du futur
maintenant on arrive à la fin
du bout de trapping
même il y a un moment quand on commence à avoir du wireguard
c'est le moment qui est gagné
est-ce qu'on pourrait même
en débémber des BMC de mains qui ont du Telscale ?
ça serait bien
en vrai de vrai
ça pourrait être complet en cas
comme ça au lieu d'avoir cette logique
parce qu'on a commencé en parlant des vélanes
de ces morts avec plein de choses
des caps qu'il faut brancher etc
est-ce que je pourrais pas dire
je branche tout au même endroit
réseau à plat mais genre plat plat plat plat plat
et après du Telscale partout
du coup tu te dirais ton réseau avec les policiers
directement comme un islène
parce que Telscale c'est un produit
qui est presque open source
il y a une implémentation
d'une telscale
d'une telscale
mais justement est-ce qu'on pourrait pas dire
de faire des réseaux à plat
et de se simplifier
complètement et que le hardware
et Oxalide
Oxalé
Oxalé ils ont pas le but de faire
ce genre de choses parce que c'est un peu la philosophie
du je montre le plus vite possible
en... j'ai pas suivi pour le coup
non mais ça pourrait être
ce genre de choses là pour dire en fait c'est ring 0
il est directement implémenté assez vite
de manière hard
sur des machines dans une BMC
et ça t'évite
tu pourrais très bien voir ça
le problème de ce paradigme
c'est que c'est tellement disruptif
que tu vas perdre tous les ressources ici de la planète
quoi
non mais attends on les a perdu avec Linux
on les a perdu avec Kubernetes
on les a perdu depuis très longtemps
en vrai
c'est qu'on s'en accorde
mais voilà c'est peut-être la chose
et moi je suis ultra fan
des réseaux à plat
de toute façon moi mon réseau de BMC
ça devrait être du wifi
ça passe tout le temps
et t'as un port wifi
voire même du l'ORA si jamais il faut
mais pour moi c'est ce genre de choses là vers lequel giraient
en fait avec des réseaux physiques
lourds d'infrastructures
et après
la route de monde c'est du wifi
la puce 5G puis Vastac
oui la puce 5G dedans
voire même je sais que au dernier fernog
il y avait des gens qui faisaient des antennes 5G locales
dans Data Center
et 5G qui tourne sur Kubernetes
donc il y a un effet de fête poule
qui fait tourner la 5G etc
mais on pourrait très bien avoir ce genre de choses
avec des choses où vraiment
on serait dans le péts absolu
enfin dans le co-absolu
qui est ce cattle où
le serveur est sorti
d'usine avec un truc où il était déjà
pour potentiellement connecter réseaux et après je l'ai branché
juste parce qu'il est un endroit
il s'auto-découvre et il fait des choses
de même pu avoir
tu pourrais même demander à n'importe qui
de dire on va voilà le câble rouge de câble bleu
c'est bébé qui a branché et hop après il y a tout qui
il y a tout qui se fait tout seul via des auto-configuration
à distance
sur des réseaux sur Phil
c'est un peu le but de Hoxag et d'infiner
c'est tout API tout configuré par API
mais je pense même que ça pourrait même être des API à distance
et je parlais de Sickfox mais ça pourrait être
ce genre de choses là
c'est un point qu'on n'a pas beaucoup appuyé c'est
les relations entre les différentes briques
par exemple on va avoir la brique de masse
avec la brique d'Oyas
avec n'importe quel brique
qui va l'exploiter
pour l'élastique du casse-endra du casse
tout ce truc là
en général quand on arrive
à ce stade là de l'entreprise
et qu'on a dépensé une année
une année et demi ou plus
à designer et à construire ce truc là
et à commencer à bâtir le bâtir de rien
le temps il se compresse
et on a plus beaucoup le temps
c'est valable pour les projets de bootstrap
mais pour n'importe quel projet logiciel
on a plus beaucoup le temps
de passer autant de temps sur ces briques
donc on se met à les exploiter
les exploiter et on ne pense pas
à définir
où on ne pense pas, où la technologie ne le permet pas
parce qu'il faudrait redéployer
quelque chose d'un wrapeur autour
on ne pense pas exploiter ces interfaces
et à définir des contrats entre les briques
et là la force de OXIDE
c'est qu'ils livrent une solution
all-in-one qui a tout
du firmware jusqu'à la VM
quasiment ils ne font pas encore le container
ça reviendra
mais surtout tout est épaisifié
alors que dans sa petite entreprise
en général on va épaisifier la fin
parce que la Kubernetes c'est facile
si on fait de l'open stack
on va bénéficier de la paye open stack
et dès qu'on va arriver il va y avoir une rupture
brute pour
manager les briques dans le sous
l'inventaire ça va être le bordel, le mass
ça dépend du mass mais ça peut être le bordel
le SDN c'est le bordel
et donc on arrive dans une situation
où les stacks sont hyper matures d'un côté
et ne sont plus matures de l'autre
et au moment de la construction on n'a pas pensé
à se dire putain comment
au lieu de faire un comide dans guide
pour demander un réseau
ou demander je ne sais pas quoi
est-ce que je vais pas mettre un control plane
un service qui va aller consommer
des API
ou qui va aller consommer une déclaration dynamiquement
pour que mes utilisateurs
puissent commencer à bâtir un truc intelligent
et c'est là où on va se heurter au limite du bootstrap
qui en fait vont rester
pendant 5, 10, 15 ans
le temps de la vie du produit et le temps de la vie
de son infra
Est-ce que ces passages sont la définition de la différence
sur dev et ops c'est l'ops c'est celui qui gère le bootstrap
une fois que ça a été fait
qui maintient ce qui a été là
au début du bootstrapping
à coup de scotch et de...
Moi je regrette ça fait 20 ans que je bosse bientôt
J'ai jamais vu
une entreprise où je suis passé
qui se transforme radicalement
qui transforme son essi
j'ai toujours passé
et je suis resté des fois 5 ans dans des boîtes
dans des boîtes où on est
de rêver par l'existent
et cette notion de transformation est très très dure
à appréhender déjà dans une entreprise
mature je sais pas si
côté exoscal ils ont déjà mené à bien des transformations
complètes du
du process en fait de production et de l'architecture
mais moi je l'ai jamais vécu
et je sais pas si je vais le voir un jour
exoscal existe avant kubernetes
c'est sûr
donc il y a forcément eu des changements
dans un point de vue temporaire
le fait que maintenant leur solution tourne sur kube
ça va être qu'il y a un moment où ça tournait avant kube
oui est-ce que tu as un exemple ?
j'ai pas l'exemple pour exoscal mais j'étais chez vipi avant
et typiquement le essi entre le moment où je suis arrivé
et encore on était en milieu de projet
et le moment où je suis parti il n'avait rien à voir
au début c'était de la vm
demander à la main ou via du terrain forme
qui est par terre
et puis à la fin on avait toute notre
ias pilotable complet avec plus
du kubernetes, managé etc
donc là on a fait une vraie transformation
de essi complète en fait
on avait énormément d'applices
ou windows qui sont passées sous linux
dans kube et tout
et même sur les machines basses, sur les couches basses également ?
les couches basses, il y a eu un recyclage de hardware
mais c'est passé de vmware du coup
de la ias sans lib vire
donc un changement radical ?
oui un changement radical
avec des paradigmes de vm
qui reste parce que mon vmware
avait un lib vire, avec des changements
c'est important
c'est juste pas une chance alors
ça viendra
c'est vrai que dans mon analogie
que je voulais faire avec les apps
ça reste quand même un domaine où
on a parlé d'ailleurs de haute valeur ajoutée
quand on est au-dessus
changer de passé de vmware
à un quelque chose de lib vire
pour quelqu'un au-dessus qui vend
en le cas de vp
des fringues et des choses comme ça
le gain en valeur ajoutée immédiat
faut un peu de temps avant de convaincre
et dans le cas de vp pour avoir un peu vécu
oui en effet il a fallu beaucoup de temps pour convaincre
de changer les choses
est-ce que c'est ça aussi ?
le temps c'est qu'il y a un moment où on arrive avec
cette dette devient tellement importante
que oui elle a un atrait de changer l'un d'entre nous
mais c'est rarement le cas parce que
ça marche quoi
tu mets plus d'ops
et on était chez Crétheo
on sait très bien il y a plein de boîtes qui
quand elles ont beaucoup d'argent préfère ajouter
des hommes que ce qu'on appelle
le meek cloud
c'est du meek cloud quoi en fait tu mets plus de gens
c'est du cloud à viande et hop là tu mets des gens et ça gère
et ça gère et ça gère et ça gère
et c'est pas une question de dit de tridio c'est que quand tu as de l'argent
tu peux gérer les choses de manière différente t'as pas besoin de te reposer
des questions là-dessus c'est pas une question de dis-dios
c'est un choix rationnel de
tu changes une technologie qui marche
mais qui marche avec plein de gens
tu rajoutes 20% de pouce
ou tu as un risque de changer vers quelque chose
tu n'es pas sûr que ça fonctionne
des fois il vaut mieux mettre plus de gens à gérer le truc
mais c'est le cas de Crétheo
c'est le cas de ce que j'ai entendu
d'AWS ou de projets comme ça
ou c'est des armées mexicaines pour gérer certains produits
mais ce truc de l'argent
tu as aussi en ce moment avec l'exote de Vmware
tu as des gens qui, tout le monde a entendu
du Vmware qui au moins avait pris
il y a des entreprises qui se posent la question
est-ce que c'est mieux de foutre de l'argent
en ce temps dans les licences de Vmware
et au moins je sais que je suis tranquille c'est du Vmware
ou est-ce que je me risque à faire une migration
vers autre chose, vers XCPNG, vers Protismans, vers Bonneveur
qui va coûter peut-être différemment
parce que au lieu de payer la licence
je vais payer du temps humain, je vais payer de la prestage, de l'accompagnement
je vais payer de la licence aussi
de l'autre côté mais moins cher
et ça c'est aussi des questions de boîte qu'elle peut avoir
est-ce que c'est plus simple de donner 20 millions
que peut-être ça coûtera moins cher de migrer
mais il faut aimer le goût du risque
il faut aimer l'inconnu
donc c'est le moment de lancer une boîte
qui fait du XCPNG,
Foxmox, OpenStack
c'est déjà un peu à la bourre
tu ne suis pas assez Twitter
mais oui c'est un peu de format depuis un an
mon bis en ce moment
c'est migrer des gens de Vmware vers XCPNG
je pense que le bis avec ça
c'est surtout vendre du conseil
pour choisir le produit de virtualisation
tu sens le grade papier
celui qui gague c'est le vendeur de pel
c'est le gars qui te conseille
le gars qui va vendre de la pel
alors je suis vrai, il est au magasin de pel
faire tampions
je pense qu'on a déjà fait un bon tour
il y a encore plein de choses à dire
parce qu'on n'a pas fait le tour de toutes les technologies
toutes les choses après au-dessus
il y avait une partie organisationnelle
qui apparaît après au-dessus
mais je pense qu'on est déjà un peu plus loin
que le bout de strapping
on pourra discuter une prochaine fois
mais j'étais assez content qu'on arrive
à se dire, poser ces questions
de tout en bas
jusqu'à quelque chose
on a des Vm qui tournent plus ou moins
des Kubernetes Managers
on a du storage, on a des choses comme ça
et on a un peu répondu
on a posé les questions
il y a des logiciels
n'hésitez pas à venir nous contacter
vous verrez dans la description
toutes les personnes
n'hésitez pas à venir nous contacter
si vous avez des questions
toutes les personnes qui sont là
sur le Discord de DevOps
vous pourrez poser des questions
sur toutes ces stacks
sur les logiciels qui peuvent être mis en place
il y a des inconnus
en tout ce qu'on a dit
parce qu'il n'y a pas une stack parfaite
loin de là aujourd'hui qui existe
on le saurait, Kubernetes n'est malheureusement pas partout
je ne le présente pas
à moitié
il n'y a pas le Kubernetes du mass
il n'y a pas un mass qui est apparu
et qui est devenu complètement leader dans son marché
et sur le SDN et sur etc
donc aujourd'hui il y a encore plein de choses
des choix qui sont très contextualisés
donc n'hésitez pas à venir poser les questions
sur Twitter, sur Discord
voilà je sais pas si vous avez un dernier mot
tout ça
ça peut être
je dirais qu'avant de vous se trapper il faut faire de l'ingénierie
il faut réfléchir avant d'y aller
parce que
partout au monde on a commandé des machines
on commandait du matériel
ça prend du temps, il y a des délais
c'est un coup et c'est très enlevé à gens
donc
oui oui bon je veux
qui a réussi à avoir l'équivalent de la production
Nvidia pendant un petit moment pour en laisser
donc voilà c'est faux
faut vraiment ne pas négiger l'ingénierie
qu'il y a avant
c'est pas que de la tech c'est beaucoup de stratégie
c'est pas juste aller braquer des trucs c'est vraiment une partie stratégique
organisationnelle, choisir les bons trucs
pour avoir un truc
l'urbanisation, l'architecture, les choix
faire des bons choix
des schémas
le business plan sur combien d'années
hardware, hardware, prévoir une salle
machine c'est jamais simple
d'autant plus c'est pas exactement
ce qu'on va en faire dès le début
et en plus ça peut changer en cours de route
donc faire des plans c'est bien
s'adapter au
changement et qui vont subvenir c'est encore mieux
ça c'est vraiment
un travail difficile
donc il n'y a pas de solution unique
faites des contrôles plaines
non mais vraiment
pensez avant tout
à comment vous allez l'opérer, avant de penser
à ce que ça va faire
parce que le coût sur la durée
le coût sur les 2, 3, 4, 10 ans
qui vont venir, il va principalement
pouvoir provenir de ça
donc je pense que ça sera une discussion qu'on pourra voir
parce que ça va être dans le cas de tout le régime
genre sa différence de coût et d'urgence dans le développement
on ne ferait pas l'ouvrir ce sujet
non non pas là mais voilà
l'opération first
notamment dans l'infra
c'est peut-être moins vrai dans le logiciel où c'est plus facile
il y a plus de stratégies de contournement
pour faire de l'abbé, du canary, du whatever
du future flag
ou de radicalement changer les choses
vraiment operation first
et il y a des kubernetes qui mènent du cloud
ah ouais là
on le leura
le point final
pour la rêve de tout ça
bon merci à tous
pour enfants, on était hébergés chez Akamai
aujourd'hui
merci Akamai
à une prochaine
on essaiera de faire des épisodes un peu plus
tôt la prochaine fois
voilà
en tout cas n'hésitez pas si vous avez des sujets
à venir nous voir, à en parler
et voilà
à une prochaine