Application Service Fabric dans Visual Studio 2017

Hello !

Suite à la création de notre cluster Service Fabric dans Azure, nous allons aujourd’hui détailler la création de notre projet dans Visual Studio 2017.

Création du projet

Tout d’abord il faut configurer le poste du développeur pour utiliser les templates de projets  ASF. Pour télécharger et installer le SDK rendez vous ici : https://docs.microsoft.com/fr-fr/azure/service-fabric/service-fabric-get-started

Nous pouvons maintenant créer notre projet Cloud de type Application Service Fabric :

1 - Application Service Fabric dans Visual Studio 2017

Nous devons ajouter un premier service à notre projet :

2 - Application Service Fabric dans Visual Studio 2017

Pour bien comprendre les différents type de service (au delà du framework .Net utilisé) que nous pourrons héberger dans notre cluster, je vous invite à consulter ce lien.

Pour faire simple nous pouvons retenir :

  • Service sans état : service “classique” ou les données sont stockés dans une source de connées externe (base de données, fichier xml).
  • Service avec état : le service conserve des données qui sont répliquées entre chaque instance du service grâce aux types Reliable. Ainsi si un client tente d’accéder à une donnée du service, peu importe l’instance qui est appelée, la donnée sera la même.

Je choisis le type de projet ASP .Net Core que je veux implémenter comme pour un projet .Net Core classique :

3 - Application Service Fabric dans Visual Studio 2017

Si par la suite je veux ajouter un nouveau projet à mon application il faudra faire clic droit sur notre projet principal et Ajouter > Nouveau Service Service Fabric pour que ce nouveau projet sois lié à notre environnement ASF.

4 - Application Service Fabric dans Visual Studio 2017

On voit ici que la différence majeure entre un service ASP .Net Core standart et un service ASP .Net Core dans Service Fabric c’est le projet par défaut créé par Visual Studio (ici Orange.Techs.Microservices).

Celui-ci contient des fichiers de configurations pour le build et déploiement de nos services dans un cluster Service Fabric. En revanche nos services en eux mêmes (ici Orange.Techs.Microservices.StatelessAPI) sont identiques aux services de type WebApi que nous connaissons déja !

Par conséquent vous retrouvez facilement vos habitudes de développement au niveau des services ! Un point plus que positif à prendre en compte pour l’adoption de cet environnement 🙂

Création d’un cluster Azure Service Fabric (Portal mode)

Hello !

Après la description de notre projet et de nos services nous allons maintenant détailler la création de notre cluster Service Fabric. Pour ce premier cluster je vais utiliser le portail Azure ! Ce ne sera plus le cas par la suite ou nous privilégierons les templates ARM.

Création

1ere étape : paramètres de bases :

1 3 - Création d'un cluster Azure Service Fabric (Portal mode)

2eme étape : configuration du cluster. On dois ici :

  • Choisir le nombre de nœud de notre cluster
  • Pour chaque nœud on configure la machine hôte et les paramètres réseaux. Attention à la configuration des ports qui seront accessibles (80,81,82 ici) et à bien activer le reverse proxy !

2 1 - Création d'un cluster Azure Service Fabric (Portal mode)

3ème étape : Gestion de la sécurité.

3 1 - Création d'un cluster Azure Service Fabric (Portal mode)

Il faut créer un coffre de sécurité qui contiendra le certificat d’accès à notre cluster, modifier les stratégies d’accès puis valider.

4 1 - Création d'un cluster Azure Service Fabric (Portal mode)

5 1 - Création d'un cluster Azure Service Fabric (Portal mode)

Téléchargez le certificat créé, il nous servira ultérieurement.

6 1 - Création d'un cluster Azure Service Fabric (Portal mode)

Téléchargez le template généré avant de valider : ce template pourra être utilisé pour recréer notre cluster :

7 1 - Création d'un cluster Azure Service Fabric (Portal mode)

Et il n’y a plus qu’a valider le déploiement de notre plateforme :

8 1 - Création d'un cluster Azure Service Fabric (Portal mode)

L’installation est en cours :

9 - Création d'un cluster Azure Service Fabric (Portal mode)

Une fois toute les étapes validées, Azure créé notre cluster Service Fabric. L’opération dure un certains temps, 10 minutes environ.

Il faut maintenant installer le certificat précédemment téléchargé pour pouvoir accéder à l’interface d’administration Service Fabric. Il faut installer le certificat dans le magasin de certificat Windows et dans le navigateur utilisé.

Voici l’interface de notre solution : Service Fabric Explorer. Cet outil permet de visualiser rapidement l’état de santé de notre cluster et des instances des applications.

L’url de cet outil est : https://nom-du-cluster.localisation-du-cluster.cloudapp.azure.com:19080/Explorer

14 - Création d'un cluster Azure Service Fabric (Portal mode)

Application Insights

Il nous reste à déployer Application Insights pour notre cluster !

Pour se faire, positionnez vous sur votre ressource Service Fabric > Application Insights et cliquez sur Créer Application Insights :

10 - Création d'un cluster Azure Service Fabric (Portal mode)

11 - Création d'un cluster Azure Service Fabric (Portal mode)

Le déploiement est en cours :

12 - Création d'un cluster Azure Service Fabric (Portal mode)

Nous avons maintenant accès au dashboard de configuration et de monitoring d’Insights pour notre cluster Service Fabric et nos services :

13 - Création d'un cluster Azure Service Fabric (Portal mode)

Configuration

Attention à l’ouverture des ports sur le cluster et sur chaque nœud pour l’accessibilité externe à Service Fabric. Pour accéder au service, il faudra ajouter des règles de routage dans l’équilibreur de charge.

15 - Création d'un cluster Azure Service Fabric (Portal mode)

L’écran « Montée en charge » permet quant à lui de renseigner des règles pour adapter le nombre d’instances de nos services disponibles suivant la charge :

16 - Création d'un cluster Azure Service Fabric (Portal mode)

Par exemple, nous pouvons définir des règles par rapport :

  • Au trafic réseau
  • Un seuil d’utilisation CPU ou mémoire
  • Au nombre d’appels à nos API …

Notre cluster Service Fabric est maintenant opérationnel dans Azure et grâce à l’Explorer nous pouvons valider son bon fonctionnement même si pour le moment aucune application n’est déployée dessus 🙂

Ce sera l’objet du prochain article !

Azure Service Fabric : notre projet

Nous allons maintenant détailler la mise en œuvre concrète de la solution Azure Service Fabric introduit précédemment.

Notre système d’information de démonstration contient une application cœur de métier, utilisée par tous les employés du SI.

Cet applicatif « monolithique » adresse ainsi tous les métiers de l’entreprise :

  • Gestion client
  • Comptabilité
  • Commerce
  • RH
  • Fournisseur / Achat

Chaque employé à accès aux divers écrans en fonction de ces droits attribués par rapport à son rôle dans l’entreprise.

Un nouveau besoin pour un usage en mobilité conduit notre SI à une étude autour de son existant et une évaluation des possibilités d’amélioration.

Problématiques de l’existant

Les problématiques autour de cette application cœur de métier sont nombreuses :

Au niveau du projet et du code .Net, une base de code volumineuse apporte plusieurs problématiques :

  • Projet Visual Studio conséquent
  • Longueur des builds sur les postes de développement.
  • Difficulté à démarrer sur le projet pour un nouveau développeur
  • Couplage entre les modules de l’application : code spaghettis

Au niveau de l’application :

  • Problèmes de performances.
  • En cas de modification, il faut retester l’application dans son ensemble car les modules sont fortement couplé.
  • Cycle en V plutôt que méthode agile lié au coup de déploiement.
  • La mise à l’échelle implique de cloner toute l’application sur un nouveau serveur.

Pour détailler les problèmes de cet existant, nous pouvons utiliser l’approche FURPSE :

7 - Azure Service Fabric : notre projet

  • Utilisabilité : L’application est pollué par des lenteurs excessive.
  • Fiabilité : En cas de défaillance d’un composant, l’application crashe totalement. L’utilisateur doit alors relancer toute l’application.
  • Performance : Lenteur de l’application, au démarrage et lors de la navigation du aux trop nombreuses dépendances. Consommation de ressources CPU/RAM importante.
  • Maintenabilité : En cas d’erreur, difficulté d’analyse.
  • Evolutivité : Les évolutions sont couteuses à mettre en place car elles impliquent beaucoup d’analyse d’impact et de tests de la part des développeurs.
Conceptions

Le but de ce chapitre est de présenter comment bâtir une architecture microservices à partir de notre existant. Ce que nous voulons obtenir c’est une application de présentation, la plus légère possible et qui ne contient aucune logique fonctionnelle et une couche de service déployé dans Azure Service Fabric.

Celui-ci contient des services regroupés par domaine fonctionnels :

  • Clients
  • Comptabilités
  • Documents

A noter que certains services n’ayant pas besoin d’être forcément scalable (car peu utilisé) peuvent être déployé dans des WebApp plus classique par soucis de simplicité.

Une fois la logique fonctionnelle extraite de notre application, il sera bien plus facile :

  • De faire évoluer nos services.
  • D’ajouter une nouvelle application cliente.
  • De tester et déployer nos services.
  • De les rendre résilient aux pannes et adaptable à la charge.

Nous allons présenter différentes possibilités pour mettre en œuvre notre architectures microservices en gardant à l’esprit nos besoins. Nous souhaitons :

  • Des services au contexte délimité.
  • Un couplage faible entre composants.
  • Testables facilement et automatiquement.
  • Déployable automatiquement.

Proposition 1 : Un monolithe organisé :6 - Azure Service Fabric : notre projet

Ce découpage ne convient pas à nos besoins pour des raisons évidente.

Proposition 2 : Un monolithe et des services :5 - Azure Service Fabric : notre projet

Proposition 3 : Un monolithe distribué. Les services sont dupliqués manuellement pour répondre à la charge :4 - Azure Service Fabric : notre projet

Le risque de cette dernière proposition est de vite se retrouver à gérer :3 - Azure Service Fabric : notre projet

Proposition 5 : Une architecture microservice avec Azure Service Fabric :

2 - Azure Service Fabric : notre projet

Proposition retenue : Si le besoin d’ouvrir notre SI à des clients externe est présent nous pourrons facilement le mettre en œuvre grace à Azure API Management :1 - Azure Service Fabric : notre projet

Prochaine étape : la création de notre cluster Service Fabric !

Microservices et Azure Service Fabric

Après ces trois derniers articles :

Nous pouvons conclure qu’Azure Service Fabric propose une solution clé en main pour la conception d’une architecture microservices dans Azure car il offre des réponses aux différentes problématiques de mise en œuvre de microservices.

6 2 - Microservices et Azure Service Fabric

Grâce à cette offre PAAS, les développeurs ont à leur disposition :

  • Un Framework de développement en .Net et des templates de projet pour VS2017
  • Une solution CI/CD compatible avec VSTS depuis peu renommé Azure DevOps 🙂

ArticleVsts Alm - Microservices et Azure Service Fabric

  • Une offre PAAS pour l’intégration de la solution dans le cloud Azure. Cette offre PAAS garantis :
  • Scalabilité de nos services.
  • Découvrabilité via le Reverse Proxy.

6 3 - Microservices et Azure Service Fabric

  • Intégration avec API Management pour les appels clients.

3 3 - Microservices et Azure Service Fabric

  • Monitoring avec Application Insights.4 2 - Microservices et Azure Service Fabric
  • Communication avec Azure Service Bus pour les appels asynchrone.

De plus, un des avantages majeurs de cette solution à mon sens est que les développeurs retrouveront leur marque assez rapidement par rapport au développement d’API REST en ASP .Net Core.

net core logo proposal - Microservices et Azure Service Fabric

A contrario une solution comme Azure Container Service implique la montée en compétence sur :

  • La gestion des conteneurs avec Docker
  • Un orchestrateur de conteneur Docker tel que Kubernetes
  • La plateforme AKS en elle-même.

Maintenant que nous en avons terminé avec l’analyse de cette solution nous allons passer à la mise en oeuvre 🙂

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 !

Data Management et Azure Service Fabric

Hello !

Suite à ce précédent article je vais aujourd’hui parler gestion des donnés avec des microservices dans Azure Service Fabric.

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

Gestion des données

Il est bien sur possible d’utiliser des bases de données existantes (on prem) et d’héberger tout type de base de données dans Azure si besoin pour répondre aux différentes problématiques Data de vos applicatifs.

  • SQL Server
  • NoSQL : mongoDB
  • MySql

En ce qui concerne la séparation des données par service ASF, il n’y a pas de solutions meilleures qu’une autre. Chaque microservice est responsable de ces données et de leurs cohérences mais il n’y a pas d’obligation de provisionner une base de données pour chaque service. Nos options sont :

  • Chaque service à son jeu de tables attribués et ne peut effectuer des opérations CRUD que sur ces tables. Un seul microservice doit avoir accès à une table de la base de données. Il est donc interdit à un service B de réaliser une opération CRUD sur les données dont est responsable le service A.

4 - Data Management et Azure Service Fabric

  • Un service pour un schéma de la base.
  • Un service : une base de données.
  • Découpage lecture/écriture des données avec la mise en oeuvre du pattern CQRS.

L’architecte positionnera en fonction des contraintes et besoins de chaque solution la meilleure gestion de donnée pour le système d’informations.

Gestion des transactions

Les microservices peuvent-ils partager une transaction ?

Si une opération de mon SI nécessite deux microservices, comment font-ils pour se partager la transaction et garantir la cohérence du système en cas d’erreur ? Il faudrait pouvoir faire un rollback en cas d’échec et un commit en cas de succès mais sur les deux services via une même transaction.

Il s’agit d’une problématique purement logicielle à traiter manuellement avec éventuellement :

  • Commit en deux étapes : voir MSDN.
  • Méthode d’annulation : gestion par le développeur d’une méthode Non A pour chaque méthode A.

Ces deux façons de faire sont compliquées à mettre en œuvre et le risque d’erreur est important … Elles ne sont pas conseillées pour du microservice… Après tout si deux services sont impliqués dans une transaction commune, le découpage en « Bounded Context » de l’approche DDD n’est probablement pas optimal !

Ici nous avons traité de problématiques logicielles qui ne sont pas forcément spécifiques à Service Fabric mais à l’implémentation d’une architecture microservices en général. Il me semblais important d’en parler tout de même.

Communication et Azure Service Fabric

Hello !

Suite au dernier article je vais présenter comment Service Fabric peut nous aider à répondre à certaines problématiques liées à la mise en œuvre de microservices. Aujourd’hui l’aspect communication !

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

Communication clients / services

 

Nous avons deux possibilités pour qu’un client (web, application Windows, mobile) puissent échanger avec un service :

  • Communication directe

1 3 - Communication et Azure Service Fabric

  • Ou en  utilisant un composant intermédiaire : un API Gateway

Nous pouvons alors développer notre propre API Gateway :

2 3 - Communication et Azure Service Fabric

Ou utiliser une passerelle de Type Azure API Management :

3 3 - Communication et Azure Service Fabric

Cet outil permet de configurer simplement un API Gateway dans Azure. Il n’y a pas de développement supplémentaire à produire.

APIM est conçue pour :

  • Gérer les API complexes avec des règles de routage
  • Un contrôle d’accès (Authentification)
  • Une surveillance
  • Une journalisation des événements
  • Une mise en cache des réponses

Attention en contrepartie notre point d’accès unique à notre API est par définition un point de défaillance important de notre système. S’il tombe, il n’y a plus de communication possible. Du côté du trafic réseaux il peut également devenir un goulot d’étranglement s’il ne s’adapte pas à la charge.

Communication entre services

 

Pour la communication entre services nous avions listé deux possibilités :

  • Echange synchrone via commande HTTP

Attention ici il s’agit bien de l’appel qui est synchrone dans le sens ou le contact entre les deux services est direct. Au niveau applicatif l’appel peut être asynchrone dans le sens ou le client peut faire un traitement en attendant une réponse du service.

Si la communication entre services est directe, cela implique que les services sachent à quelle adresse ils peuvent s’appeler. Pour cela, Azure Service Fabric nous propose une solution de Reverse Proxy.

Au démarrage d’un service celui-ci vient s’identifier auprès du service d’attribution de noms d’ASF. Celui-ci tient une table qui mappe les instances de service et les adresses de point de terminaison :

4 3 - Communication et Azure Service Fabric

La résolution et la connexion aux services impliquent l’exécution des étapes suivantes en boucle :

  • Obtenir le point de terminaison publié par un service à partir du Service d’attribution de noms.
  • Se connecter au service sur le point de terminaison en question.
  • Si la tentative de connexion échoue, les étapes précédentes de résolution et de connexion doivent être réessayées, et ce cycle se répète jusqu’à ce que la connexion aboutisse ou qu’elle soit désactivée (Pattern circuit breaker)

Appel entre services :

5 3 - Communication et Azure Service Fabric

Appel depuis l’extérieur :

6 3 - Communication et Azure Service Fabric

Dans les deux cas c’est le reverse proxy qui nous renseigne sur les url des instances de services accessibles.

  • Échange asynchrone via un bus d’évènement basé sur le protocole AMQP.

7 3 - Communication et Azure Service Fabric

Si nos besoins nous conduisent vers une communication asynchrone, nous pouvons utiliser Azure Service Bus. Il y a alors deux cas d’utilisation.

    • Les files d’attente

Elles permettent une communication unidirectionnelle. Chacune agit comme un intermédiaire (ou broker) qui stocke les messages envoyés jusqu’à leur réception. Chaque message est reçu par un destinataire unique.

Il s’agit du cas le plus simple pour une communication par message : un émetteur, une file d’attente, un destinataire.

8 2 - Communication et Azure Service Fabric

  • Les rubriques

Les expéditeurs envoient les messages à la rubrique de la même façon qu’ils envoient des messages dans la file d’attente. Ces messages ont le même aspect.

À l’inverse des files d’attente cependant, un message unique envoyé à une rubrique peut être reçu par plusieurs abonnements. Cette approche, communément appelée publication et abonnement (ou pub/sub), est utile quand plusieurs applications sont intéressées par les mêmes messages.

9 2 - Communication et Azure Service Fabric

Les files d’attente et les rubriques dans Azure Service Bus se basent sur le protocole AMQP : ce protocole de messagerie open standard permet le développement d’applications basées sur des messages à l’aide de composants créés avec plusieurs langages, infrastructures et systèmes d’exploitation.

10 2 - Communication et Azure Service Fabric

Qu’il s’agisse d’une communication synchrone via appel HTTP ou asynchrone avec Azure Service Bus, les deux implémentations sont possibles avec Azure Service Fabric. Les deux solutions ont des avantages et des inconvénients, à chacun de les mesurer en amont du projet !

Mon architecture microservices dans Azure

Maintenant que nous avons présenté les problématiques à étudier pour la mise en œuvre de microservices :

Ainsi que la façon dont gérer l’intégration et le déploiement continu dans VSTS, il est temps de s’intéresser aux moyens qu’Azure met à notre disposition pour héberger nos composants logiciels !

Azure est une plateforme Cloud d’hébergement d’applications, de données et de services créés en 2008 par Microsoft. Les solutions proposées par Azure sont nombreuses. Ils se déclinent en trois principales catégories :

1 3 - Mon architecture microservices dans Azure

L’IaaS (Infrastructure as a Service) est une externalisation de l’infrastructure informatique matérielle. L’offre gère pour nous :

  • L’installation des serveurs fichiers
  • Les réseaux
  • Le stockage de données

Le PaaS (Platform as a Service) est un IaaS plus poussé. Il consiste à sous-traiter non seulement l’infrastructure matérielle mais également vos applications middleware :

  • Systèmes d’exploitation
  • Base de données
  • Serveurs web

A nous ensuite d’y ajouter nos applications et services.

Le SaaS (Software as a Service) est la version la plus aboutie et la plus complète de l’externalisation de composants du système d’information. Le fournisseur gère, pour nous :

  • L’installation
  • La configuration
  • Le fonctionnement
  • La maintenance

2 3 - Mon architecture microservices dans Azure

Pour l’hébergement d’applications de type microservices dans Azure nous disposons de plusieurs possibilités avec des offre de type PAAS.

Web App

Les web applications constituent le moyen le plus simple d’héberger une application dans Azure. Il s’agit d’une solution PAAS qui fais partie du groupe de fonctionnalités Azure App Services.

3 - Mon architecture microservices dans Azure

Web App est un service pour l’hébergement d’applications web, d’API REST et de backends mobiles. Vous pouvez y déployer des applications développées en .NET, .NET Core, Java, Ruby, Node.js, PHP ou Python.Les Web App sont déployés sur des machines virtuelles Windows ou Linux.

Il est également possible d’y déployer des applications s’exécutant dans un conteneur Docker.

Azure Container Service

On passe à une solution PAAS bien plus complète que les « simples » WebApp.

ACS est une plateforme de conteneur pouvant être orchestré par :

4 5 - Mon architecture microservices dans Azure

  • DC/OS
  • Docker Swarm
  • Kubernetes  : (l’orchestrateur Docker de Google) : on parle alors d’AKS.

5 - Mon architecture microservices dans Azure

Azure Container Service est une solution permettant de déployer, provisionner et manager des conteneur Docker.

La technologie d’un conteneur virtualise le système d’exploitation par rapport aux applications. Par rapport aux machines virtuelles, les conteneurs présentent les avantages suivants :

  • Ils sont bien plus légers. Un conteneur ne contient que l’application à déployer et ces dépendances.
  • Démarrage rapide : comme les conteneurs n’ont pas besoin d’initialiser l’intégralité d’un système d’exploitation, ils peuvent démarrer beaucoup plus rapidement, généralement en quelques secondes.
  • Portabilité : une image d’application en conteneur peut être portée de manière à s’exécuter dans le cloud ou sur site, à l’intérieur de machines virtuelles ou directement sur des machines physiques.

L’utilisation de cette plateforme me semble intéressent pour un SI qui maitrise déjà docker et un orchestrateur et qui veux migrer vers le Cloud. Historiquement Docker et les orchestrateurs de conteneur adresse plutôt des technologies open source mais se sont tournés récemment vers Microsoft grâce à .Net Core.

La troisième option est le concurrent direct d’ACS / AKS.

Azure Service Fabric

6 2 - Mon architecture microservices dans Azure

Azure Service Fabric est la plateforme de microservices signée Microsoft. Elle peut être déployée OnPrem sur des serveurs Windows Server 2016 ou Linux, dans le Cloud sous Azure, mais également dans n’importe quel autre Cloud.

La plateforme est mise à disposition de tous depuis 2015 mais Microsoft l’éprouve depuis plusieurs années. En effet plusieurs services Azure utilisent cette infrastructure :

  • Skype pour les entreprises
  • DocumentDB
  • Event Hubs
  • Azure SQL Database (qui héberge plus de 1,4 million de bases de données clients)
  • Cortana qui peut traiter plus de 500 millions de requêtes par seconde.

Source MSDN : «  Azure Service Fabric est un orchestrateur de services sur un cluster de machines. Azure Service Fabric est une plateforme de systèmes distribués qui facilite le packaging, le déploiement et la gestion de conteneurs et de microservices évolutifs et fiables. Les développeurs et administrateurs sont en mesure d’éviter les problèmes d’infrastructure complexes et peuvent se concentrer sur l’implémentation de charges de travail stratégiques et exigeantes, évolutives, fiables et faciles à gérer. »

Autrement dit, il s’agit d’une plateforme PaaS associée à un système d’orchestration des services, façon Kubernetes.

7 2 - Mon architecture microservices dans Azure

Azure Service Fabric propose :

  • Une gestion de la haute disponibilité des services.
  • Un modèle de programmation simple.
  • Une scalabilité des services à grande échelle.
  • Un partitionnement des données.
  • Une gestion fine des mises à jour que ce soit en upgrade ou en downgrade.
  • Un monitoring simple de la santé de vos services.
  • Un démarrage et un arrêt rapide des services.
  • La gestion du load balancing des services.
  • Une gestion de récupération automatique des services.
  • Un système de réplication et de gestion de failover.

Les différents types d’applicatifs pouvant être exécutés dans Service Fabric sont :

  • Stateless service : Un service au sens courant qui ne maintiens pas d’état entre les appels.
  • Stateful service : Un service capable de conserver des informations grâce aux ReliableDictionary qui garantis une persistance des données entre les différentes instances du service.
  • Actor service : Par exemple, un panier d’un utilisateur sur un site de e-commerce peut être un actor service.
  • Guest exécutable : Permet d’exécuter une application exe dans Service Fabric
  • Container : Exécutions d’un conteneur docker dans ASF : disponible depuis peu.

Ces différents types de services peuvent être développé en utilisant .Net ou .Net Core.

Dans les prochains articles nous allons reprendre point par point les problématiques relevés pour l’implémentation d’une architecture microservices et détailler comment Azure Service Fabric réponds à chacun d’entre eux. Je reviendrais plus tard également sur Azure Container Services 🙂

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 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 🙂