Tests du CI/CD dans Pivotal Cloud Foundry et des clusters Payara Micro dans Jelastic ...
Karim le 28 mars 2017Une nouvelle version majeure de la plateforme Jelastic est sortie en version 5.0.5 =>
La grande nouveauté est la prise en charge native de Docker en version communautaire notamment :
Je me connecte tout d'abord en test à une platefome en Finlande (puisqu'il n'y en que deux actuellement dans cette nouvelle version au sein de cette union mondiale Jelastic Cloud : en Finlande et en Suisse) pour tester les clusters Payara Micro (issu du serveur d'application open source Glassfish) en autoscaling horizontal :
Pour cela, j'utilise une sorte de manifeste (comme dans Cloud Foundry) : Jelastic Platform Cloud Scripting (JPS) => http://docs.cloudscripting.com/
et à partir de ce fichier de manifeste, l'environnement est prêt à être déployé :
Une fois fait, j'ai bien l'environnement déployé avec de l'autoscaling horizontal et le monitoring :
et avec l'endpoint public fourni pour accéder à la page web de test du cluster Payara Micro :
Je dispose de la possibilité maintenant de déployer dans la plateforme Jelastic un cluster Docker Swarm :
et de définir le déploiement d'une stack via la nouvelle version 3 de Docker-Compose intervenue dans la version 1.13 de Docker, avec des services dans ce cluster Swarm :
Exemple de stack pour la démo fournisseur de service FranceConnect Particulier :
Mais je peux également dans la plateforme Jelastic raccorder un cluster Docker Swarm existant : exemple ici avec un cluster Swarm initié avec playwithdocker.com =>
ou je peux tout simplement comme dans le message précédent, initier le déploiement multi-container de l'image de démo de FranceConnect au sein de la plateforme :
Je n'oublie pas le binding vers les ports privés des containers : il y a un load balancing automatique effectué sur la base du endpoint public qui émet sur le port TCP 80 :
Ce qui fait qu'une fois déployé, je peux disposer de l'autoscaling à configurer sur la base de métriques existantes (mémoire, CPU, I/O disques ou réseau ...) :
et du monitoring :
et l'accès à l'endpoint publique unique =>
Je fais là un test avec Jelastic, une plateforme qui se retrouve sur toute la planête dans une quarantaine de pays avec une déclinaison on-premise également :
Je profile de la lancée de Payara Micro dans Jelastic (pour rappel, Payara reprend les serveur open source Glassfish qu'Oracle a abandonné recemment ... comme tout ce qui est open source de Sun) avec son mécanisme de clustering qui permet de lancer WAR, dépôts Maven ou des sources sans avoir à installer quoique ce soit avec un mécanisme fournis dans Jelastic de load balancing et de scaling horizontal et vertical, le tout avec du cache assuré pour le cluster par Hazelcast :
et je lance depuis le dépôt github, la démo de ce déploiement avec un cluster Payara Micro :
celui-çi se déploit directement dans la plateforme avec un stockage mutualisé pour le cluster :
Je vois les deux noeuds docker du cluster :
et je test le lancement d'un gestionnaire de traffic basé sur Nginx :
configuré en round robin sur les deux noeuds :
et il est déployé :
je créé une regle de scaling horizontal pour ce cluster :
et je lance un double test de charge :
et le cluster encaisse la charge avec un petit pic CPU/Mémoire :
J'ai pu tester en trial les services de la plateforme Pivotal Cloud Foundry (j'avais déjà réalisé un test précédent avec Bluemix qui utilise elle aussi les services Cloud Foundry). Application encore une fois à FC Particulier Fournisseur de services : accès à la plateforme en CLI =>
et je pousse depuis une copie du dépôt git de FCDEMO =>
et le déploiement est réussi :
Il faut prendre soin de bien déclarer le port utilisé par l'application dans le code de celle-çi :
L'application est visible depuis le dashboard de Pivotal :
avec la route fournie :
J'y adjoins un service d'autoscaling horizontal et un service de test de charge :
et je peux lancer un rapide test avec pendant 5 minutes un pic de charge à 100 utilisateurs concurrents sur l'application :
Je vois que je ne dépasse pas 320 ms d'attente par utilisateur ce qui est bon et qui n'engendre pas le scaling automatique pour l'application :
On voit d'ailleurs les logs sur l'application avec les GET engendrés par le test :
ce qui logique au vu du scénario de test utilisé par défaut :
Je réalise un autre test de CI/CD avec Concourse, une autre solution open source de déploiement continu que je lance sous forme de containers Docker dans une instance Cloudwatt avec lancement d'un pipeline test :
Et je vois exécuter les différentes phases de test unitaire / déploiement dans Pivotal CF et de test de charge avant un test final de blue/green deployment pour valider les routes en cas de mise à jour de l'application avec deux versions concurrentes :
L'application est déployée et les différentes phase du pipeline réussies ...
Artillery étant utilisé pour le test de charge :
avec les différentes routes pour le scénario du blue/green deployment :
IBM a annoncé l'intégration de Kubernetes dans Bluemix Container Services. Test rapide de la solution. Je commence à utiliser les nouveaux CLI de Bluemix nommé bx :
et je créé le cluster Kubernetes :
Celui-çi est accessible depuis la console Bluemix :
et je teste le pipeline montré en exemple par IBM pour initier du CI/CD avec ce cluster Kubernetes :
je configure la partie déploiement avec les credentials du cluster Kubernetes :
et les phases de BUILD&DEPLOY se passent sans problème :
J'ai une IP d'accès via un host Minion du cluster Kubernetes (il faut y ajouter un ingress controller avec Nginx, Traefik ou HAProxy) :
Un développement à suivre pusque Kubernetes est encore en phase de preview dans Bluemix :
https://www.ibm.com/blogs/bluemix/2017/03/kubernetes-now-available-ibm-bluemix-container-service/