Osones vous propose de vivre le Summit OpenStack 2016 de Barcelone !

¡ Buenos Dias !

La keynote de ce matin était animée par Jonathan Bryce, Chief Executive Officer de la Fondation OpenStack. Beaucoup de variétés dans les sujets abordés, on retiendra notamment le passage d'Elizabeth K. Joseph, core développeuse sur le projet OpenStack-infra. Ce projet maintient toute la chaîne d'intégration continue (CI) permettant de valider, reviewer et merger les patches dans OpenStack. On notera que 8 cloud providers (dont nos amis roubaisiens d'OVH) fournissent de l'infrastructure pour cette CI, sur 12 régions. Un million (vous voyez ce que ça fait déjà, un million, Larmina ?) de jobs lors des six derniers mois, de 10000 à 20000 instances créées.

Les breakout sessions

Controlling Access to OpenStack in the Enterprise: This is Not a Public Cloud!

Dans cette présentation, Shaun O’Meara, architecte et contributeur OpenStack employé par Mirantis nous fait un point sur les problématiques liées à AAA (Authentication, Authorization, Accounting) rencontrées en entreprise et les solutions, actuelles et futures, qui peuvent être apportées.

Les entreprises veulent :

• De multiples backend d'authentification : problématiques de filiales, avec des niveaux de confiance différents
• Une intégration dans leurs outils AAA existants : ceux-ci ont déjà pris un temps (et un budget considérable) pour être implémentés, il est hors de question de tout remplacer
• Un contrôle d'accès granulaire : certains administrateurs doivent pouvoir créer des projets OpenStack sans néanmoins pouvoir accéder aux contenus de ceux-ci
• Une séparation des privilèges (pour des raisons réglementaires, notamment dans la finance ou le médical)
• Un workflow pour autoriser les actions (= qui valide que tel client peut avoir un quota augmenté ? probablement pas la même personne que celle qui est en capacité d'effectuer cette action)

La fonctionalité de RBAC (Role-Based Access Control) dans OpenStack doit répondre à ces problématiques. Cependant, son implémentation est jeune et encore imparfaite :

• Pour l'instant, chaque instance de chaque service possède un fichier policy.json
• Celui-ci est évalué à chaque appel de l'API
• Il s'agit du travail de la classe enforcer dans oslo

Il nous manque, entre autres :

• Une journalisation positive de chaque action faite par les clients, afin de pouvoir certifier qu'une personne a accedé (ou non) à une ressource donnée
• Une syntaxe plus facile à lire et à comprendre pour le policy.json
• Une synchronisation des règles : actuellement, tous les fichiers policy.json de chaque démon doivent être modifiés par un administrateur, il n'y a pas de point central de configuration

Des améliorations sont néanmoins déjà en route :

• La syntaxe du policy.json va être migrée vers du YAML, ce qui signifie la possibilité d'utiliser des mécanismes d'héritage/override comme avec Hiera
• La possibilité de faire des commentaires inlines sans casser le fichier
• La possibilité de "plugger" des classes enforcer tierces : les modules tiers pourront par exemple proposer la centralisation des autorisations (dans un LDAP ou un SQL par exemple)

Serverless applications avec OpenWhisk et Swift

Le concept d'applications serverless est apparu lorsque Amazon Web Services a lancé Lambda. Lambda est un service permettant d'exécuter du code en réponse à un évènement. L'intérêt de l'utilisateur en ce qui concerne AWS c'est qu'il ne paye que le temps d'exécution de la fonction Lambda. Celui-ci étant souvent compté en millisecondes, la facture est relativement appréciable.

Dans le cadre d'une API, ce genre de service est apprécié, chaque call à l'API peut par exemple déclencher une fonction Lambda pour effectuer l'action attendue.

IBM est le développeur d'OpenWhisk et présente ce produit ainsi :

• Le développeur spécifie des Rules
• Celles-ci gèrent la façon dont les Actions gère les events

Les actions peuvent actuellement être écrites en Java, Python, Javascript ainsi qu'en "image-docker". Ce qu'on entend par là c'est qu'un conteneur docker peut être instancié et faire tourner son propre code. On devient à ce moment libre d'utiliser le langage de notre choix.

• Le tout est déclenché par des Triggers

Pour la démonstration, les ingénieurs d'IBM ont repris exactement le même type de tutoriel présenté par Alexis. Il s'agit d'uploader une image sur Swift et de faire en sorte qu'OpenWhisk traite cette image (en la redimensionnant) et pousse la nouvelle image dans un second container Swift. La principale difficulté est de faire communiquer OpenWhisk et Swift. En effet, chez AWS on peut directement configurer S3 pour aller toquer à la porte de Lambda lorsque un événement survient, chez Swift ça n'est nativement pas possible. Il faut pour cela passer par un middleware qui étend les fonctions de Swift lui permettant de déclencher une action OpenWhisk.

Ce genre d'architecture a le vent en poupe depuis la sortie de Lambda chez AWS (on peut aussi citer API Gateway) et permet d'importantes réductions de coût.

Neutron est-il pret pour les cloud à grande échelle ?

Cette présentation est un retour d'expérience de Mirantis sur un test de charge. Ce test a mobilisé une équipe de 12 personnes sur 3 jours.

La plate-forme de test est équipée de Neutron avec le plugin ML2 utilisant OpenVSwitch (configuré pour encapsuler en VXLAN), la fonctionnalité DVR (routeur virtuel distribué) a été utilisée, mais seulement les contrôleurs avaient une interface vers le réseau public. La plate-forme dispose de deux contrôleurs et de 357 computes avec des interfaces de 10Gbs.

Pour tester la plate-forme, Mirantis a utilisé le projet OpenStack Rally et un outil déployé en interne appelé Shaker (https://github.com/openstack/shaker). Cet outil utilise des templates Heat pour monter des instances et exécuter iperf pour vérifier les débits entre ces deux instances.

Le résultat de cette expérience a confirmé les points suivants :

• Activer le jumbo frame est fortement recommandé : le passage du MTU 1500 à 9000 permet de multiplier les débits par 7
• Activer le HW offload améliore les performances, surtout avec un MTU de 1500 où le gain est de 350%

Ces points ne sont pas une surprise car le VXLAN encapsule le trafic inter-instances, ce qui entraine une diminution du débit utile et des problèmes de segmentation des trames.

Le test a surtout permis de démontrer que dans ces conditions Neutron est capable de supporter un cloud comprenant plus de 300 computes et plus de 24K instances. Le trafic est-ouest n'a pas montré de limitation due à l'architecture de la plate-forme. Cependant le trafic nord-sud a été limité par la capacité des deux interfaces de sortie se trouvant sur les contrôleurs.

Kolla Kubernetes

Le projet Kolla est parti du simple constat qu'OpenStack n'est finalement qu'un ensemble d'applications, et ce nombre d'applications ne fait qu'augmenter au fil des releases.

De nos jours, la meilleure façon de gérer des micro-applications est d'utiliser les conteneurs ! Le cycle de vie des conteneurs se divise en deux grandes tâches, le build et le deploy. Maitriser le build permet de maitriser la version de l'application, ce qui est très pratique avec OpenStack.

Le projet Kolla utilise déjà Docker mais le projet Kolla Kubernetes souhaite utiliser Kubernetes pour l'orchestration de ces conteneurs Dockers.

Le projet Kubernetes regroupe chaque service OpenStack dans des pods, chaque service dispose d'une VIP gérée nativement par le "service registry" de Kubernetes. Kubernetes permet les fonctionnalités suivantes:

• autoscaling : qui peut se reposer sur le temps de réponse d'un service ou sur la charge CPU
• le déploiement, la mise à jour des conteneurs
• pet set (gestion des applications stateful), pour la base de données, ou d'autres applications stateful
• storage management, monter les volumes nécessaires à ses conteneurs au besoin

Les volumes persistants comme le volume qui contient la base de données MySQL sont gérés par Ceph.

La présentation a fini sur une démonstration de la capacité de la solution à gérer les erreurs dues au matériel. Elle a consisté à faire tomber un des 3 hôtes hébergeant plusieurs services. Kubernetes a détecté la perte de l'hôte et a remonté les pods manquants sur les hôtes restants. Parmi ces conteneurs se trouvait le conteneur de MariaDB, son montage disque a été remonté sur le nouvel hôte.

Chez Osones, nous espérons que cette solution qui ressemble beaucoup à Stackenetes sera rapidement mature.

Organiser un OpenStack Day

Voilà une session un peu particulière et totalement d'actualité pour l'équipe Osones.
Particulière car il ne s'agissait officiellement ni d'une conférence, ni d'une session de travail, mais d'un panel. Cinq personnes, ayant déjà organisé un OpenStack Days, étaient invitées à faire un feed-back de leur expérience, mais la discussion était en réalité ouverte au public, ce qui a rendu les échanges d'autant plus intéressants. D'actualité pour Osones, car nous travaillons à l'heure actuelle, avec un certain nombre d'autres membres de la communauté OpenStack-Fr, à l'organisation du premier OpenStack Day France. En effet, l'OpenStack Day France 2016 aura lieu le 22 novembre prochain à Paris.

Ainsi, de multiples sujets ont pu être abordés :

• Pourquoi organiser un OpenStack Day ? Pour rassembler les acteurs du marché afin de promouvoir la technologie et l'expliquer, mais aussi pour développer le marché qui entoure l'écosystème OpenStack.
• Comment gérer les finances ? Qui prend la responsabilité de signer les contrats (location du lieu, etc.) ? Souvent, il s'agit d'une des entreprises qui co-organise l'événement, dans de plus rares cas il s'agit d'une personne individuellement ou bien d'une organisation indépendante, comme c'est le cas pour l'OpenStack Day France avec l'association des utilisateurs francophones d'OpenStack.
• Les organisateurs travaillent-ils sur le sujet directement pour le compte de leur entreprise ou sur leur temps libre ? Généralement, la réponse est "les deux". En tout état de cause, la préparation d'un événement d'une telle ampleur nécessite une sérieuse implication et notamment durant les derniers mois.

Ce ne sont ici que quelques éléments de discussion, et il s'agit d'un sujet typiquement "communauté" que l'on ne retrouve pas de manière aussi prépondérante dans d'autres écosystèmes. C'est un point structurant dans le succès du projet OpenStack.

Applications orientées API et micro-services - Intel, Yih Leong Sun

Au début, il y avait l'application monolithique : un ensemble de type LAMP, avec toutes les fonctionnalités de l'application dans une seule entité, Apache en frontal pour traiter les requêtes http et MySQL en backend pour le stockage persistant des données. Ce type d'application présente au moins deux grands inconvénients hérités justement du caractère monolithique :

• si l'on doit mettre à l'échelle (scaler), on le fait d'un bloc, toutes les fonctionnalités en même temps
• un bug classique du genre fuite de mémoire peut mettre par terre la totalité des fonctionnalités de l'application.

Puis sont apparues les applications SOA (Service Oriented Architecture) : des web services, des entités "métier" et un service de files de messages pour la communication entre les entités. Mais ces applications se sont avérées complexes à développer, maintenir et opérer. Par conséquent, elles ne paraissent plus capables de faire face aux nouveaux challenges de la compétition économique : course à l'innovation, nécessité de saisir les opportunités du marché, être agile dans un environnement changeant rapidement tout en s'intégrant facilement avec l'existant, etc.

La réponse à ces nouveaux défis ? Les applications orientées API et micro-services ! Prolongeant et simplifiant l'approche SOA, ces applications :

• exposent leurs fonctionnalités sous forme d'API REST
• s'appuient sur http pour transporter les requêtes via une passerelle d'API
• utilisent un service de files de messages pour faire communiquer les micro-services entre eux
• apportent indépendance et légèreté grâce à une approche super-modulaire

Cette nouvelle façon d'architecturer les applications apporte les bénéfices principaux suivants : modularité des fonctionnalités, isolation des services, possibilité de facilement mêler des briques technologiques différentes. À ce stade, soulignons deux conséquences immédiates de ceci :

• l'intégration continue (CI) de l'application devient plus facile à concevoir et à maitriser.
• chaque micro-service peut être déployé indépendamment des autres

Toutefois, ce lot de bénéfices s'accompagne de quelques difficultés potentielles : gestion globale complexe dans le cas des applications de nature distribuée, la division en micro-services amène à multiplier les déploiements et il peut s'avérer diffcile de garantir un ensemble cohérent.

À titre d'exemple, prenons une application permettant à des étudiants de gérer en ligne leurs inscriptions aux cours. Il est dans ce cas facile d'imaginer 3 micro-services : un pour prendre en charge les requêtes adressées à une entité "université", un deuxième pour les requêtes destinées à une entité "cours" et un dernier pour traiter les requêtes adressées à une entité "étudiants". Chacun de ces services possède sa propre API ainsi que la technologie de stockage persistant qui lui convient le mieux : par exemple MySQL pour les micro-services "université" et "étudiants" qui doivent gérer un modèle de données de type relationnel, et MongoDB pour le micro-service "Cours" qui tirera avantage de la notion de "collection" proposé par ce moteur NoSQL.

Mais ce n'est pas tout, qu'en est-il de la couche Infrastructure ? Nous sommes dans un Cloud, ne l'oublions pas, nous avons donc affaire à une infrastructure pilotée par des API. Nous avons donc tout ce qu'il nous faut sous la main - et surtout dans les APIs OpenStack - pour mettre en oeuvre un modèle de type "infrastructure immutable". On ne configure plus les serveurs virtuels mais on en instancie de nouveaux à chaque déploiement de l'application ou de modification de l'infrastructure elle-même !

Et si l'on associe tout cela à Magnum, le CaaS (Container As A Service) d'OpenStack, que l'on déploie nos micro-services dans des conteneurs et que l'on applique une stratégie de déploiement continu (CD) de type blue-green, on reste agile jusqu'au bout et parfaitement aligné sur l'esprit DevOps.

Agile dans le pilotage du projet, agile dans le développement de l'application, agile dans l'intégration et le déploiement de l'application et agile dans la gestion de l'infrastructure qui la supporte grâce à OpenStack, la boucle est bouclée !

OpenStack in the Wild ! How to Make OpenStack a Reality in Your Company

Grant Kirkwood, CTO de Unitas Global, conscient de la complexité de l’écosystème OpenStack a présenté sa vision pour que l’implémentation d’OpenStack en entreprise soit une réussite.

La première chose selon Grant est de se demander pourquoi OpenStack, car sans réel objectif, le projet sera un échec. Il faut donc s’inspirer des grosses « success stories », et comprendre les avantages d’OpenStack que l’on ne cesse de rappeler : agilité, flexibilité, pas de vendor lock-in, réduction des coûts, standardisation des APIs, etc. Grant Kirkwood a insisté sur l’importance du « Pourquoi » avant de penser au « Comment ».
Après le pourquoi vient donc le comment. Pour le comment, cela commence selon lui par l’identification des compétences de ses équipes et ensuite dans le choix de la construction ou de "l'achat" d'un cloud.

Si on construit soit même :

• Faut-il construire son propre cloud "vanilla" ? Ce qui est complexe mais qui a l'avantage d'être extrêmement personnalisable
• Faut-il passer par un revendeur de distributions OpenStack pour construire sa plate-forme ? Ce qui amène une adhérence avec le revendeur mais permet un support revendeur

Si on décide "d'acheter" un cloud : doit-on consommer une offre hébergée/managée ou acheter une appliance clé en main, ou même la nouvelle approche SaaS/Appliance hybride (dans lequel votre control plane OpenStack est en SaaS et vos computes des appliances on-premise) !

Si la raison de l'implémentation d'OpenStack est liée à votre cœur de métier il faut que vous considériez d'héberger votre plate-forme, voilà de précieux conseils de Grant Kirkwood avec lesquels nous sommes d'accord.

Il a ensuite parlé de l'importance de l'adoption de la plateforme, inutile de construire une plate-forme cloud si personne ne l'utilise. Il faut que ce soit simple pour que les gens s'en servent, donc faites quelque chose de simple ! Commencez petit en vous concentrant sur les services core. Puis ajoutez des services supplémentaires lorsqu'une réelle demande est identifiée. Laissez les futures utilisateurs essayer la plate-forme, c'est un des meilleurs moyens pour qu'ils l'adoptent ! Mais il faut encore penser à modifier ses processus pour que deux semaines et trois formulaires ne soient pas nécessaires afin d'avoir des ressources cloud ! Et la dernière chose est de monitorer l'utilisation de la plate-forme et de réaliser du reporting afin d'avoir les armes face aux réfractaires du cloud OpenStack !

À demain pour le jour 3 ;)

L'équipe Osones