Aujourd’hui nous allons parler application Kubernetes. Ce template de projet est maintenant intégré utilinativement à Visual Studio 2019. Avec VS 2017 il fallait installer une extension nommée Visual Studio Tools for Kubernetes désormais obsolète.
Ce type de projet permet de générer automatiquement une application “Kubernetes ready”. Visual Studio créé les fichiers nécessaires pour prendre en charge le déploiement dans Kubernetes (dockerfile et Helm).
Helm est un outil permettant de déployer des applications dans Kubernetes en utilisant un système de template auquel on vient associer une configuration. Pratique pour gérer des contextes ou environnements différents. Nous y reviendrons dans un prochain article 🙂
Préparation de l’environnement Azure
Pour l’illustrer, nous allons d’abord créer rapidement un cluster AKS pour notre POC. Je créé un ressource group :
az group create --name aks --location eastus
Puis un cluster AKS :
az aks create --resource-group aks --name myAKS --node-count 1
Je me connecte à mon cluster maintenant qu’il est disponible :
az aks get-credentials --resource-group aks --name myAKS
J’y ajoute le support Azure Dev Spaces :
az aks use-dev-spaces -g aks -n myAKS -s dev -y
Si la CLI Azure Dev Spaces n’est pas installée sur votre pc vous obtiendrez cet écran vous invitant à l’installer :
La création du “dev spaces” peux prendre quelque instant. Une fois terminé vous verrez :
A noter qu’on peux créer des sous espaces en dessous de la racine créé ici (dev) pour travailler éventuellement à plusieurs développeurs. Exemple :
az aks use-dev-spaces -g aks -n myAKS -s dev/thomas -y
Création du projet
Notre environnement de test est désormais prêt. Passons au projet ! Sous Visual Studio 2019 je créé un projet de type Application Kubernetes :
Je demande donc une WebAPI .Net Core. Actuellement j’utilise le framework .Net Core 2.2.
Visual Studio me créé alors le projet ci dessous. Nous retrouvons un dockerfile, et les fichiers helm de déploiement dans mon cluster K8s :
Je vais configurer Swagger pour une interface plus agréable (se référer à ce tutoriel) ! La marche à suivre est strictement identique 🙂 Si j’exécute mon application en local j’obtiens alors :
Déploiement
Déployons maintenant dans mon cluster AKS grâce à Azure Dev Spaces :
Visual Studio me demande de choisir mon tenant Azure, mon cluster Kubernetes ainsi que mon espace de travail :
Le build est en cours :
Au bout de quelques temps vous devriez voir ceci :
Et l’appel suivant s’exécuter dans votre navigateur :
Problème, mon application semble s’exécuter en local … Mais en fait non ! Démonstration.
Vérifions ce qui est déployé sur mon cluster dans Azure :
kubectl get service --all-namespaces
Je récupère le nom de l’instance :
kubectl get pod -n thomas
En fait, ce qui est effectué par Visual Studio c’est une redirection de flux. Vous pouvez la faire vous même grâce à cette commande :
kubectl port-forward k8sapplication-778fd64ccd-mxhxl 8080:80 -n thomas
Précision : le premier paramètre correspond au nom de mon pod, le dernier au namespace de mon application.
Grâce à cette comande, les actions que j’effectue en local seront en fait bien réalisée dans mon cluster distant au travers de cette url :
http://localhost:8080/api/values
Je peux donc bien tester ma WebAPI déployée dans mon AKS via l’url fournie en sortie de build par Visual Studio :
Et confirmer que le debug :
Fonctionne toujours, malgré la redirection :
Le code est disponible sur Github ici !
C’est tout pour aujourd’hui ! A+