Pré-voo: Validação do servidor antes da implementação

No Azure Resource Manager (ARM), a validação do lado do servidor consiste em duas partes distintas:

• Validação estática, que é a operação com que os desenvolvedores interagem.
• Validação pré-voo do fornecedor de recursos, que é a fase interna de validação do fornecedor de recursos.

A validação estática verifica aspetos do template que o ARM pode avaliar sem chamar fornecedores de recursos, tais como:

• Estrutura do modelo e correção do esquema
• Definições de parâmetros e restrições básicas de valores
• Avaliação de expressões e consistência do modelo

Estas verificações garantem que o modelo é sintático e estruturalmente válido antes de ocorrer uma validação mais profunda.

A validação pré-voo é um processo interno do Azure Resource Manager (ARM) executado durante a fase de validação. O seu objetivo é acelerar a deteção de erros, prevenindo implementações conhecidas por falharem. Durante esta etapa, o ARM invoca os fornecedores de recursos relevantes para verificar se a implementação é viável, sem criar ou modificar quaisquer recursos. Esta parte valida:

• Conflitos de nomes de recursos: Durante o pré-voo, o ARM avalia os nomes finais de recursos resolvidos e verifica se violam as regras de unicidade ou de nomeação impostas pelo fornecedor. Esta verificação acontece depois de expressões como concat() ou uniqueString() serem resolvidas. A validação pré-voo falha frequentemente quando:

  • Um nome globalmente único (por exemplo, um nome de conta de armazenamento) já é adotado
  • Um nome de recurso viola restrições de nomenclatura específicas de cada fornecedor

• Correção do âmbito: A validação pré-voo assegura que os recursos estão a ser implementados para um âmbito válido e que o comando de implementação corresponde aos tipos de recursos declarados no modelo. Esta validação inclui:

  • Se o âmbito de implementação (grupo de recursos, subscrição, grupo de gestão, inquilino) é compatível com os tipos de recursos
  • Se existem parâmetros parentais obrigatórios. Por exemplo, implementar um recurso destinado a um grupo de recursos, mas a um nível de subscrição sem um grupo de recursos.

• Permissões RBAC (se pode implementar esses tipos de recursos): Durante o pré-voo, o ARM verifica se o chamador tem permissões suficientes no âmbito de implementação para criar ou modificar os recursos solicitados. Se a identidade não tiver permissões, a implementação é rejeitada antes da execução. Falhas típicas de permissões pré-voo incluem:

  • Falta de permissões de escrita para um tipo de recurso
  • Permissões insuficientes no âmbito alvo
  • Fornecedores de recursos obrigatórios não registados

• Compatibilidade básica do fornecedor e da API: A validação pré-voo confirma que:

  • Os fornecedores de recursos referenciados estão registados
  • As versões especificadas da API são válidas e suportadas
  • O tipo de recurso é reconhecido pelo Azure Resource Manager

  Se um fornecedor não estiver registado ou a versão da API for inválida, o ARM falha a implementação durante o pré-voo.

Se alguma destas verificações falhar, a implementação nunca começa.

Limitações

A validação pré-implementação é um processo de máxima capacidade e não identifica todos os erros durante a implementação. Não consegue detetar falhas em tempo de execução (por exemplo, erros dentro de uma extensão de script personalizada durante a execução), e a sua validação pode ser incompleta quando recursos dependem de valores ainda não disponíveis, como propriedades geradas dinamicamente a partir de outros recursos.

Permissões RBAC herdadas por meio de grupos de gestão

Quando a pré-validação é executada para recursos ao nível do tenant ou do grupo de gestão, o Azure Resource Manager avalia as permissões ao nível do pedido de validação. Em alguns casos, o ARM não resolve toda a cadeia ancestral do grupo de gestão durante esta avaliação. Como resultado, atribuições de funções RBAC herdadas pela hierarquia do grupo de gestão podem não ser reconhecidas durante o pré-voo, mesmo que essas mesmas permissões sejam respeitadas durante a implementação propriamente dita.

Este comportamento pode causar a falha do pré-voo com um erro de autorização (HTTP 401 ou 403) para identidades que têm permissões suficientes através da herança do grupo de gestão. A implementação efetiva do mesmo template teria sucesso porque o pipeline padrão de criação de recursos avalia totalmente as permissões herdadas.

Solução alternativa: Atribuir o papel necessário (por exemplo, Contribuidor ou Proprietário) diretamente no âmbito da subscrição ou do grupo de recursos, em vez de depender apenas das permissões herdadas do grupo de gestão. Em alternativa, use a opção --validation-level Template (CLI do Azure 2.76.0+) ou -ValidationLevel Template (Azure PowerShell 13.4.0+) com os comandos what-if e validate para ignorar as verificações prévias de permissões.

Executar verificação prévia

A validação pré-voo corre automaticamente quando se usam comandos do tipo deployment validate ou what-if. Por exemplo, estas operações executam a validação pré-voo:

• Validação ARM JSON ou Bicep em CLI do Azure ou PowerShell

  • CLI do Azure
  • PowerShell

  az deployment group validate \
    --resource-group myResourceGroup \
    --template-file main.bicep
  

• Azure portal Review + create step

  Atualmente, o portal Azure apenas suporta a implementação de templates ARM JSON. Para mais informações, consulte Implementar modelos ARM com o Portal do Azure.

• Teste de hipóteses

  What-If inclui verificações prévias antes de calcular as alterações, a menos que seja configurado para ignorar esta etapa. Para mais informações, consulte Executar a operação de simulação "e se".

Os erros pré-voo aparecem no registo de atividade, mas não no histórico de implementação, porque a implementação nunca começou.

Passos seguintes

• Para usar a operação 'e se', consulte Bicep What-If: Pré-visualizar Alterações Antes da Implementação.