Il y a quelques semaines, nous avons mis en place un serveur de log "conteneurisé" basé sur Elastic Search, Kibana et sécurisé via Nginx. L'objectif de base est de pouvoir mettre en place un serveur de log en quelques minutes. Nous avons tout d'abord opté pour une solution IaaS, en hébergeant ce dernier dans une machine virtuelle Azure. 

** Avant de continuer la lecture de cet article, il est nécessaire de prendre connaissance de comment nous avons architecturer nos conteneurs via ce blog post ** 

Hébergement IaaS

En soit, l'hébergement IaaS fonctionne parfaitement. Nous avons le contrôle total sur la machine et nous pouvons facilement nous connecter sur la machine virtuelle en SSH si besoin. Cependant, l'administration d'une machine virtuelle est coûteuse en temps, une solution PaaS ou Serverless nous permettrait de réduire ce temps d'administration et de pouvoir mettre à l'échelle notre serveur de log plus facilement. 

Notre serveur de log est basé sur Docker. Actuellement 4 services Azure permettent d'exécuter des conteneurs Docker sans administrer l'infrastructure sous-jacente : Azure App Service, Azure Container Instance, Azure Services Fabric Mesh et Azure Kubernetes Service. 

Dans cet article, nous allons nous intéresser à l'hébergement des conteneurs dans Azure, puis dans les deux prochains articles nous utiliserons Azure Service Fabric Mesh (ASFM) et Azure Container Instance (ACI) pour héberger notre serveur de log. 

Workflow de déploiement pour ASFM et ACI

Pour publier une application ASFM et ACI, le workflow de déploiement est relativement similaire. Dans un premier temps, nous avons besoin d'héberger les images de conteneurs dans un registry Docker puis il est nécessaire de référencer les images Docker depuis un template ARM. Ce sont les templates ARM qui sont responsables de créer les conteneurs dans les services cibles. 

Stocker ses images Docker dans un Azure Container Registry (ACR)

ACR est un registry Docker entièrement managé par Azure. Il offre les mêmes fonctionnalités qu'un registry Docker classique : Stockage et récupération des images Docker. Cependant puisque c'est un service Azure, nous pouvons tirer parti du système RBAC pour gérer les autorisations d'accès au registry et certaines fonctionnalités comme la géo-replication sont disponibles avec le niveau de service premium.

Création d'une instance ACR

La création d'une instance ACR peut se faire avec Azure CLI (et le portail bien sur!). Le script suivant crée un groupe de ressource et y place une instance ACR : 

$resourceGroupName = "tranise-rg"
$acrName = "traniseRegistry"

az group create -n $resourceGroupName -l westeurope
az acr create -g $resourceGroupName -n $acrName --sku Basic --admin-enabled

Avec la commande az acr create, nous spécifions le niveau de service "Basic". De plus, nous utilisons le flag --admin-enabled qui permet de créer un compte administrateur au niveau de l'instance ACR. C'est par l'intermédiaire de ce compte administrateur que nous pourrons nous connecter à l'instance en utilisant la commande docker login.

Depuis le portail, nous pouvons facilement récupérer les informations du compte administrateur (username et password) : 

Publier ses images Docker dans ACR

Maintenant que l'instance ACR est créée, il est temps d'y publier nos images Docker. Dans mon repo github, nous trouvons un dossier "serverless". Dans ce dernier, un dossier "log_server" contient la définition de chaque conteneur (kibana, nginx, elasticsearch). Il existe un dossier par conteneur cible. Pour chaque dossier, nous allons créer un image Docker et stocker cette dernière dans l'instance ACR.  

Dans un premier temps, il est nécessaire de se connecter à l'instance ACR avec la commande docker login (et les informations d'authentification du compte administrateur). 

docker login traniseregistry.azurecr.io

Pour chaque dossier, nous devons effectuer les étapes suivantes :

• Build : Créer un image Docker à partir du Dockerfile
• Tag : Spécifie le registry Docker de destination de l'image ainsi que son tag
• Push : Stocke l'image dans le registry Docker distant

La première étape et la seconde étape peuvent être factorisées avec la commande docker build et l'utilisation du paramètre -t (pour tag) :

docker build –t {registryuri}/{repositoryname}:{tag} .

Avec le paramètre -t nous spécifions le registry cible, ainsi que le repository et le tag. Le "point" indique qu'il faut utiliser le Dockerfile présent dans le dossier courant. 

Une fois l'image prête à l'emploi, on peut la stocker sur l'instance ACR distante avec la commande docker push :

docker push  {registryuri}/{repositoryname}:{tag}

Par exemple, si nous nous plaçons dans le dossier kibana, nous devons exécuter les commandes suivantes:

docker build -t traniseregistry.azurecr.io/es_kibana:dev .
docker push traniseregistry.azurecr.io/es_kibana:dev

dans le dossier elasticsearch : 

docker build -t traniseregistry.azurecr.io/es_elasticsearch:dev .
docker push traniseregistry.azurecr.io/es_elasticsearch:dev

et finalement dans le dossier nginx:

docker build -t traniseregistry.azurecr.io/es_proxy:dev .
docker push traniseregistry.azurecr.io/es_proxy:dev

Trois repository sont alors crées dans l'instance ACR :

Chaque image a été taguée avec le tag "dev", les images sont donc disponibles via les paths suivants :

• traniseregistry.azurecr.io/es_elasticsearch:dev
• traniseregistry.azurecr.io/es_kibana:dev
• traniseregistry.azurecr.io/es_proxy:dev

Nos images sont maintenant stockées au niveau d'une instance ACR dans Azure, elles sont prêtes à l'emploi ! Dans le prochain article nous les utiliserons pour déployer nos conteneurs dans Azure Service Fabric Mesh. 

Happy coding :)