Gerenciar ambientes de desenvolvimento de aplicativos nas zonas de aterrissagem do Azure
Este artigo descreve como as equipes da plataforma de nuvem podem implementar guarda-corpos para gerenciar ambientes de aplicativos nas zonas de aterrissagem do Azure. Ele também explica como alinhar vários ambientes de desenvolvimento de aplicativos com sua estrutura. Um aspeto fundamental na criação do ambiente adequado é colocar assinaturas nos grupos de gerenciamento apropriados.
Estabeleça a base
As equipes de desenvolvimento exigem a capacidade de iterar rapidamente, e as equipes de plataforma e governança de nuvem precisam gerenciar o risco organizacional, a conformidade e a segurança em escala. Você pode gerenciar adequadamente os ambientes de aplicativos concentrando-se em dois princípios principais de design da zona de aterrissagem do Azure: governança orientada por políticas e democratização da assinatura. Esses princípios fornecem guarda-corpos fundamentais e descrevem como delegar controles às equipes de aplicativos. As equipes de aplicativos usam a orientação do Azure Well-Architected Framework para projetar sua carga de trabalho. Eles implantam e gerenciam seus próprios recursos da zona de aterrissagem, e a equipe da plataforma controla os recursos atribuindo políticas do Azure.
É importante fornecer recursos de área restrita para recursos semigovernados , para que as equipes de aplicativos possam experimentar tecnologias e recursos.
Quando os proprietários de aplicativos usam a venda automática de assinaturas ou outros processos de criação de assinaturas, eles devem saber como solicitar assinaturas para vários ambientes de desenvolvimento.
Este artigo descreve a zona de aterrissagem do Azure, incluindo os grupos de gerenciamento, as políticas e a arquitetura de plataforma compartilhada e a zona de aterrissagem de carga de trabalho ou de aplicativo.
Nota
A orientação neste artigo é apenas para cargas de trabalho ou zonas de aterrissagem de aplicativos. Para testar e segregar o ambiente para a própria plataforma de zona de aterrissagem do Azure, consulte Abordagem de teste para zonas de aterrissagem do Azure, que descreve a abordagem canária.
Na prática, você pode usar qualquer número e tipo de ambiente em fases. Este artigo faz referência aos seguintes ambientes em fases.
| Environment | Description | Grupo de gestão |
|---|---|---|
| Área restrita | O ambiente que é usado para a inovação rápida de protótipos, mas não configurações vinculadas à produção | Grupo de gerenciamento de sandbox |
| Desenvolvimento | O ambiente usado para criar potenciais candidatos a lançamento | Grupo de gestão de arquétipos, como corp ou online |
| Teste | O ambiente usado para executar testes, incluindo testes de unidade, testes de aceitação do usuário e testes de garantia de qualidade | Grupo de gestão de arquétipos, como corp ou online |
| Produção | O ambiente usado para entregar valor aos clientes | Grupo de gestão de arquétipos, como corp ou online |
Para obter mais informações, consulte os vídeos Manipulando ambientes de desenvolvimento, teste e produção para cargas de trabalho de aplicativos e Quantas assinaturas devo usar no Azure?
Ambientes, assinaturas e grupos de gerenciamento
Como pré-requisito para esta seção, consulte Área de design da organização de recursos.
Você deve organizar adequadamente suas assinaturas ao adotar as práticas da zona de aterrissagem do Azure. Idealmente, cada ambiente de aplicativo deve ter sua própria assinatura. Esse método fornece controles de segurança e de política que mantêm os ambientes isolados. Ele contém problemas potenciais para um ambiente.
Assinaturas separadas têm as mesmas políticas no nível do arquétipo. Se necessário, os proprietários de aplicativos podem atribuir políticas específicas de assinatura para impor o comportamento específico do aplicativo e do ambiente.
Algumas arquiteturas de aplicativos exigem que os serviços sejam compartilhados entre ambientes. Se esse for o caso, você pode usar uma única assinatura para vários ambientes. Recomendamos que os proprietários de carga de trabalho trabalhem com equipes de plataforma de nuvem para determinar se uma única assinatura para vários ambientes é necessária.
Use uma única assinatura para vários ambientes de aplicativos se:
Os ambientes não podem ser isolados em suas próprias assinaturas.
Os ambientes têm as mesmas equipes atribuídas a funções funcionais, como operadores de rede.
Os ambientes podem usar as mesmas políticas.
Se uma carga de trabalho de aplicativo ou serviço precisar estar em uma única assinatura e você precisar fazer alterações nas políticas que se aplicam a cada ambiente, você poderá:
Crie um novo grupo de gerenciamento alinhado ao arquétipo abaixo do grupo de gerenciamento de zonas de aterrissagem. Para obter mais informações, consulte Hierarquia do grupo de gerenciamento neste artigo.
Use assinaturas de área restrita para atividades de desenvolvimento. Os ambientes de teste têm um conjunto de políticas menos restritivo.
Use políticas aplicadas no nível de assinatura em vez do nível do grupo de gerenciamento. Você pode adicionar tags nas definições de política para ajudar a filtrar e aplicar políticas ao ambiente correto. Você também pode atribuir políticas ou excluí-las de grupos de recursos específicos.
Você pode atribuir políticas durante o processo de criação de assinatura como parte da vending de assinatura.
Para políticas que você implementa para ajudar a controlar custos, aplique a definição de política em um nível de assinatura quando necessário. Ou você pode tornar o proprietário da zona de desembarque responsável pelos custos, o que proporciona verdadeira autonomia. Para obter mais informações, consulte Automação de plataforma e DevOps.
Aviso
Ao contrário das políticas e controles no nível do grupo de gerenciamento, as políticas e tags baseadas em assinatura podem ser alteradas por indivíduos com permissões elevadas para a assinatura. Os administradores com funções apropriadas podem ignorar esses controles excluindo políticas, modificando políticas ou alterando as tags em recursos.
Como resultado, você não deve aplicar tags nas definições de políticas focadas em segurança. Além disso, não atribua permissões como sempre ativas para as seguintes ações:
Microsoft.Authorization/policyAssignments/*Microsoft.Authorization/policyDefinitions/*Microsoft.Authorization/policyExemptions/*Microsoft.Authorization/policySetDefinitions/*
Você pode controlar essas ações usando o Gerenciamento Privilegiado de Identidades (PIM).
Hierarquia do grupo de gestão
Evite hierarquias complicadas de grupos de gerenciamento. Podem exigir alterações frequentes, escalar de forma ineficiente e carecer de valor. Para evitar esses possíveis problemas, os grupos de gerenciamento de zona de aterrissagem do Azure são alinhados ao arquétipo da carga de trabalho. Para obter mais informações, consulte Grupo de gerenciamento e organização de assinatura.
Arquétipo alinhado significa que os grupos de gerenciamento são criados apenas para arquétipos de carga de trabalho específicos. Por exemplo, na arquitetura conceitual, o grupo de gerenciamento de zonas de pouso tem grupos de gerenciamento de filhos corp e online . Esses grupos de gerenciamento de filhos se alinham com padrões de arquétipo distintos para as cargas de trabalho que eles possuem. Os grupos de gerenciamento filho se concentram nos requisitos de conectividade híbrida (VPN/Rota Expressa do Azure), como aplicativos e serviços internos versus voltados para o público.
Excluindo ambientes de área restrita, vários ambientes de aplicativos devem usar o mesmo arquétipo para implantação. Mesmo que os ambientes sejam divididos em várias assinaturas, eles são mantidos dentro do mesmo grupo de gerenciamento único (corp ou online), com base no arquétipo do grupo de gerenciamento e nos requisitos.
Você pode usar assinaturas de área restrita para desenvolvimento não estruturado, como laboratórios pessoais ou para uma carga de trabalho que não tenha um arquétipo. Uma equipe de carga de trabalho de aplicativo ou serviço usa um grupo de gerenciamento de área restrita para testar vários serviços do Azure para determinar o que funciona melhor para seus requisitos. Depois de decidirem sobre os serviços, eles podem provisionar uma zona de pouso (no grupo de gerenciamento alinhado ao arquétipo da carga de trabalho correta na hierarquia do grupo de gerenciamento de zonas de pouso) para a equipe.
Os ambientes de área restrita podem ser usados para aplicativos específicos ou uma equipe de carga de trabalho pode usá-los para experimentação.
Para obter mais informações, consulte:
- Grupos de gestão.
- Área de design de organização de recursos.
- Personalize a arquitetura da zona de aterrissagem do Azure para atender aos requisitos.
Desafios do grupo de gestão baseada no ambiente
Os grupos de gerenciamento para ambientes dentro de arquétipos podem adicionar sobrecarga de gerenciamento e fornecer valor mínimo.
O grupo de gerenciamento de zonas de pouso deve ter políticas universais que imponham guarda-corpos para grupos de gerenciamento de crianças on-line e corp. Corp e online têm políticas exclusivas que aplicam as diretrizes da empresa relacionadas a cargas de trabalho públicas e privadas.
Muitas organizações criam grupos de gerenciamento separados para ambientes SDLC (ciclo de vida de desenvolvimento de software de carga de trabalho) para atribuir políticas e controles ambientais. Na prática, esse método cria mais desafios para as equipes de carga de trabalho do que resolve. Os ambientes SDLC não devem ter políticas diferentes, por isso não recomendamos grupos de gerenciamento separados.
Os proprietários de aplicativos podem alterar a topologia ou a configuração de recursos de uma carga de trabalho para alinhá-la às políticas em vários ambientes SDLC pelos quais ela é promovida. Este método aumenta o risco. Regras específicas para cada ambiente podem resultar em uma experiência de desenvolvimento ruim para as equipes de desenvolvimento e garantia de qualidade. Também podem surgir problemas se um aplicativo tiver um conjunto de políticas de guardrail que funcionam em um ambiente e o aplicativo for exposto a um conjunto diferente de políticas posteriormente em seu ciclo de promoção. Talvez seja necessário fazer ajustes em um aplicativo se os controles forem alterados.
Para evitar esse trabalho extra, crie políticas consistentes em toda a promoção de código em ambientes SDLC. Você não deve criar políticas para cada ambiente, mas sim fornecer um conjunto consistente para todos os ambientes de desenvolvimento, excluindo ambientes de área restrita.
Por exemplo, imagine que uma organização define uma política que exige que as contas de armazenamento sejam configuradas com regras de firewall específicas para impedir a entrada de redes públicas. Em vez disso, as contas de armazenamento usam pontos de extremidade privados dentro das redes da zona de aterrissagem do Azure para comunicação. Se o ambiente de desenvolvimento não tiver essa política, o teste da carga de trabalho não encontrará uma configuração incorreta da conta de armazenamento que permita acesso público. As implantações de teste funcionam no ambiente de desenvolvimento e são iteradas. Quando a solução é promovida para outro ambiente que tenha a política de conta de armazenamento, a implantação falha devido à política imposta.
Como resultado, a equipe de desenvolvimento de aplicativos deve retrabalhar sua implantação e arquitetura, depois de já investir um esforço significativo. Este exemplo demonstra como diferentes políticas em vários ambientes podem criar problemas.
Nota
A equação a seguir demonstra por que um grupo de gerenciamento separado para cada ambiente ou carga de trabalho não é bem dimensionado: N cargas de trabalho x Z grupos de gerenciamento = total de grupos de gerenciamento.
Se uma organização tiver 30 cargas de trabalho que exijam um grupo de gerenciamento e um grupo de gerenciamento filho para ambientes de desenvolvimento, teste e produção, a organização ficará com:
N = o número de cargas de trabalho/aplicações = 30
Z = o número de grupos de gerenciamento para a carga de trabalho e ambientes (1 para a carga de trabalho + 3 para os ambientes) = 4
N (30) x Z (4) = 120 grupos de gestão totais
Os proprietários de aplicativos podem precisar de políticas para aplicar de forma diferente a vários ambientes. Por exemplo, os proprietários de aplicativos podem precisar de configurações de backup para ambientes de produção, mas não para outros ambientes.
Algumas políticas podem ser habilitadas como políticas de auditoria no nível do grupo de gerenciamento. As equipes de aplicativos determinam como implementar o controle. Esse método não impede implantações, mas cria reconhecimento e permite que as equipes de aplicativos gerenciem suas necessidades exclusivas. Em seguida, eles podem criar políticas de subnível ou incorporar esses requisitos em sua infraestrutura como módulos de implantação de código (IaC).
Neste modelo de responsabilidade compartilhada, a equipe da plataforma audita as práticas e a equipe do aplicativo gerencia a implementação. Esse modelo pode melhorar a agilidade das implantações.
Os operadores de plataforma devem trabalhar com cada equipe de carga de trabalho de aplicativo ou serviço (proprietários de zona de pouso) para entender seus requisitos. Os operadores da plataforma podem fornecer assinaturas com base nos requisitos e planos do aplicativo. Os operadores de plataforma também podem decidir designar linhas de produtos para vários tipos de cargas de trabalho para que possam criar processos de criação de assinatura e ferramentas com base em requisitos comuns das equipes de carga de trabalho de aplicativos ou serviços.
Cenário: cargas de trabalho baseadas em máquina virtual (VM)
As primeiras cargas de trabalho nas zonas de aterrissagem do Azure geralmente são compostas por VMs do Azure. Você pode implantar essas cargas de trabalho no Azure ou migrá-las de datacenters existentes.
Em vez de implantar VMs em vários ambientes em uma única assinatura, você pode:
Estabeleça assinaturas para cada ambiente de aplicativo e coloque-as todas no mesmo grupo de gerenciamento de arquétipo.
Implante uma rede virtual para cada ambiente de aplicativo na assinatura apropriada. Você pode determinar o tamanho da rede virtual com base no tamanho do ambiente do aplicativo.
Implante as VMs em sua assinatura apropriada. As VMs podem usar SKUs diferentes e configurações de disponibilidade diferentes para cada ambiente, se apropriado.
Vários recursos do ambiente do aplicativo são protegidos por diferentes controles de acesso. Como resultado, quando os desenvolvedores de aplicativos configuram pipelines de implantação, a identidade de cada pipeline pode ser limitada ao ambiente. Essa configuração ajuda a proteger os ambientes contra implantações acidentais.
Cenário: Serviço de Aplicativo do Azure
Uma carga de trabalho com assinaturas ambientais que usam o Serviço de Aplicativo pode criar desafios. Para desenvolvedores de aplicativos, uma prática recomendada do Serviço de Aplicativo é usar slots de implantação para ajudar a gerenciar alterações e atualizações em um aplicativo Web.
No entanto, esse recurso só pode ser usado com o aplicativo que está no plano do Serviço de Aplicativo, que só pode viver em uma única assinatura. Se os operadores de plataforma exigirem que os proprietários de aplicativos usem assinaturas separadas para ambientes de desenvolvimento, teste e produção, o ciclo de vida da implantação do aplicativo poderá ser mais difícil de gerenciar.
Neste exemplo, a melhor opção é uma única assinatura para a carga de trabalho do aplicativo ou serviço. Os proprietários de aplicativos podem usar o RBAC (controle de acesso baseado em função) do Azure com o PIM no nível do grupo de recursos para aumentar a segurança.