Après Vancouver, Tokyo, Austin et Barcelone, Boston, c’est au tour de Sydney d’être la ville de l’OpenStack Summit ! 16ème summit OpenStack, Osones vous fait, comme a son habitude, vivre l’OpenStack Summit de Sydney comme si vous y étiez !

Le menu est simple : par ici pour le JOUR 1 et le JOUR 2 !

Le coeur du sujet : les Breakout sessions retenues par Osones !

- Kubespray pour la construction d'un cluster Kubernetes

Kubernetes est l'un des plus gros projets open source du monde, écrit en Go, qui supporte de nombreuses méthodes d'implémentations cloud ou bare-metal, avec de nombreuses variantes côté moteur ou même réseau. Il est supporté par la plupart des cloud providers du marché. Aujourd'hui il existe une trentaine d'outils pour déployer Kubernetes, commerciaux ou communautaires. Les 3 plus gros qui se démarquent sont :

• kubespray
• kube-aws
• kops

Ihor Dvoretskyi (CNCF) et Rob Hirschfeld (CEO de RackN) nous ont présenté le fonctionnement de Kubespray plus en détails pendant ce Summit.

Le projet Kubespray, précédemment nommé Kargo, a été initié par des développeurs indépendants. Basé sur Ansible, il est hautement personnalisable et facile à étendre. Il permet de gérer le cycle de vie d'un cluster Kubernetes, du bootstrap d'un node à l'upgrade ou au redimensionnement du cluster complet. Il est en incubation chez Kubernetes, en attendant son intégration au projet officiel. Parmi les fonctionnalités intéressantes de Kubespray on trouve :

• La mise en place automatique d'un cluster en haute disponibilité
• Le renouvellement automatique des certificats
• L'intégration native aux clouds populaires
• Sécurisation par défaut/design
• Gestion des mises à jour
• Ajout incrémental de nœuds dans un cluster existant
• Peut facilement s'intégrer à n'importe quel outil de CI/CD

De nombreuses options d'implémentations sont possibles. L'utilisateur dispose du choix de l'OS, de la technologie réseau (L2 et L3), du container engine (Docker, rkt...), de la méthode de déploiement et de l'infrastructure (qu'elle soit chez un cloud provider ou on premise). Kubespray tire profit de l'API de Kubernetes pour l'ajout de nœud dans un cluster, gérer le dimensionnement automatique, la coordination des upgrades... La configuration du cluster peut être ainsi centralisée et l'installation d'un nœud très rapide. Il laisse la porte ouverte au recyclage automatique des nœuds de l'infrastructure, très pertinent dans une optique de autohealing (par exemple renouvellement automatique de tous les nœuds chaque semaine).

C'est un outil bien connu chez Osones, puisqu'il s'agit d'une des principales méthodes retenues pour déployer des cluster Kubernetes chez nos clients. Nous sommes aussi contributeurs sur le projet.

- Blueprint for a successful OpenStack

Mark Shuttleworth, Canonical

Le CEO de Canonical vient nous exposer quels sont, selon lui, les principaux facteurs techniques et économiques déterminants pour la réussite d'un projet de cloud privé OpenStack.

1) bien choisir le matériel

• un maximum de RAM par compute node
• du Direct Attached Storage à chaque fois que possible
• du stockage hiérarchisé: NVMe (Non Volatile Memory express) -> SSD -> disque dur classique
• réseau type "Whitebox"

2) provisioning bare-metal en mode "zero-touch". C'est-à-dire automatisable et exécutable à distance.

3) conteneuriser les services qui constituent le control plane OpenStack

4) limiter le périmètre fonctionnel du cloud au IaaS + orchestration de conteneurs (Magnum)

5) le déploiement du Cloud ne doit être ni trop cher -> risque d'image négative, ni trop long -> risque que les clients se tournent vers d'autres solutions

Enfin, toujours selon Mark Shuttleworth, les deux principaux signes de bonnes santé d'un cloud privé sont :

• l'aptitude à l'upgrader tous les 6 mois en déployant la version N+1 d'OpenStack (plutôt que l'ajout de telle ou telle nouvelle fonctionnalité)
• l'automatisation effective des opérations quotidiennes

Même s'il apparaît en filigrane un certain parti pris dans l'intervention du patron de Canonical/Ubuntu, écouter les arguments d'un tel acteur du marché reste très intéressant !

- Make your appliction "Serverless"

Lingxian Kong (PTL Qinling, ex core reviewer Mistral), Feilong Wang (PTL Zaqar)

Lingxian et Feilong viennent nous parler du principe "serverless" et du projet Qinling (prononcer "tchineline"), l'implémentation OpenStack du Function as a Service.

De façon synthétique, le principe "serverless" affranchit le développeur de toutes considérations liées à l'environnement technique dans lequel s'exécute son application. Ainsi, il en oublie la notion même de serveur (d'où le nom du principe) et peut se concentrer sur le code applicatif. En quelque sorte, l'application (mobile ou serveur web), qui auparavant s'adressait à un ou plusieurs serveurs d'API, s'adresse à présent à une forme de fonction (en fait, du code écrit par le développeur de l'application et qui sera exécuté dans le cloud) !

Toutefois, le "serverless" n'adresse pas toutes les applications mais est particulièrement recommandé pour les cas d'usage suivants : travaux batch (cron jobs), applications orientées micro-services, data processing, IoT, chatbots.

Quelques mots à présent sur Qinling, l'implémentation du Serverless/Function as a Service d'OpenStack :

• Qinlin est composé d'une API Rest (comme tout bon service OpenStack qui se respecte), d'un moteur, d'un CLI et d'un dashboard Web.
• il gère des "fonctions" et leurs exécutions (jobs)
• il est intégré aux autres services et composants d'OpenStack
• il utilise les orchestrateurs de conteneurs (Kubernetes, Swarm, Mesos, Zun)

Les intervenants nous interpellent sur le fait que de leur point de vue, un FaaS ne délivre sa pleine puissance que si il est couplé efficacement aux autres services du cloud. Et ceci est vrai qu'il s'agisse de Lambda, le FaaS d'AWS, ou de Qinling, celui d'OpenStack.

La présentation se termine par deux "live demos" plutôt réussies :

1) Qinling + AODH : envoi d'un email lorsqu'un objet dont la taille dépasse une valeur fixée est uploadé dans un conteneur Swift (OpenStack object storage service) Cette première démo met en œuvre les commandes Qinling et AODH suivantes :

  $ openstack function create  # la fonction en question est codée en python
  $ aodh alarm create
  $ openstack function execution log show

2) Qinling + Zaqar : monitoring de serveurs (il y en a encore dans la vraie vie...) avec envoi de sms Ici, Zaqar (Messaging as a Service) permet d'une part la communication entre fonctions - et donc un découplage poussé du code applicatif en plusieurs fonctions - et d'autre part un mécanisme de retry efficace. La commande suivante est utilisée pour cette deuxième démo :

$ openstack job create $FUNCTION_ID --name service_check_job --pattern '*/1 * * * *'

La variable FUNCTION_ID est récupérée précédemment via une autre commande au moment de la création de la fonction grâce à une commande Qinling. On voit ici que la valeur du paramètre --pattern est exprimée selon une syntaxe proche de celle utilisée par le service "cron" de Linux.

Quelques ressources pour en savoir plus sur Qinling :

• Code: github.com/openstack/qinling
• Doc: http:///qinling.readthedocs.io
• IRC: #openstack-qinling

- RBAC customs

RBAC pour Role Based Access Control est la méthode utilisée par les projets OpenStack pour s'assurer qu'une action sur le cloud est bien effectuée par une entité autorisée.

Par défaut, il n'existe que deux rôles : admin et member. Le premier a le droit de tout faire et le second uniquement les actions qui concerne le projet auquel il est associé. Pour chaque services OpenStack, il existe un fichier policy.json qui defini les actions autorisées par les rôles.

On comprend qu'ajouter un rôle est compliqué car il n'est realisable que par l'administrateur du cloud, c'est à dire qu'un utilisateur (administrateur de son projet) ne peut se créer un rôle avec des droits restreints pour certains de ses collaborateurs comme sur AWS. Changer le fichier policy.json est un vrai casse-tête en plus d'être particulierement dangereux si il est mal executé.

Certaines règles du policy.json peuvent s'appliquer à plusieurs commandes API et certaines commandes API peuvent demander des droits sur plusieurs services :

• le démarrage d'une instance demande évidement le droit de création d'instance sur le policy.json de Nova mais aussi le droit de récupération d'image sur le policy.json de Glance, etc...

Parmi les améliorations prévues pour Queens, on trouve :

• Une vraie documentation pour les policy.json
• La possibilité de passer des policies en deprecated
• Création d'un scope system (action sur l'infra du cloud) et d'un scope projet (création d'instance...)

Pour aller plus loin :

• https://trello.com/b/bpWycnwa/policy-roadmap
• https://etherpad.openstack.org/p/queens-PTG-keystone-policy-roadmap

Forum

- Keystone Update

- Pike

Comme expliqué dans notre article d'hier, la documentation est revenue dans le giron de chaque projet et l'équipe Keystone s'est donc chargée d'améliorer grandement la documentation. La default policy de Keystone est située dans le code et un policy.json léger permet de redéfinir ce qui est nécessaire. Il reste possible via la CLI de regénérer un policy.json complet. Les tests de rolling upgrade ont eux été améliorés.

Queens

Les mises à jour prévues pour Queens incluent :

- Suppression de l'API v2
- Gestions des tags sur les projets et gestion uniforme des projets par tags

La core team s'est considérablement réduite lors du dernier cycle et un travail sur la reconstruction de l'équipe upstream sera nécessaire pour assurer la pérénité du développement.

- Rocky

Un nouveau type de jeton verra le jour, les JWT (Json Web Token). Ce sont des tokens standards (RFC 7519, qui auraient dû sortir avec la version Juno, malheureusement la RFC est sortie quelques mois après Juno et les tokens de Fernet ont perduré depuis. Avec ce nouveau type de token, les tokens "uuid" et "persistent storage" seront supprimés, seuls les JWT et Fernet resteront. JWT apporte notamment du chiffrement asymétrique, contrairement à la symétrie des tokens de Fernet. Les rôles permettront d'être mieux définis, avec un meilleur mappage entre les règles et les calls API correspondant.N éanmoins l'équipe annonce qu'OpenStack Keystone se trouve encore très loin d'IAM d'Amazon Web Services sur ce point.

- Octavia Update

Octavia est le projet de Load Balancing as a Service sorti du projet Neutron. Le projet a réuni 78 contributeurs de 25 sociétés différentes pour le cycle de Pike.

- Pike

La spécification de l'API v2 du LBaaS de Neutron a été réimplémentée dans ce qui est maintenant l'API v2 d'Octavia. Tous les appels faits à l'API LBaaS v2 devraient fonctionner sur Octavia v2. Un plugin pour OpenStack Client est désormais disponible permettant de piloter directement Octavia en ligne de commande. Une policy d'anti-affinité soft pour Nova est désormais présente, avant Pike, seule une policy hard était présente ce qui pouvait faire échouer le scheduler et placer les instances en erreur. Désormais le scheduler pourra fonctionner en best-effort si une policy soft est spécifiée.

- Queens

Afin de déprécier l'agent LBaaS de Neutron, Octavia doit supporter les provider drivers qui étaient une des principales raisons d'être du LBaaS Neutron. Une spécification a été écrite pour implémenter le support d'une topologie actif/actif. Le dashboard Horizon sera amélioré, du code est d'ailleurs déjà présent sur la branche master du projet.

C'est tout pour ce troisième jour ! Si vous les avez loupés, voici le JOUR 1 et le JOUR 2 !

La Team Osones