HOWTO Février 2020 HOWTO - Développement de Web API et déploiement Docker/Kubernetes sur Azure
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
HOWTO
Février 2020
HOWTO – Développement de Web API et déploiement
Docker/Kubernetes sur Azure
Préparé par
Christophe Pichaud
Leader de Domaine NET – MVP Developer Technologies
christophe.pichaud@infeeny.com
Revision and Signoff Sheet
Change Record
Date Author Version Change Reference
17/02/20 CPi 0.1 Initial version for review/discussion
19/02/20 CPi 0.9a Chapitre kubernetes
20/02/20 CPi DRAFT Cluster ok – pods running – test OK
Reviewers
Name Version Approved Position Date
Michel Hubert TODO
Cédric Cousin TODO
Michel Ruiz DRAFT Director 20/02/20
Table des Matières
1 Préambule .............................................................................................................................. 1
2 Introduction ........................................................................................................................... 2
2.1 NET ou NET Core ........................................................................................................................... 2
2.2 Introduction aux Web API ............................................................................................................. 2
2.2.1 La classes Controller .................................................................................................... 2
3 Docker et Containers : Introduction et concepts .............................................................. 3
3.1 Les containers Docker.................................................................................................................... 3
3.2 Docker et VM ................................................................................................................................. 3
3.3 Petit lexique de Docker.................................................................................................................. 4
3.4 Docker containers, images, registries ............................................................................................ 5
3.5 Docker containers : NET ou NET Core ? ......................................................................................... 5
3.6 Quel OS cibler avec les Containers ? ............................................................................................. 5
4 Architectures microservices et Containers ......................................................................... 7
5 Opérations dans Visual Studio 2019 .................................................................................. 8
5.1 Création d’un projet Web API NET Core ........................................................................................ 8
5.2 Docker : les opérations de base ................................................................................................... 12
5.3 VS2019 : la classe Controller du Web API .................................................................................... 13
5.4 VS2019 : le Dockerfile généré ...................................................................................................... 14
5.5 VS2019 : build & run du Dockerfile ............................................................................................. 15
5.6 Modifions le code source du Web API ........................................................................................ 17
6 Déploiement dans Azure (Registry ACR).......................................................................... 19
6.1 Etape : Login Azure ...................................................................................................................... 19
6.2 Etape : Création du Resource Group Azure MyBankWebAPI_RG ................................................. 19
6.3 Etape: Build de l’image Docker .................................................................................................... 20
6.4 Etape : Création de la Registry CPIACR02 dans ACR ................................................................... 23
iii
HOWTO
6.5 Etape: Tag de l’image Docker locale avec la Registry CPIACR02.azurecr.io ................................. 24
6.6 Etape : Login dans la Registry CPIACR02 Azure ........................................................................... 24
6.7 Etape : Push de l’image Docker dans CPIACR02 .......................................................................... 24
6.8 Etape : Création du cluster AKS CPI02Cluster Azure .................................................................... 25
6.9 Etape : Connexion au cluster CPI01Cluster .................................................................................. 25
6.10 Etape : Liaison entre le cluster AKS CPI02Cluster et la Registry CPIACR02 .................................. 26
6.11 Etape : Installation de helm ......................................................................................................... 28
6.12 Etape: Création des fichiers pour helm ........................................................................................ 28
6.12.1 Chart.yaml .................................................................................................................. 29
6.12.2 values.yaml................................................................................................................. 29
6.12.3 templates\deployment.yaml ........................................................................................ 29
6.12.4 templates\service.yaml : .............................................................................................. 30
6.13 Etape : Déploiement dans AKS via helm ...................................................................................... 31
6.14 Etape : Fichier de déploiement YAML (my1.yaml) ....................................................................... 31
6.15 Etape : Déploiement dans Kubernetes du fichier YAML .............................................................. 32
6.16 Etape : Exposition du déploiement en service via type=LoadBalancer ........................................ 32
6.17 Etape : récupération de l’adresse IP externe du service ............................................................... 32
6.18 Test du service ............................................................................................................................. 32
7 Monitoring ........................................................................................................................... 33
7.1 Portail Azure : Le cluster .............................................................................................................. 33
7.2 Portail Azure : Les controllers ...................................................................................................... 34
7.3 Portail Azure : Les logs du container ........................................................................................... 35
8 Conclusion ............................................................................................................................ 36
iv
HOWTO
1 Préambule
Le développement des Web API est une activité très répandue. Pourquoi ? Parce que les Web API sont
une technologie de Web Services qui échangent des données au format JSON donc exploitable par tous
les langages. Le JSON , c’est comme du XML mais en moins verbeux. De plus, les architectures modernes
exposent les front-end en JS et les Back-end en Web API Rest. Dans le monde des technologies
Microsoft, les Back-end se font en C#/NET et utilisent les architectures micros-services.
Une fois développés, les Web API sont déployés dans des microservices et tournent sur Docker et
Kubernetes dans Azure. C’est la voie royale de fonctionnement des systèmes modernes.
Page 1
HOWTO
2 Introduction
2.1 NET ou NET Core
Avant de développer sur la technologie NET, il faut choisir entre NET et NET Core. Microsoft préconise
de développer les nouvelles applications en .NET Core et de laisser les applications déjà développées en
NET Framework. Nous allons donc choisir .Net Core. La version exacte en NET Core 3.1. Vous pouvez
télécharger .NET Core et .NET Core SDK sur https://dotnet.microsoft.com/download.
2.2 Introduction aux Web API
La technologie ASP.NET Core prend en charge le support des Web Services REST aka Web API. Les
données sont gérées sous forme de flux JSON et exploitables par des clients hétérogènes comme C#, TS
ou Javascript. Dans ASP.NET Core, une Web API est une classe qui hérite de ControllerBase. ASP.NET
Core support les HTTP Web Services au travers une API simple à exploiter. La technologie précédente à
Web API se nommait WCF (Windows Communication Foundation) mais on laisse de côté cette chose là
avec ASP.NET Core. Les nouvelles APIs sont plus simples à utiliser.
Pour les applications clientes, Web API cela représente avant tout le format de données échangées à
savoir JSON qui est moins verbeux que XML et plus rapide à traiter.
2.2.1 La classes Controller
La classe Controller gère toute le pipeline ASP.NET Web API. Il suffit de créer une méthode dans une
classe dérivée et cela devient une méthode d’une Web API. La classe dérivée est la Web API. La
méthode est une méthode http. Exemple :
[HttpGet("GetHW")]
public JsonResult GetHW()
{
string [] result = { "Hello World !", "C# is great", "NET is wonderful" };
return new JsonResult(result);
}
Page 2
HOWTO
3 Docker et Containers : Introduction et concepts
Les conteneurs sont une (autre) façon de faire tourner un système d’exploitation et une application de
manière isolée et virtualisée. À chaque démarrage, on part sur un nouvel environnement tout neuf. Il
est possible de faire tourner plusieurs containers sur une même machine (host). En terme de montée en
charge, une solution à base de containers a des perspectives intéressantes. Les containers offrent les
bénéfices de l’isolation, de la portabilité, de l’agilité et une isolation entre les Dev et les Ops.
3.1 Les containers Docker
Docker est un projet Open-Source pour faire tourner des containers Linux ou Windows sur le Cloud ou
sur une machine standard (on-premise). Sous Windows, les développeurs peuvent faire tourner des
images Linux ou Windows.
3.2 Docker et VM
Docker c’est un peu comme une VM mais en plus souple. Dans une VM, il y a un OS, et N applications.
Sous Docker, on a une application. Et il est possible de faire tourner plusieurs containers Docker sur la
même machine. L’avantage d’utiliser Docker c’est que le syndrome du « ça marche sur ma machine ! »
ne tient plus. Si ça tourne sur Docker, ça tourne tout le temps.
Page 3
HOWTO
Figure 1: Différence entre VM et Docker
3.3 Petit lexique de Docker
• Une image de Container : package incluant avec toutes les dépendances nécessaires à sa
création. Une image contient les Frameworks, les DLL, les fichiers de configurations et tout ce
qui est nécessaire au runtime du container. Une fois créée, une image ne peut plus être
modifiée.
• Fichier Dockerfile : fichier texte contenantt les instructions pour construire une image Docker.
Ce fichier est comme un fichier CMD avec des commandes de copy, d’exécution pour définir
l’environnement.
• Build : commande docker permettant de construire une image Docker à partir d’un Dockerfile.
• Container : instance d’une image Docker. Il exécute un service, une application et les modules
de l’OS.
• Volumes : Espace de fichiers que le container peut utiliser.
• Tag : Identifiant d’une image docker
• Repository : Lieu de stockage des images Docker.
• Registry : Service qui permet d’accéder aux repositories. Les registries peuvent être locales ou
dans le Cloud.
Page 4
HOWTO
3.4 Docker containers, images, registries
Une image Docker est une représentation statique d’une application ou d’un service avec sa
configuration et ses dépendances. Pour faire fonctionner un service, l’image de l’application est
instanciée pour créer un container.
3.5 Docker containers : NET ou NET Core ?
Quel est le framework NET à choisir lorsqu’on utilise les containers Linux ou Windows ?
Architecture / App Type Linux containers Windows Containers
Microservices on containers .NET Core .NET Core
Monolithic app .NET Core .NET Framework .NET Core
Best-in-class performance and .NET Core .NET Core
scalability
Windows Server legacy app – .NET Framework
(“brown-field”) migration to
containers
New container-based .NET Core .NET Core
development (“green-field”)
ASP.NET Core .NET Core .NET Core (recommended)
.NET Framework
ASP.NET 4 (MVC 5, Web API 2, – .NET Framework
and Web Forms)
SignalR services .NET Core 2.1 or higher .NET Framework .NET Core 2.1
version or higher version
WCF, WF, and other legacy WCF in .NET Core (client .NET Framework WCF in .NET
frameworks library only) Core (client library only)
Consumption of Azure .NET Core (eventually all Azure .NET Framework .NET Core
services services will provide client (eventually all Azure services
SDKs for .NET Core) will provide client SDKs for
.NET Core)
Source:
3.6 Quel OS cibler avec les Containers ?
Pour Windows, on va adresser Windows Server Core ou Windows Nano Server.
Pour Linux, il existe de nombreuses distributions…
Page 5
HOWTO
Figure 2: Choix des OS cibles
Page 6
HOWTO4 Architectures microservices et Containers
Les architectures micro-services permettent de réaliser une application serveur en un ensemble de
petits services. Une architecture microservices est orientée back-end. Chaque service tourne dans son
propre processus et communique avec d’autres en utilisant les protocoles HTTP/HTTPS, les WebSockets
ou AMQP. Ils utilisent pour cela un bus de messages transactionnel. Chaque microservice couvre un
domaine ou une partie spécifique métier de manière autonome et déployable indépendamment.
Chaque microservice possède son moteur de stockage relationnel (base de données) ou moteur NoSQL
et peut être écrit en différents langages. Il n’y a pas de taille idéale pour un microservice mais il est
préférable qu’il soit, le plus petit possible, autonome et indépendant des autres services.
Les microservices permettent une meilleure maintenabilité dans un système complexe et hautement
scalable en vous laissant mettre en œuvre des services déployables indépendamment qui ont chacun
leur niveau de granularité et d’autonomie.
Page 7
HOWTO5 Opérations dans Visual Studio 2019
Dans les paragraphes suivants, nous vous proposons de mettre en œuvre un microservice simulant un
service bancaire viaune méthode GetAccounts qui retourne des informations sur des comptes.
5.1 Création d’un projet Web API NET Core
Lancez Visual Studio 2019 et créer un nouveau projet « ASP.NET Core Web Application »
Nommez le projet MyBankWebAPI et choisir un répertoire de travail ou seront déposé les fichiers
source :
Page 8
HOWTOChoisissez ensuite le type d’application API. Sur la droite de la boite de dialogue, choisissez les options
support HTTPS et support Docker. Attention, dans la combo-box, vérifier que Linux est sélectionné.
Page 9
HOWTOAppuyez sur Create.
Visual Studio vous propose de lancer Docker Desktop avec une configuration par défaut et Visual Studio
vous affiche la boite suivante :
Cliquez sur Yes pour passer en containers Linux.
Page 10
HOWTOUne boite de popup de Docker va s’afficher pour savoir si vous voulez partager votre drive C:\. Cliquez
sur Oui. Visual Studio lance des commandes en arrière-plan et le browser par défaut se lance et la Web
API s’affiche. En parallèle, le firewall demande une autorisation d’accès.
Voici l’affiche du browser :
On remarque que Visual Studio 2019 a généré automatiquement :
- Le code d’une WebAPI
- Le mécanisme Docker pour faire tourner notre application dans un container.
Page 11
HOWTO5.2 Docker : les opérations de base
Ouvrez une ligne de commande :
Tapez la commande : docker ps -a
C:\dev\netcore\MyBankWebAPI>docker ps -a
CONTAINER ID IMAGE COMMAND CREATED
STATUS PORTS NAMES
a50cafc6a432 mybankwebapi:dev "tail -f /dev/null" 10 minutes ago Up
10 minutes 0.0.0.0:32769->80/tcp, 0.0.0.0:32768->443/tcp MyBankWebAPI
Cette commande permet de lister les processus Docker qui tourne. On voit que le processus
MyBankWebAPI tourne et que le port 443 est redirigé vers le port 32768 et que le port 80 est redirigé
vers le port 32769.
Tapez la commande : docker images
Page 12
HOWTOLes images générées par la commande build sont mybankwebapi et les deux mcr.microsoft.xx. ne tenez
pas compte des images alpine et mywebapi1 sont des scories. TODO : refaire l’image
5.3 VS2019 : la classe Controller du Web API
En navigant dans le code généré par Visual Studio, on remarquera qu’il existe un contrôler nommé
WeatherForecast. D’où la construction de l’URL avec https://localhost:32768/WeatherForecast. TODO
Voici l’extract du code source.
Page 13
HOWTOPour créer une Web API, il suffit de créer une classe qui hérité de ControllerBase et d’avoir une méthode
public préfixée de l’attribut HttpGet. C’est très simple.
public class WeatherForecastController : ControllerBase
{
// …
[HttpGet]
public IEnumerable Get()
{
// …
}
}
5.4 VS2019 : le Dockerfile généré
Pour utiliser Docker, il faut faire un fichier Dockerfile qui contient la description du système. Avec
Docker, on démarre d’une image de système d’exploitation vide. C’est la première ligne d’un Dockerfile.
Voici le Dockerfile généré par Visual Studio pour un support NET Core pour Linux :
#####################################################################
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 ["MyBankWebAPI.csproj", ""]
RUN dotnet restore "./MyBankWebAPI.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "MyBankWebAPI.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "MyBankWebAPI.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "MyBankWebAPI.dll"]
#####################################################################
Le fichier Dockerfile décrit les étapes de construction de l’image :
- On démarre d’une image d’OS Linux ASP.NET Core 3.1
- On expose les ports 80 (HTTP) et 443 (HTTPS)
Page 14
HOWTO- On copy les fichiers sources et projet
- On build l’application
- On démarre la dll MyBanKWebAPI.dll (en NET Core, tout est DLL)
5.5 VS2019 : build & run du Dockerfile
Pour pouvoir utiliser une image, il faut builder le Dockerfile et faire un run. Visual Studio fait tout ça en
arrière-plan quand on fait Build et Run… Mais la visualisation des commandes se fait dans le panel
Output :
1>------ Build started: Project: MyBankWebAPI, Configuration: Debug Any CPU ------
1>MyBankWebAPI -> C:\dev\netcore\MyBankWebAPI\bin\Debug\netcoreapp3.1\MyBankWebAPI.dll
1>docker build -f "C:\dev\netcore\MyBankWebAPI\Dockerfile" --force-rm -t mybankwebapi:dev
--target base --label "com.microsoft.created-by=visual-studio" --label
"com.microsoft.visual-studio.project-name=MyBankWebAPI" "C:\dev\netcore\MyBankWebAPI"
1>Sending build context to Docker daemon 18.43kB
1>
1>Step 1/6 : FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
1> ---> e28362768eed
1>Step 2/6 : WORKDIR /app
1> ---> Using cache
1> ---> 98c5404ce8a7
1>Step 3/6 : EXPOSE 80
1> ---> Using cache
1> ---> c11256aa40ab
1>Step 4/6 : EXPOSE 443
1> ---> Using cache
1> ---> 2a59406c84ff
1>Step 5/6 : LABEL com.microsoft.created-by=visual-studio
1> ---> 2dbf280807a4
1> ---> Using cache
1>Step 6/6 : LABEL com.microsoft.visual-studio.project-name=MyBankWebAPI
1> ---> Using cache
1> ---> b5db44270da3
1>Successfully built b5db44270da3
1>Successfully tagged mybankwebapi:dev
1>SECURITY WARNING: You are building a Docker image from Windows against a non-Windows
Docker host. All files and directories added to build context will have '-rwxr-xr-x'
permissions. It is recommended to double check and reset permissions for sensitive files
and directories.
1>docker run -dt -v "C:\Users\cpichaud\vsdbg\vs2017u5:/remote_debugger:rw" -v
"C:\dev\netcore\MyBankWebAPI:/app" -v "C:\dev\netcore\MyBankWebAPI:/src" -v
"C:\Users\cpichaud\AppData\Roaming\Microsoft\UserSecrets:/root/.microsoft/usersecrets:ro"
-v "C:\Users\cpichaud\AppData\Roaming\ASP.NET\Https:/root/.aspnet/https:ro" -v
"C:\Users\cpichaud\.nuget\packages\:/root/.nuget/fallbackpackages2" -v
"C:\Microsoft\Xamarin\NuGet\:/root/.nuget/fallbackpackages" -e
"DOTNET_USE_POLLING_FILE_WATCHER=1" -e "ASPNETCORE_ENVIRONMENT=Development" -e
"ASPNETCORE_URLS=https://+:443;http://+:80" -e
"NUGET_PACKAGES=/root/.nuget/fallbackpackages2" -e
Page 15
HOWTO"NUGET_FALLBACK_PACKAGES=/root/.nuget/fallbackpackages;/root/.nuget/fallbackpackages2" -P
--name MyBankWebAPI --entrypoint tail mybankwebapi:dev -f /dev/null
1>b2fa83ba188d126ba1f6ef9bebead5f61204ddd70e411f3f0a6235e037ebdde3
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
On remarque qu’il y a bien les commandes docker build et docker run. La commande run est assez
compliquée car VS2019 permet de débugguer un container donc on ne lance pas directement celle-ci
mais le remote debugguer.
Page 16
HOWTO5.6 Modifions le code source du Web API
Pour réaliser le microservice bancaire, le code source peut être modifié comme suit :
- Changez le nom de la classe
- Ajoutez la méthode GetAccounts
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Logging;
namespace MyBankWebAPI.Controllers
{
public class Account
{
public string number { get; set; }
public long value { get; set; }
}
[ApiController]
[Route("[controller]")]
public class MyWebBankAPI : ControllerBase
{
private readonly ILogger _logger;
public MyWebBankAPI(ILogger logger)
{
_logger = logger;
}
[HttpGet]
public string Get()
{
return "MyWebBankAPI";
}
[HttpGet("GetAccounts")]
public JsonResult GetAccounts()
{
Account[] accounts =
{
new Account { number = "35021100", value = 100 },
new Account { number = "65021200", value = 1000 },
new Account { number = "95021400", value = 500 },
};
Page 17
HOWTOreturn new JsonResult(accounts);
}
}
}
La méthode GetAccounts retourne un objet de type JsonResult qui est en fait la sérialisation d’un objet
C# au format JSON.
Maintenant, le Web API se nomme MyWebBankAPI et la méthode se nomme GetAccounts. On teste
tout cela dans le browser :
Il ne reste plus qu’à faire tourner cette Web API dans Kubernetes sur Azure.
Page 18
HOWTO6 Déploiement dans Azure (Registry ACR)
Allez sur le portail portal.azure.com et s’identifier. Vérifier que l’on dispose d’une souscription à jour.
Ensuite, lancez un cmd.
6.1 Etape : Login Azure
C:\dev\netcore\Azure>az login -u christophepichaud@hotmail.com -p
[
{
"cloudName": "AzureCloud",
"id": "26b14cad-ba1a-40b6-b455-412cab815096",
"isDefault": true,
"name": "Visual Studio Enterprise",
"state": "Enabled",
"tenantId": "f9398754-5b65-4713-a85b-c2c8a9eb7857",
"user": {
"name": "christophepichaud@hotmail.com",
"type": "user"
}
}
]
6.2 Etape : Création du Resource Group Azure MyBankWebAPI_RG
C:\dev\netcore\Azure>az group create --name MyBankWebAPI_RG --location francecentral
{
"id": "/subscriptions/26b14cad-ba1a-40b6-b455-412cab815096/resourceGroups/MyBankWebAPI_RG",
"location": "francecentral",
"managedBy": null,
"name": "MyBankWebAPI_RG",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null,
"type": "Microsoft.Resources/resourceGroups"
}
Page 19
HOWTO6.3 Etape: Build de l’image Docker
C:\dev\netcore\MyBankWebAPI>docker build -t mybanwebapi:dev .
Sending build context to Docker daemon 18.43kB
Step 1/17 : FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
---> e28362768eed
Step 2/17 : WORKDIR /app
---> Using cache
---> 98c5404ce8a7
Step 3/17 : EXPOSE 80
---> Using cache
---> c11256aa40ab
Step 4/17 : EXPOSE 443
---> Using cache
---> 2a59406c84ff
Step 5/17 : FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
3.1-buster: Pulling from dotnet/core/sdk
dc65f448a2e2: Pull complete
346ffb2b67d7: Pull complete
dea4ecac934f: Pull complete
8ac92ddf84b3: Pull complete
d6bef01952b9: Pull complete
9311becdb99f: Pull complete
Page 20
HOWTOcdbf4d78a668: Pull complete
Digest: sha256:08b93fd4e811dde905df14d06b5aa9e637583a17b440aa8c1df1b25bf3dc654e
Status: Downloaded newer image for mcr.microsoft.com/dotnet/core/sdk:3.1-buster
---> 0a4c7c13f9d6
Step 6/17 : WORKDIR /src
---> Running in d13115373bca
Removing intermediate container d13115373bca
---> f5607eab696a
Step 7/17 : COPY ["MyBankWebAPI.csproj", ""]
---> f20ddc1e9368
Step 8/17 : RUN dotnet restore "./MyBankWebAPI.csproj"
---> Running in e14b2d217f9c
Restore completed in 1.83 sec for /src/MyBankWebAPI.csproj.
Removing intermediate container e14b2d217f9c
---> 330b5390b57d
Step 9/17 : COPY . .
---> e5e1875a1fdc
Step 10/17 : WORKDIR "/src/."
---> Running in 77e886e74273
Removing intermediate container 77e886e74273
---> fc6ea2d0b2e7
Step 11/17 : RUN dotnet build "MyBankWebAPI.csproj" -c Release -o /app/build
---> Running in d8c43cdee6f5
Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
Restore completed in 32.92 ms for /src/MyBankWebAPI.csproj.
MyBankWebAPI -> /app/build/MyBankWebAPI.dll
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:02.41
Removing intermediate container d8c43cdee6f5
---> 32172aca48c4
Step 12/17 : FROM build AS publish
---> 32172aca48c4
Step 13/17 : RUN dotnet publish "MyBankWebAPI.csproj" -c Release -o /app/publish
---> Running in 7e4188357dd5
Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
Restore completed in 32.84 ms for /src/MyBankWebAPI.csproj.
MyBankWebAPI -> /src/bin/Release/netcoreapp3.1/MyBankWebAPI.dll
MyBankWebAPI -> /app/publish/
Removing intermediate container 7e4188357dd5
---> 9f2daea1727e
Step 14/17 : FROM base AS final
---> 2a59406c84ff
Step 15/17 : WORKDIR /app
---> Running in 824ef5fb4bab
Page 21
HOWTORemoving intermediate container 824ef5fb4bab
---> 609e96e9f999
Step 16/17 : COPY --from=publish /app/publish .
---> a2f0be5cbc50
Step 17/17 : ENTRYPOINT ["dotnet", "MyBankWebAPI.dll"]
---> Running in c03408eacfd8
Removing intermediate container c03408eacfd8
---> c18007d5f700
Successfully built c18007d5f700
Successfully tagged mybanwebapi:dev
SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host.
All files and directories added to build context will have '-rwxr-xr-x' permissions. It is
recommended to double check and reset permissions for sensitive files and directories.
Page 22
HOWTO6.4 Etape : Création de la Registry CPIACR02 dans ACR
C:\dev\netcore\Azure>az acr create --resource-group MyBankWebAPI_RG --name CPIACR02 --sku Basic
{
"adminUserEnabled": false,
"creationDate": "2020-02-18T14:49:11.744126+00:00",
"id": "/subscriptions/26b14cad-ba1a-40b6-b455-
412cab815096/resourceGroups/MyBankWebAPI_RG/providers/Microsoft.ContainerRegistry/registries/CPIA
CR02",
"location": "francecentral",
"loginServer": "cpiacr02.azurecr.io",
"name": "CPIACR02",
"networkRuleSet": null,
"policies": {
"quarantinePolicy": {
"status": "disabled"
},
"retentionPolicy": {
"days": 7,
"lastUpdatedTime": "2020-02-18T14:49:38.348081+00:00",
"status": "disabled"
},
"trustPolicy": {
"status": "disabled",
"type": "Notary"
}
},
"provisioningState": "Succeeded",
"resourceGroup": "MyBankWebAPI_RG",
"sku": {
"name": "Basic",
"tier": "Basic"
},
"status": null,
"storageAccount": null,
"tags": {},
"type": "Microsoft.ContainerRegistry/registries"
}
Page 23
HOWTOC:\dev\netcore\Azure>az acr list --resource-group MyBankWebAPI_RG --query
"[].{acrLoginServer:loginServer}" --output table
AcrLoginServer
-------------------
cpiacr01.azurecr.io
C:\dev\netcore\MyBankWebAPI>az acr login --name CPIACR01 -u CPIACR01 -p
iX003z/60onei89cIrxUF2VsMk03RJVw
Uppercase characters are detected in the registry name. When using its server url in docker
commands, to avoid authentication errors, use all lowercase.
Login Succeeded
6.5 Etape: Tag de l’image Docker locale avec la Registry
CPIACR02.azurecr.io
C:\dev\netcore\MyBankWebAPI>docker tag mybankwebapi:dev cpiacr02.azurecr.io/mybankwebapi:dev
6.6 Etape : Login dans la Registry CPIACR02 Azure
C:\dev\netcore\Azure>az acr login --name CPIACR02 -u CPIACR02 -p H++H6BrAstb2gfr5pLh=dbnO0ti58HSp
Uppercase characters are detected in the registry name. When using its server url in docker
commands, to avoid authentication errors, use all lowercase.
Login Succeeded
6.7 Etape : Push de l’image Docker dans CPIACR02
C:\dev\netcore\Azure>docker push cpiacr02.azurecr.io/mybankwebapi:dev
The push refers to repository [cpiacr02.azurecr.io/mybankwebapi]
cd716a073a1a: Pushed
a7aa6b2d6085: Pushed
0152e28994ea: Pushed
f24f88aebde0: Pushed
acfb6a7e0442: Pushed
488dfecc21b1: Pushed
dev: digest: sha256:3ceed356a3b09c7d714e8efe677272189f59df286a265a2760210cfb504d56dd size: 1582
Page 24
HOWTO6.8 Etape : Création du cluster AKS CPI02Cluster Azure
6.9 Etape : Connexion au cluster CPI01Cluster
C:\dev\netcore\Azure>az aks get-credentials --resource-group MyBankWebAPI_RG --name CPI01Cluster
Merged "CPI01Cluster" as current context in C:\Users\cpichaud\.kube\config
Page 25
HOWTO6.10 Etape : Liaison entre le cluster AKS CPI02Cluster et la Registry
CPIACR02
C:\dev\netcore\Azure>az aks update -n CPI02Cluster -g MyBankWebAPI_RG --attach-acr CPIACR02
[K{- Finished ..ion done[############################################] 100.0000%
"aadProfile": null,
"addonProfiles": {
"httpApplicationRouting": {
"config": null,
"enabled": false
},
"omsagent": {
"config": {
"logAnalyticsWorkspaceResourceID": "/subscriptions/26b14cad-ba1a-40b6-b455-
412cab815096/resourcegroups/defaultresourcegroup-
Page 26
HOWTOpar/providers/microsoft.operationalinsights/workspaces/defaultworkspace-26b14cad-ba1a-40b6-b455-
412cab815096-par"
},
"enabled": true
}
},
"agentPoolProfiles": [
{
"availabilityZones": null,
"count": 3,
"enableAutoScaling": null,
"enableNodePublicIp": null,
"maxCount": null,
"maxPods": 110,
"minCount": null,
"name": "agentpool",
"nodeTaints": null,
"orchestratorVersion": "1.14.8",
"osDiskSizeGb": 100,
"osType": "Linux",
"provisioningState": "Succeeded",
"scaleSetEvictionPolicy": null,
"scaleSetPriority": null,
"type": "VirtualMachineScaleSets",
"vmSize": "Standard_DS2_v2",
"vnetSubnetId": null
}
],
"apiServerAccessProfile": null,
"dnsPrefix": "CPI02Cluster-dns",
"enablePodSecurityPolicy": null,
"enableRbac": true,
"fqdn": "cpi02cluster-dns-f0a101a9.hcp.francecentral.azmk8s.io",
"id": "/subscriptions/26b14cad-ba1a-40b6-b455-
412cab815096/resourcegroups/MyBankWebAPI_RG/providers/Microsoft.ContainerService/managedClusters/
CPI02Cluster",
"identity": null,
"kubernetesVersion": "1.14.8",
"linuxProfile": null,
"location": "francecentral",
"maxAgentPools": 10,
"name": "CPI02Cluster",
"networkProfile": {
"dnsServiceIp": "10.0.0.10",
"dockerBridgeCidr": "172.17.0.1/16",
"loadBalancerProfile": {
"effectiveOutboundIps": [
{
"id": "/subscriptions/26b14cad-ba1a-40b6-b455-
412cab815096/resourceGroups/MC_MyBankWebAPI_RG_CPI02Cluster_francecentral/providers/Microsoft.Net
work/publicIPAddresses/a66840ea-a9e1-417d-81c3-59b486775640",
"resourceGroup": "MC_MyBankWebAPI_RG_CPI02Cluster_francecentral"
Page 27
HOWTO}
],
"managedOutboundIps": {
"count": 1
},
"outboundIpPrefixes": null,
"outboundIps": null
},
"loadBalancerSku": "Standard",
"networkPlugin": "kubenet",
"networkPolicy": null,
"outboundType": "loadBalancer",
"podCidr": "10.244.0.0/16",
"serviceCidr": "10.0.0.0/16"
},
"nodeResourceGroup": "MC_MyBankWebAPI_RG_CPI02Cluster_francecentral",
"privateFqdn": null,
"provisioningState": "Succeeded",
"resourceGroup": "MyBankWebAPI_RG",
"servicePrincipalProfile": {
"clientId": "d144475e-6ad6-43fb-a72e-1c813d4b07b7",
"secret": null
},
"tags": null,
"type": "Microsoft.ContainerService/ManagedClusters",
"windowsProfile": null
}
6.11 Etape : Installation de helm
helm est un gestionnaire de packages pour kubernetes.
Dans un powershell admin :
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'))
choco install kubernetes-helm
6.12 Etape: Création des fichiers pour helm
Créez un répertoire chart avec deux fichiers : Chart.yaml et values.yaml.
Page 28
HOWTO6.12.1 Chart.yaml
name: aspnet3-demo
version: 1.0.0
6.12.2 values.yaml
environment: development
apphost: k8s
label:
name: mybankwebapi
container:
name: mybankwebapi
pullPolicy: IfNotPresent
image: cpiacr02.azurecr.io/app1
tag: dev
port: 80
replicas: 3
service:
port: 8888
#type: ClusterIP
type: NodePort
6.12.3 templates\deployment.yaml
Créez un répertoire chart/templates avec deux fichiers : deployment.yaml et service.yaml.
Page 29
HOWTOapiVersion: 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}}
6.12.4 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 }}
Page 30
HOWTO6.13 Etape : Déploiement dans AKS via helm
helm installl app1 ./chart
Au lieu de faire en helm, le déploiement peut de faire via kubectl :
6.14 Etape : Fichier de déploiement YAML (my1.yaml)
Créez le fihicer texte YAML suivant :
apiVersion: apps/v1
kind: Deployment
metadata:
name: mybankwebapi-app
spec:<
selector:
matchLabels:
run: mybankwebapi
replicas: 3
template:
metadata:
labels:
run: mybankwebapi
spec:
containers:
- name: mybankwebapi
image: cpiacr02.azurecr.io/mybankwebapi:dev
ports:
- containerPort: 80
protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
name: mybankwebapi-service
labels:
app: mybankwebapi
spec:
ports:
- port: 8888
protocol: TCP
targetPort: 80
selector:
app: mybankwebapi
type: NodePort
Page 31
HOWTO6.15 Etape : Déploiement dans Kubernetes du fichier YAML
C:\dev\netcore\Azure>kubectl apply -f my1.yaml
deployment.apps/mybankwebapi3 unchanged
6.16 Etape : Exposition du déploiement en service via
type=LoadBalancer
kubectl expose deployment app1-deployment --type=LoadBalancer --name=app2-service
6.17 Etape : récupération de l’adresse IP externe du service
C:\dev\netcore\Azure>kubectl get service app2-service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
app2-service LoadBalancer 10.0.79.209 20.40.145.151 80:31346/TCP 159m
6.18 Test du service
Avec l’adresse IP externe du service, nous pouvons créer l’URL de test du microservices :
C:\dev\netcore\Azure>curl 20.40.145.151/MyWebBankAPI/GetAccounts
[{"number":"35021100","value":100},{"number":"65021200","value":1000},{"number":"95021400","value
":500}]
Page 32
HOWTO7 Monitoring
7.1 Portail Azure : Le cluster
Page 33
HOWTO7.2 Portail Azure : Les controllers
Page 34
HOWTO7.3 Portail Azure : Les logs du container
Page 35
HOWTO8 Conclusion
La mise en œuvre des technologies NET Core et leur déploiement sous Docker et Kubernetes est un
challenge à relever pour les développeurs legacy NET Framework. Avec un peu de bonne volonté, il est
possible de mettre à niveau ses compétences rapidement. L’utilisation de Kubernetes requiert la
maitrise d’outils en mode ligne de commandes sous un shell. Cela peut paraitre compliqué mais il n’en
est rien.
Page 36
HOWTOVous pouvez aussi lire
