Usando o Azure Cloud Shell e a az CLI pela primeira vez

Eu tinha feito tudo no portal do Azure clicando em tudo, o que funciona bem até você precisar fazer a mesma coisa duas vezes. Estudar para o AZ-900 me empurrou para o Cloud Shell e a CLI, e a parte que me surpreendeu foi quão pouco setup isso exigiu.

Cloud Shell é um terminal que já está logado

O Cloud Shell roda no navegador, de dentro do portal. Não tem nada para instalar, e ele já sobe autenticado como a conta com a qual estou logado, com o tooling do Azure já lá.

Essa última parte foi o que fez sentido para mim. Configurar uma CLI localmente normalmente significa instalar ela, depois autenticar, depois descobrir para qual subscription ela está apontada. O Cloud Shell pula tudo isso, o que torna ele uma forma genuinamente de baixo atrito de experimentar comandos quando você está aprendendo e não quer que o setup seja o obstáculo.

Ele oferece tanto Bash quanto PowerShell. Uso Bash porque é o que estou acostumado no macOS.

Tem uma pegadinha que vale a pena saber: o Cloud Shell precisa de storage para qualquer coisa que você queira persistir, então ele pede para criar uma storage account na primeira vez. Arquivos no seu diretório home sobrevivem entre sessions por causa disso. Qualquer coisa fora dele não sobrevive, já que a própria máquina é temporária e é reciclada.

Os comandos az seguem um padrão

Essa é a coisa que transformou a CLI de intimidante em aprendível. Quase todo comando tem o mesmo formato:

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

Assim que notei isso, parei de tentar decorar comandos e comecei a chutá-los, geralmente corretamente:

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

Os mesmos verbos voltam em todo lugar. create, list, show, delete, update. Então se eu sei como listar resource groups, consigo chutar como listar web apps:

az webapp list
az vm list
az storage account list

Todos funcionam, porque é o mesmo padrão com um substantivo diferente.

Os comandos com os quais eu de fato me apoiei

Quando eu não sabia um comando, a flag de help era mais rápida do que procurar documentação:

az vm --help
az vm create --help

Isso lista os subcomandos e cada opção, no terminal, para a versão exata que estou rodando.

Mais dois que foram imediatamente úteis:

# em qual subscription eu de fato estou trabalhando?
az account show

# JSON cru, ou só os campos que eu quero
az group list --output table

--output table foi o que eu não esperava que fosse importar. O output padrão é JSON, que é o default certo para scripting e difícil de ler quando você só quer ver o que existe. --output table transforma isso numa lista legível.

Por que isso importa além de passar num exame

O portal é bom para olhar as coisas e para mudanças pontuais. O que ele não consegue fazer é me dar um registro do que eu fiz.

Um comando é repetível. Posso colar ele num documento, salvar no README de um projeto, ou eventualmente colocar num script que configura um ambiente do mesmo jeito toda vez. Clicar em onze telas do portal produz o mesmo resultado e não deixa nada para trás que qualquer um, incluindo eu mesmo no mês que vem, consiga seguir.

Essa é a mudança de verdade. Não que a CLI seja mais rápida, embora para trabalho repetido ela seja, mas que um comando é algo que você consegue guardar e um clique não é.

Para onde eu iria a seguir

O próximo passo óbvio é infrastructure as code de verdade, onde os resources são declarados num arquivo em vez de criados por comandos que eu rodo em ordem. A CLI ainda é a versão imperativa da ideia, já que estou dizendo ao Azure o que fazer passo a passo. Mas aprender a CLI primeiro tornou óbvio o motivo desse próximo passo, o que não era o caso quando tudo que eu tinha usado era o portal.