Modelos do ARM: estrutura JSON, parâmetros, saídas e implantação
Infraestrutura como código, orquestração do Azure Resource Manager, seções JSON, provedores, implantações locais e vinculadas, parâmetros seguros, saídas, idempotência e exercício guiado com conta de armazenamento.
Tempo de estudo sugerido: 35 minutos • Nível intermediário • Reescrita autoral baseada no módulo fornecido do Microsoft Learn
Por João Ricardo Dutra••Conteúdo autoral completo
1. Introdução, cenário e objetivos de aprendizagem
Os modelos do , normalmente chamados de modelos do , descrevem infraestrutura e configuração do em arquivos reutilizáveis. O modelo pode permanecer no mesmo repositório de código-fonte do aplicativo, permitindo revisar, versionar e publicar as mudanças de infraestrutura junto com o software.
Considere uma equipe que desenvolve uma plataforma de estoque para várias empresas parceiras. Cada parceira precisa de uma implantação independente no , e as políticas de armazenamento podem variar. Instruções manuais diferentes fariam os ambientes se afastarem ao longo do tempo. Um modelo do versionado fornece uma base consistente, enquanto os parâmetros mantêm a flexibilidade de cada implantação.
Objetivos de aprendizagem
Implementar um modelo do em com o .
Explicar infraestrutura como código declarativa e a estrutura de um modelo do .
Implantar um modelo local usando a CLI do ou o .
Declarar recursos por meio de provedores, tipos, versões de e propriedades.
Tornar o modelo reutilizável com parâmetros, restrições de validação e saídas.
Executar o exercício da conta de armazenamento, examinar o histórico e interpretar a validação.
Pré-requisitos
Familiaridade com o , incluindo o , assinaturas, grupos de recursos e definições de recursos.
Uma conta do com permissão para criar os recursos do exercício.
instalado localmente.
A versão mais recente da CLI do ou do instalada localmente.
A Microsoft recomenda o para quem está começando com infraestrutura como código no , pois ele oferece as capacidades dos modelos do com uma experiência de autoria mais concisa. Este capítulo ainda estuda porque conhecer a estrutura gerada continua importante para administração e diagnóstico na AZ-104.
A infraestrutura como código mantém aplicativo e ambiente versionados juntos; o mesmo modelo cria implantações consistentes de desenvolvimento, teste e produção.
2. Infraestrutura como código e modelos declarativos
Infraestrutura como código, ou IaC, representa em código a infraestrutura necessária ao aplicativo, em vez de depender de uma sequência de ações manuais no portal. Arquivos do aplicativo e definições de implantação podem compartilhar repositório, revisão e histórico de versões.
Vantagens destacadas pelo módulo fornecido.
Vantagem
Efeito operacional
Configurações consistentes
A mesma definição revisada cria ou atualiza cada ambiente.
Melhor escalabilidade
A automação repete a implantação sem reconstruir o procedimento para cada parceira.
Implantações mais rápidas
O Resource Manager organiza dependências e cria recursos independentes em paralelo.
Melhor rastreabilidade
O código-fonte e o histórico do mostram a definição e os valores utilizados.
Um modelo do é um arquivo , sigla de JavaScript Object Notation. Sua sintaxe é declarativa: ela informa quais recursos e propriedades devem existir, sem prescrever todo o fluxo de controle para criá-los. Um script imperativo, por outro lado, concentra-se na sequência de comandos que o computador executará.
O converte o estado desejado em operações de implantação. Assim, o autor se concentra no resultado e a plataforma cuida de validação, dependências, ordem e paralelismo quando possível.
3. Por que os modelos do são repetíveis
: o modelo faz parte do projeto de infraestrutura e desenvolvimento, não de uma lista externa de passos.
Controle de versão: os arquivos podem ser armazenados, comparados, revisados e marcados como o código do aplicativo.
Idempotência: repetir a mesma definição com as mesmas entradas mantém os recursos no estado desejado, sem duplicá-los.
Orquestração de dependências: o Resource Manager respeita a ordem necessária e executa trabalho independente em paralelo.
Validação anterior à implantação: verificações estruturais e operacionais podem falhar antes da criação dos recursos.
Modularidade: soluções grandes podem usar modelos vinculados menores ou aninhar modelos.
Auditoria: o apresenta estado, modelo, parâmetros e saídas da implantação.
Integração de CI/CD: , GitHub Actions e fluxos do podem publicar aplicativo e infraestrutura juntos.
Um modelo vinculado fica separado e é chamado por um modelo principal. Quando o arquivo privado está no , uma assinatura de acesso compartilhado, ou SAS, pode protegê-lo. Implantar o modelo principal dispara as implantações vinculadas.
O Resource Manager valida a declaração, resolve dependências, aciona provedores de recursos e registra o resultado no histórico.
4. Estrutura do arquivo de modelo do
Um modelo do em é organizado em seções de nível superior. Algumas são obrigatórias em um modelo comum com escopo de grupo de recursos; outras aparecem somente quando a solução precisa delas.
Seções representadas no material fornecido.
Elemento
Obrigatório?
Finalidade
$
Sim
do esquema que descreve a estrutura. O valor depende do escopo da implantação e do editor.
contentVersion
Sim
Versão atribuída pelo autor, como 1.0.0.0, para documentar alterações importantes.
apiProfile
Não
Coleção de versões de que pode evitar uma versão individual em cada tipo compatível.
parameters
Não
Valores fornecidos na implantação por arquivo de parâmetros, linha de comando ou .
variables
Não
Valores reutilizáveis que simplificam expressões da linguagem do modelo.
functions
Não
Funções definidas pelo usuário para substituir expressões repetidas ou complexas.
resources
Sim
Recursos que serão criados ou atualizados no grupo de recursos, assinatura ou outro escopo.
outputs
Não
Valores devolvidos após a implantação. A tabela exportada usa output, mas a propriedade real é outputs.
O contentVersion pertence ao autor; o não o incrementa automaticamente. As versões de dos recursos são outra coisa: cada declaração escolhe o contrato exposto pelo provedor correspondente.
A estrutura separa entradas, expressões reutilizáveis, declarações de recursos e valores devolvidos.
5. Formas de implantar um modelo no
O módulo apresenta três caminhos: modelo local, modelo vinculado e de implantação contínua. A prática se concentra no arquivo local, que exige a CLI do ou o na estação.
Preparar o grupo de recursos com a CLI do
az login
az account list-locations --output table
az group create --name rg-contoso-estoque --location eastus
A CLI do pode manter uma região padrão com az configure --defaults location=<local>. O lista regiões por -AzLocation. Depois que o grupo existe, use o comando atual para o escopo de grupo:
templateFile="azuredeploy.json"
az deployment group create --name armazenamento-estoque-v1 --resource-group rg-contoso-estoque --template-file $templateFile
A forma antiga az group create está obsoleta; use az group create. No , o cmdlet equivalente é New-AzResourceGroupDeployment.
Modelos vinculados dividem a solução entre um modelo principal e modelos filhos reutilizáveis; um SAS pode proteger arquivos privados. Para entregas automatizadas, e GitHub Actions incluem validação e implantação do modelo no fluxo do aplicativo.
Use nomes de implantação descritivos, pois cada execução gera uma entrada no histórico. As ferramentas precisam do grupo de recursos de destino; determinados escopos e comandos também exigem região. O portal apresenta estado, parâmetros enviados e saídas.
O modelo pode começar na estação, em um endereço protegido ou no ; o Resource Manager continua sendo o mecanismo de implantação.
6. Declarar recursos com provedores, tipos e propriedades
Cada tipo de recurso do pertence a um provedor. O modelo combina o e o tipo no formato provedor/tipo. Para uma conta de armazenamento, Microsoft. e storageAccounts formam Microsoft./storageAccounts.
Depois de escolher o tipo, consulte a referência de modelos do para saber quais propriedades a versão de aceita. A referência é organizada por provedor, tipo e versão. Uma declaração costuma trazer type, apiVersion, name, location e valores específicos como sku, kind e properties.
Fixar nome, região e SKU facilita a leitura inicial, mas dificulta a reutilização. Parâmetros e funções removem essas suposições fixas.
7. Parâmetros, restrições e proteção de segredos
A seção parameters define entradas resolvidas antes das operações de implantação. Valores diferentes permitem que o mesmo modelo atenda desenvolvimento, teste, produção ou parceiras distintas. Um modelo aceita até 256 parâmetros, e a definição pode usar a maioria das funções do modelo.
Propriedades de parâmetro cobertas pelo material.
Propriedade
Finalidade
type
Tipo de dado obrigatório para a entrada.
defaultValue
Valor usado quando a implantação não fornece outro.
allowedValues
Lista explícita de valores aceitos.
minValue / maxValue
Limites numéricos inclusivos para inteiros.
minLength / maxLength
Limites inclusivos de tamanho para cadeias de caracteres ou matrizes.
.description
Orientação legível apresentada aos usuários do modelo.
Os tipos clássicos mostrados são string, secureString, int, bool, object, secureObject e array. Use parâmetros para SKU, capacidade, tamanho, região e nomes sujeitos a convenções. Forneça descrições claras e padrões seguros quando fizer sentido.
Nunca fixe nomes de usuário, senhas ou segredos, nem dê valores padrão a eles. Senhas e cadeias secretas usam secureString; objetos sensíveis usam secureObject. Esses valores não ficam no histórico nem nos . Para reutilizar segredos, armazene-os no e faça a referência por arquivo de parâmetros.
8. Usar parâmetros no modelo da conta de armazenamento
A função parameters acessa uma entrada. O nome e a marca displayName podem usar storageName, a SKU usa storageSku e resourceGroup().location mantém o recurso na região do grupo de destino.
Os valores podem vir da linha de comando, de um arquivo de parâmetros ou do . A CLI do pode substituir a SKU padrão:
az deployment group create --name armazenamento-estoque-teste --resource-group rg-contoso-estoque --template-file azuredeploy.json --parameters storageName=contosoestoque001 storageSku=Standard_GRS
Um valor padrão reduz repetição quando há uma escolha comum; allowedValues impede que o usuário envie opções que o recurso não deve aceitar.
Parâmetros separam entradas do ambiente da definição reutilizável; saídas expõem informações para etapas posteriores.
9. Saídas e reimplantação segura
A seção outputs devolve valores depois de uma implantação bem-sucedida. Ela é útil quando outra etapa, script ou configuração precisa de informações do recurso recém-criado.
Elementos de uma saída.
Elemento
Obrigatório?
Significado
output-name
Sim
Identificador JavaScript válido usado para endereçar a saída.
type
Sim
Tipo de dado do valor devolvido.
condition
Não
Expressão booleana que decide se a saída será retornada; o padrão é true.
value
Não
Expressão da linguagem do modelo avaliada e devolvida.
copy
Não
Definição de iteração para devolver vários valores.
A função reference lê o estado da conta durante a execução e devolve pontos de extremidade primários, como blob, arquivo, fila, tabela, DFS e web quando aplicáveis. O limite atual é de 64 saídas por modelo.
A idempotência torna a repetição segura: sem mudança no modelo ou nas entradas, os recursos permanecem iguais. Se uma propriedade ou parâmetro mudar, o Resource Manager aplica a atualização necessária. Um recurso só é criado quando ainda não existe no estado de destino.
10. Exercício guiado: parâmetros, validação e saídas
O exercício evolui o arquivo azuredeploy. em etapas observáveis. No , Alt+Shift+F formata o ; salve após cada edição e use o IntelliSense para reduzir erros.
Etapa 1 - Parametrizar o nome
Adicione storageName como string com minLength 3, maxLength 24 e descrição.
Use o parâmetro no nome do recurso e na marca displayName.
Escolha um nome globalmente exclusivo. A regra atual permite somente letras minúsculas e números; o PDF menciona hífens, mas essa parte está desatualizada.
Reutilize o nome válido para atualizar a conta existente, em vez de criar outra.
Adicione storageSku com padrão Standard_LRS e os oito valores do exercício: Standard_LRS, Standard_GRS, Standard_RAGRS, Standard_ZRS, Premium_LRS, Premium_ZRS, Standard_GZRS e Standard_RAGZRS. Modelos do aceitam comentários // e /* ... */, portanto a razão da lista pode ser registrada no próprio arquivo.
Essa execução usa um valor permitido e termina com sucesso. Repita com -storageSku "Basic" para observar allowedValues rejeitar a entrada durante a validação.
Etapa 3 - Devolver e examinar os pontos de extremidade
Adicione storageEndpoints a outputs com reference(parameters('storageName')).primaryEndpoints. Implante novamente com uma SKU permitida. O imprime o objeto e o também o mostra na implantação.
Abra o grupo de recursos e selecione o link de implantações bem-sucedidas.
Compare as entradas do modelo base, do parâmetro de nome, da validação de SKU e das saídas.
Abra a implantação de saídas e analise Entradas, Saídas e detalhes do modelo.
Confirme que o devolvido contém os pontos de extremidade expostos pela conta.
Uma SKU válida funciona, uma inválida falha na validação, as saídas revelam os pontos de extremidade e repetir sem mudanças preserva o recurso.
11. Verificação de conhecimento comentada
Avaliação reescrita a partir do módulo.
Pergunta
Melhor resposta
Justificativa
O que é um modelo do ?
Um arquivo que define infraestrutura e configuração de uma implantação.
Ele é uma definição declarativa, não uma sequência da CLI nem um script exclusivo para armazenamento.
Qual opção não é um elemento do modelo: idempotent, ou parameters?
idempotent
Idempotência é um comportamento da implantação; e parameters são seções.
O que acontece ao repetir sem mudanças um modelo idempotente?
O Resource Manager não altera os recursos que já correspondem ao estado desejado.
Ele não cria cópias nem apaga e recria recursos sem uma alteração declarada.
12. Resumo do capítulo
Modelos do representam infraestrutura declarativa, reutilizável e versionável.
O Resource Manager valida, resolve dependências, aciona provedores e registra o histórico.
A estrutura separa esquema, versão, parâmetros, variáveis, funções, recursos e saídas.
Modelos locais usam CLI do ou ; modelos vinculados e atendem cenários modulares ou automatizados.
Parâmetros validam valores de cada ambiente e tipos seguros protegem segredos.
Saídas devolvem informações de execução e a idempotência permite repetir o estado desejado.
O exercício parametriza uma conta, restringe a SKU, testa um valor inválido e devolve os pontos de extremidade.
