← AZ-104: administração Azure em produção
13 / 17 · 40 MIN

Templates, módulos e estado pretendido

Revê mudanças declarativas, análise incompleta e concorrência entre deployments.

Recursos e propriedades

Num deployment incremental, recursos existentes omitidos do template permanecem. A regra não significa que propriedades omitidas num recurso declarado sejam preservadas. Declara o estado pretendido completo desse recurso, incluindo valores não predefinidos.

Dividir propriedades entre definições parciais concorrentes não cria automaticamente um merge seguro. Compara a configuração publicada com a que a aplicação precisa, antes de aceitar a alteração como pequena ou inofensiva.

Interpretar what-if

Compilação verifica a definição; what-if compara alterações previstas no ambiente. Nenhum dos dois prova por si o resultado funcional da aplicação. Uma expressão não resolvida pode impedir a análise de um recurso ou módulo.

Nesse caso, a ausência de diferenças apresentadas não é evidência de igualdade. Regista o âmbito efetivamente comparado e resolve a dependência que impediu a análise. Filtrar a saída não retira o recurso do deployment real.

Identidade de execução

Um módulo Bicep representa um deployment aninhado. Se duas execuções concorrentes usam o mesmo name fixo no mesmo âmbito, podem interferir nos outputs observados. O nome simbólico usado no ficheiro não é o mesmo que a identidade do deployment remoto.

Usa nomes de execução distintos ou o mecanismo de nomes gerados, e mantém identidade estável dos recursos quando isso é o pretendido. Isolar a execução não exige duplicar indiscriminadamente a infraestrutura.

Migração e exercício de revisão

Mudar location num template não transporta uma VM existente para outra região. Planeia recursos alvo, dados, rede, dependências e transição. No exercício, um pipeline publica um template com propriedades em falta, um módulo não analisado e um nome partilhado.

Produz três decisões independentes: completar o estado declarado, recuperar a comparação omitida e evitar colisão de execução. Só depois avalia a aceitação funcional e a recuperação, de acordo com o risco da mudança.

NA PRÁTICA

Duas equipas recebem outputs de storage trocados entre deployments concorrentes. Regista o âmbito e name de cada deployment; corrige a identidade da execução antes de usar os outputs para autorizar publicação.

Armadilhas comuns

Evita tratar incremental como patch de propriedades, resultado omitido como comparação bem-sucedida e name do módulo como mero comentário.

Tópicos relacionados: Máquinas, discos e capacidade efetiva · Containers: repetição, revisões e promoção

Leva esta ideia contigo

A revisão deve ligar definição, estado remoto e identidade da execução a critérios de aceitação.

Criar conta

Referências

Azure é uma marca comercial do grupo de empresas Microsoft. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por Microsoft. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.