Noções básicas sobre os modos de implantação
Máquinas virtuais, servidores lógicos e bancos de dados SQL do Azure, contas de armazenamento, redes virtuais e a maioria dos outros recursos do Azure precisam ser colocados em um grupo de recursos. No entanto, alguns recursos podem – ou devem – ser implantados de uma maneira diferente. Esses recursos são normalmente usados para controlar o comportamento do ambiente do Azure.
Nesta unidade, você examinará a hierarquia da organização de recursos do Azure e examinará como determinados recursos podem ser implantados em vários escopos.
A hierarquia de recursos do Azure
O Azure tem uma estrutura de recursos hierárquicos com vários níveis de gerenciamento. Este é um diagrama que mostra como a sua empresa de brinquedos pode organizar o ambiente do Azure:
Seu locatário corresponde à instância do Microsoft Entra. Uma organização normalmente tem apenas uma instância do Microsoft Entra. Essa instância funciona como a raiz da hierarquia de recursos.
Os grupos de gerenciamento fornecem uma forma de organizar assinaturas do Azure. Cada locatário tem um só grupo de gerenciamento raiz e você pode estabelecer uma hierarquia própria de grupos de gerenciamento nele. Você pode criar grupos de gerenciamento separados para as várias partes da sua organização ou para as assinaturas que têm requisitos próprios de segurança ou governança. É possível aplicar restrições de política e controle de acesso a grupos de gerenciamento, e todas as assinaturas abaixo desse grupo de gerenciamento na hierarquia herdarão essas restrições. Os grupos de gerenciamento não são implantados em regiões e não têm impacto sobre os locais de seus recursos.
As assinaturas funcionam como contas de cobrança e contêm recursos e grupos de recursos. Assim como os grupos de gerenciamento, as assinaturas não têm uma localização e não restringem o local em que os recursos são implantados.
Os grupos de recursos são contêineres lógicos para seus recursos. Com os grupos de recursos, você pode gerenciar e controlar os recursos relacionados como uma só unidade. Recursos como máquinas virtuais, planos do Serviço de Aplicativo do Azure, contas de armazenamento e redes virtuais precisam ser colocados em um grupo de recursos. Os grupos de recursos são criados em uma localização para que o Azure possa acompanhar os metadados dos recursos no grupo, mas os recursos dentro do grupo podem ser implantados em outras localizações.
O exemplo ilustrado anteriormente é um cenário razoavelmente básico que mostra como você pode usar os grupos de gerenciamento. Sua organização também pode considerar a implementação de uma zona de destino, que é um conjunto de recursos e configurações do Azure de que você precisa para começar a trabalhar com um ambiente de produção do Azure. A zona de destino de escala empresarial é uma abordagem comprovada para o uso de grupos de gerenciamento e assinaturas para gerenciamento efetivo dos seus recursos do Azure:
Independentemente do modelo que você seguir, compreendendo os vários níveis da hierarquia, você pode começar a aplicar controles flexíveis sobre como o seu ambiente do Azure é usado e gerenciado. Usando o Bicep, você pode gerenciar esses controles com todos os benefícios da infraestrutura como código.
Observação
Também há alguns outros recursos implantados em escopos específicos. Os recursos de extensão são implantados no escopo de outro recurso do Azure. Por exemplo, um bloqueio de recurso é um recurso de extensão que é implantado em um recurso, como uma conta de armazenamento.
Você já está familiarizado com a implantação de recursos em grupos de recursos. Portanto, vamos ver os outros escopos para implantação.
Recursos com escopo de assinatura
Você pode implantar recursos em uma assinatura quando:
- Precisa criar um grupo de recursos. Um grupo de recursos é, na verdade, apenas um recurso com escopo de assinatura.
- Precisa permitir acesso a todos os recursos de uma assinatura. Por exemplo, se o departamento de RH tiver uma assinatura do Azure que contenha todos os recursos do Azure do departamento, você poderá criar atribuições de função para permitir que todos no departamento de RH leiam o conteúdo da assinatura.
- Você está usando o Azure Policy e deseja definir ou aplicar uma política a todos os recursos da assinatura. Por exemplo, o departamento de P e D da sua empresa de brinquedos pediu para você implantar uma política que restringe a lista de SKUs de máquina virtual que podem ser criadas na assinatura da equipe.
Recursos com escopo de grupo de gerenciamento
Você pode implantar recursos em um grupo de gerenciamento quando:
Precisa permitir acesso a todos os recursos em todas as assinaturas que se enquadram na hierarquia do grupo de gerenciamento. Por exemplo, sua equipe de operações de nuvem pode exigir acesso a todas as assinaturas na sua organização. Você pode criar uma atribuição de função no grupo de gerenciamento raiz, o que permite à equipe de operações de nuvem acesso a tudo no Azure.
Cuidado
Seja extremamente cuidadoso ao permitir acesso a recursos usando grupos de gerenciamento e, especialmente, o grupo de gerenciamento raiz. Lembre-se de que cada recurso no grupo de gerenciamento na hierarquia herda a atribuição de função. Certifique-se de que sua organização siga as práticas recomendadas de gerenciamento e autenticação de identidade e que ela siga o princípio de privilégios mínimos; ou seja, não conceda nenhum acesso que não seja necessário.
Precisa aplicar políticas em toda a sua organização. Por exemplo, sua organização pode ter uma política que estabelece que os recursos não podem ser criados em determinadas regiões geográficas, em qualquer circunstância. Você pode aplicar uma política ao grupo de gerenciamento raiz, que bloqueará a criação de recursos nessa região.
Observação
Antes de usar grupos de gerenciamento pela primeira vez, configure-os para o seu ambiente do Azure.
Recursos com escopo de locatário
Você pode implantar recursos no seu locatário quando:
Precisa criar assinaturas do Azure. Quando você usa grupos de gerenciamento, as assinaturas residem em grupos de gerenciamento na hierarquia de recursos, mas uma assinatura é implantada como um recurso com escopo de locatário.
Observação
Nem todos os clientes do Azure podem criar assinaturas usando a infraestrutura como código. Dependendo do seu relacionamento de cobrança com a Microsoft, talvez isso não seja possível. Para obter mais informações, confira Criar assinaturas do Azure de modo programático.
Você está criando ou configurando grupos de gerenciamento. O Azure cria um único grupo de gerenciamento raiz ao habilitar grupos de gerenciamento para o seu locatário, e você pode criar vários níveis de grupos de gerenciamento abaixo dele. Você pode usar o Bicep para definir toda a hierarquia do grupo de gerenciamento. Você também pode atribuir assinaturas a grupos de gerenciamento.
Com o Bicep, você pode enviar implantações para o escopo de locatário. As implantações com escopo de locatário exigem permissão especial. No entanto, na prática, não é preciso enviar implantações com escopo de locatário. Em vez disso, é mais simples implantar recursos com escopo de locatário usando um modelo em outro escopo. Você verá como fazer isso mais adiante no módulo.
Dica
Não é possível criar políticas nem atribuições de função no escopo de locatário. No entanto, se você precisar permitir acesso ou aplicar políticas em toda a organização, poderá implantar esses recursos no grupo de gerenciamento raiz.
IDs de recurso
Agora, você está familiarizado com as IDs dos recursos que residem nas assinaturas. Por exemplo, esta é uma ID de recurso que representa um grupo de recursos, que é um recurso com escopo de assinatura:
/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyDevelopment
Veja abaixo uma representação visual das mesmas informações:
As assinaturas em si têm IDs próprias, como esta:
/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e
Observação
Embora as assinaturas sejam consideradas filhos de grupos de gerenciamento, as IDs de recurso não incluem uma ID de grupo de gerenciamento. O Azure controla a relação entre assinaturas e grupos de gerenciamento de uma maneira diferente de outras relações de recursos. Isso proporciona a você a flexibilidade de mover assinaturas entre grupos de gerenciamento sem precisar alterar todas as IDs de recurso.
Quando você trabalha com recursos em um grupo de gerenciamento ou um escopo de locatário, as IDs de recurso podem parecer um pouco diferentes do normal. Na maioria das vezes, elas seguem o padrão de intercalação do tipo de recurso com as informações sobre seus recursos específicos. No entanto, o formato específico depende do recurso com o qual você está trabalhando.
Este é um exemplo de ID de recurso para um grupo de gerenciamento:
/providers/Microsoft.Management/managementGroups/ProductionMG
Esta é a aparência dela:
Observação
Os grupos de gerenciamento têm um identificador e um nome de exibição. O nome de exibição é uma descrição legível do grupo de gerenciamento. Você pode alterar o nome de exibição sem afetar a ID do grupo de gerenciamento.
Quando um recurso é implantado em um escopo de grupo de gerenciamento, a ID do recurso inclui a ID do grupo de gerenciamento. Este é um exemplo de ID de recurso para uma definição de função que foi criada em um escopo de grupo de gerenciamento:
/providers/Microsoft.Management/managementGroups/ProductionMG/providers/Microsoft.Authorization/roleDefinitions/00000000-0000-0000-0000-000000000000
Veja abaixo uma representação visual da mesma ID:
Outra definição de função pode ser definida em um escopo de assinatura. Portanto, a ID do recurso será um pouco diferente:
/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Authorization/roleDefinitions/00000000-0000-0000-0000-000000000000
Veja abaixo uma representação visual da mesma ID:
Agora que você entende a hierarquia de recursos do Azure e os tipos de recursos que você pode implantar em cada escopo, você pode tomar decisões sobre os escopos nos quais implantar seus recursos. Por exemplo, você pode fazer uma escolha informada sobre se uma definição de política deve ser criada no escopo de um grupo de recursos, uma assinatura ou um grupo de gerenciamento. Na próxima unidade, você aprenderá a criar arquivos Bicep direcionados a cada um desses escopos.