Pour ceux qui ont déjà installé Cloud Foundry dans le passé, BOSH était le seul moyen d’installer et de gérer un cluster Cloud Foundry. Enfin, c’était avant l’arrivée de CF-Operator, Cloud Foundry Quarks, Eirini, et KubeCF …
Une expérience locale rapide et facile de Cloud Foundry pour les développeurs via CF Dev / Stratos…
*Je vais m’intéresser dans cet article à l’un projet de l’incubateur de Cloud Foundry à savoir CF Dev et son pendant…*medium.com
Déploiement d’un cluster Cloud Foundry avec Stratos dans Azure et mise en oeuvre de pipelines de…
*Je vais m’interesser à Cloud Foundry, une plate-forme d’application multi-cloud open source et multi-cloud sous forme…*medium.com
Dans cette nouvelle expérience, je commence par lancer un cluster Kubernetes par l’entremise d’AKS-Engine. AKS Engine fournit des outils pratiques permettant d’amorcer rapidement via ARM (Azure Resource Manager), de créer, de détruire et de maintenir des clusters Kubernetes approvisionnés en ressources IaaS sur Azure. AKS Engine est également la bibliothèque utilisée par AKS pour effectuer ces opérations afin de fournir des implémentations de services gérés :
Azure/aks-engine
*AKS Engine is the easiest way to provision a self-managed Kubernetes cluster on Azure. AKS Engine provides convenient…*github.com
Après avoir cloné localement le dépôt d’AKS-Engine sur Github, je récupère le fichier JSON qui permet de profiter des machines virtuelles Spot dans Azure dans le cluster Kubernetes à provisionner. Les machines virtuelles Spot Azure vous donnent accès à une capacité de calcul Azure inutilisée en échange de remises importantes. Les tarifs Spot sont disponibles sur les machines virtuelles uniques, en plus de groupes de machines virtuelles identiques (VMSS — Virtual Machine Scale Sets). Cela vous permet de déployer sur Azure un plus large éventail de charges de travail tout en bénéficiant de prix réduits. Les machines virtuelles Spot offrent les mêmes caractéristiques que les machines virtuelles avec paiement à l’utilisation, et se distinguent en termes de tarification et de suppression. Les machines virtuelles Spot peuvent être supprimées à tout moment si Azure a besoin de capacité :
Machines virtuelles Spot désormais en préversion | Mises à jour Azure | Microsoft Azure
*Les Machines virtuelles Azure Spot vous permettent d'accéder à la capacité de calcul inutilisée d'Azure en bénéficiant…*azure.microsoft.com
Au préalable, j’ai récupéré le binaire AKS-Engine sur Github :
Azure/aks-engine
*You can't perform that action at this time. You signed in with another tab or window. You signed out in another tab or…*github.com
et j’ai généré un principal du service Azure AD pouvant créer des ressources :
Utilisez des principaux du service Azure avec Azure CLI
*Les outils automatisés qui utilisent les services Azure doivent toujours avoir des autorisations restreintes. Automated…*docs.microsoft.com
Je lance la création du nouveau cluster Kubernetes avec le binaire AKS-Engine :
Le cluster AKS est présent et opérationnel dans Azure :
Je bénéficie normalement du service de Load Balancing dans AKS-Engine mais pour initier mon plan d’adressage, j’ai initié un plan d’adressage avec ZeroTier dans ce cluster :
Pour la suite, j’ai besoin d’installer Helm 3 dans ce cluster et je récupère le binaire depuis Github :
helm/helm
*Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 40…*github.com
CF-Operator est un opérateur Kubernetes déployé via un Helm Chart qui installe une série de définitions de ressources personnalisées (CRD) qui convertissent les versions BOSH en ressources Kubernetes telles que des pods, des déploiements et des ensembles avec état. Cela n‘entraîne pas à lui seul un déploiement de Cloud Foundry.
KubeCF est une version de Cloud Foundry déployée sous la forme d’un Helm Chart, principalement développée par SUSE, qui exploite CF-Operator.
Eirini échange le backend Diego contre Kubernetes, ce qui signifie que lorsque vous poussez, vos applications s’exécutent en tant que pods Kubernetes à l’intérieur d’un ensemble avec état.
En utilisant ces outils ensemble, on peut déployer un plan de contrôle Cloud Foundry et faire fonctionner les applications en tant que Pods dans Kubernetes.
Project Quarks for Application Runtime | Cloud Foundry
*Project Quarks is an incubating effort within the Cloud Foundry Foundation that packages Cloud Foundry Application…*www.cloudfoundry.org
Project Eirini | Application Runtime & Kubernetes | Cloud Foundry
*Project Eirini is an incubating effort within the Cloud Foundry Foundation enabling pluggable scheduling for the Cloud…*www.cloudfoundry.org
Je lance le déploiement de CF-Operator dans le cluster via un Helm Chart :
$ kubectl create cf-operator
$ helm install cf-operator \
--namespace cf-operator \
--set "global.operator.watchNamespace=kubecf" \
https://s3.amazonaws.com/cf-operators/release/helm-charts/cf-operator-v2.0.0-0.g0142d1e9.tgz
Je vérifie que les Pods / CRD sont bien lancés :
Pour définir les bons plans d’adressage à déclarer dans le fichier de configuration nommé values.yaml, je lance ces commandes :
$ kubectl cluster-info dump --output yaml \
| awk 'match($0, /cluster-cidr=(.*)/, cidr) { print cidr[1] }'
$ kubectl cluster-info dump --output yaml \
| awk 'match($0, /service-cluster-ip-range=(.*)/, range) { print range[1] }'
d’où le fichier avec une configuration minimale pour le déploiement de Cloud Foundry (en prenant un domaine Wilcard qui pointera sur l’adresse IP du segment déclaré dans MetalLB qui sera attribuée au service nommé kubecf-router-public) :
Installation de KubeCF via un autre Helm Chart :
$ helm install kubecf \
--namespace kubecf \
--values values.yaml \
https://github.com/SUSE/kubecf/releases/download/v0.2.0/kubecf-0.2.0.tgz
avec ce fichier YAML minimal par défaut. Je possède l’adresse IP fournie par le service de Load Balancing via MetalLB pour le service nommé kubecf-router-public :
Un lancement des Pods avec ces valeurs s’opèrent dans le cluster (après une dizaine de minutes) :
Je charge CF CLI depuis Github pour me connecter à Cloud Foundry :
Avec le client CF déjà installé, je peux cibler et m’authentifier sur Cloud Foundry en utilisant l’URL du domaine qui correspond à celui enregistré dans le fichier de configuration values.yaml :
Getting Started with the cf CLI
*This topic describes configuring and getting started with the Cloud Foundry Command Line Interface (cf CLI). The cf CLI…*docs.cloudfoundry.org
ce que je peux alors faire :
$ admin_pass=$(kubectl get secret \
> --namespace kubecf kubecf.var-cf-admin-password \
> -o jsonpath='{.data.password}' \
> | base64 --decode)
$ cf auth admin "${admin_pass}"
Je crée mon Espace et mon Organisation :
$ cf create-org MAS
$ cf create-space TEST -o MAS
$ cf target -o MAS
Je peux activer dans Cloud Foundry, Diego un système de gestion de containers auto-réparables qui tente de maintenir le nombre correct d’instances en cours d’exécution dans les cellules afin d’éviter les pannes et les plantages du réseau. Diego programme et exécute des tâches et des processus de longue durée :
$ cf enable-feature-flag diego_docker
Il est dès lors possible de lancer une image Docker via le client CF :
$ cf push fcdemo -o mcas/franceconnect-agent-demo:master -m 128M -k 384M
J’installe Stratos, une interface utilisateur Web (console) open source pour la gestion de Cloud Foundry. Cela permet aux utilisateurs et aux administrateurs de gérer les applications et d’effectuer des tâches de gestion du cluster :
$ cf push console -o splatform/stratos:stable -m 128M -k 384M
Connexion à Stratos avec les mêmes identifiants utilisés avec le client CF :
Je peux visualiser l’application lancée précédemment :
Autre test avec le lancement directement depuis un dépôt source récupéré depuis Github (avec encore une fois le démonstrateur FC) qui va engendrer le chargement des buildpacks dans Cloud Foundry :
visualisable dans la console Stratos :
Rapide test de mise à l’echelle horizontale et verticale de cette application :
On peut visualiser les Pods engendrés par cette application dans le cluster Kubernetes :
également via Weave Scope :
Avec accès à l’application via la route fournie dans Cloud Foundry :
On pourrait aller plus loin dans ce cluster Cloud Foundry via l’initiation de Pipelines de CI/CD via Concourse :
7. Concourse Pipeline (Cloud Foundry)
*Important In this chapter, we assume that you deploy your application to Cloud Foundry PaaS. The Spring Cloud Pipelines…*cloud.spring.io
Quelques liens sur le sujet :
Integrate Cloud Foundry with Kubernetes using the cf-operator and kubecf
*If you work in the software industry, you have more then likely come across the terms IaaS, PaaS and SaaS. IaaS stands…*www.careyscloud.ie
Running Cloud Foundry on Kubernetes using KubeCF
*At Stark & Wayne, we've spent a ton of time figuring out the best solutions to problems using the open source tools we…*starkandwayne.com
Deploying CloudFoundry on a local Kubernetes
*I have met a lot of people which uses Docker/Kubernetes but which never used CloudFoundry so I will start with a short…*medium.com
KubeCF et CF-Operator sont amenés à évoluer rapidement pour simplifier l’usage et le déploiement d’applications dans Kubernetes via … Cloud Foundry. En effet, avec ceci on a la possibilité de fournir une offre de type PaaS plus complète aux équipes de développement tout en profitant de déploiements dans Kubernetes. Cela permettrait aux équipes de développement de décider lequel de ces deux types de services ou d’applications convient le mieux en sélectionnant l’une de ces deux plate-formes voire les deux. Les équipes disposant d’applications de base pourraient les déployer en exécutant simplement un “cf push” par exemple …
À suivre …
Oldest comments (0)