Historiquement, le déploiement de ressources dans Azure s’effectue par l’intermédiaire d’un modèle de déploiement nommé : « Azure Service Management » (ASM). Aujourd’hui WAML (Windows Azure Management Libraires), les « cmdlets » PowerShell / Azure cli, sont basés sur ASM. Ce dernier supporte deux modes d’authentification : Azure Active Directory (AAD) et les certificats X.509.

« Azure Resource Manager » procure un nouveau modèle de déploiement de ressources dans Azure qui a pour objectif de remplacer à terme ASM. ARM supporte uniquement Azure Active Directory comme mode d’authentification et supporte nativement RBAC (role-based access control). Le nouveau portail Azure est basé sur ARM, pour utiliser ARM avec PowerShell un ensemble modules est disponible (modules AzureRM.*).

Aujourd’hui, il est donc possible de créer des ressources dans Azure avec les deux modèles de déploiement / deux API :

• ASM (l’ancien)
• ARM (le nouveau)

L’ancien portail Azure utilise de base ASM, mais tout comme le nouveau portail, il nous permet maintenant d’utiliser les deux modèles de déploiement. Pour la grande partie des ressources l’usage d’ARM est transparent, cependant la différence n’est pas négligeable pour les ressources suivantes :

•     Storage
•     Network
•     Compute

C’est pour cela que pour ces trois types de ressources, on trouve deux services sur le nouveau portail, un service (« classic ») qui permet de créer la ressource avec ASM et un nouveau service qui permet de créer la ressource avec ARM :

A l’heure actuelle, on peut schématiser l’utilisation de ces deux API de la manière suivante :

Ce schéma se veut simple mais il est en réalité un peu plus complexe, puisqu’actuellement, il est possible d’utiliser ASM et ARM depuis les deux portails pour les ressources : Storage, Network et Compute.

Une nouvelle façon de faire du Iaas (Infrastructure as service), « IaaS v2 » :

Le modèle de déploiement ARM introduit une nouvelle manière de provisionner les machines virtuelles totalement détachée de la notion de « cloud service » :

Sur le nouveau portail on remarque un service nommé « cloud service classic », ce service correspond au « cloud service » utilisé historiquement par ASM. Dans le modèle ASM le cloud service est la pierre angulaire des services « compute » ! C’est un conteneur qui permet d’associer différents web role, worker role et machines virtuelles en leur permettant de communiquer entre eux.

Toutes les machines virtuelles créées avec le modèle ASM utilisent un cloud service : ce cloud service possède une adresse IP virtuelle qui permet d’accéder aux différentes vms, il possède un nom DNS et utilise un DNS azure pour la résolution de noms de vms de plus il procure un système de load balancing et de scaling automatique pour les vms qu’il contient.

Le modèle de déploiement ARM n’utilise plus le cloud service : Les machines virtuelles provisionnées via ARM ne sont plus contenues dans un « cloud service » mais à l’intérieur d’un « virtual network » qui doit lui-même être contenu dans un « ressource group ». Dorénavant toutes les machines virtuelles possèdent leur propre adresse IP publique dynamique ou statique. Un « network adapter » permet de mettre en place du load balancing entre les vms.

Trois fournisseurs de ressources sont utilisés pour créer une machine virtuelle avec ARM :

•   SRP « Storage Resource Provider » : Création du compte de stockage qui va contenir les disques durs virtuels (.vhd) de la vm
•   NRP « Network Resource Provider » : Création du « virtual network » qui va contenir les machines virtuelles ainsi que le « network adapter » qui va gérer le load balancing
•   CRP « Compute Resource Provider » : Création des instances de machines virtuelles et de groupes de haute disponibilité

Les « cloud services » sont cependant toujours utilisables pour faire du PaaS (Plateforme as service).

Comment s’y retrouver entre les ressources déployées avec les deux modes de déploiement ?

Progressivement, nos souscriptions Azure vont donc héberger des ressources qui auront été créées certaines via ASM et d’autres via ARM. Certaines ressources créées avec ARM sont visibles en utilisant l’api ASM, mais l’inverse n’est pas vrai ! Toutes les ressources créées avec ASM ne seront pas visibles en utilisant l’API ARM. Par exemple si je crée un compte de stockage (« classic ») depuis l’ancien portail ou par l’intermédiaire d’une commande cmdlet PowerShell, ce compte de stockage ne sera pas visible en utilisant le module PowerShell AzureRM.storage !

Pourquoi utiliser ARM ?

Azure Resource Manager permet de provisionner un ensemble de ressources de manière déclarative en json. L’idée principale est déployer ou mettre à jour un ensemble de ressources en une seule opération. La création d’environnements avec ARM se fait toujours au sein d’un groupe de ressources, ce qui permet de gérer beaucoup plus facilement les ressources déployées (Télémétries, Tags, consommation…).

Pour créer un environnement, il suffit de décrire les ressources que l’on veut déployer directement en json puis d’envoyer notre fichier à l’api ARM qui va s’occuper de déployer les ressources que nous avons définies. Il est possible de contacter l’api ARM pour déployer notre modèle json de plusieurs façons :

•      Appel direct aux API Azure
•      Portail Azure
•      PowerShell / Azure Cli
•      Visual Studio (avec le SDK Azure 2.6)

Pour résumer ARM propose les fonctionnalités suivantes :

•       Définition des environnements en json (modèle déclaratif)
•       Ordonnancement de la création des ressources directement dans le modèle json
•       Gestions des accès au sein du groupe de ressource via RBAC.

Avec ARM, on peut maintenant parler de « Infrastructure as code ». L’idée est de définir et de traiter son infrastructure Cloud avec du code, de manière similaire au développement d’une application. Le code en question est dans notre cadre, le modèle ARM en json. Ce modèle json doit contenir la définition de l’environnement cloud cible, c’est la plateforme de déploiement (Azure) qui se charge de la complexité technique du déploiement. Ce modèle de déploiement peut être « versionné » et faire ainsi partie intégrante du « code source » du projet.

Happy coding