Openstack sous Kubernetes avec Kolla et Helm dans Azure ...

Kubernetes peut servir de réceptacle à Openstack avec le projet Kolla :

Or il se trouve que grâce à l'action des labos ATT, on a la possibilité de déployer un cluster Openstack sous Kubernetes via Helm. Je commence donc par déployer un nouveau cluster Kubernetes puis à y installer et initialiser Helm :

Je récupère les Charts depuis le dépôt officiel de la fondation Openstack (car les labos ATT ont tous migré vers celui-çi) :

Activation d'un repo local pour Helm et transfert des Charts de Helm vers celui-çi :

et je déploie ceux-çi au sein du cluster Kubernetes :

Après cela tous les PODs sont en mode RUNNING :

Je n'ai plus alors qu'à exposer le service Horizon via le load balancer attaché au sein du Cluster Kubernetes dans Azure et sur le port 80 :

Je n'ai plus qu'à me connecter au dashboard Horizon avec les identifiants par défaut :

PS: Microsoft a fait tout un battage autour de la sortie de Windows 10 Creators Update. Mais pour moi le plus intéressant a été l'amélioration apportée par Windows Subsystem for Linux qui comme son nom

l'indique apporte un noyau Ubuntu de canonical :

On voit que c'est une base Ubuntu 16.04 qui est utilisée (et plus 14.04 LTS) :

Et il est possible d'invoquer des scripts shell bash depuis powershell directement :

et même d'exécuter tmux depuis la console :

Microsoft a fait l'acquisition du PaaS Open Source Deis pour Azure =>

C'est une décision très importante car c'est justement Deis qui était à l'origine de Helm mais également de Deis Workflow et Deis Steward.

Pour rappel, Deis Workflow qui forme l'ossature de la plateforme PaaS, s'installe au dessu de Kubernetes =>

Avec le cluster Kubernetes précedemment créé, je teste le déploiement de Deis Workflow :

et j'attends que tous les PODs de la plateforme Deis soit en mode RUNNING :

J'atends alors l'IP de l'Ingress fournie avec le déploiement de la plateforme (ici tout fonctionne avec un service public de Wild Card DNS très connu nip.io) :

Je procède à l'enregistrement de l'administrateur de la plateforme :

Une fois effectuée, je n'ai plus qu'à réaliser un petit test avec un simple serveur web en Go =>

On peut également effectuer un pull d'une image Docker existante du Docker Hub : exemple avec l'image précedente du botdiplomatique =>

Il est possible de coupler Deis avec un processus de CI/CD comme celui-çi (et en y faisant participer par exemple le packager Helm) :

Mais le plus intéressant va être la possibilité de coupler des services de Deis avec ceux de la plateforme Cloud Foundry via la brique (toujours en Alpha) Deis Steward :

Un webinar intéressant a eu lieu sur le thème de l'insertion de Helm dans Kubernetes au sein d'Azure =>

Je commence donc à relancer un cluster Kubernetes (cette fois-çi "full linux") dans Azure =>

et je vais tenter de créer un Chart d'Helm pour Kubernetes à partir du projet Kompose :

Pour rappel, Helm est une sorte de gestionnaire de package pour Kubernetes (comme Yum ou apt-get dans Linux) :

Kompose permet très facilement de générer un Chart à partir d'un fichier Docker-Compose.yml comme cet exemple avec le démonstrateur FranceConnect Particulier :

avec cette structure dans l'arborescence générée :

et je teste ce Chart avec une installation dans le cluster Kubernetes via le binaire Helm (préalablement installé) :

et cela fonctionne :

mais j'ai également la possibilité de générer ce chart à partir d'un template vide via la commande Helm =>

Je peux alors après modification des variables du template autogeneré par Helm, procéder à son installation dans le cluster via également la commande Helm :

et le load-balancer attaché au cluster Kubernetes dans le pool de ressources dans Azure, me fournit un accès externe au service déployé via ce Chart :

*

On peut alors packager ce Chart et l'envoyer dans le dépôt officiel dans Github =>

Kubeapps.com constitute une sorte de marketplace externe de la Cloud Native Computing Foundation pour des Charts officiels =>

un marketplace qui peut être déployé localement avec le projet monocular de Kubernetes =>

Installation depuis Helm directement :

avec un accès local par exemple :

Helm devient une composante importante du CI/CD car on peut implémenter ce type de workflow :

avec un exemple dans la plateforme Wercker =>