DevObs

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.

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