De retour de l'OpenStack Ops Midcycle Meetup à Milan

Publié le
par Adrien Cunin, Kevin Lefèvre
dans OpenStack
⭠ Retour à la liste des articles


De retour de l'OpenStack Ops Midcycle Meetup à Milan : que retenir de cette réunion d'opérateurs OpenStack ?

Introduction

Il y a principalement deux occasions au sein d'un cycle de développement d'OpenStack pour les que les opérateurs (Ops) puissent échanger en face à face :

Ce n'est que la seconde fois que cet événement se déroule en Europe, et c'est à Milan pour ce premier Ops Meetup de l'année. Kevin et Adrien on fait le déplacement pour participer à ces deux journées d'échanges.

Comme lors des sessions Ops des Summits, l'idée est pour les opérateurs d'échanger bonnes pratiques, problèmes rencontrés, solutions trouvées et axes de travail sur tous les sujets liés à OpenStack en conditions réelles : du déploiement aux upgrades en passant par la gestion des patches ou les challenges de passage à l'échelle.

Nous avons décollé pour Milan ce mercredi matin avec l'idée notamment de discuter containers et surtout Magnum, le composant d'OpenStack permettant de déployer des moteurs d'orchestration de conteneurs (COE pour Container Orchestration Engine).



Qui fait le déplacement ?

Sur la bonne centaine de participants, on retrouve beaucoup d'opérateurs de cloud publics et privés, ainsi que quelques consultants. Des représentants de tous les continents ou presque, avec évidemment une majorité d'Européens.

On note que les outils de déploiement utilisés vont de la solution maison à OpenStack-Ansible en passant par une base CFEngine, TripleO et Puppet-OpenStack; on retrouve très peu de solutions "éditeurs" voire propriétaires. Cela n'empêche pas que beaucoup de déploiements ne soient pas encore totalement à jour (en Ocata) !


OpenStack sandwich ?

Vous en aviez déjà marre en 2016 ? 2017 n'est pas non plus la bonne année pour détester les conteneurs. La tendance se confirme ici également avec des sessions découpées en deux morceaux tellement il y a de choses à dire et avec deux sujets bien différents :

  • Les conteneurs sur OpenStack
  • OpenStack dans des conteneurs

Et par extension : les conteneurs qui tournent sur OpenStack qui tourne dans des conteneurs #mindblown.

Pour rappel pour la suite, il existe deux type de conteneurs :

  • Les conteneurs systèmes : notamment LXC/LXD qui font fonctionner un OS entier de la même manière qu'une VM, à l'exception du kernel.
  • Les conteneurs process : Docker/RKT qui sont destinés à un temps de vie plus court et font fonctionner en général un seul processus.


OpenStack on Containers - #pad



Dans les faits les conteneurs sont plus simples et plus flexibles que de gérer un système "classique". Ils permettent d'éviter notamment les cas de dependency hell entre les différents composants. Par exemple pour OpenStack, chaque projet a des requirements en terme de packages, qu'ils soient Python sur pypi ou des binaire spécifiques à la distribution utilisée. Une des réponses déjà utilisée par un grand nombre de déploiements est le virtualenv qui permet d'isoler les binaires Python entre eux mais ce n'est pas suffisant.

Avec les conteneurs, on se détache encore un peu plus du materiel et de la distribution utilisée (oui oui, bien sûr un conteneur se base sur une distribution) et c'est là tout l'intérêt : avoir des méthodes de déploiement idempotentes peu importe l'infrastructure sous-jacente.

Il existe pour le moment deux méthodes de déploiement basées sur les conteneurs :

OpenStack-Ansible est plus mature et stable, c'est celle que nous utilisons et déployons actuellement pour beaucoup de clients. Les conteneurs sont déployés avec LXC pour la partie control plane et les compute sont toujours en bare-metal. La configuration est réalisée entièrement par Ansible, c'est simple, bourré de fonctionnalités et cela fonctionne.

Kolla Ansible fait globalement la même chose mais en déployant des conteneurs Docker.

Les deux solutions sont plutôt statiques, il n'y a pas de notion avancée de scheduling, de redémarrage de services, etc. La grosse nouveauté et tendance (qu'on soit clair personne ne le fait encore), ce serait de pouvoir utiliser les super fonctionnalité de Kubernetes pour faire fonctionner OpenStack. C'est le but de Kolla Kubernetes.

Alors pourquoi Kubernetes ? Déjà parce que Kubernetes c'est cool, et également parce qu'il dispose de plein de fonctionnalités qui vont permettre de deployer et scaler facilement le control plane :

  • Services Load Balancing : (bye bye HAproxy)
  • Deployment : résilience native des conteneurs stateless (API)
  • StatefulSet : résilience des application stateful (RabbitMQ, Galera)
  • Jobs : Pour les tâches de setup (DB migration, initialisation, etc.)

Pour le moment très peu de personnes utilisent ou ont déjà testé ces différentes solutions mais on semble avoir atteint un consensus sur la facilité de gestions apportée par les conteneurs et la volonté de les utiliser pour déployer et piloter OpenStack.

Il ne reste plus qu'à répondre à toutes les autres question soulevées par les Ops comme par exemple la nécessité de faire fonctionner des conteneurs en mode privilégié pour les services de compute OpenStack, comment gérer les updates/upgrades (questions éternelle et valable pour tous les types de déploiement d'OpenStack) ou encore l'accès au matériel depuis les conteneurs (PCI passthrough, SR-IOV).

En plus des projets officiels, des éditeurs se sont également lancés pour faire fonctionner OpenStack dans des containeurs, comme par exemple Mirantis ou CoreOS.

Ce sera sûrement un des points les plus important pour le futur d'OpenStack.


Containers on OpenStack - #pad



Ici, les projets OpenStack évoqués sont Magnum et Zun. D'abord Magnum, qui vise à permettre le déploiement de COEs (Kubernetes, Swarm, etc.) sur des ressources d'infrastructure par les autres composants d'OpenStack. Zun prend une approche différente en souhaite directement offrir une API de manipulation de conteneurs.

Le constat : comme on pouvait s'y attendre, peu d'utilisateurs de Zun à l'heure actuelle, mais nous réalisons également que Magnum reste encore nouveau et au stade d'évaluaton pour beaucoup d'opérateurs. Sur ce point nous avons ainsi pu partager notre expérience récente et les travaux que nous réalisons au sein de la communauté sur les drivers Magnum.

Des solutions alternatives sont également évoquées. Ne pas utiliser de composant OpenStack spécifique aux containers, et se contenter de mettre en oeuvre des outils comme Terraform, Kubernetes Kargo ou encore Kubeadm.


Méthode de déploiement - #pad



Sujet simple mais avec en réalité beaucoup de ramifications. L'idée n'était évidemment pas de déterminer quelle méthode est la meilleure, mais plutôt d'identifier les éléments auxlesquels les opérateurs accordent de l'importance, ainsi que les problématiques communes à toutes les solutions.

Faire tourner les services OpenStack dans des containers, bonne ou mauvaise idée ? Ce sujet déborde évidemment sur la session "OpenStack sur des containers" mais ne se limite pas aux containers Docker, OpenStack-Ansible utilisant par défaut LXC (containers systèmes) pour déployer les services OpenStack. Le consensus est que dans tous les cas, séparer les services OpenStack dans leurs containers simplifie grandement la maintenance de la plateforme.

Intérêt pour AIO ? AIO pour All In One, c'est-à-dire la capacité pour une méthode de déploiement de déployer (facilement) OpenStack sur une seule machine. Beaucoup d'opérateurs apprécient la fonctionnalité, que ce soit pour pouvoir tester la méthode, tester des choses spécifiques dans OpenStack, ou encore faire des démonstrations.

Enfin, la capacité de réaliser les mises à jour majeures d'OpenStack reste un point crucial pour tous.


Nouveauté Nova : cells v2 - #pad

Session intéressante sur une fonctionnalité qui arrive réellement avec la version Ocata : les cells v2 dans Nova. v2 car Nova supportait déjà auparavant les cells, fonctionnalité notamment utilisée par le CERN dont un représentant modérait la session.

Les cells (cellules en Français) permettent de faire passer à l'échelle un déploiement de Nova. Comment ? Principalement en déployant de multiples bases de données MySQL/MariaDB et bus de messages RabbitMQ (1 par cell). Seuls les déploiements de très grandes tailles nécessitent l'utilisation des cellules.

Cells v2 résout un certain nombres de limitations de v1, mais en même temps apporte son lot de questions notamment pour la problématique de migration v1 -> v2. Malheureusement, aucun développeur Nova n'était présent dans la salle (c'est un Ops Meetup après tout !). Boston devrait être l'occasion d'organiser une discussion entre Ops et développeurs Nova sur le sujet.


OpenStack se cloudifie ? Go Go Go

À la fin de la journée, juste avant la session feedback, Monty Taylor demande à l'assemblée "Would you come at me with forks and shovels if we build a hard dependency on etcd?"


Qu'est ce qu'etcd et pourquoi ce choix ?

Etcd est la solution de stockage clé / valeur developper à la base par CoreOS et bientôt dans la CNCF (Cloud Native Computing Foundation). Il en existe d'autres comme Consul ou ZooKeeper mais Etcd un peu devenue la solution de choix. Elle est par exemple utilisée en tant que backend par Kubernetes.

Réaction mitigée de l'assemblée, pour plusieurs raisons :

  • Peur de CoreOS
  • Peur du Go
  • Un autre service pré-requis à OpenStack (hard dependency)
  • J'utilise déjà le service X

Alors pourquoi utiliser un K/V (Key/value) store ? Il viendrait se rajouter à la suite MySQL/MariaDB et RabbitMQ et permettrait aux projets de l'utiliser en tant que solution de stockage distribuée par exemple pour stocker de la configuration ou pour du service discovery.

Sans cette solution, les développeurs pourraient potentiellement créer des interfaces afin d'abstraire les solutions existantes et ainsi laisser le choix du K/V à l'operateur et/ou la solution de déploiement d'OpenStack utilisée. Cette solution plus ouverte pourrait cependant ralentir les releases de certaines fonctionnalités car elle ajoute son lot de travail supplémentaire pour supporter de multiple backends.


Conclusion

Notre avis sur cet Ops Midcycle Meetup ? Définitivement ce fut deux journées extrêmement productives !

Par rapport à un OpenStack Summit, beaucoup de facteurs font la différence :

  • Beaucoup moins de personnes sont présentes (100 vs quelques milliers)
  • Tout le monde est là pour se concentrer sur un seul sujet, pas de conférences à donner ou écouter, pas de stands à parcourir (et de goodies à collectionner), pas de réunions partenaires/clients, pas de vendeurs (de matériel, de solutions propriétaires, de distributions OpenStack)

Nous sommes ainsi très satisfaits d'avoir fait ce déplacement, nous repartons avec plein de bonnes idées pour nos actuels et futurs projets client et plein d'axes de travail au sein de la communauté.

Le programme complet de ces deux jours avec les liens vers les pads utilisés pour la prise de note est disponible dans ce document

Enfin à noter le pad de travail est ouvert aux suggestions pour le programme des sessions Ops du prochain Summit : https://etherpad.openstack.org/p/BOS-UC-brainstorming

On embarque pour le vol retour, RDV à Boston !

Adrien Cunin
Kevin Lefevre

⭠ Retour à la liste des articles

Découvrez les derniers articles d'alter way

Découvrez les technologies d'alter way