OpenStack Summit Vancouver 2018

Pause Cloud & DevOps – édition spéciale OpenStack Summit Vancouver 2018

Jour 3

Vous n’avez pas pu venir à Vancouver pour assister à l’OpenStack Summit et vous souhaitez savoir ce qui est annoncé/présenté d’important ? Les consultants d’Objectif Libre sur place vous racontent.

Au menu : du cloud, de l’Open Source, du stockage, du réseau, de l’Open Infrastructure… tout ce qui fait OpenStack.

  • Zero to Continous Delivery
  • Vitrage
  • Encrypt your data with Barbican
  • Project Updates

Bonne lecture !

Pour lire le retour du jour 1 : https://olib.re/20180522-pause-openstack-summit-1

Pour lire le retour du jour 2 : https://olib.re/20180523-pause-openstack-summit-2

Zero to Continuous Delivery

Présenté par Liam Newman, Jenkins Contributeur

L’objet de cette conférence est d’apprendre à créer un pipeline de CI/CD from scratch sur Jenkins, en utilisant le plugin Blue Ocean, la nouvelle interface graphique de Jenkins. Celle-ci est basée sur Jenkins pipeline, un outil permettant de définir des pipelines (enchaînement de tests, de jobs) grâce à des Jenkinsfile, des fichiers avec une syntaxe plus simple que les jobs classiques en XML. La CI as code rend la CI accessible à l’ensemble de l’équipe technique.

Blue Ocean

Blue Ocean est un outil graphique permettant de créer des pipelines et de générer un Jenkinsfile, qui sera automatiquement poussé dans le dépôt du projet. Une fois créé, vous aurez la possibilité de modifier ce pipeline soit en mode graphique, soit en éditant le Jenkinsfile. Il offre également la possibilité de lancer des jobs en parallèle au sein d’une même étape. Une fois le pipeline lancé, vous pourrez facilement voir d’où provient l’erreur grâce à l’interface graphique.

Blue Ocean offre un support docker natif, ce qui facilite l’utilisation de frameworks de tests lourds tels que Maven ou Gatling.

Une autre fonctionnalité plutôt intéressante est le stash. Celui-ci permet de créer des artefacts lors d’une étape du pipeline et de les réutiliser lors d’une autre.

Start from Zero

Pour la démo, départ de zéro et arrivée avec un pipeline de déploiement continu.

Planning pipeline :

  • Stages:
    • build
    • test
      • unit
      • Perf
      • Front end
  • Static Analysis
  • Deployment

Toutes les étapes de la partie « test » sont parallélisées. Malheuruesement nous avons eu droit à un effet demo… L’étape build restera en FAILED.

Conclusion

Blue Ocean semble bel et bien fonctionnel et facilite l’accès au CI/CD pour l’ensemble de l’équipe technique.

 

Vitrage

Plusieurs conférences autour de Vitrage ont eu lieu ce jour :

  • Project Update & On-boarding
  • Proactive Root Cause Analysis

Rappel : qu’est-ce que Vitrage ? Pourquoi ?

Vitrage est le projet officiel de Root Cause Analysis (RCA) pour OpenStack. Il est utilisé pour l’organisation, l’analyse et l’amélioration d’alarmes et d’événements dans OpenStack.

D’un point de vue architectural, Vitrage utilise différentes sources de données. Les datasource permettent de proposer 2 éléments : topologie et alarme.
Afin de remonter les alarmes et événements en fonction de ces sources de données, Vitrage utilise un système de templates, modifiables par les administrateurs. Ces templates sont stockés en DB.

Fonctionnalités proposées :

  • Holistique et vue complète de l’infrastructure OpenStack
  • Organisation des alarmes et événements d’OpenStack
  • Déduction d’alarmes et d’états
  • Envoi d’informations (alarmes, états, etc.) au travers de notifications

Les principaux services sont :

  • vitrage-collector : récupère les informations depuis les sources de données (soit en push soit en pull)
  • vitrage-graph : stocke la topologie
  • vitrage-notify : envoi de notifications
  • vitrage-api : l’api

Vitrage propose aussi un dashboard offrant une visualisation à plusieurs niveaux (topologie, RCA, liens entre les services).

Root Cause Analysis (RCA)

La RCA est le fer de lance de Vitrage ! Grâce à ce principe, le debug d’une plateforme OpenStack est grandement facilité :

  • L’information est centralisée, de par des alarmes basées sur des métriques extérieures (ex : Zabbix & Prometheus), mais également via un dashboard explicite.
  • Automatisation du support niveau 1 :
    • Récolte d’informations pour le processus de debug
    • Exécution d’actions correctives automatiques (via Mistral). Exemple : anticiper le crash d’un compute en évacuant les VMs en amont.
  • Lancer des actions de diagnostic à la demande (ex : test mémoire, habituellement coûteux et ne pouvant pas être exécuté de façon périodique).

Monitoring réactif Vs monitoring proactif

It’s too late ! → Réactif :

  • Quand une erreur remonte, le problème est déjà présent
  • Aucune corrélation des alertes et événements (remontées unitaires)
  • Passif sur la remontée d’alertes

You still have chance ! → Proactif :

  • Quand une erreur remonte, le problème n’est pas forcément présent
  • Anticipation des erreurs
  • L’utilisateur final n’est pas encore affecté
  • Corrélation des alertes et événements
  • Déclenchement de diagnostics et d’actions préventives

Show time !

Dr. Liat Pele commente une démonstration (pas en live, dommage) du fonctionnement de Vitrage. Le lab :

  • 2 sources de données :
    • Prometheus
    • Zabbix
  • 1 cluster Kubernetes sur OpenStack
  • 1 événement perturbateur : stress CPU.

Workflow de la démo :

  1. Zabbix est utilisé pour prédire l’alarme « high CPU »
  2. Lancement du stress CPU
  3. Dégradation des performances sur la prod k8s
    • Prometheus remonte l’alarme high CPU
    • Zabbix remonte un warning de prédiction de surcharge CPU

Résultat : Vitrage déduit une nouvelle alarme « Host degraded performance »

Évolutions

Queens

  • Support de webhook (par ID, nom d’alarme, regexp, callback HTTP)
  • Bannière des alarmes actives dans Horizon (visibles dans tous les menus)
  • Amélioration des performances. Vitrage est testé et validé pour 60,000 entités
  • Gestion des traps SNMP
  • Amélioration des templates
    • API d’ajout / suppression de templates
    • Syntaxe : expressions régulières, fonctions, include

Rocky (à venir)

  • Une amélioration importante de la HA
  • Historique des alarmes dans le but de pouvoir faire de la RCA sur les alarmes de la veille ainsi que des statistiques
  • Vitrage ajoute aussi K8s (en tant que topologie de datasource) et Promotheus (pour les alarmes liées à K8s) en tant que Datasources
  • Un panel Horizon qui graphe des actions réalisées va bientôt être ajouté. Il sera possible de trier ou d’exécuter des actions directement.

Un travail autour du cross-project est en cours, en particulier avec congress et monasca.

Pour finir…

La présentation se termine sur une vision à long terme : pousser la RCA jusqu’à l’analyse des logs des différents composants (Bell Labs Change Detection System). À suivre !

 

Encrypt your data with Barbican

Par Duncan Wannamaker, OpenStack Engineer (OnRamp)

La première question est : pourquoi chiffrer ?
On pense bien sûr à la protection des données en cas de fuites, mais c’est également utile pour des besoins de compliance (légale en particulier).
Dans ce cas, quel est l’intérêt d’un gestionnaire de clés (Key Manager) ? C’est une bonne pratique de sécurité (pour la même raison que vous ne laissez pas vos clés de voiture sur le contact) et c’est également souvent un besoin de compliance.
Où se situe Barbican dans tout ça ?
  • C’est une API REST pour la gestion des secrets.
  • Il supporte des backends via plugins de simple_crypto à PKCS#11 et KMIP (HSM).
  • Il est intégré avec Nova, Cinder, Swift, Neutron, Heat.
  • Il est capable d’utiliser Keystone pour les RBAC et l’authentification.
  • Et comme les projets OpenStack il est prévu pour scaler.
  • Par contre, il ne faut pas compter sur lui pour avoir une belle interface graphique ni pour émettre des certificats (depuis Pike)

Qu’en est-il du chiffrement des volumes ?

Cinder est capable d’utiliser LUKS (Linux Unified Key Seup), ce qui a comme avantage:

  • De pourvoir avoir plusieurs clés utilisateurs (ou pass) par volume
  • Le support de l’accélération matérielle
  • Et, depuis Queens, un support natif dans QEMU/LibVirt
Le chiffrement est désormais transparent dans nova et cinder, avec le déchiffrement qui se passe sur l’hyperviseur au lieu de l’instance :
  • Agnostique au système d’exploitation de l’instance
  • Pas besoin d’agent
  • Volumes bootables
  • Chaque volume possède sa propre clé unique
Il est important de noter que dans le cas d’utilisation de volumes chiffrés :
  • La live migration ne fonctionne pas (avant Queens) et est dangereuse car il y a un gros risque de perte de données. C’est corrigé en Queens.
  • Un problème dans le packaging RDO de Barbican fait que le service n’est pas bien lancé après un reboot. Cela devrait être corrigé très rapidement.
Il existe également quelques limitations :
  • Pas d’interface dans horizon
  • Pas de mécanisme pour assurer la rotation des clés de chiffrement : ll faut créer un nouveau volume manuellement et copier les données – pourtant avec le support de multiples clés dans LUKS c’est possible
  • Le choix du backend cinder peut aussi ajouter des contraintes au niveau du chiffrement et rendre ce mécanisme non fiable
Enfin, une démonstration (enregistrée) est faite de l’utilisation de Barbican pour la gestion des volume en Queens / RDO. 

 

Project Updates

La majorité des projets OpenStack proposent une présentation de leur actualité : ce sont les sessions « project update ».

Durant cette journée, Horizon et Magnum ont retenu notre attention.

 

Horizon project update

Horizon est le projet de Dashboard OpenStack. Basé sur Django, il offre un système permettant d’intégrer des plugins tels que le dashboard CloudKitty.

Nouveautés Queens :

  • L’api v3 de Cinder et de Keystone sont utilisées par défaut
  • Le dashboard heat est désormais disponible en tant que plugin
  • La feature trunk de Neutron est supportée dans Horizon. Il est désormais possible d’associer plusieurs vlan à une instance via Horizon.
  • Une option POLICY_DIRS a été ajoutée, permettant de supporter plusieurs fichiers policy.

À venir pour Rocky :

  • Supports d’attachement multiples pour les volumes
  • Support de groupes de volumes génériques
  • Topologie auto-allouée pour neutron
  • Possibilité d’éditer les groupes de sécurité des instances en fonction des ports
  • Support de Django 1.11 et support expérimental de Django 2.0 (et donc de python3 pour tous les plugins)

 

Magnum

Par Ricardo Rocha (CERN)

Le but du projet Magnum est assez simple : fournir un service de création de cluster (mono-tenant) de conteneurs. La gestion des credentials est prise en compte, tout comme la possibilité de réaliser des opérations de lifecycle.

Les orchestrateurs qui peuvent être déployés sont :

  • K8s
  • Swarm
  • Mesos

Un point de vocabulaire particulier a été abordé pour mieux appréhender la conférence. Il s’agissait de rappeler ce qu’est un template de cluster (Cluster Template) au sens magnum : c’est le fichier qui permet la création du cluster. C’est là que sont par exemple définies les options de création :

  • le nombre de masters ou de nodes
  • le système déexploitation de base des conteneurs (Fedora Atomic, CoreOS, Uuntu, CentOS)
  • la cible de déploiement (Baremetal ou VM)
  • le type d’orchestrateur à déployer
  • ….

Un tour des nouveautés de Queens a été présenté :

  • L’accent a été mis sur la simplification de création des clusters sans avoir besoin de créer un template complet. Un mécanisme d’override de paramètres a été mis en place pour permettre de gérer :
    • les flavors pour les master et les nodes
    • la taille des volumes utilisés par Docker
    • les labels
  • Il est désormais possible de choisir une Availlibity Zone lors de la création du cluster

Un éclairage particulier a été fait sur les nombreuses nouvelles fonctionnalités de K8s (avec le support des version 1.9.X et 1.10.X) qui sont désormais configurables/déployables :

  • Calico comme driver réseau
  • RBAC
  • Pile de monitoring avec heapster, influxDB et grafana
  • Traefik en Ingress
  • Les composants de K8s sont dans des conteneurs, ce qui simplifie les montées de version

Des nouveautés pour les Ops et les Devs sont aussi apparues en Queens:

  • la possibilité de lister, supprimer, détailler des clusters sur tous les projets
  • la possibilité d’utiliser des autorités de certification personnalisées
  • la possibilité d’étendre les drivers disponibles pour les clusters grâce à l’agent Heat à la place des user data nova pour mieux gérer des gros déploiements

Que nous réserve Rocky ?

  • Cluster upgrade avec l’introduction de rolling upgrade par lot, afin de faciliter les migrations sans impact sur le service proposé par l’orchestrateur
  • Un effort important sur le monitoring des clusters (Health et Healing). Pour ce faire, un nouveau champ dans le statut va être ajouté (Healhy|Unhealthy) et reprendra le statut retourné par le moteur d’orchestrateur lui-même. Un ensemble de traitements automatiques des raisons d’état non normaux sera mis en place.
  • L’introduction de différents containers runtime (docker, kata, gvisor, cri-o et cri-containerd)
  • L’ajout du support de la fédération K8s
  • L’ajout de l’authentification Keystone pour K8s
  • La possibilité de remplacer des nodes du cluster