← tous les articles

Azure

Utiliser Azure Cloud Shell et la az CLI pour la première fois

Un terminal dans le navigateur, déjà authentifié, avec le tooling installé. Dès que j'ai vu le pattern derrière les commandes az, le portail a commencé à sembler plus lent que de taper.

Je faisais tout dans le portail Azure en cliquant à travers, ce qui marche bien jusqu'à ce qu'il faille refaire la même chose deux fois. Étudier pour l'AZ-900 m'a poussé vers Cloud Shell et la CLI, et ce qui m'a surpris, c'est le peu de setup que ça demandait.

Cloud Shell est un terminal déjà connecté

Cloud Shell tourne dans le navigateur, depuis l'intérieur du portail. Il n'y a rien à installer, et il démarre déjà authentifié en tant que compte avec lequel je suis connecté, avec le tooling Azure déjà là.

Cette dernière partie, c'est ce qui a fait tilt pour moi. Configurer une CLI localement veut normalement dire l'installer, puis s'authentifier, puis comprendre vers quelle subscription elle pointe. Cloud Shell saute tout ça, ce qui en fait une façon vraiment peu contraignante d'essayer des commandes quand on apprend et qu'on ne veut pas que le setup soit l'obstacle.

Il propose à la fois Bash et PowerShell. J'utilise Bash parce que c'est ce à quoi je suis habitué sur macOS.

Il y a un piège qui mérite d'être connu : Cloud Shell a besoin de storage pour tout ce que vous voulez faire persister, donc il demande de créer un storage account la première fois. Les fichiers dans votre home directory survivent entre les sessions grâce à ça. Tout ce qui est en dehors ne survit pas, puisque la machine elle-même est temporaire et se fait recycler.

Les commandes az suivent un seul pattern

C'est ce qui a transformé la CLI d'intimidante à apprenable. Presque chaque commande a la même forme :

az <group> <subgroup> <action> --options

Une fois que j'ai remarqué ça, j'ai arrêté d'essayer de mémoriser les commandes et j'ai commencé à les deviner, généralement correctement :

az group create --name my-resources --location eastus2
az group list
az group delete --name my-resources

Les mêmes verbes reviennent partout. create, list, show, delete, update. Donc si je sais lister des resource groups, je peux deviner comment lister des web apps :

az webapp list
az vm list
az storage account list

Elles marchent toutes, parce que c'est le même pattern avec un nom différent.

Les commandes sur lesquelles je me suis vraiment appuyé

Quand je ne connaissais pas une commande, le flag d'aide était plus rapide que de chercher la documentation :

az vm --help
az vm create --help

Ça liste les sous-commandes et toutes les options, dans le terminal, pour la version exacte que je fais tourner.

Deux autres qui ont été immédiatement utiles :

# dans quelle subscription est-ce que je travaille vraiment ?
az account show

# du JSON brut, ou juste les champs que je veux
az group list --output table

--output table est celle à laquelle je ne m'attendais pas à tenir. L'output par défaut est du JSON, ce qui est le bon défaut pour le scripting et difficile à lire quand vous voulez juste voir ce qui existe. --output table en fait une liste lisible.

Pourquoi ça compte au-delà de réussir un examen

Le portail convient pour regarder des choses et pour des changements ponctuels. Ce qu'il ne peut pas faire, c'est me donner une trace de ce que j'ai fait.

Une commande est reproductible. Je peux la coller dans un document, la sauvegarder dans le README d'un projet, ou éventuellement la mettre dans un script qui configure un environnement de la même façon à chaque fois. Cliquer à travers onze écrans du portail produit le même résultat et ne laisse rien derrière que qui que ce soit, moi y compris le mois prochain, puisse suivre.

C'est le vrai changement. Pas que la CLI soit plus rapide, même si pour du travail répété elle l'est, mais qu'une commande est quelque chose qu'on peut garder et un clic non.

Où j'irais ensuite

L'étape suivante évidente, c'est l'infrastructure as code proprement dite, où les resources sont déclarées dans un fichier plutôt que créées par des commandes que j'exécute dans l'ordre. La CLI reste la version impérative de l'idée, puisque je dis à Azure quoi faire étape par étape. Mais apprendre la CLI en premier a rendu évidente la raison de cette étape suivante, ce qui n'était pas le cas quand tout ce que j'avais utilisé était le portail.