Déploiement d’un cluster Cloud Foundry avec Stratos dans Azure et mise en oeuvre de pipelines de déploiement continu …
Je vais m’interesser à Cloud Foundry, une plate-forme d’application multi-cloud open source et multi-cloud sous forme de service (PaaS) régie par la Cloud Foundry Foundation (organisme indépendant sans but lucratif au sein de la Linux Foundation). Suite à la création de la Cloud Foundry Foundation, la plate-forme Cloud Foundry (code source et toutes les marques associées) a été transférée pour être détenue par la fondation Open Source. Elle est principalement écrite en Ruby, Go et Java.
Cloud Foundry est adaptée aux processus de livraison continue car elle prend en charge l’ensemble du cycle de développement de l’application, depuis le développement initial jusqu’au déploiement en passant par toutes les étapes de test. L’architecture en conteneurs de Cloud Foundry exécute des applications dans n’importe quel langage de programmation sur une variété de fournisseurs de services cloud. Cet environnement multi-cloud permet aux développeurs de tirer parti de la plate-forme cloud qui convient à des charges de travail applicatives spécifiques et de déplacer ces charges de travail en quelques minutes, sans modification de l’application.
Je lance le déploiement d’un cluster Cloud Foundry en profitant des templates ARM mis à disposition par la communauté et la fondation Cloud Foundry sur github. Cela passe par le déploiement de BOSH Director sur une VM qui servira de pivot au déploiement du cluster Cloud Foundry :
On dispose via azure d’un script shell accompagné d’un template ARM en JSON avec un fichier de paramêtre en JSON également pour ce déploiement :
Une fois le déploiement de BOSH Director, le déploiement du cluster Cloud Foundry se met en place (en un peu plus d’une heure au total) :
Je peux alors me logger sur la VM BOSH Director :
J’en profite alors pour dôter ce cluster Cloud Foundry d’un tableau de contrôle graphique qui va servir d’interface d’administration via le projet Cloud Foundry Stratos :
Je lance pour cela un manifeste en YAML dans un espace dédié créé au préalable :
Le déploiement de STRATOS est réussi et un endpoint m’est proposé pour accéder à cette interface :
On a une visualisation des logs générés par cette application dans cette interface :
et les différents buildpacks disponibles pour le déploiement des applicatiosn dans Cloud Foundry :
Comme d’habitude, je peux me lancer dans le test du déploiement du traditionnel démonstrateur FranceConnect Agent dans le cluster :
On visualise le déploiement ici de 3 instances dans le tableau de bord de STRATOS :
avec la route proposée :
et bien évidemment le démonstrateur :
Concourse s’est imposé comme l’une des solutions privilégiées pour créer des pipelines de déploiement continu dans Cloud Foundry.
Test rapide via Spring Cloud Pipelines qui propose un démonstrateur avec Concourse :
Dans une VM dédiée je lance la stack composée de Concourse et d’Artifactory avec Docker Compose :
git clone https://github.com/spring-cloud/spring-cloud-pipelines
cd spring-cloud-pipelines/concourse
./setup_docker_compose.sh
./start.sh <IP PUBLIQUE DE LA VM>
L’interface graphique de Concourse est accessible :
tout comme celle d’Artifactory :
et je lance ce script pour clôner des dépôts vers Artifactory :
git clone https://github.com/spring-cloud/spring-cloud-pipelines
cd spring-cloud-pipelines/
./tools/deploy-infra.sh
J’initie la création de trois espaces de test, stage et prod dans Cloud Foundry :
et j’installe le client fly nécessaire au lancement de pipelines dans Concourse :
le pipeline via cet exemple fourni par Spring Cloud est alors lancé dans Concourse :
Concourse permet l’exécution du pipeline via son interface graphique :
Je visualise alors les différentes étapes du pipelines proposées dans cet exemple avec Spring Cloud :
La phase de build avec Maven va générer les artefacts qui seront chargés dans Artifactory :
Et quand l’étape est terminée, une autre phase commence et ainsi de suite …
Via la plate-forme Gitlab.com il est également possible d’initier un pipeline de déploiement continu (un peu dans la logique GitOps) avec le mode Auto DevOps vers le cluster Cloud Foundry. Je pars pour cela d’un dépôt du démonstrateur FranceConnect Particulier :
avec un fichier de paramêtre .gitlab-ci.yml :
et bien évidemment d’un fichier de manifeste en YAML pour Cloud Foundry :
le pipeline est initié dans Gitlab à la création de ces deux fichiers dans le dépôt Git :
qui se termine correctement :
le démonstrateur sous la forme de 3 instances en exécution dans Cloud Foundry apparaît dans le tableau de bord de STRATOS :
et l’endpoint fourni encore une fois :
Je peux enfin profiter de la brique DIEGO dans Cloud Foundry pour lancer directement des applications sous la forme d’images Docker :
Après avoir rendu la brique DIEGO disponible dans le cluster Cloud Foundry, je lance le test du déploiement du portail OpenAcadémie en Next.js :
OpenAcadémie apparait également dans l’interface de STRATOS :
et cet endpoint en Wild Card DNS (via xip.io comme les exemples précédents) :
On peut aller beaucoup plus lin en profitant notamment de Cloud Foundry Container Runtime que l’on avait vu sous le nom de Kubo et qui initie l’utilisation de Kubernetes :
Anciennement connu sous le nom de Project Kubo, un projet d’incubation au sein de la Cloud Foundry Foundation initié par des ingénieurs de Google et de Pivotal, Coud Foundry Container Runtime, alimenté par Kubernetes offre une méthode uniforme pour instancier, déployer et gérer des clusters Kubernetes hautement disponibles sur une plate-forme cloud utilisant BOSH :
Que l’on soit amené à manipuler des conteneurs et que l’on ait besoin de la flexibilité de ces derniers, ou que l’on soit amené à construire des applications 12 facteurs à partir de zéro, Cloud Foundry donne les outils dont on a besoin (avec donc ces deux moutures Cloud Foundry Application Runtime ou Cloud Foundry Container Runtime mais également avec d’autres briques/projets en développement) pour réaliser le job …
A suivre ! …
Quelques liens à ce sujet:
