O que são pilhas de implantação?
Uma pilha de implantação do Azure é um tipo de recurso do Azure que permite gerenciar o ciclo de vida de uma coleção de recursos do Azure como uma única unidade atômica, mesmo que eles abranjam vários grupos de recursos ou assinaturas. Ele permite implantações consistentes e repetíveis, simplifica o gerenciamento e permite o dimensionamento e a atualização eficientes de recursos.
Nesta unidade, você aprenderá sobre a organização de recursos no Azure e como as pilhas de implantação podem ajudá-lo a gerenciar seus recursos de maneiras que não eram possíveis antes.
Organização de recursos
Há muitas maneiras de organizar seus recursos no Azure. Você pode optar por organizar recursos com base em um ambiente (produção, preparação, desenvolvimento), um ciclo de vida do aplicativo ou uma função (por exemplo, conectividade ou recursos de computação). Fatores como o tamanho da sua organização, o número de aplicativos e a residência de dados influenciam essas decisões, e há práticas recomendadas gerais para cada cenário.
Para ambientes de implantação, você pode separá-los em assinaturas diferentes ou até mesmo grupos de gerenciamento. Todos os componentes de um aplicativo podem existir em um único grupo de recursos, vários grupos de recursos ou até mesmo várias assinaturas. Para a organização de recursos do Azure, as práticas recomendadas sugerem a organização de recursos em grupos de recursos com base no ciclo de vida e na segurança.
Aplicativo de grupo de recursos únicos
Há momentos em que usar um único grupo de recursos para seu aplicativo faz sentido. Se você é novo no Azure e está apenas começando com um ambiente de desenvolvimento ou implantando um aplicativo de produção sem muitos recursos, um único grupo de recursos pode funcionar.
Um grupo de recursos é frequentemente usado como um limite de segurança para permissões. Você pode gerenciar uma única atribuição de controle de acesso baseado em função (RBAC) no escopo do grupo de recursos se seus requisitos de segurança não forem rigorosos.
Digamos que seu aplicativo consiste em um serviço de aplicativo, insights de aplicativos e um banco de dados SQL implantado em um único grupo de recursos. Sua organização tem equipes separadas para gerenciar computação, aplicativos Web e bancos de dados. Se a política de segurança da sua organização exigir RBAC granular, é necessário definir o escopo das permissões no escopo do recurso em vez do escopo do grupo de recursos.
Com o tempo, é possível que recursos não relacionados ao aplicativo também sejam implantados no mesmo grupo de recursos. Por exemplo, um colega seu implanta um novo Cofre de Chaves do Azure e escolhe acidentalmente o grupo de recursos errado no momento da implantação. Esse cenário pode dificultar a determinação de quais recursos pertencem a qual aplicativo e pode levar a problemas como a exclusão acidental de um recurso crítico.
Aplicativo de grupo de vários recursos
O que acontece quando seu aplicativo é dimensionado até o ponto em que uma alteração é necessária? Pode ser necessário pegar partes do seu aplicativo e dividi-las em grupos de recursos separados para controles de segurança simplificados. Por exemplo, você pode colocar todos os recursos de computação no grupo de recursos de computação, os recursos de aplicativo no grupo de recursos de aplicativo e todos os bancos de dados no grupo de recursos de banco de dados.
Esse modelo permite que você defina o escopo de permissões para as equipes de computação, aplicativo e banco de dados para seus grupos de recursos apropriados. Embora essa prática possa resolver um problema, você introduziu o gerenciamento descentralizado. Como a maioria das implantações no Azure tem como escopo o grupo de recursos, você não tem mais a capacidade de gerenciar os recursos como uma única unidade.
Se os recursos do aplicativo forem implantados em grupos de recursos separados, pode ser difícil identificar quais recursos fazem parte do aplicativo. Você pode usar as Marcas do Azure para ajudar a identificar recursos em um aplicativo, mas é possível que um recurso não esteja marcado corretamente.
As operações de implantação podem precisar ser executadas mais de uma vez no modelo de grupo de vários recursos. Quando você implanta recursos, dependendo do seu método de implantação, pode ser necessário executar vários comandos de implantação. A maioria das implantações no Azure tem como escopo o grupo de recursos, portanto, seria necessário implantar seus recursos de rede primeiro, seguidos pelos recursos do aplicativo. O mesmo se aplica às operações de eliminação. Se você precisar remover todos os grupos de recursos relacionados ao aplicativo, talvez seja necessário executar várias operações de exclusão.
Inserir pilhas de implantação
As pilhas de implantação alteram a forma como você pensa sobre a organização de recursos em grupos de recursos e assinaturas. Uma pilha de implantação permite que você agrupe todos os recursos que compõem seu aplicativo, independentemente de onde eles estejam em sua hierarquia organizacional de recursos do Azure. Você pode gerenciá-los como uma única unidade. Com pilhas de implantação, você pode executar operações de ciclo de vida na coleção de recursos que compõem a pilha.
Pense nas pilhas de implantação como uma série de ponteiros que agrupam os recursos do seu aplicativo em uma única unidade. As pilhas de implantação podem ser criadas em escopos diferentes, como grupos de recursos, assinaturas e grupos de gerenciamento.
Considere o exemplo anterior. Ao implantar seu aplicativo e seus recursos com uma única pilha, com escopo no nível de assinatura e entre grupos de recursos, agora você pode gerenciar o aplicativo como uma única unidade. Cada grupo de recursos e seus recursos são gerenciados pela pilha.
Usando pilhas de implantação
Quais operações podem ser executadas em pilhas de implantação? Você pode criar, listar, atualizar e excluir pilhas de implantação. Para recursos, você pode visualizar os recursos na pilha, adicionar e remover recursos dentro da pilha e proteger a pilha e seus recursos contra exclusão.
Criar e implantar uma pilha de implantação e seus recursos é quase idêntico a uma implantação padrão do Azure e usa os mesmos modelos JSON ARM, arquivos Bicep ou especificações de modelo que você está acostumado. Por exemplo:
O comando da CLI do Azure para implantar um arquivo Bicep em um grupo de recursos é:
az deployment group create \
--resource-group rg-depositsApplication \
--template-file ./main.bicep
O comando da CLI do Azure para criar uma pilha de implantação no escopo do grupo de recursos é:
az stack group create \
--name stack-deposits \
--resource-group rg-depositsApplication \
--template-file ./main.bicep \
--action-on-unmanage detachAll \
--deny-settings-mode none
As pilhas de implantação permitem uma limpeza eficiente do ambiente. As pilhas de implantação permitem que você exclua a pilha e todos os seus recursos por meio de uma única chamada de API, sem a necessidade de entender as dependências. Este recurso simplifica a remoção dos recursos de forma confiável, melhora a velocidade de remoção de recursos. Por exemplo:
O comando da CLI do Azure para excluir uma pilha de implantação no escopo do grupo de recursos junto com seus recursos é:
az stack group delete \
--name stack-deposits \
--resource-group rg-depositsApplication \
--action-on-unmanage detachAll
Nota
Você já pode usar implantações de modo completo como parte de uma estratégia de implantação existente. Se você fizer isso, considere as pilhas de implantação como a próxima evolução, bem como uma opção mais segura.
Recursos geridos
Quando você envia um arquivo Bicep, modelo JSON ARM ou especificação de modelo para uma pilha de implantação, a pilha se torna responsável pelo gerenciamento dos recursos descritos no arquivo. Os recursos gerenciados pela pilha são conhecidos como recursos gerenciados, mas esses recursos ainda são modificados por meio dos arquivos de modelo originais.
Se um recurso não precisar mais ser gerenciado pela pilha de implantação, você poderá modificá-la para não incluir mais o recurso. A ação sobre o comportamento não gerenciado de uma pilha de implantação determina o que acontece com um recurso que é removido da definição da pilha de implantação. Esse comportamento, discutido posteriormente na unidade, determina se um recurso, grupo de recursos ou grupos de gerenciamento é desanexado ou excluído da pilha.
Negar configurações
Além disso, você pode configurar uma "configuração de negação" para a pilha e seus recursos que impedem alterações não autorizadas. Essas atribuições de negação são personalizáveis. Você pode definir o modo como sem sinalizador, negar exclusão ou negar gravação e exclusão, o que pode soar semelhante aos bloqueios do Azure. Além disso, você pode excluir ações específicas ou entidades de serviço das atribuições de negação. Considere negar configurações uma camada extra de proteção contra modificações e exclusões acidentais.