Dans mon dernier article, nous avons découvert comment utiliser Azure Container Registry pour stocker les images Docker qui composent notre serveur de logs. Dans cet article nous allons découvrir comment héberger nos conteneurs avec Azure Service Fabric Mesh.

Introduction à Azure Service Fabric Mesh

Azure Service Fabric  est une plateforme d’hébergement et d’orchestration de micro services développée et mise à disposition dans Azure par Microsoft. Dans sa version « classique », un cluster Service Fabric est composé d'un ensemble de nœuds. Ces nœuds sont des machines virtuelles Azure que nous devons adminstrer par l'intermédiaire d'un ou plusieurs Azure VM scale sets. Il est donc nécessaire d’administrer ces ressources IaaS et de veiller à la politique de mise à l’échelle.

Azure Service Fabric Mesh est la version Serverless de la plateforme Azure Service Fabric. Elle permet d’héberger et d’orchestrer des conteneurs sans avoir à administrer les ressources IaaS sous-jacentes ainsi que la mise à l’échelle horizontale. L’idée est de déclarer dans un template de déploiement les conteneurs à héberger et les ressources IaaS nécessaires pour chaque conteneurs (CPU & RAM), la plateforme s’occupe du reste.

Ressources Azure nécessaires

Pour bien comprendre les ressources Azure à déployer, regardons d’un peu plus près l’architecture d’une application Service Fabric Mesh : Une application SF Mesh est une collection de conteneurs (nommées services) qui s’exécutent au sein d’un réseau privé. Ce réseau n’est pas accessible depuis l’extérieur, c’est pourquoi nous avons besoin d’une passerelle (gateway) pour rendre ce réseau privé accessible depuis le web. La passerelle définit un point d’entrée vers un conteneur précis et spécifie quel protocole est utilisable (http ou tcp).

Un service fait donc référence à une image de conteneur hébergé dans un registry docker public ou privé. Pour chaque service, il est nécessaire de configurer les éléments suivants :

• Le registry Docker cible et une image
• Propriétés du conteneurs (variables d’environnement, volumes…)
• Un point d’accès sur le réseau privé
• Les ressources matérielles nécessaire à l’exécution du conteneur (CPU and memoire)
• Le nombre de réplica

Pour chaque brique de notre serveur de log (Kibana, Elasticsearch, Nginx) nous allons définir un service. Le service Elastic search utilisera un volume SF Mesh pour stocker ses données.

Un volume SF mesh a besoin d’un compte de stockage Azure. Nous allons donc en créer un avec un partage de fichier.

$resourceGroupName = ''
$storageAccountName = ''
$location = ''
$storageAccountFileShareName = ''

az storage account create -n $storageAccountName -g $resourceGroupName -l $location --sku Standard_LRS
storageConnexionString=$(az storage account show-connection-string -n $storageAccountName -g $resourceGroupName --query 'connectionString' -o tsv)
storagePrimaryKey=$(az storage account keys list --resource-group $resourceGroupName --account-name $storageAccountName --query "[0].value" | tr -d '"')

az storage share create --name $storageAccountFileShareName --connection-string $storageConnexionString

Nous utiliserons le nom du compte de stockage, sa clef d’accès ainsi que le nom du partage de fichier dans les paramètres du template de déploiement.

Template de déploiement Azure Ressource Manager

Pour déployer notre application SF Mesh, nous allons utiliser un template de déploiement avec 4 types de ressources :

1. Network (Microsoft.ServiceFabricMesh/networks)
2. Gateway (Microsoft.ServiceFabricMesh/gateways)
3. Application (Microsoft.ServiceFabricMesh/applications) with services as linked resources
4. Volume (Microsoft.ServiceFabricMesh/volume)

Ce template est verbeux, et le coller dans ce post ne serait pas particulièrement lisible. Il est disponible sur mon GitHub ici. En fin de déploiement, le template retourne l’adresse IP de la passerelle et donc le point d’entrée de notre serveur de log.

Dans le schéma, suivant, les flèches représentent les relations de dépendances (« dependsOn ») entre les ressources Azure à déployer :

Notre template va déployer un service pour chaque composant de notre serveur de log (elastic search, kibana et nginx). Le conteneur nginx sera exposé sur le port 80 et donnera donc accès publiquement au serveur de log.

Le fichier de paramètre du template de déploiement va spécifier les éléments suivants :

• Informations d’authentification au registry privée Docker
• Images Docker cibles (elastic search, kibana, nginx)
• Informations de connexion au compte de stockage (pour le Volume SF mesh)

Déploiement

Maintenant que notre template de déploiement est fin prêt, une seule commande de CLI Azure va nous permettre de déployer notre application.

Il est tout d’abord nécessaire d’installer la CLI Azure ainsi que l’extension mesh :

az extension add --name mesh

Dans l’exemple suivant, nous utilisons la commande az mesh deployment create. Cette dernière a besoin de 3 paramètres :

• Le nom du groupe de ressources cible
• Le template ARM à déployer
• Le fichier de paramètre

az mesh deployment create --resource-group {resourceGroupName} --template-file ./azuredeploy.full.json --parameters ./azuredeploy.parameters.json

Happy coding :)