WEBVTT

00:00:43.281 --> 00:00:46.403
Bonjour à toutes et à tous, et bienvenue dans un nouveau numéro de DevOps.

00:00:46.883 --> 00:00:49.385
Alors, ça fait longtemps qu'on en a pas fait, j'ai l'impression de dire ça à

00:00:49.385 --> 00:00:52.667
chaque podcast, mais là ça fait quand même un petit moment. Et aujourd'hui on

00:00:52.667 --> 00:00:54.748
va parler d'un vieux sujet, OpenStack.

00:00:55.549 --> 00:00:59.191
Vieux sujet parce que c'est un logiciel qui n'est pas très récent pour le coup,

00:00:59.191 --> 00:01:02.133
mais ça faisait un petit moment qu'on voulait en parler.

00:01:02.133 --> 00:01:06.636
Ça fait un moment que le sujet peut revenir, surtout quand on le compare avec

00:01:06.636 --> 00:01:09.318
d'autres technologies actuelles. Et donc avec moi aujourd'hui,

00:01:09.318 --> 00:01:12.650
j'ai plusieurs personnes qui vont se présenter via leur expérience.

00:01:13.081 --> 00:01:16.944
Hello ! Alors, moi c'est Flint, vous pouvez me retrouver sur YouTube,

00:01:16.944 --> 00:01:22.208
sur Twitter pardon, sur Kobayashi Maru. Mon boulot c'est être senior architect

00:01:22.208 --> 00:01:27.491
cloud privé, cloud public, pour une boîte qui fait de l'armement et de l'identité.

00:01:29.273 --> 00:01:33.436
Avant ça j'ai fait pas mal de banques, d'hyper scalers et de jeux vidéo,

00:01:33.436 --> 00:01:39.140
puis je me suis retrouvé à bosser là-dedans maintenant depuis depuis 2012, on va dire.

00:01:39.641 --> 00:01:45.125
Donc, je bosse sur OpenStack depuis 2012 avec pas mal de sujets autour de ça,

00:01:45.125 --> 00:01:48.247
sur comment est-ce qu'on déploie, comment est-ce qu'on le manage,

00:01:48.247 --> 00:01:52.250
comment est-ce qu'on va gérer le life cycle, qu'est-ce qui est contenu dans

00:01:52.250 --> 00:01:56.414
OpenStack, qu'est-ce que ça fait, comment ça fonctionne, qu'est-ce qui fonctionne,

00:01:56.414 --> 00:01:57.234
qu'est-ce qui ne fonctionne pas.

00:01:57.815 --> 00:02:02.178
Et toutes les questions satellites à OpenStack, comme le storage,

00:02:02.178 --> 00:02:08.423
Ceph, Kubernetes, les pratiques qui vont au-dessus, comment est-ce qu'on emborde les gens, etc. Voilà.

00:02:08.423 --> 00:02:13.507
Hello tout le monde, moi c'est Julien, je suis ingénieur réseau SRE chez Deezer,

00:02:13.507 --> 00:02:18.751
je suis également IT et infrastructure manager pour les Restaurants du Coeur

00:02:18.751 --> 00:02:22.374
en tant que bénévole, les Restaurants du Coeur de Rélois, puisque je suis de Chartres.

00:02:22.794 --> 00:02:27.477
Je suis aussi également DJ à mes heures perdues, ça m'arrive de mixer

00:02:27.588 --> 00:02:31.300
en festival principalement, et puis aussi à côté de ça,

00:02:31.300 --> 00:02:35.404
avant de bosser chez Deezer, c'est FreeRudder,

00:02:35.404 --> 00:02:38.506
une boîte qui fabrique un levier sale

00:02:38.506 --> 00:02:41.788
open source du même banc pour la gestion de configuration et

00:02:41.788 --> 00:02:45.231
fait de l'OpenStack maintenant depuis 8-9

00:02:45.231 --> 00:02:47.913
ans et c'est quelque chose que je suis en train

00:02:47.913 --> 00:02:52.977
de mettre en place et mettre à disposition au niveau des restos du cœur pour

00:02:52.977 --> 00:02:58.201
offrir de l'infrastructure à toutes les antennes départementales puisque les

00:02:58.201 --> 00:03:02.913
restos s'est un peu éclaté sur toute la France et pour offrir du coup une infrastructure

00:03:02.913 --> 00:03:05.529
relativement solide à base d'OpenStack.

00:03:06.178 --> 00:03:08.670
Alors d'ailleurs, Røder, à mon avis, tout le monde doit les connaître si jamais

00:03:08.670 --> 00:03:12.513
on va dans une conférence, puisqu'ils sont quand même très souvent partenaires de conférences.

00:03:12.854 --> 00:03:17.197
Et notamment, c'était dans tout le temps des DevOps Rex, etc.

00:03:17.638 --> 00:03:20.160
Ah, ils étaient même organisateurs. Oui, voilà.

00:03:20.160 --> 00:03:23.602
Ils étaient même organisateurs, oui, tout à fait, pour le DevOps Rex.

00:03:24.223 --> 00:03:26.465
Petite anecdote assez rigolote, quand je bossais chez Røder,

00:03:26.465 --> 00:03:30.448
même si le DevOps Rex était terminé, j'avais quand même ma boîte mail DevOps

00:03:30.448 --> 00:03:32.149
Rex, qui était créée automatiquement.

00:03:33.210 --> 00:03:34.630
Donc voilà, c'était assez rigolo.

00:03:34.761 --> 00:03:37.974
Oui, c'est vraiment très cool, donc voilà, on leur passe le bonjour,

00:03:37.974 --> 00:03:41.276
c'est vrai qu'ils ont été très importants, ils sont toujours très importants

00:03:41.276 --> 00:03:44.699
sur la scène FR, donc c'est vraiment très sympa.

00:03:45.199 --> 00:03:48.201
Donc aujourd'hui, comme je l'ai dit un peu en introduction, on va parler d'OpenStack.

00:03:48.201 --> 00:03:51.784
Alors moi je vais me présenter un peu sur mon expérience en tout cas avec OpenStack,

00:03:51.784 --> 00:03:55.146
moi je l'ai connu parce que j'ai travaillé chez CloudWatts, CloudWatts où on

00:03:55.146 --> 00:03:57.288
avait un OpenStack pour le coup full public,

00:03:57.628 --> 00:04:01.951
et d'ailleurs il y a des gens aussi, parce qu'on est en direct sur Discord,

00:04:01.951 --> 00:04:06.695
Donc il y a des gens aussi là qui nous écoutent qui étaient avec moi chez CloudWatt

00:04:06.695 --> 00:04:09.797
et on a beaucoup utilisé OpenStack, beaucoup fait de contributions d'ailleurs

00:04:09.797 --> 00:04:14.000
à Open Source et c'est même via ce mode là en fait que je suis rentré vraiment

00:04:14.000 --> 00:04:16.442
dans le cloud public et dans la création de ces clouds là.

00:04:16.592 --> 00:04:22.506
Et c'est vrai que le fait que ce logiciel soit mal aimé, j'ai vraiment jamais trop compris pourquoi.

00:04:22.506 --> 00:04:25.068
C'est un logiciel qui peut être très complexe, notamment quand on fait du cloud

00:04:25.068 --> 00:04:29.275
public avec, quand on l'offre à disposition à des autres, mais c'est aussi un

00:04:29.275 --> 00:04:33.403
cloud privé. Et justement je Je voulais savoir si l'un de vous pouvait me le

00:04:33.403 --> 00:04:36.287
décrire avec des mots, pour savoir un peu comment lui expliquerait OpenStack.

00:04:39.849 --> 00:04:42.531
En fait, OpenStack, c'est comme on le disait en introduction,

00:04:42.531 --> 00:04:45.674
c'est un logiciel qui est une collection de logiciels.

00:04:46.214 --> 00:04:50.858
Déjà, c'est le premier truc à prendre en compte, c'est que ce n'est pas un seul

00:04:50.858 --> 00:04:53.660
logiciel. On parle d'OpenStack, mais OpenStack, c'est une suite de projets.

00:04:54.681 --> 00:04:58.764
Le but de cette suite de projets, c'est tout simplement d'être scheduler de ressources.

00:04:59.444 --> 00:05:04.528
Il y a des définitions alambiquées qui vont être cloud, ressources manager, etc.

00:05:05.549 --> 00:05:09.332
Je pense qu'elles sont trop alambiquées que ça perd un peu les gens.

00:05:10.013 --> 00:05:15.637
Globalement, le but premier d'OpenStack c'est d'être une abstraction aux ressources

00:05:15.637 --> 00:05:19.340
qu'on peut avoir dans une infrastructure, qu'elles soient dans un data center,

00:05:19.340 --> 00:05:21.041
une salle technique, sous le bureau, etc.

00:05:21.331 --> 00:05:27.206
Et en fait ça permet quelque part de réunir toutes ces infrastructures un peu

00:05:27.206 --> 00:05:30.768
diverses et éparses au sein d'une seule et même interface unifiée,

00:05:30.768 --> 00:05:34.491
que ce soit des API ou le dashboard ou la CLI.

00:05:35.112 --> 00:05:38.755
Grosso modo, n'importe quelle ressource on peut on peut manager de la VM,

00:05:38.755 --> 00:05:44.359
du conteneur, des volumes de stockage, object storage ou block storage,

00:05:44.359 --> 00:05:50.584
mais aussi également des services qui sont un peu plus abstraits par rapport

00:05:50.584 --> 00:05:53.486
au hardware, qui vont être par exemple le DNS à The Service,

00:05:53.486 --> 00:05:56.728
l'authentification à The Service ou des choses comme ça.

00:05:56.728 --> 00:05:59.009
Et là, je me fais un peu l'avocat du diable, mais c'est quoi les différences

00:05:59.009 --> 00:06:01.049
avec un Kubernetes pour le coup ?

00:06:01.049 --> 00:06:05.730
Exactement. Alors, la particulière différence qu'on constate,

00:06:05.730 --> 00:06:11.041
on va dire, Avec le Kubernetes, c'est notamment justement sur les briques logicielles

00:06:11.041 --> 00:06:14.652
qui sont un peu plus proches du hardware,

00:06:14.652 --> 00:06:18.233
donc on va dire par exemple pour la gestion des VMs Jusqu'à très récemment avec

00:06:18.233 --> 00:06:22.014
cubevirte c'était un peu compliqué de spawner des vm c'était pas infaisable

00:06:22.014 --> 00:06:23.534
mais c'était un peu plus compliqué,

00:06:24.428 --> 00:06:27.980
Là, sur OpenStack, on a quand même quelque chose qui est rodé depuis longtemps.

00:06:28.651 --> 00:06:31.933
Tu as des services, par exemple, comme l'authentification type Keystone,

00:06:31.933 --> 00:06:37.377
qui, eux, vont être super efficaces parce que tu n'as pas besoin de réinventer la roue.

00:06:37.377 --> 00:06:40.680
Le service est là. C'est-à-dire que si tu veux de l'authentification,

00:06:40.680 --> 00:06:44.002
c'est built-in. Tu n'as pas besoin d'aller chercher à refaire,

00:06:44.002 --> 00:06:48.185
en fait, refabriquer quelque chose de ton côté. C'est fourni par défaut.

00:06:48.446 --> 00:06:51.307
Donc là, justement, si on résume un peu les services qu'on a,

00:06:51.307 --> 00:06:56.231
Ça correspond à quoi à peu près les noms, la myriade de projets justement qu'on va avoir ?

00:06:56.932 --> 00:06:59.894
Alors, il faut savoir un truc, c'est que sur OpenStack, tu as la notion en fait

00:06:59.894 --> 00:07:01.415
de ce qu'on appelle la Big Tent.

00:07:01.856 --> 00:07:05.278
Alors, c'est une notion qui tend à disparaître parce que le nombre de projets

00:07:05.278 --> 00:07:09.060
augmentant, ça va être difficile de tout garder sous la Big Tent et ça va être

00:07:09.060 --> 00:07:12.983
difficile de garder cette analogie-là. Mais grosso modo, on va appeler ce qu'on

00:07:12.983 --> 00:07:14.344
appelle un OpenStack Vanilla.

00:07:15.065 --> 00:07:19.328
C'est un OpenStack avec les services minimum, c'est-à-dire Keystone,

00:07:19.328 --> 00:07:21.829
donc qui va être le service d'identification et d'authentification.

00:07:22.801 --> 00:07:26.653
On va avoir Glens qui est le service des images, donc de gestion des images

00:07:26.653 --> 00:07:31.937
au sens images de VM ou conteneurs ou artefacts en fait de déploiement pour du workload.

00:07:33.798 --> 00:07:39.002
Tu as Cinder qui est le service en charge de la gestion du bloc storage.

00:07:40.043 --> 00:07:44.165
Tu as Swift qui est en charge lui de la gestion de l'object store.

00:07:49.590 --> 00:07:53.523
Tu as derrière Neutron qui est en fait le service qui lui gère toute la partie

00:07:53.523 --> 00:07:59.478
réseau et qui est en fait quasiment l'épine dorsale d'OpenStack finalement parce

00:07:59.478 --> 00:08:01.099
que sans réseau point de communication,

00:08:01.830 --> 00:08:06.183
et puis derrière normalement tu as Horizon qui est en fait le dashboard et qui

00:08:06.183 --> 00:08:10.827
se sert de tous les services précédemment cités pour offrir quelque part une

00:08:10.827 --> 00:08:12.568
interface un peu cliqueticlic à l'utilisateur.

00:08:14.219 --> 00:08:19.823
Et donc chaque service qu'on vient de citer, il vient avec son endpoint API

00:08:19.823 --> 00:08:23.145
qui te permet de l'instrumenter directement depuis une API.

00:08:23.145 --> 00:08:27.248
Et c'est ce qui fait la force de tout ça, c'est qu'en fait quelque part derrière

00:08:27.248 --> 00:08:30.490
tu peux jouer au chef d'orchestre assez facilement avec tes ressources puisque

00:08:30.490 --> 00:08:34.273
une fois qu'elles ont été adoptées par ces services-là, tu peux directement

00:08:34.273 --> 00:08:37.305
les scheduler et les manager depuis ces services.

00:08:38.056 --> 00:08:41.898
D'accord, et donc là tous ces services sont obligatoires, ils sont mandatoriels,

00:08:41.898 --> 00:08:47.222
là on est dans le bar minimum d'un d'un OpenStack ou c'est modulable ?

00:08:47.822 --> 00:08:52.865
Alors jusqu'à il y a quelques temps tu avais des attachements forts entre les

00:08:52.865 --> 00:08:56.908
services et donc tu avais que ces services là entre guillemets on recommandait

00:08:56.908 --> 00:08:58.970
de les installer toujours avec le même package,

00:08:58.970 --> 00:09:03.873
c'est à dire toujours ce package là de services parce que ça faisait donc le

00:09:03.873 --> 00:09:08.296
core vanilla Aujourd'hui c'est moins vrai, tu pourrais en fait les installer

00:09:08.296 --> 00:09:12.979
un à un et utiliser un seul des services parce que tu n'as besoin que de ce service là par exemple.

00:09:13.399 --> 00:09:18.323
Tu pourrais dire moi j'ai un besoin de gestion de bloc storage uniquement et

00:09:18.323 --> 00:09:19.344
n'installer que Cinder.

00:09:19.765 --> 00:09:24.268
Dans la majorité des cas on installe le corps complet pour la bonne et simple

00:09:24.268 --> 00:09:28.291
raison c'est qu'on n'a jamais trop besoin que d'un seul service et qu'à un moment donné,

00:09:28.291 --> 00:09:32.054
Bon ben quand on fait de l'infrastructure à la demande, généralement on va essayer

00:09:32.054 --> 00:09:36.157
d'avoir un seul tool qui le fait et du coup on va déployer ces vanillas là.

00:09:36.578 --> 00:09:40.021
Au delà de ces services core, t'as toute

00:09:40.021 --> 00:09:44.324
une autre ribambelle de projets qui existent et qui eux sont totalement optionnels

00:09:44.324 --> 00:09:50.068
puisque en fait le principe même d'OpenStack c'est de dire ok chaque projet

00:09:50.068 --> 00:09:56.594
est censé être standalone et autonome mais être entre guillemets normalisé d'une

00:09:56.594 --> 00:09:59.236
façon qui fait que chaque service,

00:09:59.236 --> 00:10:02.778
s'il a envie de parler avec les autres services d'OpenStack et sous couvert

00:10:02.778 --> 00:10:07.373
de configuration correcte, il va pouvoir, et on va constituer en fait un catalogue

00:10:07.373 --> 00:10:11.888
de services qui va permettre d'être accessible de façon unifiée.

00:10:12.039 --> 00:10:14.511
Et qui va pouvoir s'appeler les uns les autres.

00:10:16.768 --> 00:10:20.700
Donc là, ça fait quand même un peu de logiciel à installer tout ça.

00:10:20.700 --> 00:10:23.683
Ça va être quoi les dépendances ? Là par exemple, Julien, dans le cadre de ton

00:10:23.683 --> 00:10:27.886
install, c'est quoi à peu près les prérequis que vous avez ?

00:10:27.886 --> 00:10:31.449
Qu'est-ce que vous allez devoir installer ? Parce que j'arrive pas à me rendre

00:10:31.449 --> 00:10:34.151
compte, là en tout cas si j'écoute, de l'installation de tout ça,

00:10:34.151 --> 00:10:38.214
à quel point ça correspond à une maintenance et à un déploiement compliqué ?

00:10:38.214 --> 00:10:42.197
Le déploiement, on ne peut pas vraiment dire qu'il est compliqué puisque justement,

00:10:42.197 --> 00:10:47.341
tout l'environnement fait OpenStack fournit un outil, donc Colen Siebel vient

00:10:47.341 --> 00:10:51.524
pour simplifier considérablement le déploiement d'OpenStack,

00:10:51.524 --> 00:10:52.604
surtout de certaines briques.

00:10:52.604 --> 00:10:55.026
Nous, par exemple, au Restos du Coeur, on ne va pas embarquer tout,

00:10:55.026 --> 00:11:01.290
on va vraiment avoir, comme l'a dit juste avant, que certaines briques, les briques de base.

00:11:01.290 --> 00:11:04.433
Donc voilà, avec Colas, ça se fait très bien, très facilement.

00:11:04.433 --> 00:11:09.036
Un gros avantage aussi que moi j'ai vu, en tout cas pour l'utiliser maintenant au quotidien,

00:11:09.376 --> 00:11:14.180
c'est que sur certains drivers, certains logiciels qui sont proposés par OpenStack,

00:11:14.180 --> 00:11:18.163
pour ajouter une certaine couche d'abstraction, c'est qu'on peut même les pluguer

00:11:18.163 --> 00:11:22.526
automatiquement à des outils qui eux sont, qu'on utilisait auparavant.

00:11:22.526 --> 00:11:26.829
Par exemple, je vois par exemple pour la partie DNS, utiliser PowerDNS plutôt

00:11:26.829 --> 00:11:30.812
que Bind qui est fourni par défaut par des inmates, et en fait c'est tout à

00:11:30.812 --> 00:11:33.454
fait connecté, on peut tout à fait le connecter sans aucun souci.

00:11:33.454 --> 00:11:36.956
Et pour la partie Load Balancing, on est plutôt sur HAProxy de notre côté,

00:11:36.956 --> 00:11:38.157
et ça marche aussi très très bien.

00:11:39.219 --> 00:11:42.561
Donc c'est aussi ça qui est important de souligner dans OpenStack,

00:11:42.561 --> 00:11:46.303
c'est qu'on peut très facilement abstraire l'infrastructure aussi actuelle.

00:11:47.645 --> 00:11:51.307
C'est pas parce que vous avez des logiciels qui sont, comment dire,

00:11:51.307 --> 00:11:54.690
pas notés dans les standards, entre guillemets, d'OpenStack,

00:11:54.690 --> 00:11:57.973
qu'ils ne sont pas forcément supportés. Si vous regardez un petit peu les drivers,

00:11:57.973 --> 00:12:02.116
très souvent, vous pouvez trouver les différentes applications.

00:12:03.177 --> 00:12:06.519
Il y a cette notion que tu viens de donner, Julien, qui est ultra importante,

00:12:06.519 --> 00:12:11.202
effectivement, sur OpenStack, c'est que OpenStack, qui est le nom global du

00:12:11.202 --> 00:12:16.305
projet, est une collection de projets, justement, et chaque projet,

00:12:16.305 --> 00:12:21.088
en fait, pour pouvoir maximiser les ressources qu'il va pouvoir gérer,

00:12:21.299 --> 00:12:27.572
a en fait en son sein un mécanisme de driver.

00:12:28.153 --> 00:12:32.015
Donc typiquement, si on prend l'objet storage, l'objet storage, donc Cinder,

00:12:32.326 --> 00:12:36.978
va pouvoir être capable de s'attacher soit à DB SAN à l'ancienne,

00:12:36.978 --> 00:12:43.101
soit à du software defined storage type Ceph, soit à d'autres types de storage,

00:12:43.101 --> 00:12:45.982
enfin de fournisseurs de stockage.

00:12:46.963 --> 00:12:48.924
Et globalement la liste est plutôt longue.

00:12:49.689 --> 00:12:53.675
Et donc du coup, en fait, c'est intéressant parce que ça permet réellement d'abstraire

00:12:53.675 --> 00:13:00.326
à un niveau beaucoup plus élevé l'intégralité du stockage que peut avoir une

00:13:00.326 --> 00:13:02.868
entreprise ou un groupe de personnes.

00:13:02.868 --> 00:13:06.891
Donc typiquement, tu peux dans SINDER choisir ton backend de stockage,

00:13:06.891 --> 00:13:11.073
mais tu peux évidemment avoir plusieurs backends de stockage en même temps.

00:13:11.073 --> 00:13:15.837
Parce qu'il suffit de lui dire, ok, moi je veux embarquer des zones SEF,

00:13:15.837 --> 00:13:18.939
des zones, je ne sais pas, moi Hitachi, des zones EMC2, etc.

00:13:19.399 --> 00:13:23.262
Et en fait ça va te permettre de couvrir l'intégralité et de piloter surtout

00:13:23.262 --> 00:13:26.845
l'intégralité de tes ressources block storage comme ça. Et donc Cinder pour

00:13:26.845 --> 00:13:32.329
le block storage, mais tu as également la même mécanique de driver pour Nova

00:13:32.329 --> 00:13:33.570
qui va gérer donc le compute.

00:13:33.950 --> 00:13:38.213
Par défaut, effectivement 90% des gens vont utiliser le KVM parce que

00:13:38.344 --> 00:13:43.017
on part avec du Linux et on part avec du KVM, mais rien ne t'empêche d'utiliser un driver VMware,

00:13:43.017 --> 00:13:47.260
un driver Hyper-V, un driver Xen, et donc du coup de driver depuis depuis Tonova,

00:13:47.260 --> 00:13:52.064
tes ressources compute qui elles se trouveraient sur des hosts et qui se trouveraient

00:13:52.064 --> 00:13:54.145
en fait dans des régions gérées par ces outils-là.

00:13:55.346 --> 00:14:02.051
En parlant de driver, il est d'ailleurs aussi important de souligner que Neutron,

00:14:02.051 --> 00:14:07.396
donc le driver SDN, donc Software Defined Network d'OpenStack,

00:14:07.396 --> 00:14:09.517
qui est clairement l'un des plus avancés

00:14:09.728 --> 00:14:15.201
en termes de gestion réseau par rapport à ce qu'on peut reprouver sur des solutions

00:14:15.201 --> 00:14:16.302
beaucoup plus simplifiées,

00:14:16.302 --> 00:14:20.826
mais par exemple je pense à Proxmox Virtual Environment qui fournit un outil

00:14:20.826 --> 00:14:25.049
qui est un hyperviseur mais que maintenant certains voient comme un mini-cloud

00:14:25.049 --> 00:14:29.692
privé, la partie SDN est encore en bêta, donc voilà un petit peu,

00:14:30.103 --> 00:14:34.636
il y a d'autres solutions, il suffit de regarder CloudStack de Candace et Apache

00:14:34.636 --> 00:14:38.018
où c'est pareil, la partie réseau n'est clairement pas aussi avancée que ce

00:14:38.018 --> 00:14:41.360
qu'on va avoir côté OpenStack, on sent qu'il y a quand même une certaine maturité

00:14:41.360 --> 00:14:44.763
qu'il n'y a pas sur d'autres projets du même genre.

00:14:44.763 --> 00:14:46.244
Ouais.

00:14:46.244 --> 00:14:49.706
Pour le dire, la partie réseau, elle s'est faite aussi de la maturité dans la

00:14:49.706 --> 00:14:54.029
douleur. Pour avoir un peu de loco-psyche, il y a un moment… Voilà,

00:14:54.029 --> 00:14:56.471
ça a pu se faire à un moment donné dans la douleur, on va dire.

00:14:56.471 --> 00:15:02.576
La partie Nova Network était salement dégueulasse, clairement, il faut dire les termes.

00:15:03.636 --> 00:15:07.430
Donc oui, c'est vrai. Alors là, c'est marrant, tu as parlé justement de Proxmox

00:15:07.430 --> 00:15:12.539
ou aux procs moches pour les intimes, justement, ça va être ça va être fin.

00:15:13.316 --> 00:15:16.538
J'arrive pas à savoir encore quel est le coût d'installation de tout ça.

00:15:16.538 --> 00:15:18.920
Donc là, j'ai compris qu'il y avait de l'Ansible pour l'installer,

00:15:18.920 --> 00:15:20.941
etc. Mais en termes de ressources, c'est gros.

00:15:20.941 --> 00:15:23.363
Quels vont être mes dépendants ? Je ne sais pas, je suis obligé d'installer

00:15:23.363 --> 00:15:27.626
un Kafka, je suis obligé d'installer des logiciels, un Zookeeper ou n'importe

00:15:27.626 --> 00:15:30.328
quoi, parce qu'on sait qu'il y a plein de logiciels qui ont besoin de ce genre de dépendance.

00:15:30.328 --> 00:15:33.470
Là, aujourd'hui, ça va être quoi la dépendance que je vais avoir besoin de gérer,

00:15:33.470 --> 00:15:37.052
moi, en infra ? Si jamais je veux juste installer le bar minimum d'avoir ça

00:15:37.052 --> 00:15:40.134
dans mon infra ? On parle pour l'instant, bien sûr, de code privé,

00:15:40.134 --> 00:15:41.835
c'est-à-dire pour un usage interne.

00:15:42.456 --> 00:15:46.118
Globalement tout dépendra je pense de ton besoin, forcément si

00:15:46.369 --> 00:15:52.873
tu souhaites déployer principalement massivement des noeuds KVM pour fournir du compute,

00:15:52.873 --> 00:15:56.525
forcément tes besoins ne sont pas les mêmes que si tu cherches à fournir de

00:15:56.525 --> 00:16:01.448
la base de données ou par exemple du Redis as a service ou ce genre de choses,

00:16:01.448 --> 00:16:05.531
tout dépendra forcément de ce que tu souhaites toi mettre en place derrière.

00:16:07.812 --> 00:16:11.344
Je vais avoir la possibilité d'avoir du Redis as a service si jamais je commence

00:16:11.344 --> 00:16:13.456
à me lancer dans une instance OpenStack.

00:16:13.536 --> 00:16:17.759
Alors pas au démarrage, mais il y a effectivement un driver qui est fourni,

00:16:17.759 --> 00:16:22.342
Zagar, qui permet justement de faire du Redis Storage as a service.

00:16:22.883 --> 00:16:26.905
En fait on arrive vraiment à la notion de cloud, enfin pas d'hyperscaler parce

00:16:26.905 --> 00:16:30.308
qu'on n'est pas l'un dedans, mais d'avoir des services managés que je vais pouvoir

00:16:30.308 --> 00:16:34.651
retrouver au sein d'une équipe qui va les fournir après aux autres avec un service d'IPI, c'est ça ?

00:16:35.091 --> 00:16:40.015
Et c'est ce qui est hyper intéressant avec OpenStack, c'est que finalement les services,

00:16:40.015 --> 00:16:43.898
habituellement côté infrastructure, on va avoir des spécialités,

00:16:43.898 --> 00:16:47.160
donc quelqu'un qui va être plutôt spécialisé en partie storage, compute,

00:16:47.160 --> 00:16:52.524
la partie networking, et en fait le gros avantage justement d'OpenStack avec tous ces modules,

00:16:52.524 --> 00:16:56.987
enfin la driver, c'est que ces drivers vont finalement concerner que certaines

00:16:56.987 --> 00:16:57.768
personnes dans l'équipe,

00:16:57.768 --> 00:17:04.232
et ces personnes-là vont pouvoir rendre les anciens blocs statiques de l'infrastructure,

00:17:04.232 --> 00:17:08.885
typiquement des Redis, en tant que service directement dans la plateforme OpenStack.

00:17:09.817 --> 00:17:13.699
Je pense qu'il y a une analogie qui marche très bien avec OpenStack,

00:17:13.699 --> 00:17:18.803
c'est l'analogie des Legos, où en fait c'est vraiment une caisse de Lego

00:17:19.054 --> 00:17:25.228
où tu vas avoir les 4 barres, double 4 barres jaunes, 2 rouges, etc.

00:17:26.349 --> 00:17:31.613
Chaque service est une brique de lego que t'assembles et que tu peux moduler comme tu veux.

00:17:31.954 --> 00:17:36.137
Donc pour répondre à ta question, le bar minimum si tu veux lancer un openstack

00:17:36.137 --> 00:17:39.498
pour faire par exemple du POC, c'est un serveur.

00:17:39.498 --> 00:17:43.060
Tu peux faire un all-in-one, ça va te coûter un serveur. Alors il faut que ça

00:17:43.060 --> 00:17:46.022
soit un peu péchu quand même parce que vu le nombre de services que tu vas faire

00:17:46.022 --> 00:17:50.184
tourner dessus, il faut que ça puisse un peu envoyer. Mais mais globalement,

00:17:50.184 --> 00:17:53.886
tu prends un serveur 32 coeurs, 64 giga de RAM, ça passe.

00:17:55.008 --> 00:17:58.490