Bonjour à toutes et à tous, et bienvenue dans un nouveau numéro de DevOps.
Alors, ça fait longtemps qu'on en a pas fait, j'ai l'impression de dire ça à
chaque podcast, mais là ça fait quand même un petit moment. Et aujourd'hui on
va parler d'un vieux sujet, OpenStack.
Vieux sujet parce que c'est un logiciel qui n'est pas très récent pour le coup,
mais ça faisait un petit moment qu'on voulait en parler.
Ça fait un moment que le sujet peut revenir, surtout quand on le compare avec
d'autres technologies actuelles. Et donc avec moi aujourd'hui,
j'ai plusieurs personnes qui vont se présenter via leur expérience.
Hello ! Alors, moi c'est Flint, vous pouvez me retrouver sur YouTube,
sur Twitter pardon, sur Kobayashi Maru. Mon boulot c'est être senior architect
cloud privé, cloud public, pour une boîte qui fait de l'armement et de l'identité.
Avant ça j'ai fait pas mal de banques, d'hyper scalers et de jeux vidéo,
puis je me suis retrouvé à bosser là-dedans maintenant depuis depuis 2012, on va dire.
Donc, je bosse sur OpenStack depuis 2012 avec pas mal de sujets autour de ça,
sur comment est-ce qu'on déploie, comment est-ce qu'on le manage,
comment est-ce qu'on va gérer le life cycle, qu'est-ce qui est contenu dans
OpenStack, qu'est-ce que ça fait, comment ça fonctionne, qu'est-ce qui fonctionne,
qu'est-ce qui ne fonctionne pas.
Et toutes les questions satellites à OpenStack, comme le storage,
Ceph, Kubernetes, les pratiques qui vont au-dessus, comment est-ce qu'on emborde les gens, etc. Voilà.
Hello tout le monde, moi c'est Julien, je suis ingénieur réseau SRE chez Deezer,
je suis également IT et infrastructure manager pour les Restaurants du Coeur
en tant que bénévole, les Restaurants du Coeur de Rélois, puisque je suis de Chartres.
Je suis aussi également DJ à mes heures perdues, ça m'arrive de mixer
en festival principalement, et puis aussi à côté de ça,
avant de bosser chez Deezer, c'est FreeRudder,
une boîte qui fabrique un levier sale
open source du même banc pour la gestion de configuration et
fait de l'OpenStack maintenant depuis 8-9
ans et c'est quelque chose que je suis en train
de mettre en place et mettre à disposition au niveau des restos du cœur pour
offrir de l'infrastructure à toutes les antennes départementales puisque les
restos s'est un peu éclaté sur toute la France et pour offrir du coup une infrastructure
relativement solide à base d'OpenStack.
Alors d'ailleurs, Røder, à mon avis, tout le monde doit les connaître si jamais
on va dans une conférence, puisqu'ils sont quand même très souvent partenaires de conférences.
Et notamment, c'était dans tout le temps des DevOps Rex, etc.
Ah, ils étaient même organisateurs. Oui, voilà.
Ils étaient même organisateurs, oui, tout à fait, pour le DevOps Rex.
Petite anecdote assez rigolote, quand je bossais chez Røder,
même si le DevOps Rex était terminé, j'avais quand même ma boîte mail DevOps
Rex, qui était créée automatiquement.
Donc voilà, c'était assez rigolo.
Oui, c'est vraiment très cool, donc voilà, on leur passe le bonjour,
c'est vrai qu'ils ont été très importants, ils sont toujours très importants
sur la scène FR, donc c'est vraiment très sympa.
Donc aujourd'hui, comme je l'ai dit un peu en introduction, on va parler d'OpenStack.
Alors moi je vais me présenter un peu sur mon expérience en tout cas avec OpenStack,
moi je l'ai connu parce que j'ai travaillé chez CloudWatts, CloudWatts où on
avait un OpenStack pour le coup full public,
et d'ailleurs il y a des gens aussi, parce qu'on est en direct sur Discord,
Donc il y a des gens aussi là qui nous écoutent qui étaient avec moi chez CloudWatt
et on a beaucoup utilisé OpenStack, beaucoup fait de contributions d'ailleurs
à Open Source et c'est même via ce mode là en fait que je suis rentré vraiment
dans le cloud public et dans la création de ces clouds là.
Et c'est vrai que le fait que ce logiciel soit mal aimé, j'ai vraiment jamais trop compris pourquoi.
C'est un logiciel qui peut être très complexe, notamment quand on fait du cloud
public avec, quand on l'offre à disposition à des autres, mais c'est aussi un
cloud privé. Et justement je Je voulais savoir si l'un de vous pouvait me le
décrire avec des mots, pour savoir un peu comment lui expliquerait OpenStack.
En fait, OpenStack, c'est comme on le disait en introduction,
c'est un logiciel qui est une collection de logiciels.
Déjà, c'est le premier truc à prendre en compte, c'est que ce n'est pas un seul
logiciel. On parle d'OpenStack, mais OpenStack, c'est une suite de projets.
Le but de cette suite de projets, c'est tout simplement d'être scheduler de ressources.
Il y a des définitions alambiquées qui vont être cloud, ressources manager, etc.
Je pense qu'elles sont trop alambiquées que ça perd un peu les gens.
Globalement, le but premier d'OpenStack c'est d'être une abstraction aux ressources
qu'on peut avoir dans une infrastructure, qu'elles soient dans un data center,
une salle technique, sous le bureau, etc.
Et en fait ça permet quelque part de réunir toutes ces infrastructures un peu
diverses et éparses au sein d'une seule et même interface unifiée,
que ce soit des API ou le dashboard ou la CLI.
Grosso modo, n'importe quelle ressource on peut on peut manager de la VM,
du conteneur, des volumes de stockage, object storage ou block storage,
mais aussi également des services qui sont un peu plus abstraits par rapport
au hardware, qui vont être par exemple le DNS à The Service,
l'authentification à The Service ou des choses comme ça.
Et là, je me fais un peu l'avocat du diable, mais c'est quoi les différences
avec un Kubernetes pour le coup ?
Exactement. Alors, la particulière différence qu'on constate,
on va dire, Avec le Kubernetes, c'est notamment justement sur les briques logicielles
qui sont un peu plus proches du hardware,
donc on va dire par exemple pour la gestion des VMs Jusqu'à très récemment avec
cubevirte c'était un peu compliqué de spawner des vm c'était pas infaisable
mais c'était un peu plus compliqué,
Là, sur OpenStack, on a quand même quelque chose qui est rodé depuis longtemps.
Tu as des services, par exemple, comme l'authentification type Keystone,
qui, eux, vont être super efficaces parce que tu n'as pas besoin de réinventer la roue.
Le service est là. C'est-à-dire que si tu veux de l'authentification,
c'est built-in. Tu n'as pas besoin d'aller chercher à refaire,
en fait, refabriquer quelque chose de ton côté. C'est fourni par défaut.
Donc là, justement, si on résume un peu les services qu'on a,
Ça correspond à quoi à peu près les noms, la myriade de projets justement qu'on va avoir ?
Alors, il faut savoir un truc, c'est que sur OpenStack, tu as la notion en fait
de ce qu'on appelle la Big Tent.
Alors, c'est une notion qui tend à disparaître parce que le nombre de projets
augmentant, ça va être difficile de tout garder sous la Big Tent et ça va être
difficile de garder cette analogie-là. Mais grosso modo, on va appeler ce qu'on
appelle un OpenStack Vanilla.
C'est un OpenStack avec les services minimum, c'est-à-dire Keystone,
donc qui va être le service d'identification et d'authentification.
On va avoir Glens qui est le service des images, donc de gestion des images
au sens images de VM ou conteneurs ou artefacts en fait de déploiement pour du workload.
Tu as Cinder qui est le service en charge de la gestion du bloc storage.
Tu as Swift qui est en charge lui de la gestion de l'object store.
Tu as derrière Neutron qui est en fait le service qui lui gère toute la partie
réseau et qui est en fait quasiment l'épine dorsale d'OpenStack finalement parce
que sans réseau point de communication,
et puis derrière normalement tu as Horizon qui est en fait le dashboard et qui
se sert de tous les services précédemment cités pour offrir quelque part une
interface un peu cliqueticlic à l'utilisateur.
Et donc chaque service qu'on vient de citer, il vient avec son endpoint API
qui te permet de l'instrumenter directement depuis une API.
Et c'est ce qui fait la force de tout ça, c'est qu'en fait quelque part derrière
tu peux jouer au chef d'orchestre assez facilement avec tes ressources puisque
une fois qu'elles ont été adoptées par ces services-là, tu peux directement
les scheduler et les manager depuis ces services.
D'accord, et donc là tous ces services sont obligatoires, ils sont mandatoriels,
là on est dans le bar minimum d'un d'un OpenStack ou c'est modulable ?
Alors jusqu'à il y a quelques temps tu avais des attachements forts entre les
services et donc tu avais que ces services là entre guillemets on recommandait
de les installer toujours avec le même package,
c'est à dire toujours ce package là de services parce que ça faisait donc le
core vanilla Aujourd'hui c'est moins vrai, tu pourrais en fait les installer
un à un et utiliser un seul des services parce que tu n'as besoin que de ce service là par exemple.
Tu pourrais dire moi j'ai un besoin de gestion de bloc storage uniquement et
n'installer que Cinder.
Dans la majorité des cas on installe le corps complet pour la bonne et simple
raison c'est qu'on n'a jamais trop besoin que d'un seul service et qu'à un moment donné,
Bon ben quand on fait de l'infrastructure à la demande, généralement on va essayer
d'avoir un seul tool qui le fait et du coup on va déployer ces vanillas là.
Au delà de ces services core, t'as toute
une autre ribambelle de projets qui existent et qui eux sont totalement optionnels
puisque en fait le principe même d'OpenStack c'est de dire ok chaque projet
est censé être standalone et autonome mais être entre guillemets normalisé d'une
façon qui fait que chaque service,
s'il a envie de parler avec les autres services d'OpenStack et sous couvert
de configuration correcte, il va pouvoir, et on va constituer en fait un catalogue
de services qui va permettre d'être accessible de façon unifiée.
Et qui va pouvoir s'appeler les uns les autres.
Donc là, ça fait quand même un peu de logiciel à installer tout ça.
Ça va être quoi les dépendances ? Là par exemple, Julien, dans le cadre de ton
install, c'est quoi à peu près les prérequis que vous avez ?
Qu'est-ce que vous allez devoir installer ? Parce que j'arrive pas à me rendre
compte, là en tout cas si j'écoute, de l'installation de tout ça,
à quel point ça correspond à une maintenance et à un déploiement compliqué ?
Le déploiement, on ne peut pas vraiment dire qu'il est compliqué puisque justement,
tout l'environnement fait OpenStack fournit un outil, donc Colen Siebel vient
pour simplifier considérablement le déploiement d'OpenStack,
surtout de certaines briques.
Nous, par exemple, au Restos du Coeur, on ne va pas embarquer tout,
on va vraiment avoir, comme l'a dit juste avant, que certaines briques, les briques de base.
Donc voilà, avec Colas, ça se fait très bien, très facilement.
Un gros avantage aussi que moi j'ai vu, en tout cas pour l'utiliser maintenant au quotidien,
c'est que sur certains drivers, certains logiciels qui sont proposés par OpenStack,
pour ajouter une certaine couche d'abstraction, c'est qu'on peut même les pluguer
automatiquement à des outils qui eux sont, qu'on utilisait auparavant.
Par exemple, je vois par exemple pour la partie DNS, utiliser PowerDNS plutôt
que Bind qui est fourni par défaut par des inmates, et en fait c'est tout à
fait connecté, on peut tout à fait le connecter sans aucun souci.
Et pour la partie Load Balancing, on est plutôt sur HAProxy de notre côté,
et ça marche aussi très très bien.
Donc c'est aussi ça qui est important de souligner dans OpenStack,
c'est qu'on peut très facilement abstraire l'infrastructure aussi actuelle.
C'est pas parce que vous avez des logiciels qui sont, comment dire,
pas notés dans les standards, entre guillemets, d'OpenStack,
qu'ils ne sont pas forcément supportés. Si vous regardez un petit peu les drivers,
très souvent, vous pouvez trouver les différentes applications.
Il y a cette notion que tu viens de donner, Julien, qui est ultra importante,
effectivement, sur OpenStack, c'est que OpenStack, qui est le nom global du
projet, est une collection de projets, justement, et chaque projet,
en fait, pour pouvoir maximiser les ressources qu'il va pouvoir gérer,
a en fait en son sein un mécanisme de driver.
Donc typiquement, si on prend l'objet storage, l'objet storage, donc Cinder,
va pouvoir être capable de s'attacher soit à DB SAN à l'ancienne,
soit à du software defined storage type Ceph, soit à d'autres types de storage,
enfin de fournisseurs de stockage.
Et globalement la liste est plutôt longue.
Et donc du coup, en fait, c'est intéressant parce que ça permet réellement d'abstraire
à un niveau beaucoup plus élevé l'intégralité du stockage que peut avoir une
entreprise ou un groupe de personnes.
Donc typiquement, tu peux dans SINDER choisir ton backend de stockage,
mais tu peux évidemment avoir plusieurs backends de stockage en même temps.
Parce qu'il suffit de lui dire, ok, moi je veux embarquer des zones SEF,
des zones, je ne sais pas, moi Hitachi, des zones EMC2, etc.
Et en fait ça va te permettre de couvrir l'intégralité et de piloter surtout
l'intégralité de tes ressources block storage comme ça. Et donc Cinder pour
le block storage, mais tu as également la même mécanique de driver pour Nova
qui va gérer donc le compute.
Par défaut, effectivement 90% des gens vont utiliser le KVM parce que
on part avec du Linux et on part avec du KVM, mais rien ne t'empêche d'utiliser un driver VMware,
un driver Hyper-V, un driver Xen, et donc du coup de driver depuis depuis Tonova,
tes ressources compute qui elles se trouveraient sur des hosts et qui se trouveraient
en fait dans des régions gérées par ces outils-là.
En parlant de driver, il est d'ailleurs aussi important de souligner que Neutron,
donc le driver SDN, donc Software Defined Network d'OpenStack,
qui est clairement l'un des plus avancés
en termes de gestion réseau par rapport à ce qu'on peut reprouver sur des solutions
beaucoup plus simplifiées,
mais par exemple je pense à Proxmox Virtual Environment qui fournit un outil
qui est un hyperviseur mais que maintenant certains voient comme un mini-cloud
privé, la partie SDN est encore en bêta, donc voilà un petit peu,
il y a d'autres solutions, il suffit de regarder CloudStack de Candace et Apache
où c'est pareil, la partie réseau n'est clairement pas aussi avancée que ce
qu'on va avoir côté OpenStack, on sent qu'il y a quand même une certaine maturité
qu'il n'y a pas sur d'autres projets du même genre.
Ouais.
Pour le dire, la partie réseau, elle s'est faite aussi de la maturité dans la
douleur. Pour avoir un peu de loco-psyche, il y a un moment… Voilà,
ça a pu se faire à un moment donné dans la douleur, on va dire.
La partie Nova Network était salement dégueulasse, clairement, il faut dire les termes.
Donc oui, c'est vrai. Alors là, c'est marrant, tu as parlé justement de Proxmox
ou aux procs moches pour les intimes, justement, ça va être ça va être fin.
J'arrive pas à savoir encore quel est le coût d'installation de tout ça.
Donc là, j'ai compris qu'il y avait de l'Ansible pour l'installer,
etc. Mais en termes de ressources, c'est gros.
Quels vont être mes dépendants ? Je ne sais pas, je suis obligé d'installer
un Kafka, je suis obligé d'installer des logiciels, un Zookeeper ou n'importe
quoi, parce qu'on sait qu'il y a plein de logiciels qui ont besoin de ce genre de dépendance.
Là, aujourd'hui, ça va être quoi la dépendance que je vais avoir besoin de gérer,
moi, en infra ? Si jamais je veux juste installer le bar minimum d'avoir ça
dans mon infra ? On parle pour l'instant, bien sûr, de code privé,
c'est-à-dire pour un usage interne.
Globalement tout dépendra je pense de ton besoin, forcément si
tu souhaites déployer principalement massivement des noeuds KVM pour fournir du compute,
forcément tes besoins ne sont pas les mêmes que si tu cherches à fournir de
la base de données ou par exemple du Redis as a service ou ce genre de choses,
tout dépendra forcément de ce que tu souhaites toi mettre en place derrière.
Je vais avoir la possibilité d'avoir du Redis as a service si jamais je commence
à me lancer dans une instance OpenStack.
Alors pas au démarrage, mais il y a effectivement un driver qui est fourni,
Zagar, qui permet justement de faire du Redis Storage as a service.
En fait on arrive vraiment à la notion de cloud, enfin pas d'hyperscaler parce
qu'on n'est pas l'un dedans, mais d'avoir des services managés que je vais pouvoir
retrouver au sein d'une équipe qui va les fournir après aux autres avec un service d'IPI, c'est ça ?
Et c'est ce qui est hyper intéressant avec OpenStack, c'est que finalement les services,
habituellement côté infrastructure, on va avoir des spécialités,
donc quelqu'un qui va être plutôt spécialisé en partie storage, compute,
la partie networking, et en fait le gros avantage justement d'OpenStack avec tous ces modules,
enfin la driver, c'est que ces drivers vont finalement concerner que certaines
personnes dans l'équipe,
et ces personnes-là vont pouvoir rendre les anciens blocs statiques de l'infrastructure,
typiquement des Redis, en tant que service directement dans la plateforme OpenStack.
Je pense qu'il y a une analogie qui marche très bien avec OpenStack,
c'est l'analogie des Legos, où en fait c'est vraiment une caisse de Lego
où tu vas avoir les 4 barres, double 4 barres jaunes, 2 rouges, etc.
Chaque service est une brique de lego que t'assembles et que tu peux moduler comme tu veux.
Donc pour répondre à ta question, le bar minimum si tu veux lancer un openstack
pour faire par exemple du POC, c'est un serveur.
Tu peux faire un all-in-one, ça va te coûter un serveur. Alors il faut que ça
soit un peu péchu quand même parce que vu le nombre de services que tu vas faire
tourner dessus, il faut que ça puisse un peu envoyer. Mais mais globalement,
tu prends un serveur 32 coeurs, 64 giga de RAM, ça passe.