← tutti gli articoli

Azure

Usare Azure Cloud Shell e la az CLI per la prima volta

Un terminale nel browser, già autenticato, con il tooling installato. Non appena ho visto il pattern dietro i comandi az, il portale ha iniziato a sembrare più lento che digitare.

Avevo fatto tutto nel portale Azure cliccandoci in giro, il che funziona bene finché non devi fare la stessa cosa due volte. Studiare per l'AZ-900 mi ha spinto verso Cloud Shell e la CLI, e la parte che mi ha sorpreso è stata quanto poco setup ci volesse.

Cloud Shell è un terminale già loggato

Cloud Shell gira nel browser, da dentro il portale. Non c'è niente da installare, e si apre già autenticato come l'account con cui ho fatto l'accesso, con il tooling Azure già lì.

Quest'ultima parte è ciò che ha fatto click per me. Configurare una CLI localmente di solito significa installarla, poi autenticarsi, poi capire a quale subscription è puntata. Cloud Shell salta tutto questo, il che lo rende un modo genuinamente a basso attrito per provare comandi quando stai imparando e non vuoi che il setup sia l'ostacolo.

Offre sia Bash che PowerShell. Uso Bash perché è quello a cui sono abituato su macOS.

C'è una trappola che vale la pena conoscere: Cloud Shell ha bisogno di storage per qualsiasi cosa tu voglia far persistere, quindi chiede di creare uno storage account la prima volta. I file nella tua home directory sopravvivono tra una session e l'altra per questo motivo. Qualsiasi cosa al di fuori non sopravvive, dato che la macchina stessa è temporanea e viene riciclata.

I comandi az seguono un pattern

Questa è la cosa che ha trasformato la CLI da intimidatoria a imparabile. Quasi ogni comando ha la stessa forma:

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

Non appena l'ho notato, ho smesso di provare a memorizzare i comandi e ho iniziato a indovinarli, di solito correttamente:

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

Gli stessi verbi tornano ovunque. create, list, show, delete, update. Quindi se so come elencare i resource group, posso indovinare come elencare le web app:

az webapp list
az vm list
az storage account list

Funzionano tutti, perché è lo stesso pattern con un sostantivo diverso.

I comandi su cui mi sono davvero appoggiato

Quando non conoscevo un comando, il flag di help era più veloce che cercare la documentazione:

az vm --help
az vm create --help

Questo elenca i sottocomandi e ogni opzione, nel terminale, per la versione esatta che sto usando.

Altri due che sono stati immediatamente utili:

# in quale subscription sto davvero lavorando?
az account show

# JSON grezzo, o solo i campi che voglio
az group list --output table

--output table è quello a cui non mi aspettavo di dare importanza. L'output di default è JSON, che è il default giusto per lo scripting e difficile da leggere quando vuoi solo vedere cosa esiste. --output table lo trasforma in una lista leggibile.

Perché questo conta oltre il superare un esame

Il portale va bene per guardare le cose e per modifiche una tantum. Quello che non può fare è darmi una registrazione di cosa ho fatto.

Un comando è ripetibile. Posso incollarlo in un documento, salvarlo nel README di un progetto, o eventualmente metterlo in uno script che configura un ambiente allo stesso modo ogni volta. Cliccare attraverso undici schermate del portale produce lo stesso risultato e non lascia niente dietro che chiunque, incluso io stesso tra un mese, possa seguire.

Questo è il vero cambiamento. Non che la CLI sia più veloce, anche se per lavoro ripetuto lo è, ma che un comando è qualcosa che puoi conservare e un click no.

Dove andrei dopo

Il passo successivo ovvio è l'infrastructure as code vera e propria, dove le resource sono dichiarate in un file invece che create da comandi che eseguo in ordine. La CLI è ancora la versione imperativa dell'idea, dato che sto dicendo ad Azure cosa fare passo dopo passo. Ma imparare prima la CLI ha reso ovvio il motivo di quel passo successivo, cosa che non era quando tutto quello che avevo usato era il portale.