Nous avons eu l’occasion de travailler à deux reprises avec Kubernetes.
Deux univers bien distinct : Windows et Linux
Ce qu’il faut savoir, c’est que Kubernetes ne fonctionne pas sous Windows dans son plus simple appareil, il faut donc utiliser Linux pour pouvoir le découvrir et pour l’apprendre concrètement.
Si vous voulez l’utiliser sous Windows, il vous faudra utiliser des services externes type AKS. Néanmoins, pour ma part, je trouve que la compréhension d’un outil via ce genre de plateforme est assez biaisé, car trop « magique”. Cela demande une certaines rigueur,une curiosité et un intérêt différent que si vous le faisiez directement sous Linux.
Prérequis pour ce tutoriel
- Visual Studio 2019 (ou Visual Studio Code)
- Internet (pour accéder au portail Azure)
- Powershell
- Helm
- Chocolatey
- Docker
- Azure-CLI
Création d’une Web API .NET Core 3.1 avec un container Docker sous Linux
Aujourd’hui, nous allons voir ensemble comment créer une Web API sous .NET Core 3.1 et la déployer sous Azure.
Ouvrez votre Visual Studio et créer un nouveau projet ASP .NET Core Application.
Choisissez ensuite API (faites attention à bien avoir sélectionné .NET Core ainsi que la version 3.1) puis dans le panneau de configuration à droite dans la partie “Advanced” de cocher “Enable Docker Support” et de choisir Linux.
L’API par défaut que crée Microsoft, s’appelle WeatherForecast, et dans notre cas nous avons choisis de nommer notre projet WeatherForecastLinux (pour les personnes manquant d’inspiration pour le nommage, c’est cadeau…).
On va donc constater qu’un fichier Dockerfile est présent. Si vous pratiquez Docker ou que vous avez quelques bases dessus vous connaissez donc son utilité. Pour expliquer pourquoi il est présent, vous vous doutez fortement que c’est dû au fait qu’on ait coché la case de support de Docker lors de la création du projet.
Pour les personnes ne sachant pas ce qu’est un Dockerfile, voici une définition succincte : c’est un fichier texte contenant des instructions sur la façon de construire une image Docker.
Voilà à quoi ressemble notre Dockerfile auto-généré :
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base WORKDIR /app EXPOSE 80 EXPOSE 443
FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build WORKDIR /src COPY [“WeatherForecastLinux.csproj”, “”] RUN dotnet restore “./WeatherForecastLinux.csproj” COPY . . WORKDIR “/src/.” RUN dotnet build “WeatherForecastLinux.csproj” -c Release -o /app/build FROM build AS publish RUN dotnet publish “WeatherForecastLinux.csproj” -c Release -o /app/publish
FROM base AS final WORKDIR /app COPY — from=publish /app/publish . ENTRYPOINT [“dotnet”, “WeatherForecastLinux.dll”]
Si vous souhaitez vérifier que votre application se lance correctement, je vous suggère de cliquer sur :
Le fait de cliquer sur Docker, va permettre de build et de run le Dockerfile et donc de créer l’image Docker.
Nous allons maintenant ouvrir une fenêtre PowerShell :
- Soit vous l’ouvrez directement dans le dossier de votre projet
- Soit vous vous placez au bon endroit pour être au niveau de votre Dockerfile
Le build et le run précédent vous on créée une image, pour vérifier le nom de celui-ci vous pouvez directement taper la commande :
docker ps -a
Ou
docker images
Maintenant que toutes les fondations sont posées, nous pouvons maintenant passer au déploiement.
Azure Kubernetes Service (AKS)
Tout d’abord, assurez-vous d’avoir accès au Portail Azure, si ce n’est pas le cas créer vous un compte via une adresse Microsoft, et utiliser les 150€ gratuit fournit de base par Microsoft (si vous êtes vigilant dans vos différentes opérations avec Azure, vous ne devriez pas utiliser tout ce crédit en un coup).
Petit disclaimer : il y aura forcément un aspect « magique » ou un aspect de confusion pour les nouveaux arrivants sur Azure (et parfois même pour les plus anciens…) car Azure est très vaste, mais ne vous inquiétez pas, c’est tout à fait normal !
Il nous faudra tout d’abord installer Azure-CLI sur notre poste, afin d’utiliser la commande az (qui nous permet de faire de l’Azure directement via notre fenêtre Powershell). Pour se faire, ouvrir Powershell en mode administrateur et utiliser la commande suivante :
Invoke-WebRequest -Uri https://aka.ms/installazurecliwindows -OutFile .\AzureCLI.msi; Start-Process msiexec.exe -Wait -ArgumentList ‘/I AzureCLI.msi /quiet’
Redémarrer votre Powershell pour que la commande puisse être active. Si cela ne fonctionne pas chez vous, installez le .msi directement sur le site et installez-le classiquement.
Il vous faut maintenant vous connecter, pour que votre instance et les informations soient bien raccorder à votre Portail Azure :
az login -u votremail@mail.com -p votremotdepasse
Kubernetes
Kubernetes est un orchestrateur. On peut dire que c’est un ensemble de services réseaux qui permet de lancer des pods Docker en cluster avec une gestion de Load Balancing.
Pods
Les pods correspondent au processus en cours d’exécution et encapsulent un ou des conteneurs applicatifs. Ce sont des instances uniques, cela signifie qu’ils possèdent :
- Une IP unique
- Un fichier qui indique comment le conteneur doit être exécuté
- Des ressources de stockage
Ce qu’il faut retenir, si nous devions résumer un peu tout ça, c’est que les pods peuvent correspondre à une application ayant sa propre mémoire, sa propre IP. Néanmoins, un pod a une durée de vie définit et ne sera pas en mesure de se relancer automatiquement de lui-même.
Load Balancing
Ou répartition de charge en français, désigne un processus de répartition d’un ensemble de tâche sur un ensemble de ressources. Le but étant de rendre le traitement global plus efficace, en permettant d’optimiser le temps de réponse pour chaque tâche tout en évitant un surcharge inégale des nœuds de calculs.
Création d’un Resource Group Azure : WeatherForecastAPI_RG
Resource Group (ou RG)
Un resource group ou groupe de ressources est en quelque sorte un conteneur dit « logique » ayant pour objectif de regrouper différentes entités (Web API, VM, Base de données, etc…). Toutes les entités présentes au sein du groupe sont alors accessibles.
Dans notre cas, cela va nous permettre de créer un cluster et de déployer notre application directement dans ce RG.
Pour pouvoir créer un groupe de ressources en ligne de commande :
az group create --name WeatherForecastAPI_RG --location francecentral
La réponse à cette commande devra vous apparaître sous cette forme :
{
"id": "/subscriptions/caf29a4f-0f21-45d9-b52e-f1e0c0b8e4be/resourceGroups/WeatherForecastAPI_RG",
"location": "francecentral",
"managedBy": null,
"name": "WeatherForecastAPI_RG",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null,
"type": "Microsoft.Resources/resourceGroups"
}
Comme nous pouvons le voir, nous retrouvons le nom de notre Resource Group ainsi que son state (Succeeded). Nous pouvons également voir que nous avons bien la localisation précédemment choisie qui nous est retournée.
Build de l’image Docker
Docker
Docker est une plateforme de conteneurisation. Et les conteneurs ressemblent en tout point à des machines virtuelles ou seul le système d’exploitation ou OS aura été virtualisé. Docker permet de regrouper tout le nécessaire de notre application et est donc qualifiée de compacte, puissante et innovante avec une scalabilité importante.
Nous allons donc builder l’image dont on parle un peu plus haut : weatherforecastlinux mais cette fois nous allons récupérer le tag avec le mot clef -t (que vous pouvez également voir sur la capture d’écran plus haut).
docker build -t weatherforecastlinux:dev .
Si tout se déroule correctement vous êtes censés avoir une mention de toutes les étapes présente dans votre Dockerfile ainsi que la notion Successfully
Création de la registry WEFCACR dans Azure Container Registry (ACR)
Registry
Une registry est une sorte de « repository » d’images. Grossièrement on peut dire que c’est un espace de stockage d’images.
Pour pouvoir la créer sous Azure en ligne de commande :
az acr create --resource-group WeatherForecastAPI_RG --name WEFCACR --sku Basic
La commande ci-dessus permet de créer une registry, en spécifiant le Resource Group ainsi que le nom que l’on souhaite donner à la registry (ici WEFACR). Le –sku Basic est un élément sans importance, d’ailleurs si vous ne l’indiquez pas, par défaut il vous sera rajouté.
La commande suivante, vous permet de lister les différentes registry.
az acr list --resource-group WeatherForecastAPI_RG --query "[].{acrLoginServer:loginServer}" --output table
Enfin la commande az acr login, vous permet comme son nom l’indique de vous connecter à Azure Container Registry (ACR).
az acr login --name WEFCACR
Tag de l’image Docker avec la registry wefcacr.azurecr.io
La commande ci-dessous, vous permet de taguer votre image docker en lui donnant un nouveau nom :
docker tag weatherforecastlinux:dev wefcacr.azurecr.io/weatherforecast:dev
Se connecter dans la registry WEFCACR
az acr login --name WEFCACR
Push de l’image Docker dans WEFCACR
On va push l’image dans la registry en faisant un docker push et en spécifiant le nom de la registry (que l’on peut retrouver à l’aide de la commande az acr list) et en spécifiant le nom de l’image ainsi que son tag.
docker push wefcacr.azurecr.io/weatherforecast:dev
Création du cluster AKS WEFCACRCluster
Cluster
Un cluster Azure peut être considéré comme une « grappe », il peut utiliser des nœuds et exécuter des conteneurs.
Allez sur le portail Azure et dans la barre de rechercher, taper Kubernetes services :
Cliquez sur le bouton Add, vous atteindrez cette page :
Puis cliquer sur Ajouter, votre Cluster mettra un certains temps à se créer ce qui est tout à fait normal. Il vous faudra donc patienter deux minutes grand maximum, avant de lancer la commande suivante :
Connexion au cluster WEFCACRCluster
az aks get-credentials --resource-group WeatherForecastAPI_RG --name WEFCACRCluster
permet d’associer le ressource group a notre cluster
Liaison entre le cluster AKS et la registry
az aks update -n WEFCACRCluster -g WeatherForecastAPI_RG --attach-acr WEFCACR
ici nous attachons notre cluster a notre registry en spécifiant a qu’elle ressources groupe notre cluster appartient
Installation de Helm sous Windows
Helm est un gestionnaire de paquets pour Kubernetes qui va permettre d’installer et de gérer le cycle de vie de nos applications.
Pour l’installer sous Windows, il vous faut installer Chocolatey et pour se faire voici la première commande permettant d’installer Chocolatey (gestionnaire de paquets pour Windows qui vous permet d’installer ou de désinstaller des applications grâce à la commande choco).
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
- Installation de Helm via Chocolatey
choco install kubernetes-helm
Création des fichiers avec Helm
Nous allons créer un dossier chart, qui sera architecturé de la façon suivante :
- chart/
- Chart.yaml
- values.yaml
- templates/
- deployment.yaml
- service.yaml
Architecture du fichier Chart.yaml
name: aspnet3-demo version: 1.0.0
Architecture du fichier values.yaml
environment: development apphost: k8s label: name: dockerwithlinux container: name: dockerwithlinux pullpolicy: IfNotPresent image: jlaacr02.azurecr.io/app1 tag: v1 port: 80 replicas: 3 service: port: 8888 #type: ClusterIP type: NodePort
Ce fichier va nous permettre de définir quelle image nous allons pull et quel tag utiliser, ainsi que les port que nous voulons.
Architecture du fichier templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-deployment
labels:
app: {{ .Values.label.name }}
spec:
replicas: {{ .Values.replicas }}
selector:
matchLabels:
app: {{ .Values.label.name }}
template:
metadata:
labels:
app: {{ .Values.label.name }}
environment: {{ .Values.environment }}
spec:
containers:
- name: {{ .Values.container.name }}
image: {{ .Values.container.image }}:{{ .Values.container.tag }}
imagePullPolicy: {{ .Values.container.pullPolicy }}
ports:
- containerPort: {{ .Values.container.port }}
env:
- name: apphost
value: {{ .Values.apphost }}
- name: appenvironment
value: {{ .Values.environment}}
Ce fichier forme notre application en type deployement .
Architecture du fichier templates/service.yaml
apiVersion: v1
kind: Service
metadata:
name: {{ .Release.Name }}-service
labels:
app: {{ .Values.label.name }}
spec:
ports:
- port: {{ .Values.service.port}}
protocol: TCP
targetPort: {{ .Values.container.port }}
selector:
app: {{ .Values.label.name }}
type: {{ .Values.service.type }}
Ce fichier forme notre application pour le mode service.
Déploiement dans AKS via Helm
La commande ci-dessous permet de déployer notre image.
helm install dockerwithlinux ./chart
Déploiement dans AKS sans Helm
Nous allons créer un fichier my1.yaml :
apiVersion: apps/v1
kind: Deployment
metadata:
name: dockerwithlinux-app
spec:
selector:
matchLabels:
run: dockerwithlinux
replicas: 3
template:
metadata:
labels:
run: dockerwithlinux
spec:
containers:
- name: dockerwithlinux
image: jlaacr02.azurecr.io/dockerwithlinux:v1
ports:
- containerPort: 80
protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
name: dockerwithlinux-service
labels:
app: dockerwithlinux
spec:
ports:
- port: 8888
protocol: TCP
targetPort: 80
selector:
app: dockerwithlinux
type: NodePort
Déploiement dans Kubernetes du fichier my1.yaml
kubectl apply -f my1.yaml
Exposition du déploiement en service
kubectl expose deployment dockerwithlinux-deployment --type=LoadBalancer --name=dockerwithlinux-service
Récupération de l’adresse IP externe du service
kubectl get service dockerwithlinux-service
Cette commande nous permet de récupérer notre service ainsi que l’IP externe qui sera tout d’abord dans un état dit « pending » (en attente en français).
Nous en avons créé un deuxième de service ici, mais fiez-vous à la commande get-service que vous voyez.
Comme nous pouvons le voir ici, par rapport à ce que nous disions, nos avons un EXTERNAL-IP ou IP externe qui prend tout d’abord un état « en attente » en fonction de l’état de votre cluster (vous n’aurez pas du tout la même IP que nous donc dans l’étape du dessous pensez bien à mettre votre EXTERNAL-IP que la commande vous indiquera).
Test du service
Comme vu juste au dessus, nous allons donc récupérer notre EXTERNAL-IP est l’inclure dans la commande suivante :
curl 20.40.148.135/controllerName/methodName
Mettre capture d’écran.
Nous allons maintenant nous rendre sur le portail Azure, afin de visualiser le cluster WEFACRCluster.
Monitoring
Cluster
Nous voici à présent sur le portail Azure, dans notre Cluster (pour rappel, pour y accéder il faut aller au niveau de Kubernetes Services, puis sur votre Cluster, et aller dans l’onglet Insights). On peut constater les diverses activités de celui-ci.
On peut voir la quantité de CPU utilisé, la mémoire, le nombre de nœuds ainsi que l’activité des pods.
Contrôleurs
Vous restez sur votre Cluster, et vous devez sélectionner Controller :
Cette partie contrôleurs, peut s’apparenter au portail Kubernetes qui nous permet de visualiser les différents états de nos images.
Conclusion
Comme nous avons pu le voir tout au long de ce tutoriel, Azure est une sorte de baguette magique surpuissante, mais qui dissimule un pouvoir mal compris ou mal utilisé par beaucoup d’entre nous finalement. Hors malgré cela, il ne faut pas simplement le pointer du doigt en disant que c’est le mal, mais plutôt essayer de comprendre en profondeur où cela veut nous mener. Kubernetes et Docker sont de plus en plus mis sur le devant de la scène et pour une meilleure compréhension, nous avons tendance à penser qu’il vaut mieux que vous vous formiez indépendamment d’Azure, car la dissimulation est le pire ennemi du savoir et dans notre milieu, en tant que développeurs, le savoir et la capacité d’apprendre par nous-même est, selon nous, primordial.
Article écrit par :
- Julie LACOGNATA <julie.lacognata@infeeny.com>
- Kévin ANSARD <kevin.ansard@infeeny.com>
