Étiquette : WebAPI

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 :

Initialisation du dépôt :

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

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

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

Et on lance une build !

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 !

Je relie ma release à ma build :

Je met en place le déploiement continu :

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 :

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.

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

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 :

Et ma Web App de production :

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

Passons à 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 !

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

Je pense à modifier le package à déployer :

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 …

Ma release est prête !

J’effectue une demande de déploiement :

Release en cours !

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

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

Mon application est donc opérationnelle sur cet environnement !

Sur l’URL “prod” en revanche :

Rien 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 :

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 !

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.

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 !

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 🙂

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 :

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

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

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

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” :

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

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.

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.

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

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.

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 !

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

Après avoir redéployé notre application :

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

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 !

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

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 :

Puis :

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.

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

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 :

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 :

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

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 :

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 :

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 :

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 :

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 :

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

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 :

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 :

En ce moment votre projet devrait ressembler à ceci :

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

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 ….

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.