Crie e implemente pilhas de implementação do Azure em Bicep

Uma pilha de implementação do Azure é um recurso que permite gerir um grupo de recursos do Azure como uma unidade única e coesa. Ao enviar um arquivo Bicep ou um modelo JSON do Azure Resource Manager (modelo JSON ARM) para uma pilha de implantação, você define os recursos que a pilha gerencia. Se você remover um recurso do modelo, ele poderá ser desanexado ou excluído com base no comportamento actionOnUnmanage especificado da pilha de implantação. Você pode restringir o acesso à pilha de implementação usando o controlo de acesso baseado em papéis do Azure (Azure RBAC), de forma semelhante a outros recursos do Microsoft Azure.

Para criar e atualizar um conjunto de implementação, use a CLI do Azure, o Azure PowerShell ou o portal do Azure com arquivos Bicep. A pilha transpila esses arquivos Bicep em modelos JSON ARM e implementa-os como um objeto de implementação. A pilha de implantação oferece recursos adicionais além dos recursos de implantação familiares e é um superconjunto desses recursos.

Microsoft.Resources/deploymentStacks é o tipo de recurso para stacks de implementação. Consiste em um modelo principal que pode executar atualizações um-para-muitos entre diferentes escopos para os recursos que descreve e impedir alterações indesejadas nesses recursos.

Ao planejar sua implantação e determinar quais grupos de recursos devem fazer parte da mesma pilha, considere o ciclo de vida de gerenciamento desses recursos, que inclui criação, atualização e exclusão. Por exemplo, talvez seja necessário provisionar algumas máquinas virtuais de teste para várias equipes de aplicativos em diferentes escopos de grupo de recursos. Você pode usar uma pilha de implantação para criar esses ambientes de teste e atualizar as configurações da máquina virtual de teste por meio de atualizações subsequentes para a pilha de implantação. Depois de concluir o projeto, talvez seja necessário remover ou excluir quaisquer recursos criados, como as máquinas virtuais de teste. Utilize uma pilha de implementação e especifique o indicador de eliminação apropriado para remover recursos geridos. Essa abordagem simplificada economiza tempo durante a limpeza do ambiente, pois envolve uma única atualização do recurso da pilha, em vez de modificar ou remover individualmente cada máquina virtual de teste em vários âmbitos de grupo de recursos.

As pilhas de implantação exigem o Azure PowerShell versão 12.0.0 ou posterior ou CLI do Azure versão 2.61.0 ou posterior.

Para criar a sua primeira pilha de implantação, siga o Início rápido: criar pilha de implantação.

Por que usar conjuntos de implantação?

As pilhas de implementação oferecem os seguintes benefícios:

Provisionamento e gerenciamento simplificados de recursos em diferentes escopos como uma entidade unificada.
Prevenção de modificações indesejadas nos recursos gerenciados por meio de configurações de negação.
Limpeza eficiente do ambiente usando marcadores de eliminação durante as atualizações do stack de implementação.
Utilização de modelos padrão, como Bicep, modelos ARM, ou especificações de modelos para as suas pilhas de implementação.

Limitações conhecidas

Há um limite de 800 pilhas de implantação que podem ser criadas dentro de um único escopo.
Um máximo de 2.000 Atribuições Negadas podem existir num dado escopo.
A pilha de implantação não gerencia recursos criados implicitamente. Portanto, você não pode usar atribuições de negação ou limpeza para esses recursos.
Atribuições de negação não suportam etiquetas.
As negativas de atribuições não são suportadas no escopo do grupo de gestão. No entanto, eles são suportados numa pilha de grupos de gestão se a implementação for direcionada para o âmbito da assinatura.
As pilhas de implementação não podem eliminar segredos do Cofre de Chaves. Se estiver a remover segredos do Key Vault de um modelo, certifique-se de executar também o comando update/delete da pilha de implantação com o modo de separação.

Problemas conhecidos

Neste momento, a eliminação de grupos de recursos ignora as atribuições de negação. Quando se cria uma pilha de implementação no âmbito do grupo de recursos, o ficheiro Bicep não inclui a definição para o grupo de recursos. Apesar da configuração de negação de atribuição, pode-se eliminar o grupo de recursos e a sua pilha contida. No entanto, se um bloqueio estiver ativo em qualquer recurso dentro do grupo, a operação de exclusão falhará.
O suporte para hipóteses ainda não está disponível.
Uma pilha com escopo de grupo de gestão não pode ser implantada em outro grupo de gestão. Só pode ser implementado no grupo de gestão do próprio stack ou numa subscrição filha.
A ajuda do comando do Azure PowerShell lista um DeleteResourcesAndResourcesGroups valor para o ActionOnUnmanage interruptor. Quando você usa esse valor, o comando desanexa os recursos gerenciados e os grupos de recursos. Esse valor é removido na próxima atualização. Não use esse valor.
Em alguns casos, os cmdlets New e Set do Azure PowerShell podem devolver um erro genérico de validação do modelo que não é claramente acionável. Este bug será corrigido na próxima versão. Se o erro não estiver claro, execute o cmdlet no modo de depuração para ver um erro mais detalhado na resposta bruta.
O provedor do Microsoft Graph não suporta pilhas de implementação.

Funções incorporadas

Aviso

A aplicação da permissão RBAC Microsoft.Resources/deploymentStacks/manageDenySetting/action está a ser implementada em todas as regiões, incluindo Nuvens Governamentais.

Existem dois papéis incorporados para a pilha de implementação.

Colaborador da Pilha de Implementação do Azure: os utilizadores podem gerir pilhas de implementação, mas não podem criar ou excluir atribuições de negação dentro das pilhas de implementação.
Proprietário da Pilha de Implementação do Azure: os utilizadores podem gerir pilhas de implementação, incluindo aqueles com atribuições de negação.

Criar pilhas de implementação

Você pode criar um recurso de pilha de implantação no escopo do grupo de recursos, da assinatura ou do grupo de gerenciamento. O modelo que é fornecido com uma pilha de implantação define os recursos a serem criados ou atualizados no escopo alvo.

A pilha de implantação no âmbito do grupo de recursos pode implantar o modelo no mesmo grupo de recursos onde essa pilha de implantação existe.
Uma pilha no âmbito da assinatura pode implantar o modelo num grupo de recursos ou na própria assinatura onde a pilha de implementação está localizada.
Uma pilha no escopo do grupo de gestão pode implantar o template na subscrição.

É importante notar que onde existe uma pilha de implementação, também é criada uma atribuição de negação com a capacidade de configurações de negação. Por exemplo, ao criar uma stack de implementação no âmbito de subscrição que implementa o modelo no âmbito do grupo de recursos e com o modo de configurações de negação DenyDelete, pode-se facilmente provisionar recursos geridos para o grupo de recursos especificado e bloquear tentativas de eliminação desses recursos. Essa abordagem ajuda a melhorar a segurança da pilha de implementação, efetuando a separação ao nível da assinatura, em vez de ao nível do grupo de recursos. Essa separação garante que as equipes de desenvolvedores que trabalham com os recursos provisionados tenham visibilidade e acesso de gravação apenas aos grupos de recursos. A pilha de implantação permanece isolada em um nível mais alto. Essa configuração minimiza o número de usuários que podem editar um stack de implantação e fazer alterações na sua atribuição de negação de permissões. Para obter mais informações, consulte Proteger o recurso gerenciado contra exclusão.

Você também pode usar os comandos create-stack para atualizar pilhas de implantação.

Para criar uma pilha de implementação no escopo do grupo de recursos:

New-AzResourceGroupDeploymentStack `
  -Name "<deployment-stack-name>" `
  -ResourceGroupName "<resource-group-name>" `
  -TemplateFile "<bicep-file-name>" `
  -ActionOnUnmanage "detachAll" `
  -DenySettingsMode "none"

az stack group create \
  --name '<deployment-stack-name>' \
  --resource-group '<resource-group-name>' \
  --template-file '<bicep-file-name>' \
  --action-on-unmanage 'detachAll' \
  --deny-settings-mode 'none'

Para criar uma stack de implementação no escopo da assinatura:

New-AzSubscriptionDeploymentStack `
  -Name "<deployment-stack-name>" `
  -Location "<location>" `
  -TemplateFile "<bicep-file-name>" `
  -DeploymentResourceGroupName "<resource-group-name>" `
  -ActionOnUnmanage "detachAll" `
  -DenySettingsMode "none"

O DeploymentResourceGroupName parâmetro especifica o grupo de recursos usado para armazenar os recursos gerenciados. Se você não especificar o parâmetro, os recursos gerenciados serão armazenados no escopo da assinatura.

az stack sub create \
  --name '<deployment-stack-name>' \
  --location '<location>' \
  --template-file '<bicep-file-name>' \
  --deployment-resource-group' <resource-group-name>' \
  --action-on-unmanage 'detachAll' \
  --deny-settings-mode 'none'

O deployment-resource-group parâmetro especifica o grupo de recursos usado para armazenar os recursos gerenciados. Se você não especificar o parâmetro, os recursos gerenciados serão armazenados no escopo da assinatura.

Para criar um conjunto de implantação no âmbito do grupo de gestão:

New-AzManagementGroupDeploymentStack `
  -Name "<deployment-stack-name>" `
  -Location "<location>" `
  -TemplateFile "<bicep-file-name>" `
  -DeploymentSubscriptionId "<subscription-id>" `
  -ActionOnUnmanage "detachAll" `
  -DenySettingsMode "none"

O deploymentSubscriptionId parâmetro especifica a assinatura usada para armazenar os recursos gerenciados. Se você não especificar o parâmetro, os recursos gerenciados serão armazenados no escopo do grupo de gerenciamento.

az stack mg create \
  --name '<deployment-stack-name>' \
  --location '<location>' \
  --template-file '<bicep-file-name>' \
  --deployment-subscription '<subscription-id>' \
  --action-on-unmanage 'detachAll' \
  --deny-settings-mode 'none'

O deployment-subscription parâmetro especifica a assinatura usada para armazenar os recursos gerenciados. Se você não especificar o parâmetro, os recursos gerenciados serão armazenados no escopo do grupo de gerenciamento.

Listar pilhas de implementação

Para listar os recursos da pilha de implantação no âmbito do grupo de recursos:

Get-AzResourceGroupDeploymentStack `
  -ResourceGroupName "<resource-group-name>"

az stack group list \
  --resource-group '<resource-group-name>'

Para listar os recursos da pilha de implantação no âmbito da assinatura:

Get-AzSubscriptionDeploymentStack

az stack sub list

Para listar recursos da pilha de implementação ao nível do grupo de gestão:

Get-AzManagementGroupDeploymentStack `
  -ManagementGroupId "<management-group-id>"

az stack mg list \
  --management-group-id '<management-group-id>'

Atualizar pilhas de implementação

Para atualizar uma pilha de implementação, o que pode envolver a adição ou eliminação de um recurso gerido, é necessário fazer alterações nos ficheiros Bicep subjacentes. Depois de fazer as modificações, você pode atualizar a pilha de implantação executando o comando update ou executando novamente o comando create.

O padrão de design de infraestrutura como código oferece controle total sobre a lista de recursos gerenciados.

Usar o comando Definir

Para atualizar uma stack de implementação no âmbito do grupo de recursos:

Set-AzResourceGroupDeploymentStack `
  -Name "<deployment-stack-name>" `
  -ResourceGroupName "<resource-group-name>" `
  -TemplateFile "<bicep-file-name>" `
  -ActionOnUnmanage "detachAll" `
  -DenySettingsMode "none"

az stack group create \
  --name '<deployment-stack-name>' \
  --resource-group '<resource-group-name>' \
  --template-file '<bicep-file-name>' \
  --action-on-unmanage 'detachAll' \
  --deny-settings-mode 'none'

Nota

A CLI do Azure não tem um comando para configuração de pilha de implantação. Em vez disso, use o comando Novo.

Para atualizar uma pilha de implantação no âmbito da subscrição:

Set-AzSubscriptionDeploymentStack `
  -Name "<deployment-stack-name>" `
  -Location "<location>" `
  -TemplateFile "<bicep-file-name>" `
  -DeploymentResourceGroupName "<resource-group-name>" `
  -ActionOnUnmanage "detachAll" `
  -DenySettingsMode "none"

O parâmetro DeploymentResourceGroupName especifica o grupo de recursos utilizado para o armazenamento dos recursos da pilha de implantação. Se não especificares um nome de grupo de recursos, o serviço de implementação cria um novo grupo de recursos para ti.

az stack sub create \
  --name '<deployment-stack-name>' \
  --location '<location>' \
  --template-file '<bicep-file-name>' \
  --deployment-resource-group '<resource-group-name>' \
  --action-on-unmanage 'detachAll' \
  --deny-settings-mode 'none'

Para atualizar uma pilha de implementação no âmbito do grupo de gestão:

Set-AzManagementGroupDeploymentStack `
  -Name "<deployment-stack-name>" `
  -Location "<location>" `
  -TemplateFile "<bicep-file-name>" `
  -DeploymentSubscriptionId "<subscription-id>" `
  -ActionOnUnmanage "detachAll" `
  -DenySettingsMode "none"

az stack mg create \
  --name '<deployment-stack-name>' \
  --location '<location>' \
  --template-file '<bicep-file-name>' \
  --deployment-subscription '<subscription-id>' \
  --action-on-unmanage 'detachAll' \
  --deny-settings-mode 'none'

Use o comando Novo

Você recebe um aviso semelhante ao seguinte:

The deployment stack 'myStack' you're trying to create already exists in the current subscription/management group/resource group. Do you want to overwrite it? Detaching: resources, resourceGroups (Y/N)

Para mais informações, consulte Create deployment stacks.

Controle a separação e a exclusão

Um recurso dissociado (ou recurso não gerido) refere-se a um recurso que a pilha de implantação não controla ou gere, mas que ainda existe no Azure.

Para instruir o Azure a eliminar recursos não geridos, atualize a pilha com o comando 'create stack' e inclua a opção ActionOnUnmanage. Para obter mais informações, consulte Criar pilha de implantação.

Use o interruptor ActionOnUnmanage para definir o que acontece aos recursos que deixam de ser geridos após uma pilha ser atualizada ou eliminada. Os valores permitidos são:

deleteAll: Use "excluir" em vez de "remover" para recursos geridos e grupos de recursos.
deleteResources: Utilize "delete" em vez de "detach", apenas para recursos geridos.
detachAll: Desanexe os recursos gerenciados e os grupos de recursos.

Por exemplo:

New-AzSubscriptionDeploymentStack `
  -Name "<deployment-stack-name" `
  -TemplateFile "<bicep-file-name>" `
  -DenySettingsMode "none" `
  -ActionOnUnmanage "deleteAll"

Use o interruptor action-on-unmanage para definir o que acontece aos recursos que deixam de ser geridos após uma pilha ser atualizada ou eliminada. Os valores permitidos são:

deleteAll: Use "excluir" em vez de "remover" para recursos geridos e grupos de recursos.
deleteResources: Utilize "delete" em vez de "detach", apenas para recursos geridos.
detachAll: Desanexe os recursos gerenciados e os grupos de recursos.

Por exemplo:

az stack sub create `
  --name '<deployment-stack-name>' `
  --location '<location>' `
  --template-file '<bicep-file-name>' `
  --action-on-unmanage 'deleteAll' `
  --deny-settings-mode 'none'

Aviso

Ao excluir grupos de recursos com a action-on-unmanage opção definida como deleteAll, você exclui os grupos de recursos gerenciados e todos os recursos contidos neles.

Lidar com o erro da pilha fora de sincronização

Ao atualizar ou excluir uma pilha de implantação, pode encontrar o seguinte erro de falta de sincronização da pilha, indicando que a lista de recursos da pilha não está devidamente sincronizada.

The deployment stack '{0}' might not have an accurate list of managed resources. To prevent resources from being accidentally deleted, check that the managed resource list doesn't have any additional values. If there is any uncertainty, it's recommended to redeploy the stack with the same template and parameters as the current iteration. To bypass this warning, specify the 'BypassStackOutOfSyncError' flag.

Você pode obter uma lista dos recursos do portal do Azure ou reimplantar o arquivo Bicep implantado atualmente com os mesmos parâmetros. A saída mostra os recursos gerenciados.

...
Resources: /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/demoRg/providers/Microsoft.Network/virtualNetworks/vnetthmimleef5fwk
           /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/demoRg/providers/Microsoft.Storage/storageAccounts/storethmimleef5fwk

"resources": [
  {
    "denyStatus": "none",
    "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/demoRg/providers/Microsoft.Network/virtualNetworks/vnetthmimleef5fwk",
    "resourceGroup": "demoRg",
    "status": "managed"
  },
  {
    "denyStatus": "none",
    "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/demoRg/providers/Microsoft.Storage/storageAccounts/storethmimleef5fwk",
    "resourceGroup": "demoRg",
    "status": "managed"
  }
]

Depois de revisar e verificar a lista de recursos na pilha, execute novamente o comando com a BypassStackOutOfSyncError opção no Azure PowerShell (ou bypass-stack-out-of-sync-error na CLI do Azure). Use essa opção somente depois de revisar completamente a lista de recursos na pilha. Não use essa opção por padrão.

Eliminar pilhas de implementação

A ActionOnUnmanage opção define a ação para os recursos que não são mais gerenciados. O switch tem os seguintes valores:

DeleteAll: Exclua os recursos e os grupos de recursos.
DeleteResources: Exclua apenas os recursos.
DetachAll: Desanexe os recursos.

Mesmo que você especifique a opção excluir tudo, os recursos não gerenciados dentro do grupo de recursos onde a pilha de implantação está localizada impedem que os recursos não gerenciados e o próprio grupo de recursos sejam excluídos.

Para excluir recursos da pilha de implantação no escopo do grupo de recursos:

Remove-AzResourceGroupDeploymentStack `
  -name "<deployment-stack-name>" `
  -ResourceGroupName "<resource-group-name>" `
  -ActionOnUnmanage "<deleteAll/deleteResources/detachAll>"

az stack group delete \
  --name '<deployment-stack-name>' \
  --resource-group '<resource-group-name>' \
  --action-on-unmanage '<deleteAll/deleteResources/detachAll>'

No portal do Azure, abra o grupo de recursos que contém as stacks de implantação.
No menu à esquerda, selecione Deployment stacks, selecione a pilha de implantação a ser excluída e, em seguida, selecione Delete stack.
Selecione um Update behaviore, em seguida, selecione Next.

Para eliminar recursos da pilha de implementação no escopo da assinatura:

Remove-AzSubscriptionDeploymentStack `
  -Name "<deployment-stack-name>" `
  -ActionOnUnmanage "<deleteAll/deleteResources/detachAll>"

az stack sub delete \
  --name '<deployment-stack-name>' \
  --action-on-unmanage '<deleteAll/deleteResources/detachAll>'

No Portal do Azure, abra a assinatura que contém as stacks de implementação.
No menu à esquerda, selecione Deployment stacks, selecione a pilha de implantação a ser excluída e, em seguida, selecione Delete stack.
Selecione um Update behavior (excluir sinalizador) e, em seguida, selecione Next.

Para eliminar recursos da pilha de implantação no âmbito do grupo de gerenciamento:

Remove-AzManagementGroupDeploymentStack `
  -Name "<deployment-stack-name>" `
  -ManagementGroupId "<management-group-id>" `
  -ActionOnUnmanage "<deleteAll/deleteResources/detachAll>"

az stack mg delete \
  --name '<deployment-stack-name>' \
  --management-group-id '<management-group-id>' \
  --action-on-unmanage '<deleteAll/deleteResources/detachAll>'

Exibir recursos geridos na pilha de implementação

O serviço de stack de implantação ainda não possui uma interface gráfica do usuário (GUI) no portal do Azure. Para exibir os recursos geridos dentro de uma pilha de implementação, use os seguintes comandos do Azure PowerShell/Azure CLI:

Para ver recursos geridos no âmbito do grupo de recursos:

(Get-AzResourceGroupDeploymentStack -Name "<deployment-stack-name>" -ResourceGroupName "<resource-group-name>").Resources

az stack group list \
  --name '<deployment-stack-name>' \
  --resource-group '<resource-group-name>' \
  --output 'json'

Para visualizar recursos geridos no âmbito da assinatura:

(Get-AzSubscriptionDeploymentStack -Name "<deployment-stack-name>").Resources

az stack sub show \
  --name '<deployment-stack-name>' \
  --output 'json'

Para exibir recursos gerenciados no escopo do grupo de gerenciamento:

(Get-AzManagementGroupDeploymentStack -Name "<deployment-stack-name>" -ManagementGroupId "<management-group-id>").Resources

az stack mg show \
  --name '<deployment-stack-name>' \
  --management-group-id '<management-group-id>' \
  --output 'json'

Adicionar recursos à pilha de implementação

Para adicionar um recurso gerenciado, adicione a definição de recurso aos arquivos Bicep subjacentes e execute o comando update ou execute novamente o comando create. Para obter mais informações, consulte Atualizar pilhas de implementação.

Eliminar recursos geridos da pilha de implementação

Para excluir um recurso gerenciado, remova a definição de recurso dos arquivos Bicep subjacentes e execute o comando update ou execute novamente o comando create. Para obter mais informações, consulte Atualizar pilhas de implementação.

Proteja os recursos gerenciados

Você pode atribuir permissões específicas aos recursos gerenciados de uma pilha de implantação para impedir que entidades de segurança não autorizadas as excluam ou atualizem. Essas permissões são chamadas de configurações de negação. Armazene pilhas no escopo pai. Por exemplo, para proteger recursos em uma assinatura, coloque a pilha no escopo pai, que é o grupo de gerenciamento pai imediato.

A configuração de negação só se aplica às operações do plano de controle e não às operações do plano de dados. Por exemplo, você cria contas de armazenamento e cofres de chaves por meio do plano de controle, o que significa que a pilha de implantação os gerencia. No entanto, você cria recursos filho como segredos ou contêineres de blob por meio do plano de dados, o que significa que a pilha de implantação não pode gerenciá-los.

A configuração de negação só se aplica a recursos criados explicitamente, não aos criados implicitamente. Por exemplo, um cluster AKS gerenciado cria vários outros serviços para suportá-lo, como uma máquina virtual. Nesse caso, como a máquina virtual não está definida no ficheiro Bicep e é um recurso criado implicitamente, não está sujeita às definições de negação da pilha de implementação.

Nota

A versão mais recente requer permissões específicas no escopo da pilha para:

Crie ou atualize uma stack de implantação e defina a negação para um valor diferente de None.
Atualize ou elimine uma pilha de implantação com uma configuração de negação existente de um valor diferente de None.

Use as funções incorporadas da pilha de implantação para conceder permissões.

O Azure PowerShell inclui estes parâmetros para personalizar a atribuição de negação:

DenySettingsMode: Define as operações que são proibidas nos recursos gerenciados para proteção contra entidades de segurança não autorizadas que tentam excluí-las ou atualizá-las. Essa restrição se aplica a todos, a menos que você conceda acesso explicitamente. Os valores incluem: None, DenyDeletee DenyWriteAndDelete.
DenySettingsApplyToChildScopes: Quando especificado, a configuração do modo de negação também se aplica ao subescopo dos recursos geridos. Por exemplo, um arquivo Bicep define um recurso Microsoft.Sql/servers (pai) e um recurso Microsoft.Sql/servers/databases (filho). Se você criar uma pilha de implantação usando o arquivo Bicep com a configuração habilitada DenySettingsApplyToChildScopes e a DenySettingsMode definida como DenyWriteAndDelete, não poderá adicionar recursos filho adicionais ao recurso Microsoft.Sql/servers ou ao recurso Microsoft.Sql/servers/databases .
DenySettingsExcludedAction: Lista de operações de gerenciamento baseadas em função que são excluídas das configurações de negação. São permitidas até 200 ações.
DenySettingsExcludedPrincipal: Lista de IDs principais do Microsoft Entra excluídas do bloqueio. São permitidos até cinco diretores.

A CLI do Azure inclui estes parâmetros para personalizar a atribuição de negação:

deny-settings-mode: Define as operações que são proibidas nos recursos gerenciados para proteção contra entidades de segurança não autorizadas que tentam excluí-las ou atualizá-las. Esta restrição aplica-se a todos, a menos que lhes seja explicitamente concedido acesso. Os valores incluem: none, denyDeletee denyWriteAndDelete.
deny-settings-apply-to-child-scopes: Quando especificado, a configuração do modo de negação também se aplica ao subescopo dos recursos geridos. Por exemplo, um arquivo Bicep define um recurso Microsoft.Sql/servers (pai) e um recurso Microsoft.Sql/servers/databases (filho). Se criares um stack de implementação usando o ficheiro Bicep com a definição deny-settings-apply-to-child-scopes habilitada e a deny-settings-mode configurada como denyWriteAndDelete, não podes adicionar quaisquer recursos filho extra ao recurso Microsoft.Sql/servers nem ao recurso Microsoft.Sql/servers/databases.
deny-settings-excluded-actions: Lista de operações de gerenciamento RBAC excluídas das configurações de negação. São permitidas até 200 ações.
deny-settings-excluded-principals: Lista de IDs principais do Microsoft Entra excluídas do bloqueio. São permitidos até cinco diretores.

Para aplicar configurações de negação no escopo do grupo de recursos:

New-AzResourceGroupDeploymentStack `
  -Name "<deployment-stack-name>" `
  -ResourceGroupName "<resource-group-name>" `
  -TemplateFile "<bicep-file-name>" `
  -ActionOnUnmanage "detachAll" `
  -DenySettingsMode "denyDelete" `
  -DenySettingsExcludedAction "Microsoft.Compute/virtualMachines/write Microsoft.StorageAccounts/delete" `
  -DenySettingsExcludedPrincipal "<object-id>,<object-id>"

az stack group create \
  --name '<deployment-stack-name>' \
  --resource-group '<resource-group-name>' \
  --template-file '<bicep-file-name>' \
  --action-on-unmanage 'detachAll' \
  --deny-settings-mode 'denyDelete' \
  --deny-settings-excluded-actions 'Microsoft.Compute/virtualMachines/write Microsoft.StorageAccounts/delete' \
  --deny-settings-excluded-principals '<object-id> <object-id>'

Para aplicar configurações de negação ao nível de subscrição:

New-AzSubscriptionDeploymentStack `
  -Name "<deployment-stack-name>" `
  -Location "<location>" `
  -TemplateFile "<bicep-file-name>" `
  -ActionOnUnmanage "detachAll" `
  -DenySettingsMode "denyDelete" `
  -DenySettingsExcludedAction "Microsoft.Compute/virtualMachines/write Microsoft.StorageAccounts/delete" `
  -DenySettingsExcludedPrincipal "<object-id>,<object-id>"

Use o DeploymentResourceGroupName parâmetro para especificar o nome do grupo de recursos onde a pilha de implantação é criada. Se um escopo não for especificado, usará o escopo do stack de implantação.

az stack sub create \
  --name '<deployment-stack-name>' \
  --location '<location>' \
  --template-file '<bicep-file-name>' \
  --action-on-unmanage 'detachAll' \
  --deny-settings-mode 'denyDelete' \
  --deny-settings-excluded-actions 'Microsoft.Compute/virtualMachines/write Microsoft.StorageAccounts/delete' \
  --deny-settings-excluded-principals '<object-id> <object-id>'

Use o parâmetro deployment-resource-group para especificar o grupo de recursos no qual a pilha de implementação é criada. Se um escopo não for especificado, usará o escopo do stack de implantação.

Para aplicar configurações de negação no escopo do grupo de gerenciamento:

New-AzManagementGroupDeploymentStack `
  -Name "<deployment-stack-name>" `
  -Location "<location>" `
  -TemplateFile "<bicep-file-name>" `
  -ActionOnUnmanage "detachAll" `
  -DenySettingsMode "denyDelete" `
  -DenySettingsExcludedActions "Microsoft.Compute/virtualMachines/write Microsoft.StorageAccounts/delete" `
  -DenySettingsExcludedPrincipal "<object-id>,<object-id>"

Use o DeploymentSubscriptionId parâmetro para especificar a ID de subscrição onde a pilha de implantação é criada. Se um escopo não for especificado, usará o escopo do stack de implantação.

az stack mg create \
  --name '<deployment-stack-name>' \
  --location '<location>' \
  --template-file '<bicep-file-name>' \
  --action-on-unmanage 'detachAll' \
  --deny-settings-mode 'denyDelete' \
  --deny-settings-excluded-actions 'Microsoft.Compute/virtualMachines/write Microsoft.StorageAccounts/delete' \
  --deny-settings-excluded-principals '<object-id> <object-id>'

Use o deployment-subscription parâmetro para especificar a ID de subscrição onde a pilha de implantação é criada. Se um escopo não for especificado, usará o escopo do stack de implantação.

Desanexar recursos geridos da pilha de implementação

Por padrão, as pilhas de implementação separam e não eliminam recursos não geridos quando já não estão contidos dentro do âmbito de gestão da pilha. Para obter mais informações, consulte Atualizar pilhas de implementação.

Exportar modelos de pilhas de implementação

Pode exportar os recursos de um conjunto de implementação para uma saída JSON. Você pode canalizar a saída para um arquivo.

Para exportar um conjunto de implementação no âmbito do grupo de recursos:

Save-AzResourceGroupDeploymentStack `
   -Name "<deployment-stack-name>" `
   -ResourceGroupName "<resource-group-name>" `

az stack group export \
  --name '<deployment-stack-name>' \
  --resource-group '<resource-group-name>'

Para exportar um stack de implementação ao nível da assinatura:

Save-AzSubscriptionDeploymentStack `
  -name "<deployment-stack-name>"

az stack sub export \
  --name '<deployment-stack-name>'

Para exportar uma pilha de implantação no âmbito do grupo de gestão:

Save-AzManagementGroupDeploymentStack `
  -Name "<deployment-stack-name>" `
  -ManagementGroupId "<management-group-id>"

az stack mg export \
  --name '<deployment-stack-name>' \
  --management-group-id '<management-group-id>'

Próximos passos

Para consultar um guia de início rápido para a implementação com o Bicep, veja Aprenda rapidamente: criar e implantar um conjunto de implantações com o Bicep.

Feedback

Esta página foi útil?

Last updated on 2025-12-22