Azure Web App Deployment Slots

Hello !

Un sujet d’actualité aujourd’hui, suite au récent rachat de GitHub par Microsoft, avec la configuration d’un pipe DevOps à partir d’un projet GitHub et en bonus la présentation des slots de déploiement Azure.

Nous allons donc brancher VSTS sur un projet de mon dépôt GitHub.

On commence par créer un nouveau projet :

1 1 - Azure Web App Deployment SlotsInitialisation du dépôt :

2 1 - Azure Web App Deployment Slots

Sélectionner Build and Release > Build > New pipeline et choisir GitHub 🙂

3 1 - Azure Web App Deployment Slots

Il s’agit toujours d’un projet ASP.NET Core :

4 1 - Azure Web App Deployment Slots

On pense à décocher “Publish Web Projects” qui ne concerne pas le type de projet WebAPI :

5 1 - Azure Web App Deployment Slots

Et on lance une build !

6 1 - Azure Web App Deployment Slots

Nous pouvons maintenant configurer notre Release. Build and Release > Release > New definition. Nous allons choisir un template un peu différent de ce que nous avons déjà testé jusqu’a présent !

7 1 - Azure Web App Deployment Slots

Je relie ma release à ma build :

8 1 - Azure Web App Deployment Slots

Je met en place le déploiement continu :

9 1 - Azure Web App Deployment Slots

Petite pause dans la configuration VSTS, nous devons également paramétrer notre Web App Azure !

Je choisis de créer une Web App et je remplis les informations habituelles :

10 1 - Azure Web App Deployment Slots

Une fois ma Web App créée je vais paramétrer un emplacement de déploiement. Ceux-ci sont bien utiles quand il s’agit d’avoir à disposition un environnement de test iso à la production. Ces emplacements de déploiements sont des “sous applications”  appartenant au même service plan que votre Web App.

11 1 - Azure Web App Deployment Slots

J’ajoute un environnement “preprod” identique à la production :

12 1 - Azure Web App Deployment Slots

J’ai désormais deux environnements à ma disposition, donc deux URL. La deuxième étant taggé avec le suffixe “preprod” qui correspond au nom de mon slot :

13 1 - Azure Web App Deployment Slots

Et ma Web App de production :

14 1 - Azure Web App Deployment Slots

Je peux vérifier que mes deux Web Apps sont fonctionnelles :

15 1 - Azure Web App Deployment SlotsPassons à la configuration de ma release !

Je remplis comme d’habitude Azure Subscription, le nom de ma Web App et du groupe de ressource associé mais je dois en plus choisir sur quel slot déployer mon application !

16 1 - Azure Web App Deployment Slots

Je choisis dans un premier temps de déployer sur preprod :

17 2 - Azure Web App Deployment Slots

Je pense à modifier le package à déployer :

19 1 - Azure Web App Deployment Slots

Et je vais désactiver la deuxième étape du déploiement. Cette étape effectue un échange entre ces deux environnements, mais ici je ne veux pas que ce swap soit fait automatiquement …

21 1 - Azure Web App Deployment Slots

Ma release est prête !

22 1 - Azure Web App Deployment SlotsJ’effectue une demande de déploiement :

23 1 - Azure Web App Deployment Slots

Release en cours !

24 1 - Azure Web App Deployment Slots

J’ai des informations détaillée sur le déploiement via l’onglet Logs :

25 1 - Azure Web App Deployment Slots

Une fois le déploiement terminé, j’obtiens sur mon environnement “preprod” :

26 1 - Azure Web App Deployment Slots

Mon application est donc opérationnelle sur cet environnement !

Sur l’URL “prod” en revanche :

15 1 - Azure Web App Deployment SlotsRien n’a changé ! C’est ce que nous voulons. Nous avons donc une version N-1 en production et une version N en preprod.

Je peux donc valider tranquillement le fonctionnement de mon API REST. En cas d’erreur, ma production n’est pas impactée et je peux apporter mes modifications. Une fois que tout est testé / vérifié / validé nous pouvons échanger nos environnements.

je retourne sur ma Web API :

27 1 - Azure Web App Deployment Slots

Et je clique sur le bouton Échanger à droite du bouton Arrêter. Je n’ai plus qu’un clic à faire pour swapper entre mes deux environnements !

28 1 - Azure Web App Deployment Slots

Ma preprod est maintenant devenu la prod et inversement. Mon environnement de preprod contient maintenant la version N-1 de mon application tendis que la prod est en version N.

30 1 - Azure Web App Deployment Slots

En cas d’anomalie détectée un peu tard, je n’ai qu’a reproduire l’opération pour que mes utilisateurs récupèrent immédiatement la version N-1 de l’API !

Dernier sujet aujourd’hui, la fonctionnalité “Test en production”. Reprenons notre déploiement de tout à l’heure avec :

  • En preprod : version N
  • En prod : version N-1

Je peux grâce à cette fonctionnalité orienter un certain volume du trafic utilisateur vers la version de preprod à la place de la production. Ainsi un certain pourcentage des utilisateurs vont pouvoir tester en condition réelle la nouvelle version de l’API. Une fois que le test me semble concluant, je peux procéder au swap !

29 1 - Azure Web App Deployment Slots

Récapitulons les avantages de ces emplacements de déploiements :

  • Pas d’intéruption de service pendant un déploiement. Tout est transparent pour l’utilisateur.
  • Possibilité de tester sur un emplacement dans les mêmes conditions que la production. Quand les tests sont validés, on opère le swap des environnements.
  • Possibilité de rediriger progressivement le flux des utilisateurs pour tester la nouvelle version et vérifier qu’elle répond correctement à l’augmentation du trafic réseaux.
  • Suite au swap, l’emplacement “preprod” contient la version qui était en production. Ainsi, en cas d’anomalie un rollback est facile à opérer.

Cette notion de deployment slot est une mise en oeuvre concrète des patterns “Blue/Green Deployment” et “Canary Release“. Je vous laisse suivre les liens pour une approche plus théorique du sujet 🙂

Azure App Service

Aujourd’hui, nous allons déployer notre Web API ASP .Net Core dans Azure. A la fin de ce tutoriel, vous aurez publié votre API dans une Web App Azure et configurer le monitoring avec Application Insights.

Je vais utiliser comme base le projet créé dans le dernier article, que vous pouvez récupérer ici : GitHub.

Dans un premier temps, nous devons paramétrer Application Insights dans notre solution :

1 - Azure App Service

2 - Azure App Service

Je précise que mon compte Azure est déjà créé et renseigné dans Visual Studio. Pour créer un tenant Azure : https://azure.microsoft.com.

A noter que si vous possédez un compte MSDN vous disposez gratuitement de crédit Azure renouvelé chaque mois.

Pour activer ce crédit : https://my.visualstudio.com

3 1 - Azure App Service

On renseigne le nom du groupe et de la ressource Insights à créer :

4 1 - Azure App Service

Un écran récapitulatif nous présente les ressources crées automatiquement dans Azure :

5 - Azure App Service

Ce paramétrage réalisé automatiquement consiste à ajouter à notre solution un fichier de configuration et à créer dans Azure une ressource Insights, chargée de logger et surveiller notre application.

Maintenant que notre application est paramétrée nous allons la déployer dans le Cloud et la rendre accessible de tous !

Sur notre projet, clic droit puis “Publier” :

6 - Azure App Service

On déploie dans une App Service, hébergée sur Windows ou Linux, à votre convenance !

7 - Azure App Service

La aussi, on renseigne le nom de notre application et le groupe de ressource auquel elle appartiendra. Un groupe de ressource est en quelque sorte un dossier virtuel qui contiendra nos éléments Azure. Un groupe de ressource est affecté à une localité d’hébergement.

8 1 - Azure App Service

On doit également choisir un plan d’hébergement. Celui-ci dépend des ressources matérielles que l’on veux avoir à notre disposition. Ce plan d’hébergement se traduira par une facturation différente suivant la puissance CPU / RAM choisie.

9 1 - Azure App Service

Il n’y a plus qu’à cliquer sur Créer :

10 1 - Azure App Service

Une fois le déploiement terminé, une page web s’ouvre sur l’URL de notre application.  Ajoutez “/swagger/” à la fin de cette URL pour retrouver une interface familière.

11 - Azure App Service

Une fois que votre Web API est déployé, Application Insights vous offre la possibilité de surveiller votre programme.

Depuis le portail Azure sélectionnez votre ressource Insights pour un accès à un ensemble de fonctionnalités :

    • Suivi d’indicateurs : latence, volumétrie des données, trafic réseaux, nombre d’erreurs …
    • Métriques en temps réel
    • Appels effectués sur votre API
    • Outils de création de graphe personnalisé
  • Langage de requête (LinQ) pour extraire les données qui vous semblent intéressante.

Énormément de possibilités pour un outils extrêmement puissant !

13.5 1 - Azure App Service

14 - Azure App Service

Pour en profiter pleinement, une mise à jour du package NuGet d’Insights s’impose !

13 - Azure App Service

Après avoir redéployé notre application :

19 - Azure App Service

Vous pourrez accéder à l’écran Flux de métriques en temps réel sur le portail Azure.

15 - Azure App Service

Pour découvrir l’étendue des possibilités de ce formidable outils : https://docs.microsoft.com/fr-fr/azure/application-insights/app-insights-visual-studio

En apparté, voici un petit outils pour tester vos API : Postman

Il vous permettra très facilement de tester vos API, et de pouvoir enreigstrer vos tests dans une collection pour pouvoir les reutiliser facilement !

16 - Azure App Service 17 - Azure App Service 18 1 - Azure App Service

Dans le prochain tuto, nous utiliserons Azure DevOps entre Visual Studio 2017 et notre WebApp Azure pour automatiser les builds et les déploiements !

Web API ASP.NET Core

Après la partie théorique, place à la pratique !

Dans cet article, nous allons détailler comment créer une Web API en utilisant un template de projet ASP .NET Core et le framework .NET Core.

A la fin du tutoriel vous aurez développé une API REST en .NET Core présenté par Swagger. J’utilise Visual Studio 2017 pour mes développements (v15.6.6  actuellement).

Démarrer Visual Studio 2017 et sans plus attendre :

1 - Web API ASP.NET Core

Puis :

2 - Web API ASP.NET Core

On voit ensuite que l’on va utiliser le framework .Net Core 2.0, dernière version stable actuellement, et créer un projet de type API.

3 - Web API ASP.NET Core

Visual Studio nous prépare notre solution que je nomme WebAppExemple :

4 - Web API ASP.NET Core

Sélectionnez maintenant “WebAppExemple” à la place de IIS Express comme ci-dessous. Ainsi votre exécution ne dépendra plus de IIS et votre projet sera auto-hebergé grâce au composant Kestrel de .Net Core :

5 1 - Web API ASP.NET Core

6 - Web API ASP.NET Core

Votre WEB API est désormais accessible en local sur le port 8299 !

Notre ControllerValues n’étant pas des plus utiles, je vais maintenant créer une classe d’entité métier et son API !

Première étape, création d’un projet WebAppExemple.Model dans notre solution :

7 - Web API ASP.NET Core

On y ajoute une classe Client. Client représente une entité métier dans notre modèle de donnée.

8 - Web API ASP.NET Core

Pour gérer notre modèle justement, je vais utiliser Entity Framework Core. Ce framework est un ORM (Object Relational Mapping) et permet comme son nom l’indique de faire le lien entre des classes C# (logique objet) et une base de données relationnelles (SGBDR comme SQLServer).

Dans l’explorateur de solution, clic droit sur notre projet Model et sélectionnez “Gérer les packages Nuget…”, vous obtiendrez cet écran :

9 - Web API ASP.NET Core

Recherchez EntityFrameworkCore et installez le ! Nous pouvons maintenant créer une nouvelle classe de type DbContext pour gérer notre modèle de donnée. Notre entité ContexteExemple contiendra une collection d’entités Clients :

10 - Web API ASP.NET Core

Avant de pouvoir aller plus loin, je dois ajouter une dépendance entre mes deux projets. Via le gestionnaire de références, j’ajoute une dépendance dans WebAppExemple :

10.5 - Web API ASP.NET Core

Pour pouvoir utiliser notre ContexteExemple, il faut déclarer cette classe en tant que Service. Cela se passe dans la classe Startup, méthode ConfigureServices. Cette méthode permet de gérer l’injection de dépendance de notre projet.

Très brièvement l’injection de dépendance (IoC) permet de gérer un catalogue des types abstrait (interfaces) lié à leurs implémentation. Le conteneur d’IoC permettra d’obtenir pour chaque type abstrait, l’implémentation correspondante.

Pour une présentation plus complète du sujet, je vous invite à lire cet article très complet : developpez.com

Pour qu’à l’exécution, la classe ContexteExemple puisse être utilisée, je dois la déclarer via la méthode AddDbContext comme ci-dessous :

10.6 - Web API ASP.NET Core

Je déclare ici que notre base de données sera uniquement “In Memory”. Il n’y aura donc pas de BDD physique comme SQLServer ou SQLite.

A présent que notre entité Client est créée et gérée au sein d’un contexte de donnée, nous avons besoin d’une API pour exposer les opérations CRUD à réaliser sur cette entité : Create / Read / Update / Delete.

Pour se faire, clic droit sur notre dossier Controllers, Ajouter, Contrôleur puis :11 - Web API ASP.NET Core

On déclare que notre Contrôleur permet de gérer notre entité Client au sein de notre ContexteExemple :

12 - Web API ASP.NET Core

On obtient alors une classe ClientsController prête à l’emploi contenant toutes les méthodes de base. Ces méthodes que je vous laisse découvrir manipule des objets Clients en lecture / écriture / modification et suppression, dans un contexte EntityFramework géré en mémoire.

Bien sur vous pouvez enrichir votre API en rajoutant les fonctionnalités de votre choix sur notre entité Client !

A noter le constructeur de notre classe ClientsController :

18 300x123 - Web API ASP.NET Core

Grace à l’injection de dépendance un ContexteExemple sera instancié automatiquement à l’appel de ClientsController.

A l’exécution de notre projet, on notera qu’une nouvelle URL est accessible : http://localhost:8299/api/clients ! Cependant en l’état son utilisation est peu évidente ! Pour répondre à ce problème, une solution : Swagger !

Premièrement ajoutons à notre projet WebAppExemple les dépendances nécessaires :

13 - Web API ASP.NET Core

En ce moment votre projet devrait ressembler à ceci :

14 - Web API ASP.NET Core

Je dois maintenant configurer l’utilisation de Swagger dans nos méthodes Configure et ConfigureServices :

15 - Web API ASP.NET Core

La méthode Configure demande de générer la documentation Swagger en JSON et d’utiliser SwaggerUI pour la présenter. Dans ConfigureServices je dois enregistrer mon service Swagger en lui précisant la version de notre API, ainsi que le titre.

Je vous invite maintenant à lancer votre application et accéder à l’url http://localhost:8299/swagger/   et ….

16 - Web API ASP.NET Core 17 - Web API ASP.NET Core

Cet outils nous permet plusieurs choses :

  • Pouvoir visualiser facilement les opérations accessibles de notre API.
  • Partager facilement une documentation entre les développeurs.
  • Pouvoir tester facilement nos méthodes via l’interface générée.

Je vous laisse tester nos différentes méthodes et vous verrez que l’on peut gérer la création (POST), la modification (PUT), la suppression (DELETE) et la lecture (GET) de nos clients !

Le code source de ce tutoriel est disponible sur GitHub.