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

Karim

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

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/) :

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

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

avec cette topologie :

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

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

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

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

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

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

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

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

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

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

Au final, OSBA se veut un broker universel :

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

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.

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é :

Je lance Kashti :

et le tableau de bord est disponible :

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 :

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 :

avec ce service test :

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

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 :