O primeiro bloco do domínio de computação do AZ-104 é "automatizar a implantação de recursos usando modelos do ARM ou arquivos Bicep". Seus cinco subitens, "interpretar um modelo do ARM ou um arquivo Bicep", "modificar um modelo do ARM existente", "modificar um arquivo Bicep existente", "implantar recursos" e "exportar uma implantação como modelo do ARM ou converter um modelo do ARM em arquivo Bicep", testam se você consegue ler e editar código por conta própria. O exame real mostra parte de um modelo e pergunta coisas como "O que você adiciona para criar três contas de armazenamento?" ou "O que acontece com os recursos existentes quando esta implantação roda?".
Este artigo coloca a mesma conta de armazenamento lado a lado em ARM JSON e em Bicep e a lê linha por linha, para que administradores sem experiência em desenvolvimento consigam acompanhar um modelo. Ele cobre as seções do modelo e as funções mais comuns, loops, condições e dependências, arquivos de parâmetros e referências ao Key Vault, escopos e modos de implantação, e exportação e conversão. O que são modelos do ARM e Bicep foi apresentado primeiro em Máquinas Virtuais e Automação de Implantação.
---
Um Modelo É um Formulário com Campos Fixos
Um formulário de órgão público tem lugares fixos para os campos que o requerente preenche, os campos que o atendente calcula, o pedido em si e o comprovante que você recebe no fim. Um modelo do ARM também é um documento JSON formado por seções fixas.
| Seção | Papel | Em um formulário de papel | |------|------|------| | $schema | Versão da linguagem do modelo e escopo de implantação | Número do formulário | | contentVersion | Versão do próprio modelo | Número de revisão do documento | | parameters | Valores recebidos de fora na hora da implantação | Campos que o requerente preenche | | variables | Valores calculados dentro do modelo e reutilizados | Campos que o atendente calcula | | resources | Recursos a criar ou atualizar | O pedido em si | | outputs | Valores retornados depois da implantação | O comprovante |
Este é um modelo do ARM que cria uma conta de armazenamento.
Funções de Modelo que Você Vai Ver com Frequência
Um valor entre colchetes é uma expressão avaliada na hora da implantação.
| Função | Resultado | Uso típico | |------|------|------| | resourceGroup().location | A região do grupo de recursos de destino | Valor padrão de location | | parameters('nome') · variables('nome') | O valor de um parâmetro ou variável | Reutilizar valores | | concat() · format() | Junta cadeias de caracteres | Montar nomes | | uniqueString(resourceGroup().id) | Um hash de 13 caracteres estável por grupo de recursos | Nomes que precisam ser globalmente únicos | | resourceId('tipo', 'nome') | A ID completa de um recurso | Referenciar outros recursos, saídas | | copyIndex() | O número da iteração atual em um loop | Nomes de recursos em loop |
Dica para o exame: "Se nenhum valor for informado, implantar na mesma região do grupo de recursos" significa usar resourceGroup().location como defaultValue. "Aceitar só os SKUs aprovados" significa allowedValues.
---
Lendo a Mesma Coisa em Bicep
Bicep é uma linguagem que expressa o ARM JSON de forma mais curta e legível, e é convertida em ARM JSON na implantação. O modelo acima fica assim em Bicep.
| ARM JSON | Bicep | O que lembrar | |------|------|------| | parameters + defaultValue | param nome tipo = padrão | O valor padrão vem depois de um sinal de igual | | allowedValues · minLength | Decoradores @allowed · @minLength | Ficam acima do parâmetro | | securestring | @secure() param | Senhas e chaves devem ser parâmetros seguros | | variables | var | Sem declaração de tipo | | type + apiVersion | 'tipo@apiVersion' | Combinados em uma só cadeia | | dependsOn | Quase sempre automático (referências por nome simbólico) | Referenciar algo como stg.id cria a dependência | | copy | [for ... in ...: {...}] | Expressão de loop | | condition | if (condição) | Implantação condicional | | outputs | output | Exige declarar o tipo |
Dica para o exame: Em questões de Bicep, uma opção como "adicionar dependsOn para que a sub-rede seja referenciada depois da criação da VNet" costuma ser desnecessária. Quando você referencia um nome simbólico (por exemplo, vnet.id), o Bicep cria a dependência automaticamente.
---
Loops, Condições e Dependências: as Edições mais Comuns
As questões de edição de modelo quase sempre tratam de uma de três coisas: criar várias cópias de um recurso, decidir se algo é criado com base em uma condição e controlar a ordem de criação.
Para criar três contas de armazenamento em ARM JSON, adicione uma propriedade copy ao recurso e acrescente copyIndex() ao nome.
No Bicep, use uma expressão for.
| Requisito | ARM JSON | Bicep | |------|------|------| | N cópias do mesmo recurso | copy + count, copyIndex() | [for i in range(0, N): {...}] | | Implantar só se uma condição for verdadeira | "condition": "[equals(parameters('env'), 'prod')]" | resource ... = if (env == 'prod') {...} | | Criar a VM depois da NIC | "dependsOn": [ "[resourceId('Microsoft.Network/networkInterfaces', 'nic1')]" ] | Automático ao referenciar nic.id | | Referenciar um recurso que já existe | reference() · resourceId() | resource vnet '...' existing = { name: 'vnet1' } |
Dica para o exame: copyIndex() começa em 0. Para "nomear stg1, stg2, stg3 começando em 1", passe um valor inicial como em copyIndex(1).
---
Arquivos de Parâmetros e Valores Secretos
Quando você implanta o mesmo modelo em desenvolvimento e produção com valores diferentes, mantenha um arquivo de parâmetros separado. Valores secretos, como senhas, não vão no arquivo; eles referenciam um segredo do Key Vault.
O parâmetro do modelo precisa ser securestring (@secure() no Bicep) para que o valor não fique no histórico de implantação nem nos logs O cofre de chaves precisa permitir acesso para implantação de modelos (enabledForTemplateDeployment) para que o segredo seja lido durante a implantação O Bicep faz o mesmo com um arquivo .bicepparam que contém using './main.bicep' e linhas param nome = valor
Dica para o exame: "Não expor a senha do administrador da VM no modelo nem no arquivo de parâmetros" significa uma referência a segredo do Key Vault mais um parâmetro securestring. Se uma implantação falha com "não é possível acessar o cofre de chaves", verifique a configuração do cofre que permite a implantação de modelos.
---
Escopos e Modos de Implantação
O comando depende de onde você implanta o modelo.
| Escopo de implantação | CLI do Azure | PowerShell | |------|------|------| | Grupo de recursos | az deployment group create --resource-group rg1 --template-file main.bicep | New-AzResourceGroupDeployment | | Assinatura | az deployment sub create --location eastus --template-file main.bicep | New-AzSubscriptionDeployment | | Grupo de gerenciamento | az deployment mg create --management-group-id mg1 --location eastus | New-AzManagementGroupDeployment | | Locatário | az deployment tenant create --location eastus | New-AzTenantDeployment |
As implantações em grupo de recursos têm dois modos. Eles diferem em como tratam os recursos existentes que não estão no modelo.
!Os modos incremental e completo tratam de forma diferente os recursos que não estão no modelo
| Modo | Recursos existentes fora do modelo | Recursos no modelo | |------|------|------| | Incremental (padrão, recomendado) | Ficam como estão | São criados, ou reaplicados com os valores do modelo | | Completo (não recomendado) | São excluídos | São criados ou reaplicados |
O modo incremental também tem uma pegadinha. Ao reimplantar um recurso existente, as propriedades não são "somadas"; o recurso é reaplicado do jeito que o modelo define, então propriedades que faltam no modelo podem ser sobrescritas com valores padrão. Além disso, a Microsoft não recomenda o modo completo e planeja descontinuá-lo aos poucos; se uma implantação precisar excluir recursos, use pilhas de implantação. Executar o what-if (az deployment group what-if) antes de implantar mostra o que será criado, alterado e excluído.
Dica para o exame: Se "o RG1 contém a VM1 e o Storage1, e um modelo que define só a VNet1 é implantado em modo completo", a VM1 e o Storage1 são excluídos e só a VNet1 fica. Implantar o mesmo modelo em modo incremental mantém os três.
---
Exportação e Conversão
Quando você quer um modelo de recursos que já criou no portal, use a exportação. O resultado muda conforme o método.
| Método | Resultado | Características | |------|------|------| | Exportar modelo de um grupo de recursos ou recurso | Bicep ou ARM JSON | Um instantâneo do estado atual, com as mudanças feitas depois da implantação; muitas propriedades, poucos parâmetros | | Salvar do histórico de implantação | Só ARM JSON | O modelo exato usado na implantação, com parâmetros; só os recursos daquela implantação | | az bicep decompile --file main.json | ARM JSON → Bicep | Uma conversão de melhor esforço que pode precisar de ajustes | | az bicep build --file main.bicep | Bicep → ARM JSON | Conferir o resultado convertido antes de implantar |
Dica para o exame: "Você precisa de um modelo que inclua configurações alteradas no portal depois da implantação" significa exportar do grupo de recursos. "Você quer reutilizar o modelo e os parâmetros originais da primeira implantação" significa salvar do histórico de implantação. "Converter um modelo do ARM existente em Bicep" significa decompile.
---
Referência Rápida do Exame
Pontos-chave para revisar uma última vez antes do exame.
| Tema | O que lembrar | |------|------| | Seções do modelo | $schema · contentVersion · parameters · variables · resources · outputs | | Região padrão | resourceGroup().location | | Nomes únicos | uniqueString(resourceGroup().id) | | Limites de entrada | allowedValues · minLength (@allowed · @minLength no Bicep) | | Valores secretos | securestring · @secure() + referência ao Key Va