Criar e implantar pilhas de implantação do Azure no Bicep

Uma pilha de implantação do Azure é um recurso que permite gerenciar um grupo de recursos do Azure como uma unidade coesa e única. Ao enviar um arquivo Bicep ou um modelo JSON do Azure Resource Manager (modelo JSON do 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 implantação usando o controle de acesso baseado em função do Azure (RBAC do Azure), assim como em outros recursos do Azure.

Para criar e atualizar uma pilha de implantaçã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 do ARM e os implanta 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 pilhas de implantação. Ele consiste em um modelo principal que pode executar atualizações de um para muitos entre escopos para os recursos descritos e bloquear quaisquer 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 pilha de implantação para criar esses ambientes de teste e atualizar as configurações de 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 todos os recursos criados, como as máquinas virtuais de teste. Use uma pilha de implantação e especifique o sinalizador de exclusão apropriado para remover recursos gerenciados. Essa abordagem simplificada economiza tempo durante a limpeza do ambiente, pois envolve uma única atualização do recurso de stack em vez de modificar ou remover individualmente cada máquina virtual de teste em vários escopos de grupo de recursos.

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

Para criar sua primeira pilha de implantação, examine Início Rápido: criar pilha de implantação.

Por que usar pilhas de implantação?

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

Provisionamento e gerenciamento de recursos simplificados em diferentes escopos como uma entidade unificada.
Prevenção de modificações indesejadas em recursos gerenciados por meio de configurações de negação.
Limpeza eficiente do ambiente usando sinalizadores de exclusão durante atualizações de pilha de implantação.
Use de modelos padrão, como Bicep, modelos do ARM ou especificações de modelo para suas pilhas de implantação.

Limitações conhecidas

Há um limite de 800 pilhas de implantação que podem ser criadas em um único escopo.
Um máximo de 2.000 atribuições de negação pode existir em qualquer escopo determinado.
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.
As atribuições de negação não dão suporte a marcas.
Não há suporte para atribuições de negação no escopo do grupo de gerenciamento. No entanto, elas têm suporte em uma pilha de grupo de gerenciamento se a implantação for apontada para o escopo da assinatura.
As pilhas de implantação não podem excluir segredos do cofre de chaves. Se você estiver removendo segredos do cofre de chaves de um modelo, execute também o comando de atualização/exclusão da pilha de implantação com o modo de desanexação.

Problemas conhecidos

A exclusão de grupos de recursos atualmente ignora as atribuições de negação. Quando você cria um stack de implantação no escopo do grupo de recursos, o arquivo Bicep não contém a definição do grupo de recursos. Apesar da configuração de atribuição de negação, você pode excluir o grupo de recursos e a pilha contida nele. No entanto, se houver um bloqueio ativo em qualquer recurso dentro do grupo, a operação de exclusão falhará.
O suporte What-if ainda não está disponível.
Uma pilha com escopo de grupo de gerenciamento não pode ser implantada em outro grupo de gerenciamento. Ele só pode ser implantado no grupo de gerenciamento da pilha em si ou em uma assinatura filho.
A ajuda do comando do Azure PowerShell lista um valor DeleteResourcesAndResourcesGroups para a opção ActionOnUnmanage. 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 retornar um erro de validação de modelo genérico que não é claramente acionável. Esse 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 dá suporte a stacks de implantação.

Funções internas

Aviso

A imposição da permissão RBAC Microsoft.Resources/deploymentStacks/manageDenySetting/action está sendo implementada em várias regiões, incluindo Nuvens de Governo.

Há duas funções internas para a pilha de implantação:

Colaborador da Pilha de Implantação do Azure: os usuários podem gerenciar pilhas de implantação, mas não podem criar ou excluir atribuições de negação dentro das pilhas de implantação.
Proprietário da Pilha de Implantação do Azure: os usuários podem gerenciar pilhas de implantação, incluindo aquelas com atribuições de negação.

Criar camadas de implantaçã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 fornecido com uma pilha de implantação define os recursos a serem criados ou atualizados no escopo de destino.

Uma pilha no escopo do grupo de recursos pode implantar o modelo no mesmo grupo de recursos em que a pilha de implantação existe.
Uma pilha no escopo da assinatura pode implantar o modelo em um grupo de recursos ou na mesma assinatura em que a pilha de implantação existe.
Uma pilha no escopo do grupo de gerenciamento pode implantar o modelo na assinatura.

É importante observar que onde existe uma pilha de implantação, assim como a atribuição de negação criada com a funcionalidade de configurações de negação. Por exemplo, criando uma pilha de implantação no escopo da assinatura que implanta o modelo no escopo do grupo de recursos e com o modo de configurações de negação DenyDelete, você pode provisionar facilmente recursos gerenciados para o grupo de recursos especificado e bloquear tentativas de exclusão para esses recursos. Essa abordagem ajuda você a aprimorar a segurança da pilha de implantação separando-a no nível da assinatura, em vez de no nível do grupo de recursos. Essa separação garante que as equipes de desenvolvedores que trabalham com os recursos provisionados tenham apenas visibilidade e acesso de gravação 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 uma pilha de implantação e fazer alterações em sua atribuição de negação. Para obter mais informações, confira Proteger o recurso gerenciado contra exclusão.

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

Para criar uma pilha de implantaçã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 pilha de implantaçã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 parâmetro DeploymentResourceGroupName 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 parâmetro deployment-resource-group 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 uma pilha de implantação no escopo do grupo de gerenciamento:

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

O parâmetro deploymentSubscriptionId 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 parâmetro deployment-subscription 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 implantação

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

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

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

Para listar recursos de pilha de implantação no escopo da assinatura:

Get-AzSubscriptionDeploymentStack

az stack sub list

Para listar recursos de pilha de implantação no escopo do grupo de gerenciamento:

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

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

Atualizar pilhas de implantação

Para atualizar uma pilha de implantação, que pode envolver a adição ou exclusão de um recurso gerenciado, você precisa fazer alterações nos arquivos Bicep subjacentes. Depois de fazer as modificações, você pode atualizar a pilha de implantação executando o comando de atualização ou executando novamente o comando create.

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

Usar o comando Set

Para atualizar uma pilha de implantação no escopo 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'

Observação

A CLI do Azure não tem um comando de conjunto de pilhas de implantação. Alternativamente, use o comando Novo.

Para atualizar uma pilha de implantação no escopo da assinatura:

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 usado para armazenar os recursos da pilha de implantação. Caso não especifique um nome para o grupo de recursos, o serviço de pilha de implantação criará um novo grupo de recursos para você.

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 implantação no escopo do grupo de gerenciamento:

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ê receberá um aviso parecido com o 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 saber mais, confira Criar pilhas de implantação.

Desanexação e exclusão de controle

Um recurso desanexado (ou recurso não gerenciado) refere-se a um recurso que a pilha de implantação não rastreia ou gerencia, mas ainda existe no Azure.

Para instruir o Azure a excluir recursos não gerenciados, atualize a pilha com o comando create stack e inclua a opção ActionOnUnmanage. Para saber mais, confira Criar pilha de implantação.

Use a chave ActionOnUnmanage para definir o que acontece com recursos que não são mais gerenciados depois que uma pilha de recursos é atualizada ou excluída. Valores permitidos são:

deleteAll: Use o comando "excluir" em vez de "desanexar" para recursos gerenciados e grupos de recursos.
deleteResources: use excluir, em vez de desanexar, somente para recursos gerenciados.
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 a chave action-on-unmanage para definir o que acontece com recursos que não são mais gerenciados depois que uma pilha de recursos é atualizada ou excluída. Valores permitidos são:

deleteAll: Use o comando "excluir" em vez de "desanexar" para recursos gerenciados e grupos de recursos.
deleteResources: use excluir, em vez de desanexar, somente para recursos gerenciados.
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 opção action-on-unmanage definida como deleteAll, você exclui os grupos de recursos gerenciados e todos os recursos contidos neles.

Lidar com o erro de pilha fora de sincronização (stack-out-of-sync)

Ao atualizar ou excluir uma pilha de implantação, você se deparar com o seguinte erro de pilha fora de sincronização, indicando que a lista de recursos da pilha não está sincronizada corretamente.

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 através do portal do Azure ou reimplantar o arquivo Bicep que está implantado no momento 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 examinar e verificar a lista de recursos na pilha, execute novamente o comando com a opção BypassStackOutOfSyncError no Azure PowerShell (ou bypass-stack-out-of-sync-error na CLI do Azure). Use essa opção somente depois de examinar completamente a lista de recursos na pilha. Não use essa opção por padrão.

Excluir pilhas de implantação

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

DeleteAll: excluir os recursos e os grupos de recursos.
DeleteResources: exclua apenas os recursos.
DetachAll: desanexar os recursos.

Mesmo que você utilize a opção de excluir tudo (delete-all), os recursos não gerenciados dentro do grupo de recursos onde a pilha de implantação está localizada impedirão que tanto os recursos não gerenciados quanto 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 os stacks de implantação.
No menu à esquerda, selecione Deployment stacks, selecione a pilha de implantação a ser excluída e selecione Delete stack.
Selecione Update behavior e, em seguida, selecione Next.

Para excluir recursos da pilha de implantaçã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 os stacks de implantação.
No menu à esquerda, selecione Deployment stacks, selecione a pilha de implantação a ser excluída e selecione Delete stack.
Selecione um Update behavior (excluir sinalizador) e, em seguida, selecione Next.

Para excluir recursos da pilha de implantação no escopo 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 gerenciados na pilha de implantação

O serviço de pilha de implantação ainda não tem uma interface gráfica do usuário (GUI) do portal do Azure. Para visualizar os recursos gerenciados dentro de uma pilha de implantação, use os seguintes comandos do Azure PowerShell ou da Azure CLI:

Para visualizar recursos gerenciados no escopo de 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 exibir recursos gerenciados no escopo 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 implantaçã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 saber mais, confira Atualizar pilhas de implantação.

Excluir recursos gerenciados da pilha de implantaçã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 saber mais, confira Atualizar pilhas de implantação.

Proteger 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 conhecidas como 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 as 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 se aplica apenas aos recursos criados explicitamente, não aos criados implicitamente. Por exemplo, um cluster AKS gerenciado cria vários outros serviços para dar suporte a ele, como uma máquina virtual. Nesse caso, como a máquina virtual não é definida no arquivo Bicep e é um recurso criado implicitamente, ela não está sujeita às configurações de negação do conjunto de implantação.

Observação

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

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

Use a pilha de implantação funções internas para conceder permissões.

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

DenySettingsMode: define as operações proibidas nos recursos gerenciados para proteger 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 explicitamente acesso. Esses valores incluem None, DenyDelete, e DenyWriteAndDelete.
DenySettingsApplyToChildScopes: quando especificada, a configuração do modo de configuração de negação também se aplica ao escopo filho dos recursos gerenciados. 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 de DenySettingsApplyToChildScopes habilitada e o DenySettingsMode definido como DenyWriteAndDelete, você 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 excluídas das configurações de negação. Até 200 ações são permitidas.
DenySettingsExcludedPrincipal: lista de IDs da entidade de segurança do Microsoft Entra excluídas do bloqueio. Até cinco entidades de segurança são permitidas.

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

deny-settings-mode: define as operações proibidas nos recursos gerenciados para proteger 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 tenham acesso explicitamente concedido. Esses valores incluem none, denyDelete, e denyWriteAndDelete.
deny-settings-apply-to-child-scopes: quando especificada, a configuração do modo de configuração de negação também se aplica ao escopo filho dos recursos gerenciados. 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 de deny-settings-apply-to-child-scopes habilitada e o deny-settings-mode definido como denyWriteAndDelete, você não poderá adicionar recursos filho adicionais ao recurso Microsoft.Sql/servers ou 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. Até 200 ações são permitidas.
deny-settings-excluded-principals: lista de IDs da entidade de segurança do Microsoft Entra excluídas do bloqueio. Até cinco entidades de segurança são permitidas.

Para aplicar as configurações de negação de acesso 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 as configurações de negação no escopo da assinatura:

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 parâmetro DeploymentResourceGroupName para especificar o nome do grupo de recursos no qual a pilha de implantação é criada. Se um escopo não for especificado, ele usará o escopo da pilha 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 implantação é criada. Se um escopo não for especificado, ele usará o escopo da pilha de implantação.

Para aplicar as 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 parâmetro DeploymentSubscriptionId para especificar a ID da assinatura na qual a pilha de implantação é criada. Se um escopo não for especificado, ele usará o escopo da pilha 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 parâmetro deployment-subscription para especificar a ID da assinatura na qual a pilha de implantação é criada. Se um escopo não for especificado, ele usará o escopo da pilha de implantação.

Desanexar recursos gerenciados da pilha de implantação

Por padrão, as pilhas de implantação desanexam e não excluem recursos não gerenciados quando não estão mais contidos no escopo de gerenciamento da pilha. Para saber mais, confira Atualizar pilhas de implantação.

Exportar modelos de pilhas de implantação

Você pode exportar os recursos de uma pilha de implantação para uma saída JSON. Você pode redirecionar a saída para um arquivo.

Para exportar uma pilha de implantação no escopo 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 uma pilha de implantação no escopo da assinatura:

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

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

Para exportar uma pilha de implantação no escopo do grupo de gerenciamento:

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óximas etapas

Para passar por um início rápido de implantação do Bicep, consulte Guia de Início Rápido: Criar e implantar uma pilha de implantação com o Bicep.

Comentários

Esta página foi útil?

Last updated on 2025-06-09