Pilhas de implantação

Artigo
06/24/2024

Uma pilha de implantação do Azure é um recurso que permite gerenciar um grupo de recursos do Azure como uma unidade coesa e única. Quando você enviar um arquivo Bicep ou um modelo JSON do ARM para uma pilha de implantação, ele define os recursos que a pilha gerencia. Se um recurso que anteriormente estava incluído no modelo for removido, ele será desanexado ou excluído com base no comportamento actionOnUnmanage especificado da pilha de implantação. O acesso à pilha de implantação pode ser restrito 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, você pode utilizar a CLI do Azure, o Azure PowerShell ou o portal do Azure junto com arquivos Bicep. Esses arquivos Bicep são transpilados em modelos JSON do ARM, que são implantados como um objeto de implantação pela pilha. A pilha de implantação oferece recursos adicionais além dos recursos de implantação familiares, servindo como 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 1 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, é importante considerar o ciclo de vida de gerenciamento desses recursos, que inclui criação, atualização e exclusão. Imagine, por exemplo, que você precise provisionar algumas máquinas virtuais (VMs) de teste para várias equipes de aplicativos em diferentes escopos de grupo de recursos. Nesse caso, uma pilha de implantação pode ser utilizada para criar esses ambientes de teste e atualizar as configurações de VM de teste por meio de atualizações subsequentes para a pilha de implantação. Depois de concluir o projeto, pode ser necessário remover ou excluir todos os recursos que foram criados, como as VMs de teste. Ao utilizar uma pilha de implantação, os recursos gerenciados podem ser facilmente removidos especificando o sinalizador de exclusão apropriado. Essa abordagem simplificada economiza tempo durante a limpeza do ambiente, pois envolve uma única atualização para o recurso de pilha em vez de modificar ou remover individualmente cada VM 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

Os recursos criados implicitamente não são gerenciados pela pilha de implantação. Portanto, não é possível realizar atribuições de negação ou limpeza.
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. Ao criar uma pilha de implantação no escopo do grupo de recursos, o arquivo Bicep não contém a definição para o grupo de recursos. Apesar da configuração de atribuição de negação, é possível 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 é restrita à implantação 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 de comando do PowerShell lista um valor DeleteResourcesAndResourcesGroups para a opção ActionOnUnmanage. Quando esse valor é usado, o comando desanexa os recursos gerenciados e os grupos de recursos. Esse valor será 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, mas, por enquanto, se o erro não estiver claro, você poderá executar o cmdlet no modo de depuração para ver um erro mais detalhado na resposta bruta.
As pilhas de implantação não são suportadas pelo provedor Microsoft Graph.

Funções internas

Aviso

A imposição da permissão RBAC Microsoft.Resources/deploymentStacks/manageDenySetting/action está sendo distribuída entre regiões, incluindo Nuvens do Governo.

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

Colaborador da Pilha de Implantação do Azure: permite que os usuários gerenciem 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: permite que os usuários gerenciem pilhas de implantação, incluindo aquelas com atribuições de negação.

Criar pilhas de implantação

Um recurso de pilha de implantação pode ser criado no escopo do grupo de recursos, da assinatura ou do grupo de gerenciamento. O modelo passado para uma pilha de implantação define os recursos a serem criados ou atualizados no escopo de destino especificado para a implantação do modelo.

Uma pilha no escopo do grupo de recursos pode implantar o modelo passado para o mesmo escopo do grupo de recursos em que a pilha de implantação existe.
Uma pilha no escopo da assinatura pode implantar o modelo passado para um escopo de grupo de recursos (se especificado) ou o mesmo escopo de assinatura em que a pilha de implantação existe.
Uma pilha no escopo do grupo de gerenciamento pode implantar o modelo passado para o escopo da assinatura especificado.

É 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. Ao usar essa abordagem, você também aprimora a segurança da pilha de implantação separando-a no nível da assinatura, em vez do 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, enquanto a pilha de implantação permanece isolada em um nível mais alto. Isso 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.

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 o parâmetro não for especificado, 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 o parâmetro não for especificado, 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 o parâmetro não for especificado, 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 o parâmetro não for especificado, 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 que as modificações forem feitas, você terá duas opções para atualizar a pilha de implantação: executar o comando update ou executar novamente o comando create.

A lista de recursos gerenciados pode ser totalmente controlada por meio do padrão de design de infraestrutura como código (IaC).

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. Se você não especificar um nome de 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 não é rastreado ou gerenciado pela pilha de implantação, mas ainda existe no Azure.

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

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

deleteAll: use 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 opção action-on-unmanage para definir o que acontece com recursos que não são mais gerenciados depois que uma pilha é atualizada ou excluída. Valores permitidos são:

deleteAll: use 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, os grupos de recursos gerenciados e todos os recursos contidos neles também serão excluídos.

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}' may not have an accurate list of managed resources. To ensure no resources are accidentally deleted, please check that the managed resource list does not have any additional values. If there is any uncertainty, we recommend redeploying the stack with the same template and parameters as the current iteration. To bypass this warning, please 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 revisar e verificar a lista de recursos a pilha, você pode executar o comando novamente com a opção BypassStackOutOfSyncError no Azure PowerShell (ou bypass-stack-out-of-sync-error na CLI do Azure). Essa opção só deve ser usada após uma revisão cuidadosa da lista de recursos na pilha antes de executar o comando novamente. Essa opção nunca deve ser usada 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: excluir 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>'

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>'

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 exibir os recursos gerenciados dentro de uma pilha de implantação, use os seguintes comandos do Azure PowerShell/CLI do Azure:

Para exibir recursos gerenciados no escopo 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 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. Você deseja armazenar pilhas no escopo pai. Por exemplo, para proteger recursos em uma assinatura, você deve colocar 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, não às operações do plano de dados. Por exemplo, contas de armazenamento e cofres de chaves são criados por meio do plano de controle, permitindo que eles sejam gerenciados por uma pilha de implantação. No entanto, recursos filho, como segredos ou contêineres de blob, que são criados por meio do plano de dados, não podem ser gerenciados por uma pilha de implantação.

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 de pilha 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 tenha acesso explicitamente concedido. 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 uma pilha de implantação for criada 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 atribuição de negação:

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 tenha 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 uma pilha de implantação for criada 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 de RBAC (controle de acesso baseado em função) 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 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, confira Início rápido: criar uma pilha de implantação.

Compartilhar via