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

¡ Holà !

Le rythme est désormais connu, 2 ans après le Summit de Paris, OpenStack revient sur le Vieux Continent et pose ses valises dans la capitale Catalane. Newton, la 14ème release d'OpenStack est sortie il y a quelques semaines, c'est donc le moment de découvrir ses nouveautés ainsi que de préparer le prochain cycle avec la release Ocata. Il est intéressant de noter que dû aux changements de rythme entre les Summits et les releases, le cycle d'Ocata durera seulement 4 mois. Sa sortie est donc prévue pour fin février permettant ainsi d'avoir un Summit (à Boston) en mai et donc avoir de réels retour sur la dernière release du projet OpenStack, ainsi que des informations de la part des développeurs sur la release à venir quelques mois plus tard. On peut donc s'attendre à une sortie de Pike (la 16ème release) 3 mois avant le Summit de Sydney en novembre prochain.

Mais quel que soit le rythme, Osones est présent toute la semaine pour suivre et participer à cette semaine majeure dans l'écosystème OpenStack.

Keynotes

La traditionnelle keynote d'ouverture ne change pas vraiment avec le temps. C'est Mark Collier, Chief Operating Officer de la Fondation OpenStack qui s'est chargé d'être le maître de cérémonie.

Cette keynote lancée sous le hashtag #RunsOnOpenStack a tout d'abord mis en lumière un nombre important de participants pour lesquels Barcelone est le premier Summit. Nous apprenons aussi que 5000 administrateurs sont maintenant certifiés par la Fondation. La Certified OpenStack Administrator est une certification lancée il y a 6 mois par la Fondation et pour laquelle Osones compte actuellement 4 certifiés (et parmi les premiers, s'il vous plait !).
Les stats continuent avec celles de Newton : 2500 contributeurs !

Et pour finir, la présentation officielle du nouveau logo OpenStack (vieux de 6 ans), définitivement plus flat, plus en accord avec la "mode graphique" actuelle, après les goûts et les couleurs, on vous laisser vous faire votre avis ;)

Le marketplace ayant ouvert dès hier soir, l'activité principale du Summit - la chasse aux goodies - avait pris un peu d'avance et nous pouvions donc nous concentrer sur l'activité très secondaire de cet évènement : les conférences !

What's OpenStack/Qu'est-ce qu'OpenStack ?

Thierry Carrez, le "Director of Engineering at OpenStack Foundation", prend le risque de rappeler l'évidence. Mais est-ce vraiment une évidence pour tout le monde ?

Alors, OpenStack c'est : une marque déposée, une production upstream industrialisée, des événements tout autour de la planète, un standard d'interopérabilité, un marché de l'emploi,...

OpenStack, c'est aussi et à la fois :

- 31 projets unitaires hébergés dans la "Big Tent" (à l'heure de la release Newton)
- Un seul et même grand projet supervisé et sécurisé par le Comité Technique, ceci afin d'apporter le meilleur niveau de cohérence et de pérennité globale pour délivrer une expérience Utilisateur optimale.

Mais comment déterminer si un projet peut devenir un "projet OpenStack" ? Pour Thierry Carrez, la réponse est simple à présent : il suffit que le problème adressé par le projet soit en ligne avec la mission d'OpenStack !

OpenStack, c'est bien entendu du code "ouvert". Mais c'est aussi une communauté ouverte, un design ouvert et un développement ouvert.

Profitons-en pour rappeler que le développement d'OpenStack est indépendant, avec un grand "I", dans le sens où le pilotage des différents projets doit absolument rester en ligne avec la vision des équipes de développement, faute de quoi il prendrait le risque que ces mêmes équipes forkent le code et aillent développer ailleurs ! Depuis le début de l'histoire d'OpenStack, les développeurs sont placés au centre du jeu. Les PTL (Project Team Lead) sont élus par les membres de la Fondation pour une période courte de 6 mois, ce qui assure un alignement fort entre eux et les contributeurs.

Pour finir, pêle-mêle, OpenStack c'est :

• L'usage intensif du langage Python (et de son outillage) : langage facile à apprendre, facile à lire, familier des équipes d'ops, en standard dans toutes les distributions Linux. (Ceci dit, gardons un œil attentif sur les langages émergents tels que Golang...)
• Une usine d'intégration continue robuste et efficace qui repose sur les revues de code, les "gated commits" et les tests automatisés (23.000 / jour en septembre 2016)
• Un projet open source très actif : plus de 90.000 commits de septembre 2015 à août 2016.
• Une machine bien huilée à produire du logiciel

Bref, une belle success story !

Le réseau dans un monde de conteneurs

Un nouveau (énième ?) talk sur les conteneurs et les problématiques réseaux qui en découlent.

Docker est le seul runtime considéré pendant ce talk. De base, le bridge docker0 permet d'avoir sur plusieurs hosts un seul et même adressage IP. Cela reste pratique lorsque les workloads déployés sont mono-host mais cela pose évidemment problème en multi-hosts.

Pour cela plusieurs solutions existent, la plus déployée actuellement est l'utilisation de réseaux overlays (VXLAN). Des conteneurs situés sur différents hosts peuvent ainsi communiquer au sein d'un même réseau L2. Un avantage certain est de ne pas avoir à gérer les plans d'adressage de ces VXLAN, ceux-ci étant encapsulés chacun dans un tunnel. Les problèmes en revanche sont assez évidents, baisse de perf due à l'encapsulation et difficultés pour débuguer. Une autre approche est celle de Calico qui se base uniquement sur un réseau full L3. Les containers et instances sont annoncés par des /32 (ou /128 en IPv6) via le protocole BGP et les requêtes ARP sont résolues par les MAC des computes (hosts Docker ou KVM).

Néanmoins des challenges sont encore à relever. Du fait de la segmentation toujours plus importante en microservices des applications, les services discovery ainsi que le DNS deviennent des élements clés de l'infrastructure. Un microservice tournant en multi-hosts doit pouvoir être joignable peu importe si un des ses conteneurs tombe.

Pour cela on prend en considération un modèle de "consommateur/producteur". Les producteurs étant les services déployés et les consommateurs étant les ressources qui vont consommer ces services. Au lieu de laisser les consommateurs "découvrir" quels services leur sont offerts, on préfère, au moyen d'un KeyValue Store, laisser les producteurs annoncer eux mêmes quels services (IP, port, etc) sont disponibles. Le DNS vient aussi jouer un rôle important et on peut vouloir descendre le TTL des annonces à 0 afin de fallback très rapidement sur un autre conteneur. Malheureusement certaines applications ne respectent pas toujours ce TTL ce qui engendre des downtimes qui ne devraient pas avoir lieu avec des applications complètement stateless.

Designate - The "Why" and the "How"

Trois speakers/contributeurs de HPE & Rackspace ont fait un point sur Designate en évoquant les raisons du projet et une façon de l'implémenter dans une organisation établie.

Designate est un DNS as a Service : il fournit à vos utilisateurs la possibilité de créer, modifier et supprimer des enregistrements DNS. Pourquoi ?

• Parce que créer un ticket pour faire modifier une entrée DNS est souvent source de confusions, d'erreurs et de délais très importants
• Parce que dans le contexte d'une utilisation d'IaaS, les clients veulent pouvoir disposer d'un hostname résolvable pour accéder à leurs services plutôt que de s'adresser directement à l'adresse IP

L'architecture de Designate est très modulaire. En particulier, les serveurs DNS qui seront exposés sur internet (ou ailleurs) peuvent être gérés par différents backend. Ainsi, il est possible que ces DNS soient hébergés par des instances OpenStack, mais il est aussi possible de déléguer ce rôle à un prestataire tel que Dyn ou Akamai. Ces prestataires proposent de l'anti DDoS, ou encore une présence anycast qui est quelque chose d'assez difficile à produire soi-même.

Designate a une notion de pools, ce qui permet d'avoir des configurations DNS (et leurs implémentations) indépendantes. Cela permet de répondre aux besoins nécessairement non standards de certains clients.

L'organisation dans laquelle vous implémentez OpenStack a très probablement déjà une infrastructure DNS, et celle-ci est hautement critique. Les speakers nous proposent une introduction de Designate étape par étape qui permet de mettre en confiance l'entreprise quant à la stabilité de la solution :

• Mettre en place Designate avec une délégation d'un sous-domaine : par exemple labs.societe.com. Faire servir cette zone par un backend "simple" : bind, unbound, ...
• Permettre aux clients de l'OpenStack de créer des sous domaines à cette délégation. Leur faire comprendre que cela fonctionne.
• Configurer un backend plus conventionnel pour l'organisation : si elle utilise Akamai, utiliser le backend Akamai puis y migrer la délégation.

À la fin de ces étapes, les utilisateurs peuvent commander leurs enregistrements avec Designate, et ceux-ci sont servis par les processus normaux de l'entreprise. Une fois que l'entreprise a confiance, on peut migrer une plus grande portion du domaine dans Designate.

Mirantis Evolve or die.

Ma première conférence sera celle de Mirantis : il s'agit d'une presentation de la nouvelle version de leur projet Fuel, appelé MCP pour Mirantis Cloud Plateform.

Mirantis insiste sur l'importance d'avoir un outil qui gère le cycle de vie complet du cloud. La partie déploiment n'est pas la plus difficile, la plus complexe est l'exploitation et la mise à jour de la plateforme. L'outil de Mirantis utilise :

• Gerrit (pour la gestion des fichiers de conf yaml)
• Kubernetes
• Docker
• Jenkins
• OpenStack-Salt (qui n'est plus un projet officiel depuis quelques semaines).

CERN

Retour d'expérience du CERN, sur leur projet de migration de nova-network vers Neutron. Le CERN traite 1Po de data par jour sur deux datacenter (à Genève et à Wigner). Le réseau du CERN est assez simple, il n'y a pas de réseau overlay, donc la configuration est flat.

Cette migration de nova-network à Neutron n'étant pas officiellement supportée par OpenStack, le CERN a dû developper un plugin pour Neutron permettant de gérer la déclaration et la suppression des ports Neutron dans une base de données du CERN (nécessaire pour le fonctionnement des IPs). Cette démarche n'est possible que grâce à la grande flexibilité de Neutron (cf. notre récent article sur Neutron).

On note également que le CERN utilise les cells Nova pour cloisonner son cloud. Ce cloisonnement permet de limiter la charge du scheduler et du conductor. Lorsque le CERN déploie du nouveau matériel, il le fait dans une nouvelle cell Nova.

Manila

Cette conférence présentée par NetApp et Red Hat a mal commencé. Même s'il est vrai que la migration d'applications existantes dans le cloud est courante, cette migration n'est pas conseillée : les applications devraient être redesignées pour tirer avantage du cloud, celui-ci n'étant pas "que" de la virtualisation comme certains acteurs peuvent le présenter. En tout cas, cette démarche existe bien, et vu l'importance du file access storage (60%) dans l'existant, le Shared Filesystem d'OpenStack (Manila) prendra de l'importance.

Manila est aujourd'hui assez mature pour envisager une utilisation en production si l'on ne souhaite pas utiliser des fonctions assez avancées qui sont encore en mode experimental (c-à-d qu'elles peuvent encore être retirées).

Automation born in cloud

Keith Tenzer, Solutions Architect chez Red Hat, a présenté la nécessité d'automatiser ses déploiements applicatifs. Il a insisté sur le fait que l’automatisation permettait de mettre l’effort sur l’innovation plutôt que sur la construction. Il a d’ailleurs comparé l'industrialisation de l'IT avec celle de l'industrie automobile, 90% des employés des compagnies travaillent dans l'innovation et non dans la construction des voitures. La construction est maintenant gérée par des chaines de plus en plus automatisées (et M. Ford n’y est pas pour rien).

Les constructeurs automobiles emploient des personnes qui innovent et non des gens qui construisent les voitures, nous devons en faire autant dans l'informatique.

Si on parle d'automatisation dans OpenStack, il faut immédiatement penser à Heat qui est le module d'orchestration de la solution. Couplé avec Ansible, cela permet de créer des stacks de ressources (OpenStack) et d'implémenter les configurations des instances. Keith Tenzer nous a également parlé d'Ansible Tower, un outil permettant de gérer une infrastructure de serveurs, avec monitoring et tableaux de bord intégrés. C'est une surcouche à Ansible le rendant plus "user-friendly". Suite au rachat d'Ansible pa Red Hat il y a un an, Ansible-Galaxy a été opensource très récemment et on espère qu'aAnsible Tower le deviendra lui aussi très bientôt.

Gestion des bugs de sécurité

Tristan Cacqueray, membre de la Vulnerability Management Team (VMT) et et Matthew Booth, développeur Nova, présentent lors de cette conférence le process lorsqu'une faille de sécurité est identifée dans OpenStack. Pour cela, les deux orateurs prennent en exemple un cas réel dans Nova, le service de Compute d'OpenStack.

Lorsque quelqu'un a connaissance d'un bug de sécurité, il doit le rapporter dans Launchpad, l'outil actuellement utilisé par OpenStack pour le suivi des bugs. Néanmoins il doit le signaler comme ayant trait à la sécurité, ce qui rend de fait le rapport invisible publiquement. C'est l'équipe VMT d'OpenStack qui est alors notifiée et qui prend le relai. Évaluation du sérieux du rapport, de l'impact potentiel de la faille, de la qualité du patch éventuellement proposé, tout ce travail est réalisé en collaboration avec des membres de l'équipe projet impactée. Cette phase reste confidentielle, et c'est là un des seuls process OpenStack qui fait exception aux 4 Opens, ce afin de garantir au mieux la sécurité des clouds OpenStack. Par la suite, la faille et son correctif sont progressivement divulgués à un cercle restreint de développeurs, notamment les intégrateurs (distributions Linux, etc.) puis au public. C'est à cet instant qu'un OpenStack Security Advisory (OSSA) est communiqué. Dans certains cas, il peut plutôt prendre la forme d'une OpenStack Security Note (OSSN).

Plus d'informations sur le sujet sont disponibles ici et là.

Design session: logging et monitoring (Monasca)

Il s'agit d'un grand échange entre les utilisateurs et les développeurs. Il permet aux utilisateurs de comprendre les problématiques des développeurs (comme le background de certains projets) et aux développeurs de comprendre les problématiques qu'on peut rencontrer dans des environements atypiques pour eux.

Parmis les problématiques abordées, on peut parler de rendre le format des logs homogène entre les differents projets OpenStack, éradiquer les messages d'erreur sur plusieurs lignes et la possibilité de remonter les logs à plusieurs agents simultanément nativement.

On remarquera que la solution EKL est très répandue chez les opérateurs de cloud.

L'équipe Osones