Gérer les problèmes dans Service Fabric

Hello !

Suite à ce précédent article je vais aujourd’hui évoquer la gestion des erreurs et la tolérance aux pannes.

Cet article est une “réponse” aux questions soulevées ici !

Gestion des logs et monitoring

Le monitoring et la gestion des logs sont intégrés a Azure Service Fabric grâce à deux composants Azure :

  • Windows Application Diagnostics
  • Application Insights

Ces deux modules doivent être activés à la création du cluster Azure Service Fabric et configuré dans la solution Visual Studio.

1 2 - Gérer les problèmes dans Service Fabric

WAD permet de :

  • Détecter et diagnostiquer les problèmes d’infrastructure
  • Détecter les problèmes liés à votre application
  • Comprendre la consommation des ressources
  • Faire le suivi du niveau de performance des applications, des services et de l’infrastructure

Pour cela WAD collecte des « journaux » :

  • Evènements de la plateforme ASF
  • Intégrité et charge des clusters
  • Monitoring et utilisation du Reverse proxy
  • Compteur de performance
  • Evènement des applications

Application Insights quant à lui permet de :

AI nous offre également un langage de requête, inspiré de LinQ (Analytics pour Application Insights) pour extraire les données qui nous intéresse et les présenter sous forme de graphiques par exemple.

2 2 - Gérer les problèmes dans Service Fabric

3 2 - Gérer les problèmes dans Service Fabric

4 2 - Gérer les problèmes dans Service Fabric

5 2 - Gérer les problèmes dans Service Fabric

Insight analyse :

  • Les exceptions dans un services :6 2 - Gérer les problèmes dans Service Fabric
  • Consultations de pages et performances de chargement.
  • Nombre de sessions et d’utilisateurs.
  • Les appels services, temps de réponse et taux d’échec.
  • Compteurs de performances des serveurs Windows ou Linux, par exemple le processeur, la mémoire et l’utilisation du réseau.
  • Diagnostics d’hébergement Azure.
  • Journaux de suivi des diagnostics des applications : pour pouvoir mettre en corrélation les événements de suivi avec les demandes.
  • Mesures et événements personnalisés (à implémenter dans le code source)
  • Permet d’envoyer des alertes en cas de télémétrie anormale :7 2 - Gérer les problèmes dans Service Fabric

Insight est un outil complet et très puissant que nous aurions tort de ne pas utiliser avec Service Fabric de même qu’avec une Web App d’ailleurs 🙂

Gestion des pannes et résilience

Dans cet article nous avions identifié ces besoins :

  • Détecter quand un service est off pour que le client ne tente pas de le joindre inutilement.
  • Auto guérison des services : le cloud favorise la gestion de ce besoin par la mise en œuvre de :
  • Scalabilité horizontale : duplication automatique des composants logiciels.
  • Scalabilité verticale : augmentation de la puissance de la plateforme hôte (CPU / RAM / espace disque).

Azure Service Fabric répond à ce besoin car la plateforme tente d’apporter la plus grande fiabilité possible à notre application en nous proposant nativement :

  • Scalabilité automatique suivant des règles de charge
  • Load balancer pour répartir la charge
  • Redémarrage des services automatique
  • Outils de monitoring et de diagnostics pour analyser les problèmes

Mais nous détaillerons ces points précisément lors de la mise en oeuvre concrète de cette solution PAAS !

Azure DevOps Project

Hello !

Après avoir vu dans un précédent article comment mettre en œuvre un process d’intégration et déploiement continu via VSTS nous allons voir comment Azure nous permet de déployer tout ça automatiquement avec Azure DevOps Project.

Dans cet article nous allons, depuis Azure et sans la moindre ligne de code, générer :

  • Un projet ASP .Net Core MVC
  • Un pipe CI / CD (intégration et déploiement continue) dans VSTS
  • Une Web Application Azure
  • Bonus : notre site web s’exécutera dans un conteneur Docker

Nous pouvons commencer ! Direction le portail Azure puis “Créer une ressource” et choisir “DevOps Project” :

1 2 - Azure DevOps Project

Je choisis le framework .Net Core :

2 2 - Azure DevOps Project

J’indique que je veux déployer mon application dans une Web App avec support de conteneurs. On peut également choisir une Web App classique Windows ou Linux :

3 3 - Azure DevOps Project

Dernière étape je sélectionne mon compte Team Services et un nom de projet ainsi qu’un tenant Azure et le nom de ma Web App :

4 4 - Azure DevOps Project

Création en cours …

5 2 - Azure DevOps Project

Déploiement réussi !

6 1 - Azure DevOps Project

Nous retrouvons bien notre groupe de ressources (dont le nom à été défini par Azure) contenant notre Web App DevOpsExemple :

7 1 - Azure DevOps Project

Détails :

8 1 - Azure DevOps Project

Si je clique sur l’URL renseignée … Success !!

16 2 - Azure DevOps Project

Voyons maintenant ce qui a été créé côté VSTS :

9 1 - Azure DevOps Project

Dans Code > Files je retrouve un projet de base ASP .Net Core MVC :

10 1 - Azure DevOps Project

Dans la section Commit je retrouve la création du projet par Azure :

11 1 - Azure DevOps Project

Dans l’onglet Build je retrouve une définition de build (étonnant !) :

12 1 - Azure DevOps Project

13 2 - Azure DevOps Project

Cette build contient deux étapes de commandes Docker pour construire puis déployer dans Azure mon image Docker. Pour se faire c’est le fichier Dockerfile présent dans le dépôt qui est utilisé.

14 1 - Azure DevOps Project

Dans la section Release je trouve : 15.5 - Azure DevOps Project

Et un pipe d’exécution depuis ma build :

15 1 - Azure DevOps Project

Bref on retrouve ici tout ce qu’on a vu et créé manuellement dans le dernier tutoriel 🙂

Récupérons le code ! On ouvre un nouveau Visual Studio > Team Explorer > Gérer les connexions > Connexion à un projet :

17 2 - Azure DevOps Project

On choisit son dossier :

18 1 - Azure DevOps Project

Et on obtient notre code source avec notre fameux Dockerfile !

19 2 - Azure DevOps Project

Ce fichier contient les instructions pour générer et déployer notre projet dans un conteneur Docker :20 1 - Azure DevOps Project

Dans ce Dockerfile les instructions vont :

  • Indiquer que je vais utiliser l’image aspnetcore-build:1.1 fourni par Microsoft pour compiler mon application dans le dossier de base “app”.
  • Je vais exécuter les commandes Restore puis Publish pour compiler mon projet et enregistrer les dll dans app/out.
  • Enfin je construis mon image Docker depuis l’image de base aspnetcore:1.1 dans laquelle je pousse mes dll.

Je fais un petit correctif sur la page d’accueil de notre site afin de vérifier notre pipe de déploiement vers Azure !

21 1 - Azure DevOps Project

On commit en local :

22 1 - Azure DevOps Project

On synchronise avec le serveur :

23 1 - Azure DevOps Project

Une nouvelle build se déclenche :

24 1 - Azure DevOps Project

En cours …

25 1 - Azure DevOps Project

Suite à cette build c’est au tour de la Release de s’exécuter :26 1 - Azure DevOps ProjectEn cours …

27 1 - Azure DevOps Project

Et notre site web est à jour !

28 1 - Azure DevOps Project

Et c’est déjà terminé !

Vous pouvez donc, en quelques clics, générer automatiquement depuis Azure un pipe d’intégration et de déploiement continu avec VSTS pour un projet .Net ou .Net Core, avec ou sans Docker 🙂

Microsoft Visual Studio Team Services

Hello !

Maintenant que nous avons développé notre Web API et que nous l’avons déployée sur Azure dans une Web App, nous allons configurer l’intégration et le déploiement continu de notre projet dans VSTS.

ArticleVsts Alm - Microsoft Visual Studio Team Services

VSTS et DevOps

J’ai effectué une présentation de cet outil dans le précédent article, n’hésitez pas à le consulter pour une vision plus globale.

Nous allons ici plutôt nous concentrer sur la mise en œuvre !

Configuration de notre projet dans VSTS

Tout d’abord nous devons créer notre projet dans VSTS. Après vous être identifié sur teamservices vous pourrez créer un nouveau compte pour héberger vos projets.

4 3 1 - Microsoft Visual Studio Team Services

Création de votre compte :5 1 - Microsoft Visual Studio Team ServicesJe choisis Git comme gestionnaire de code source.

6 - Microsoft Visual Studio Team Services

J’ai désormais accès à l’interface VSTS pour gérer mes projets depuis l’URL : thomasrannou.visualstudio.com. Par défaut un projet existe déjà.

8 - Microsoft Visual Studio Team ServicesCréons un nouveau projet pour héberger notre application !

9 - Microsoft Visual Studio Team Services

Je choisis d’initialiser mon répertoire avec un README.

10 - Microsoft Visual Studio Team Services

C’est terminé, mon répertoire est disponible et n’à plus qu’a accueillir mon code source.

11 - Microsoft Visual Studio Team Services

Maintenant je dois connecter mon projet VSTS à mon Visual Studio 🙂

Ouvrir un nouveau Visual Studio. Puis Team Explorer > Gérer les connexions (l’icône verte en forme de prise) > connexion à un projet.

Sélectionnez votre compte puis votre projet créé précédemment.

13 1 - Microsoft Visual Studio Team Services

Visual Studio vous propose alors un répertoire sur disque ou stocker votre projet.

14 - Microsoft Visual Studio Team Services

Modifiez-le si besoin et “Cloner”. Puis vous devrez copier dans ce répertoire C:\W\WebAppExempleAzure votre solution .Net :

  • WebAppExemple
  • WebAppExemple.Model
  • WebAppExemple.sln

Vous pourrez alors ouvrir normalement votre solution et y apporter des modifications. Il n’y a plus qu’à archiver tout ça !

En local :

57 - Microsoft Visual Studio Team Services

Il faut d’abord “Indexer” les nouveaux fichiers.

58 - Microsoft Visual Studio Team Services

Puis “Valider les changements intermédiaires” :

59 - Microsoft Visual Studio Team Services

On synchronise sur le serveur …

16 1 - Microsoft Visual Studio Team Services

La synchronisation permet de “Push” (pousser) sur le serveur nos modifications et de “Pull” (tirer) en local les modifications versionnées par d’autres développeurs dans le cadre de projet d’équipes. Ici forcément, je n’ai pas grand chose à récupérer 🙂

17 - Microsoft Visual Studio Team Services

Une fois qu’on a cliqué sur Synchroniser un message nous confirme que notre répo local est en phase avec le serveur.

18 - Microsoft Visual Studio Team Services

Pensez bien à exclure les dossiers bin et obj de vos modifications à archiver : clic droit puis “Ignorer ces éléments locaux”. Ces dossiers n’ont pas besoin d’être versionnés et ne feront qu’alourdir votre dépôt.

Si vous connaissez Git rien ne vous surprend la dedans. Si ce gestionnaire de source ne vous est pas familier vous serez étonné par le double push, d’abord en local, puis sur le serveur, mais c’est tout à fait normal. Avec Git les modifications sont d’abord validées localement avant d’être envoyées sur le serveur. Pour savoir l’essentiel de git c’est par ici.

Je peux maintenant visualiser mon code versionné depuis l’onglet “Code” > Files de VSTS. Dans la section “Commits” je pourrais voir tous les Push effectué sur ce dépôt.

19 - Microsoft Visual Studio Team Services

Maintenant que nous avons notre code source dans notre répertoire , il nous reste à configurer une build et une release vers Azure 🙂

Sélectionner Build and Release > Build > New pipeline

20 - Microsoft Visual Studio Team Services

On indique notre projet courant et la branche de travail. Ici il s’agit du master puisque nous n’avons pas créé d’autre branche. Pour un vrai projet on ne développera pas sur le master mais sur des branches de développement issues de celle-ci. Voir GitFlow !

21 - Microsoft Visual Studio Team Services

Je vais utiliser le template de projet .Net Core.

22 - Microsoft Visual Studio Team Services

Ce template de build est très simple et permet de compiler une solution .Net Core et de générer un fichier zip contenant les dll du projet.

Je renomme également ma build au passage :

23 - Microsoft Visual Studio Team Services

Pensez à décocher “Publish Web Projects” qui ne convient qu’au projet ASP .NET Core MVC.

24 - Microsoft Visual Studio Team Services

Cliquez alors sur “Save And Queue” pour enregistrer notre définition et lancer une build. Je peux alors préciser l’ID du commit que je veux lier a cette build  (que j’ai récupérée en parallèle).

26 - Microsoft Visual Studio Team Services

Build en cours…

27 - Microsoft Visual Studio Team Services 28 - Microsoft Visual Studio Team Services

Lorsque la build est terminée, en cas de succès et d’échec vous recevrez un mail de notification :

29 - Microsoft Visual Studio Team Services

Nous pouvons maintenant configurer notre Release. Build and Release > Release > New definition

30 - Microsoft Visual Studio Team Services

Je choisis un template de déploiement Azure Application.

Ici le template choisis est le plus simple possible mais il est possible de sélectionner des templates plus évolué permettant de :

  • Paramétrer automatiquement Insights.
  • Basculer des slots de déploiement : utile pour la mise en oeuvre du blue/green deployment.
  • Effectuer des tests de charge.
  • Executer des scripts powershell avant de pousser les dll.
  • etc …

Bien sur la release se base sur un template mais peut être enrichis par la suite sans problème pour répondre à de nouveaux besoins.

48 - Microsoft Visual Studio Team Services

Je donne un nom à mon environnement de travail :

49 - Microsoft Visual Studio Team Services

On sélectionne le build que l’on veut lier à cette release via “Add artifact” :

32 - Microsoft Visual Studio Team Services

Je peux ensuite cliquer sur “1 phase, 1 task” pour configurer ma release.

Je renseigne mon ID Azure et la Web App d’hébergement de mon application :

50 1 - Microsoft Visual Studio Team Services

Je modifie les propriétés de mon déploiement :

56 1 - Microsoft Visual Studio Team Services

Sélectionner le zip WebAppExemple dans la séction “Package or folder” :

53 - Microsoft Visual Studio Team Services

Je vais indiquer maintenant dans la section “Continuous deployment trigger” que chaque build provoque une release et donc un déploiement.

54 - Microsoft Visual Studio Team Services

On note que l’on peut préciser des conditions aux déploiements en cliquant sur la zone colorée ci-dessous :

55 - Microsoft Visual Studio Team Services

On peux alors configurer des déploiements qui dépendront par exemple :

  • D’une heure ou d’un jour
  • D’une approbation préalable d’un utilisateur

Voyons maintenant ce qu’il se passe si je modifie mon code ! Je vais ajouter une propriété Ville à mon Client et j’archive.

38 1 - Microsoft Visual Studio Team Services

Je synchronise sur le serveur à nouveau …

39 - Microsoft Visual Studio Team Services 40 - Microsoft Visual Studio Team Services

Une build se lance automatiquement !

42 - Microsoft Visual Studio Team Services

En cours …

43 - Microsoft Visual Studio Team Services

Et suite à la build, une release se déclenche également !

44 - Microsoft Visual Studio Team Services

En cours …

Capture - Microsoft Visual Studio Team Services

Une fois ces deux étapes terminées, si je retourne sur le contrat swagger de ma WebApp je retrouve bien ma nouvelle propriété Ville 🙂

47 - Microsoft Visual Studio Team Services

Et c’est finis pour aujourd’hui ! Nous avons en fin de compte une API .Net Core déployée dans une WebApp Azure, monitoré via Application Insights avec un pipe DevOps géré sur VSTS ! Pas mal pour gérer sans encombre son projet perso 😉

Microservices et Application Lifecycle Management

Le but d’un microservice étant d’être isolé, facilement testable et déployable, un critère important de cette mise en œuvre est l’utilisation d’un outil de build et de déploiement continu (continuous intégration / continuous déploiement).

Des solutions existent sur le marché comme TeamCity ou Jenkins. Ici nous parlerons bien sur de Microsoft Visual Studio Team Services 🙂

VSTS  permet :

  • D’avoir une forge logicielle avec un outils de gestion de version.
  • De configurer des processus de build avec exécution de tests automatisés
  • De configurer des processus de releases : déploiement sur des serveurs ou dans le Cloud.

1 - Microservices et Application Lifecycle Management

Au-delà de l’aspect CI/CD VSTS permet également de gérer un projet en méthode agile avec la gestion des itérations de développement (sprints), les work items, backlog etc …

Une maturité DevOps est obligatoire pour la mise en œuvre de notre architecture. En effet, nos services seront nombreux et doivent pouvoir être déployé rapidement suite à une évolution. Sans une plateforme DevOps d’industrialisation logicielle pour nous aider, la tâche s’annonce plus que compliqué.

2 - Microservices et Application Lifecycle Management

Intégration

La partie intégration est assurée par :

  • Un outil de gestion de version : Git qui n’est plus à présenter ou TFVC, l’outils de gestion de version Microsoft, en fin de vie. La firme ne conseille plus son utilisation. A noter que VSTS peut également récupérer les sources d’un dépôt disant comme GitHub.
  • Un outil de Builds, intégré à VSTS.

3 1 - Microservices et Application Lifecycle Management

Les builds sont configurables, s’exécutent sur une branche du repository git et permettent de réaliser un certains nombre d’actions :

  • Télécharger les dépendances Nuget du projet.
  • Compiler la solution.
  • Exécuter les tests automatisés.
  • Exécuter des commandes Windows.
  • Pousser l’artifact généré .
  • Envoyer un rapport de build par mail.
  • Lancer un tests Sonar.
  • …..

De la façon la plus concise possible, sur un projet de type .Net core la build se déroulera en 4 commandes :

  • dotnet restore
  • dotnet build
  • dotnet tests
  • dotnet publish

Tests

Pour nos services, différent type de tests sont à mettre en œuvre pour garantir la stabilité du code source et éviter les régressions :

Tests unitaires

Chaque test valide le bon fonctionnement d’une méthode bien précise de notre service, l’utilisation d’un framework de mock (moq, rhinoMock) est indispensable pour garantir le caractère « unitaire » de nos tests. Un framework de mock permet de simuler le fonctionnement d’une méthode.

Par exemple, nous testons la méthode B. Dans l’implémentation de B il y a un appel a la méthode A qui retourne un booléen. Alors pour notre test de B on précisera en amont que notre méthode A renverra systématiquement true si elle est appelée. Pendant notre test si A() est appelé, on est assuré d’avoir le résultat true, et on peut tester notre méthode B indépendamment de A.

Microsoft propose son propre framework de mocking : Microsoft.Fakes.

A noter que la mise en œuvre d’une stratégie Test Driven Development (TDD) peut aider à garder une couverture de tests satisfaisante.

Tests d’intégration

Chaque test valide le bon fonctionnement d’une méthode de notre service, de l’appel jusque la base de données. Le test balaie donc la totalité de notre méthode. Par exemple avec l’appel GET http://www.urltest.com/clients/2,  on pourra valider qu’en sortie on obtient un client provenant de la base de données dont l’identifiant est 2.

Tests de qualité

Il est possible d’intégrer un outils comme Sonar pour la qualimétrie logicielle et l’analyse du code :

  • Respect des normes de développement
  • Complexité cyclomatique
  • Présence des commentaires
  • Duplication de code
  • Évaluation de la couverture de code

4 1 - Microservices et Application Lifecycle Management

Tests statiques

On peut utiliser le module de code review de VSTS pour la relecture de code entre développeurs.

Les tests statiques sont effectués par les développeurs avant de pousser leurs modifications sur la forge. Les tests unitaires, d’intégration et de qualité quand à eux pourront être exécuté de manière automatisée par notre outils DevOps pendant une build. En cas d’erreur sur un des tests, l’archivage sera rejeté pour être corriger par le développeur.

Déploiements

La partie Déploiements de notre solution est géré par les « Releases » de VSTS. Les releases permettent à partir d’une build de déployer nos dll dans un environnement cible, serveurs interne ou environnement cloud.

L’hébergement de notre architecture microservices peut se faire dans un environnement Cloud afin de répondre facilement aux besoins de disponibilités et de scalabilité des applications. Ici nous nous intéresserons évidemment à Azure et aux différentes solutions offertes par cette plateforme pour répondre à notre besoin.

Les releases permettent en plus du déploiement d’effectuer des opérations comme :

  • Jouer des scripts SQL
  • Déplacer des fichiers (xml, json)
  • Exécuter des commandes PowerShell, FTP

A noter que des outils externes à Microsoft s’interface très bien avec VSTS, au niveau des builds comme des releases pour exécuter diverses taches. Je pense notamment à Octopus, Sonar, Docker, WebPack … Un système de plugin est même mis en œuvre pour pouvoir ajouter des fonctionnalités à VSTS.

Microsoft VSTS est donc un outils très complet pour la gestion du cycle de vie de nos applications. Il conviendra parfaitement dans le cadre d’un projet microservices déployé dans Azure.