Depuis le 18 Décembre 2018 un nouveau module PowerShell peut être utilisé pour piloter Azure. C’est le module AZ. Il a pour but d’unifier les cmdlet PowerShell sous un même préfix et de disposer d’une version identique pour PowerShell 5.1, Azure Cloud Shell et PowerShell Core. Il remplace les modules AzureRM et AzureRM.netcore. Outre la possibilité d’utiliser un même module en Core et en Windows PowerShell, le nouveau module dispose de nouvelles fonctionnalités.
- Mise à jour toutes les deux semaines pour rester en phase avec les mises à jour d’Azure (les mises à jour commenceront à partir du 15/01/19, il faudra utiliser update-module).
- De meilleurs options d’authentification pour PowerShell core (SPN à renouvellement auto et authentification par certificat prévus)
Pour l’installer :
Install-module -Name Az
Si AzureRM est déja installé il faut utiliser
install-module -name az -AllowClobber
Attention, cela ne fonctionne qu’avec Windows PowerShell 5.1 (avec le framework .net 4.7.2) et PowerShell Core.
Attention, Le module AZ fonctionne mal avec le module AzureRM, ils utilisent les mêmes dépendances dans des versions différentes.
Pour faire face à cela il y a trois solutions possibles :
Utiliser le cmdlet uninstall-azurerm fournis par le module AZ et réécrire les scripts ce qui peut être long et non souhaitable.
Installer et utiliser PowerShell Core pour les scripts utilisant AZ et PowerShell 4/5 avec AzureRm, cependant il y a de forte chance que les scripts doivent être repris du fait des différences entre les deux versions de PowerShell.
Faire une stricte séparation des sessions qui fonctionnent avec AzureRm et celles qui fonctionnent avec le module AZ. Cela est possible, mais il devient alors nécessaire d’importer le module souhaité de façons explicite.
Import-Module -Name AzureRM.Compute
Il existe, enfin une dernière solution, activer les alias AzureRm dans le module AZ. Cela permet de continuer à utiliser les mêmes scripts. Mais comme la correspondance n’est pas parfaite et la logique applicative n’est pas la même, le risque est grand de devoir revoir tout ou partie du code.
Enable-AzureRmAlias -Scope CurrentUser
La gestion du scope est préférable des lors que la machine dispose de plusieurs profile. Attention, il est nécessaire d’avoir supprimer le module AzureRm avant d’activer les alias, faute de quoi il risque d’y avoir confusion et le résultat risque d’être catastrophique. Il est possible d’activer les alias uniquement pour certains modules.
Enable-AzureRmAlias -Scope CurrentUser -module Az.Compute, Az.Accounts
Pour désactiver les alias il suffit de taper la commande suivante
Disable-AzureRmAlias
L’un des grands changements concerne les façons d’ouvrir une connexion vers Azure. Par exemple, les connexions interactive, l’ouverture d’une page web de connexion n’est plus disponible. A la place, le module AZ utilise un token qu’il faut identifier sur https://microsoft.com/devicelogin avec un code unique. Cela autorise uniquement la session PowerShell en cours.
Pour pouvoir l’utiliser dans plusieurs session PowerShell ou apres un reboot de la machine il faut utiliser un Context. Un context permet de conserver les différentes informations d’un login (Souscription, compte, …) sur la machine locale.
Pour créer un context, apres avoir été logué par Connect-AzAccount
Set-AzContext -Subscription "Nom Souscription" -Name "Nom du Context"
Pour l’utiliser
Select-AzContext "Nom du Context"
Bien sur il faut éviter de créer un context avec l’administrateur de la souscription.
Autre possibilité, l’utilisation d’un Service Principal Name. C’est une des méthodes à privilégier. Elle permet de définir au mieux les droits nécessaires au fonctionnement du script. Dans ce cadre Connect-AzAccount prend 3 paramètres :
ApplicationID Credential TennantID Et le switch -ServicePrincipal D’autres méthodes devraient voir le jour dans le courant de l’année 2019.