Open Service Broker, Cloud Foundry, Kubernetes-native CI/CD avec Brigade/Kashti, Serverless et Maillage de microservices avec Conduit.io…

Je vais parler d’Open Service Broker (OSBA) :

Image for post
Image for post

L’API Open Service Broker (OSBA) fournit un moyen standard pour les fournisseurs de services d’exposer les services de sauvegarde aux applications exécutées sur des plates-formes natives cloud comme Kubernetes et Cloud Foundry. OSBA expose les services Azure populaires tels que Azure CosmosDB, Azure Database for PostgreSQL, et Azure Blob Storage. Avec OSBA et le catalogue de services Kubernetes, les clients peuvent gérer ces services de données Azure avec SLA via l’API Kubernetes, ce qui permet aux développeurs d’utiliser facilement les bases de données Azure en mode natif Kubernetes. Par exemple, en utilisant OSBA et Helm on peut installer facilement une instance de Wordpress soutenue par Azure Database pour MySQL, au lieu d’exécuter la base de données dans un conteneur …

Je pars donc pour la démo d’un déploiement d’un cluster Cloud Foundry “natif” (donc issu des sources de la Cloud Foundry Foundation => https://www.cloudfoundry.org/foundation/) :

Image for post
Image for post

Je pars des templates de déploiement communautaires pour cela :

Image for post
Image for post
Image for post
Image for post

J’obtiens donc le pool de ressources avec les VMs du clust Cloud Foundry :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

avec cette topologie :

Image for post
Image for post

Je me connecte à mon espace dans le cluster avec le lancement test de la célèbre démo FranceConnect Particulier …

Image for post
Image for post

qui répond à partir de la route préconfigurée et du service de wild card DNS :

Image for post
Image for post
Image for post
Image for post

Je vais installer l’API OSBA à partir d’un cache REDIS qui lui est nécessaire :

Image for post
Image for post

et je crée le lancement de l’API à partir d’un fichier de manifest préfourni :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Je vois que j’ai maintenant accès à une partie du marketplace d’Azure notamment pour les services bases de données :

Image for post
Image for post

et je fais un test de connexion du cache Redis avec mon appli de démo de FC Particulier :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

J’effectue la liaison avec les credentials fournis avec l’applide démo FCP :

Image for post
Image for post

avec la prise en compte de ces credentials et la reconfiguration du fichier de manifest, je peux relancer l’appli de démo FCP :

Image for post
Image for post
Image for post
Image for post

La suppression de cette liaison et de ce service issu du marketplace Azure est tout aussi rapide :

Image for post
Image for post

Je peux également lancer OSBA dans un cluster Kubernetes … Ou par exemple ici avec l’installation du catalogue générique de la CNCF …

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Au final, OSBA se veut un broker universel :

Image for post
Image for post

Je passe ensuite à Brigade, une initiative des anciens de Deis, racheté par Microsoft, sur les pipelines CI/CD dans Kubernetes …

Image for post
Image for post

Ils ont en effet annoncé Kashti : Kashti est un tableau de bord et un outil de visualisation pour Brigade Pipelines, un projet annoncé à Prague lors du Sommet Open Source. Brigade aide les développeurs et les gestionnaires d’opérations à faire leur travail rapidement en planifiant plusieurs tâches en les exécutant à l’intérieur des conteneurs.

Image for post
Image for post

Ceci a de nombreuses applications, y compris Kubernetes-native CI/CD, ETL, flux de travail par lots, et plus encore. Kashti étend Brigade avec un tableau de bord UI, construit comme un service Kubernetes et installé via Helm. Avec Kashti, les développeurs peuvent facilement gérer et visualiser leurs événements et projets Brigade à l’aide d’un navigateur Web. Le projet Kashti n’en est qu’à ses débuts …

Application au cluster Kubernetes déployé :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Je lance Kashti :

Image for post
Image for post
Image for post
Image for post

et le tableau de bord est disponible :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Au passage dans OpenFaaS, le célèbre outil permettant de disposer des fonctions à la demande avec les containers, on peut disposer d’un petit marketplace :

Image for post
Image for post
Image for post
Image for post

Je teste ensuite Conduit.io ! Conduit est un maillage réseau de microservice ultraléger pour Kubernetes. Il rend l’exécution des services sur Kubernetes plus sûre et plus fiable en gérant de manière transparente la communication runtime entre les services. Il offre des fonctionnalités d’observabilité, de fiabilité et de sécurité, le tout sans que vous ayez à modifier votre code …

Le maillage de service Conduit est déployé sur un cluster Kubernetes comme deux composants de base: un plan de données et un plan de contrôle. Le plan de contrôle pilote le plan de données et fournit des API pour modifier son comportement (ainsi que pour accéder aux métriques agrégées). Le Conduit CLI et l’interface utilisateur web consomment cette API et fournissent des contrôles ergonomiques. Le plan de contrôle Conduit est un ensemble de services qui s’exécutent dans un espace de nom Kubernetes dédié (conduit par défaut). Ces services permettent d’accomplir diverses choses: agrégation des données de télémétrie, fourniture d’une API orientée utilisateur, fourniture de données de contrôle aux mandataires du plan de données, etc …

Déploiement test dans le cluster Kubernetes :

Image for post
Image for post

avec ce service test :

Image for post
Image for post
Image for post
Image for post

et j’ai le tableau de bord de Conduit qui me permet de visualiser le comportement de ce service :

Image for post
Image for post

Je termine par le projet Kubeflow qui est dédié à rendre l’apprentissage machine sur Kubernetes facile … Il contient des manifestes de création pour JupyterHub afin de créer et gérer des notebooks Jupyter interactifs, un contrôleur Tensorflow qui peut être configuré pour utiliser des processeurs ou des GPU, et ajusté à la taille d’un cluster avec un seul paramètre ainsi qu’un modèle Tensorflow consommable sous forme de web service … Le but étant d’avoir un ensemble de manifestes simples qui donnent une pile ML facile à utiliser n’importe où où Kubernetes est déjà en cours d’exécution et qui peut se configurer en fonction du cluster dans lequel il se déploie …

Exemple encore ici :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

avec cette topologie et ressources utilisées …

Image for post
Image for post
Image for post
Image for post

avec ce test rapide de reconnaissance d’image d’un chat …

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Bref, de nombreuses évolutions et ajout de fonctionnalités nouvelles pour Kubernetes et … Cloud Foundry !

A suivre …

Originally published at telegra.ph on December 11, 2017.

Above the clouds, the sky is always blue ...

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store