Février 2019

Volume 34, numéro 2

Cet article a fait l'objet d'une traduction automatique.

[Azure]

Créer et déployer des solutions hautement disponibles et résilientes sur Azure

Par Srikantan Sankaran

Parmi les technologies abordées dans cet article sont en version préliminaire. Toutes les informations contenues dans le présent document peuvent faire l'objet de modifications.

Les organisations de nos jours avoir une présence globale et qu’elles attendent de leurs applications critiques d’atteindre des utilisateurs sur plusieurs zones géographiques. Informatique de ces organisations est sous pression pour répondre à ces attentes, et leur réussite varie selon le degré leurs applications et les plateformes sont architecture et la conception pour faire face à la complexité inhérente à cet objectif. Microsoft Azure offre de nombreux services et fonctionnalités qui fournissent une implémentation presque clés en main pour répondre aux exigences pertinentes, si elles impliquent l’activation de géo-réplication des services et données, sensibles à la latence des requêtes utilisateur pour le routage un service de plus près aux utilisateurs finaux, ou en fournissant basculement transparente des applications vers d’autres régions en cas de catastrophe. Dans cet article j’Examinons quelques-unes de ces objectifs et décrivent comment Azure peut servir à implémenter des applications hautement disponibles et résilientes globales.

Je vais utiliser une solution à trois niveaux consistant en une application MVC et API Web pour illustrer les principaux aspects de la création et déploiement d’applications hautement disponibles et résilientes dans Azure. L’application est accessible par un utilisateur pour capturer des informations de base se rapportant à sa famille, qui est transmise à la couche API, qui à son tour conserve les données dans une base de données Cosmos DB géorépliqué. L’application est déployée dans plusieurs régions pour garantir la résilience contre les pannes de courant régionales actif. Dans une région, il est déployé sur les Zones de disponibilité pour protéger contre les défaillances de centre de données (bit.ly/2zXlRll). La base de données a une fonctionnalité d’écriture multirégions activée (bit.ly/2zV6OI0), en garantissant que les utilisateurs peuvent écrire et lire des données à partir d’une base de données est proche de leur point d’accès, pour réduire la latence (bit.ly/2QRr1Il).

Architecture de la Solution

Figure 1 représente l’architecture de la solution. Azure Service Fabric héberge les composants d’application empaquetées en tant que conteneurs Docker pour Linux fournit les capacités d’orchestration et garantit la disponibilité et la fiabilité de l’application. Il existe deux clusters Service Fabric zonales sont déployés pour chacune des deux régions Azure, en Asie du Sud-est et est des États-Unis 2. Un équilibreur de charge Azure redondant est utilisée à répétition alternée les demandes entre les deux Zones de disponibilité dans chaque région.

Figure 1 Architecture de Solution

Azure Service porte d’entrée (toujours en version préliminaire publique) dirige les requêtes utilisateur à un des points de terminaison avec équilibrage de charge entre les deux régions, selon le chemin d’accès de la latence la plus faible. Il fournit également la résilience en cas de l’application ou un centre de données jusqu’au bas d’une des régions, en dirigeant les demandes au point de terminaison dans l’autre région.

La base de données Azure Cosmos DB utilisé dans l’application est géo-répliquées dans les deux régions Azure et configuré pour l’écriture de plusieurs régions. Par conséquent, écritures de données à partir du Service d’API dans chaque région d’origine sont écrits dans une collection Cosmos DB locale pour cette région.

Azure DevOps est le référentiel de code source pour l’application. Les Pipelines Azure est utilisé pour générer les applications, de les empaqueter en tant que conteneurs Docker et de les charger dans un Registre de Hub Docker.

Les stratégies informatiques de l’organisation à cette solution d’hébergement interdisent l’accès administratif au cluster Service Fabric via l’Internet public. Un pipeline de livraison continue (CD) est implémenté à l’aide de Jenkins déployé à l’intérieur d’un réseau virtuel Azure. Il extrait les packages de déploiement et les conteneurs à partir du référentiel Git dans Azure DevOps et Docker Hub et déploie l’application sur les clusters Service Fabric dans les deux régions.

Le cluster Service Fabric déployé dans chaque région se compose de deux types de nœuds. Le type de nœud principal exécute les services de plateforme Service Fabric et expose les points de terminaison de gestion à l’aide d’un équilibreur de charge interne. Le type de nœud secondaire s’exécute les applications MVC et API Web empaquetées à l’aide de conteneurs Docker. Un équilibreur de charge de publique achemine les demandes des utilisateurs finaux accèdent à l’application via Internet.

Un équilibreur de charge Azure tiers (non illustré dans le diagramme) est utilisé dans cette architecture pour permettre les appels sortants vers Internet à partir du cluster, pour télécharger les composants de la plateforme Service Fabric. L’équilibreur de charge interne configuré n’a pas un point de terminaison publics et ne peut pas accéder à Internet. Sans créer cet équilibreur de charge public supplémentaires pour la connectivité sortante, le cluster Service Fabric ne peut pas être configuré (bit.ly/2A0VBpp).

Notez que les référence (SKU) d’Azure Load Balancer et l’adresse IP publique adresse ressources standard uniquement prendre en charge le déploiement pour les Zones de disponibilité Azure, éliminait la référence de base, qui est pas le cas.

Azure Service Fabric s’appuie sur la capacité des ressources Azure Virtual Machine Scale Sets (VMSS) sous-jacentes pour le déploiement zonale. 

Développement d’Applications

Il existe deux fichiers de solution Visual Studio 2017 partagés avec cet article :

• censusapp.sln : L’application ASP.NET Core 2.0 MVC.

• censusapi.sln : L’application API Web de ASP.NET Core 2.0.

N’oubliez pas que même si cet exemple d’application a été créé à l’aide d’ASP.NET Core 2.0, il pourrait très bien être une application Web créée à l’aide d’autres technologies, telles que Node.js, PHP et ainsi de suite. En outre, l’exemple d’application partagé avec cet article n’implémente pas les bonnes pratiques de codage. Il est conçu uniquement pour illustrer la conception sélectionnez Détail d’implémentation.

L’application MVC implémente l’interface utilisateur qui permet aux utilisateurs d’envoyer des données de recensement et affiche ces données. Il utilise la fonctionnalité de découverte de service dans Service Fabric pour appeler l’API REST qui rend persistantes les données dans Azure Cosmos DB. Le projet d’API utilise le SDK Cosmos DB pour implémenter une liste hiérarchisée des emplacements de base de données pour vous connecter à pour lire et écrire des données. L’application est déployée sur la région Asie du Sud ajouteriez cette région en tant que « priorité 1 » et est des États-Unis 2 en tant que « priorité 2 ». Pour un déploiement vers la région est des États-Unis 2, il serait l’inverse. Par conséquent, il y aura deux images de conteneur distinct pour le projet d’API Web, un pour chaque déploiement dans les régions respectives. L’image de conteneur pour le projet MVC serait la même, quelle que soit la région Azure sur lequel elle est déployée.

L’extrait de code suivant montre comment la liste hiérarchisée des emplacements est ajoutée à la connexion de Cosmos DB et comment configurer des écritures multirégions dans l’application :

ConnectionPolicy policy = new ConnectionPolicy
  {
    ConnectionMode = ConnectionMode.Direct,
    ConnectionProtocol = Protocol.Tcp,
    UseMultipleWriteLocations = true,
  };
policy.PreferredLocations.Add("East US 2");
policy.PreferredLocations.Add("South East Asia");
DocumentClient client = new DocumentClient(new Uri(this.accountEndpoint), 
  this.accountKey, policy);

Le projet d’API Web utilise le package NuGet de « Bogus » pour générer des données fictives.

Les clés d’accès et de la chaîne de connexion Cosmos DB sont stockés dans le fichier appsettings.json du projet API Web par souci de simplicité. À des fins de production, elles impossible à la place stockées dans Azure Key Vault. Reportez-vous à mon article « Sécuriser votre sensibles Business informations avec Azure Key Vault » pour obtenir des conseils (msdn.com/magazine/mt845653).

Activer les Applications Web pour les conteneurs DockerVisual Studio 2017 Tools pour Docker fournir une implémentation de clé en main pour activer une application Web ASP.NET 2.0 pour les conteneurs Windows et Linux. L’option avec le bouton droit sur le projet dans Visual Studio 2017 sur « Activer la prise en charge Docker » ajoute un fichier Docker. En sélectionnant l’option de clic droit sur le projet pour « activer la prise en charge de l’orchestration » crée une commande Docker compose le fichier.

Les applications dans cette solution ont été regroupées pour les conteneurs Docker Linux. Modifications mineures ont été effectuées pour le Docker compose de fichier pour ajouter le mappage de port à utiliser lors du déploiement de l’application (port 80 sur les nœuds VMSS pour accéder à l’application MVC et de port 5002 pour l’API Web).

Intégration continue (CI) The Visual Studio 2017 des fichiers solution sont archivés dans un référentiel Git de DevOps Azure. Un pipeline Azure est créé qui serait exécution Docker fichiers compose pour chacun des projets MVC et API Web créés dans les étapes précédentes. Cela génère les applications ASP.NET Core 2.0 et crée les images de conteneur Docker.

Dans l’étape suivante dans le pipeline, un script Bash est utilisé pour marquer les images de conteneur et les envoient vers Docker Hub. Cette étape doit être effectuée une seule fois pour le déploiement vers la région Azure en Asie du Sud-est et qu’une seule fois pour le déploiement sur Azure région est des États-Unis 2. Là encore, le conteneur MVC est le même aucune question sur la région Azure dans laquelle elle est déployée. Figure 2 affiche un instantané du pipeline CI créé pour effectuer cette étape.

Figure 2 Azure DevOps Pipeline

Empaquetage d’Applications pour le déploiement sur Service Fabric que j’ai utilisé le Yeoman generator pour Windows générer l’application et les fichiers manifeste de service et de la solution de package. Vous trouverez des conseils à l’aide de cet outil à bit.ly/2zZ334n.

Un package d’application unique est créé que les applications MVC et API offres groupées en tant que Types de Service. Dans les fichiers manifeste de service, entrez les noms de conteneur téléchargés vers Docker Hub dans les étapes précédentes.

Notez que le manifeste de service du projet API Web définit un nom DNS du service qui doit correspondre à la valeur dans le fichier appsettings.json du projet MVC, à être utilisés dans la découverte de service.

Le nombre d’instances de chaque type de service (autrement dit, les projets Web et API) dans le manifeste est défini à deux. Cela indique à Service Fabric que deux instances du conteneur de ce type de service toujours en cours d’exécution dans le cluster. Ce nombre peut être modifié en fonction du déploiement, ou peut être défini à l’échelle automatique dans une plage maximale et le min.

Le manifeste de service prend en charge la notion d’une contrainte de placement. Dans l’extrait suivant, une contrainte de placement est définie sur le nom de type de nœud dans le cluster Service Fabric sur lequel le service doit être déployé. Si non spécifié, le package de code pourrait être déployé sur tous les types de nœud, notamment le type de nœud principal du cluster Service Fabric. Toutefois, j’ai l’intention d’héberger uniquement les Services Service Fabric plateforme dans le type de nœud principal.

<ServiceTypes>
  <StatelessServiceType ServiceTypeName="censusapiType" 
    UseImplicitHost="true">
<PlacementConstraints>(NodeTypeName==nt-sfazvm0) </PlacementConstraints>
  </StatelessServiceType>
</ServiceTypes>

Le nom du type de nœud configuré dans le modèle Azure Resource Manager (ARM) (abordé plus tard) pour déployer le Cluster Service Fabric doit correspondre à celui de la contrainte de placement du manifeste de service.

Déployer les Applications de Service Fabric

Maintenant nous allons créer le cluster Service Fabric, puis déployer les packages d’application vers elle.

La première étape consiste à configurer une base de données Cosmos DB, qui peut être effectuée à partir du portail Azure. Commencez par créer une base de données en Asie du Sud-est et activer la géo-réplication pour la région est des États-Unis 2. Sélectionnez l’option « Activer l’écriture Multirégions » dans l’Assistant.

J’ai conservé la configuration de la cohérence de Session, qui est la valeur par défaut pour la base de données Cosmos DB et le paramètre de toutes les propriétés qui les index dans le schéma par défaut. Vous pouvez sélectionner uniquement les propriétés spécifiques à l’index si vous préférez, selon le besoin d’interroger les données.

Pour gérer les conflits potentiels qui surviennent en dehors de l’activation de l’écriture multimaître, j’ai utilisé le par défaut, la stratégie « résolution des conflits de dernière gagne ».

Ensuite, vous configurez le cluster Service Fabric à l’aide d’un modèle ARM (bit.ly/2swVkI5 et bit.ly/2rBvFfi). Modèle SF-Std-ELB-ZonalDeployment.Json déploie deux clusters zonales dans un réseau virtuel existant. Il existe certaines conditions préalables pour exécuter ce modèle.

Tout d’abord, utilisez un certificat stocké dans Azure Key Vault pour la sécurité nœud à nœud du cluster. L’URL d’empreinte numérique, URL de Key Vault et du certificat à partir de cette étape doivent être entrés dans la section Paramètres du modèle ARM, comme indiqué dans Figure 3. Cela doit être fait pour chacune des régions séparément, parce que le cluster Service Fabric et le coffre de clés utilisées par ce dernier doivent résider dans la même région.

Figure 3 stockage l’empreinte numérique, Azure Key Vault URL et l’URL du certificat

"certificateThumbprint": {
      "type": "string",
      "defaultValue": "<Certificate Thumb print>
    },
    "sourceVaultValue": {
        "type": "string",
        "defaultValue": "/subscriptions/<SubscriptionId>/resourceGroups/
          lpvmvmssrg/providers/Microsoft.KeyVault/vaults/<vaultname>”
    },
    "certificateUrlValue": {
        "type": "string",
        "defaultValue": "https://<vaultname>.vault.azure.net/secrets/
          soloclustercert/<GUID>
        }
  }

En second lieu, un certificat auto-signé est généré à l’aide d’Open SSL. L’empreinte numérique de ce certificat est entré dans la section Paramètres du modèle ARM :

"clientCertificateStoreValue": {
      "type": "string",
      "defaultValue": "<Client certificate thumbprint
    },

Ce certificat est utilisé dans Jenkins pour se connecter au cluster Service Fabric pour déployer l’application. Consultez bit.ly/2GfLHG0 pour plus d’informations.

Notez que cet article utilise un certificat auto-signé à titre d’illustration. Pour les déploiements de production, vous utiliseriez des informations d’identification Azure pour se connecter au point de terminaison de gestion en toute sécurité et pour déployer l’application.

Pour plus d’informations sur la sécurité de Service Fabric, consultez bit.ly/2CeEzpi et bit.ly/2SR1E73.

Les sondes d’intégrité utilisées dans l’équilibreur de charge pour l’application MVC et l’API Web doivent être configurés pour le protocole HTTP, avec les numéros de port de droite et le chemin d’accès de la demande, comme indiqué dans Figure4.

Figure 4 configurer les Ports et les chemins d’accès de la demande

{
    "name": "SFContainerProbe1",
    "properties": {
      "protocol": "Http",
      "port": 5002,
      "requestPath": "/api/family",
      "intervalInSeconds": 5,
      "numberOfProbes": 2
    }
  },
    {
    "name": "SFContainerProbe2",
    "properties": {
      "intervalInSeconds": 5,
      "numberOfProbes": 2,
      "port": 80,
      "requestPath": "/",
      "protocol": " Http "
    }
  }

Voici les autres configurations marquants dans le modèle ARM, spécifique à des déploiements zonaux :

• La référence SKU standard est choisie pour tous les équilibreurs de charge utilisés dans le cluster.

• La référence SKU standard est choisie pour la ressource d’adresse IP publique.

• La propriété de Zone de disponibilité doit être spécifié. Comme il s’agit d’un déploiement zonal, une zone unique est spécifiée dans une valeur de propriété. Pour zonale SF Cluster 1 dans l’Asie du Sud-est, cette valeur doit être « 1 » et pour zonale SF Cluster 2 en Asie du Sud-est, la valeur est « 2 ».

• La propriété « SinglePlacementGroup » est définie sur « true ».

• Pour activer la découverte de service dans le cluster, le DNS de Fabric Service doit être activé.

Figure 5 montre comment ils sont configurés dans le modèle ARM. Vérifiez que le modèle a correctement déployé et que les services affichés dans Figure 5 sont visibles dans le portail Azure.

Figure 5 ressources VMSS utilisés dans le modèle ARM pour le déploiement Zonal

Notez que les Zones de disponibilité Azure ne sont pas disponibles dans toutes les régions Azure encore. En outre, la fonctionnalité a atteint la disponibilité générale (GA) dans certaines régions, mais est uniquement en version préliminaire dans d’autres.

Maintenant nous allons vous connecter au cluster Service Fabric. Le point de terminaison de gestion de Service Fabric est déployé derrière un équilibreur de charge interne. Par conséquent, pour accéder à Service Fabric Explorer pour déployer l’application, de déployer une machine de virtuelle de zone saut (VM) exécutant Windows Server 2016, soit dans le même réseau virtuel que le cluster Service Fabric, ou vers un autre virtuel réseau qui a homologués à celle de la Grappe.

Copiez le certificat pour le client administrateur de Service Fabric (le certificat auto-signé qui a été créé précédemment) au magasin de certificats utilisateur sur le saut zone machine virtuelle. Lors du lancement du Service Fabric Explorer, sélectionnez ce certificat lorsque vous y êtes invité.

Ensuite, configurez Jenkins pour déployer l’application. Pour le scénario de cet article, je vais utiliser une image de conteneur Docker en cours d’exécution Jenkins et le plug-in Service Fabric. Cette image est déployée sur une VM Ubuntu dans Azure en cours d’exécution dans le même réseau virtuel que le cluster Service Fabric.

Vous trouverez plus d’informations sur les étapes requises pour télécharger, installer et configurer l’image de conteneur à bit.ly/2RRRt1Q.

Pour préparer Jenkins pour se connecter au cluster Service Fabric, j’ai effectué les étapes supplémentaires suivantes :

• Copiez le certificat pour le client administrateur de Service Fabric (le certificat auto-signé créé précédemment) dans le répertoire de base sur la VM Jenkins, à l’aide d’outils tels que WinSCP.

• Démarrer le conteneur Jenkins sur cette machine virtuelle et exécutez la commande « docker exec » pour copier ce certificat vers le répertoire de base Jenkins à l’intérieur du conteneur.

Lancez Jenkins et connectez-vous à http://<Public-IP-of-JenkinsVM>:8080 pour configurer le plug-in Service Fabric.

Les étapes pour configurer le plug-in Service Fabric pour Jenkins sont décrites sur bit.ly/2UBVhWV. La configuration de « Post Build Actions » qui a été utilisée pour exécuter le déploiement de l’application à l’un des clusters zonales est présentée dans Figure 6. Ajouter une Action de génération de Post supplémentaires pour le deuxième cluster zonal, dans le même esprit.

Figure 6-Service-Fabric plug-in pour Jenkins

Déclenchement manuel de l’option de créer un travail dans Jenkins et vous assurer que l’action post-déclencheur se termine avec succès. À partir de la machine virtuelle jump box, lancez le Service Fabric Explorer pour vérifier que l’application est déployée sur les deux clusters zonales. Figure 7montre l’Explorateur de Fabric Service une fois que l’application est déployée.

Figure 7 le point de terminaison de gestion dans Service Fabric Explorer

Répétez ces étapes pour déployer dans la deuxième région Azure. Vérifiez que le fichier de manifeste de service du projet d’API est modifié afin qu’il pointe vers l’image de conteneur du service API destiné à cette région. Rappelez-vous que les deux images de conteneur du service de API ont une priorité de région distincte lors de la connexion à Cosmos DB et pour implémenter les écritures dans plusieurs régions.

Exécution de l’Application

Pour afficher l’application déployée à la région 1, lancez les URL suivantes :

• http://<Public-IP-Address-LB Région1 > démarre l’Application MVC

• http://<Public-IP-Address-LB Région1 > : 5002/api/famille démarre l’API Web directement. Le projet MVC appelle l’API en interne, à l’aide de la découverte de Service.

Un autre ensemble d’URL est accessibles pour la région 2.

Figure 8 montre la page d’application accédée via les points de terminaison exposés par le Service de la porte d’entrée Azure. Vous remarquerez une colonne appelée DataOrigin qui indique le nom de la région d’écriture de la base de données Cosmos DB à partir de laquelle l’enregistrement a été inséré, présentant la capacité d’écriture de plusieurs régions de Cosmos DB.

Exemple d’Application de recensement figure 8

Configuration du Service Azure porte d’entrée

Utiliser le portail Azure pour approvisionner Azure porte d’entrée Service et ajoutez les points de terminaison publics des applications MVC et API Web comme back se termine sur le Service de la porte d’entrée.

Les sondes d’intégrité configurées dans le Service de la porte d’entrée Vérifiez que, quand un point de terminaison principal n’est pas accessible, en raison d’une panne dans la mesure région ou lorsque l’application obtient ne répond pas, les demandes sont dirigées à l’autre sain. Les paramètres de configuration dans Figure 9 montrent comment les points de terminaison d’application dans les deux régions ont été mappés à un seul point de terminaison exposé par le Service de la porte d’entrée. Bien que Azure Traffic Manager pourrait avoir été utilisé comme alternative à Azure porte d’entrée, j’ai choisi d’implémenter le dernier ici car il fournit un Proxy inverse de couche 7, un arrêt SSL et routage des requêtes, qui sont requis dans de telles applications.

Figure 9 porte d’entrée Azure Configuration

Vous trouverez plus d’informations sur la création d’une porte d’entrée pour les applications Web globales à bit.ly/2QXRkwu.

Pour résumer

Dans cet article, j’ai abordé comment Azure Service Fabric peut être utilisé pour empaqueter et déployer des applications prenant en charge le conteneur de Docker et implémenter une orchestration et les fonctionnalités de découverte de service qui sont indispensables pour une architecture de microservices. Avec la prise en charge pour les Zones de disponibilité dans Azure, j’ai déployé 2 clusters zonale Service Fabric qui s’étendent sur plusieurs centres de données dans une région afin d’éliminer les effets de défaillances de centre de données.

Pour augmenter la portée de l’application, j’ai déployé l’application dans plusieurs régions Azure et exploité la dans plusieurs régions écrivent prise en charge dans Azure Cosmos DB, ce qui garantit que sont non seulement les niveaux d’application sans état géo-répliquée, mais la base de données est également véritablement distribuées et répliquées. Enfin, pour vous assurer que les utilisateurs rencontrent le moins de latence lors de l’accès de l’application, j’ai implémenté un seul Service porte d’entrée Azure qui positionne des demandes au point de terminaison d’application appropriée. Pour montrer comment vous pouvez implémenter cette architecture avec le moins de perturbations pour les entreprises et pour garantir que les stratégies de sécurité sont respectées, j’ai abordé comment CI et CD pratiques peuvent être implémentées à l’aide du Service de DevOps Azure et Jenkins, respectivement et comment ceux-ci peuvent être exécutées au sein d’un réseau d’entreprise.

Vous pouvez télécharger l’exemple d’application à bit.ly/2Lra9Dm. Voir « Configuration logicielle requise » pour plus d’informations sur les logiciels requis pour implémenter l’exemple d’application.

Srikantan Sankaran est développeur technique principal de l’équipe d’un partenaire Commercial en Inde, basé à Bangalore. Il fonctionne avec nombreux éditeurs de logiciels indépendants en Inde et leur permet de concevoir et déployer leurs solutions sur Microsoft Azure. Vous pouvez le contacter sansri@microsoft.com.

Merci aux experts techniques Microsoft suivants d'avoir relu cet article : Sudhanva Huruli, Pulipalyam Muni

Discuter de cet article sur le forum MSDN Magazine