Arquitetura de referência empresarial do DevTest Labs

Este artigo fornece diretrizes de arquitetura de referência para o Azure DevTest Labs em uma empresa. A arquitetura inclui os seguintes elementos principais:

• Conectividade local por meio do Azure ExpressRoute
• Um gateway de área de trabalho remota para se conectar remotamente a máquinas virtuais (VMs)
• Conectividade com um repositório de artefato privado
• Outros componentes de PaaS (plataforma como serviço) que os laboratórios usam

Arquitetura

O diagrama a seguir mostra uma implantação empresarial típica do DevTest Labs. Essa arquitetura conecta vários laboratórios em diferentes assinaturas do Azure à rede local de uma empresa.

Componentes do DevTest Labs

O DevTest Labs torna fácil e rápido o acesso das empresas aos recursos Azure. Cada laboratório contém recursos de SaaS (software como serviço), IaaS (infraestrutura como serviço) e PaaS. Os usuários de laboratório podem criar e configurar VMs, ambientes de PaaS e artefatos de VM.

No diagrama anterior, o Team Lab 1 na Assinatura 1 do Azure mostra um exemplo de componentes do Azure que os laboratórios podem acessar e usar. Para saber mais, confira Sobre atualizações.

Componentes de conectividade

Você precisará de conectividade local se seus laboratórios precisarem acessar recursos corporativos locais. Os cenários mais comuns são:

• Alguns dados locais não podem ser movimentados para a nuvem.
• Você deseja ingressar VMs de laboratório em um domínio local.
• Você deseja forçar todo o tráfego de rede de nuvem por meio de um firewall local por motivos de segurança ou conformidade.

Essa arquitetura usa o ExpressRoute para conectividade com a rede local. Mas você também pode usar uma VPN de site a site.

Localmente, um gateway de área de trabalho remota permite conexões RDP (protocolo RDP) de saída para o DevTest Labs. Enterprise firewalls corporativos geralmente bloqueiam conexões de saída no firewall corporativo. Para habilitar a conectividade, você terá que:

• Usar um gateway de área de trabalho remota e permitir o endereço IP estático do balanceador de carga do gateway.
• Use o túnel forçado para redirecionar todo o tráfego RDP de volta pela conexão VPN do ExpressRoute ou site a site. O túnel forçado é uma funcionalidade comum para implantações de DevTest Labs em escala empresarial.

Componentes de rede

Nessa arquitetura, o Microsoft Entra ID fornece gerenciamento de identidade e acesso em todas as redes. As VMs de laboratório geralmente têm uma conta administrativa local para acesso. Se houver um Microsoft Entra ID no local ou um domínio do Microsoft Entra Domain Services disponível, você poderá ingressar as VMs de laboratório no domínio. Os usuários podem usar suas identidades baseadas em domínio para se conectar às VMs.

A topologia de rede do Azure controla como os recursos de laboratório acessam e se comunicam com redes locais e com a Internet. Essa arquitetura mostra uma maneira comum de as empresas da rede DevTest Labs. Os laboratórios se conectam com redes virtuais ponto a ponto em uma configuração hub-spoke, por meio da conexão VPN site a site ou do ExpressRoute, com a rede local.

No entanto, como o DevTest Labs usa diretamente a Rede Virtual do Azure, não há restrições sobre como configurar a infraestrutura de rede. Você pode configurar um grupo de segurança de rede para restringir o tráfego de nuvem com base nos endereços IP de origem e de destino. Por exemplo, para permitir que apenas o tráfego originado na rede corporativa chegue às redes do laboratório.

Considerações sobre escalabilidade

O DevTest Labs não tem cotas ou limites integrados, mas outros recursos do Azure que os laboratórios usam têm cotas no nível da assinatura. Portanto, em uma implantação empresarial típica, você precisa de várias assinaturas do Azure para abranger uma grande implantação do DevTest Labs. As empresas geralmente atingem as seguintes cotas:

• Grupos de recursos. O DevTest Labs cria um grupo de recursos para cada nova VM e os usuários de laboratório criam ambientes em grupos de recursos. As assinaturas podem conter até 980 grupos de recursos, portanto, esse é o limite de VMs e ambientes em uma assinatura.

  Duas estratégias podem ajudá-lo a permanecer sob os limites do grupo de recursos:

  • Todas as VMs existem no mesmo grupo de recursos. Essa estratégia ajuda você a atingir o limite do grupo de recursos, mas afeta o limite de tipo de recurso por grupo de recursos.
  • Use IPs públicos compartilhados. Se as VMs têm permissão para ter endereços IP públicos, coloque todas as VMs do mesmo tamanho e região no mesmo grupo de recursos. Essa configuração ajuda a atender às cotas do grupo de recursos e às cotas de tipo de recurso por grupo de recursos.

• Recursos por grupo de recursos, por tipo de recurso. O limite padrão de recursos por tipo de recurso por tipo de recurso é 800. Colocar todas as VMs no mesmo grupo de recursos atinge este limite muito mais cedo, especialmente se as VMs tiverem muitos discos extras.

• Contas de armazenamento. Cada laboratório do DevTest Labs é fornecido com uma conta de armazenamento. A cota do Azure para o número de contas de armazenamento por região por assinatura é 250. O número máximo de DevTest Labs na mesma região também é de 250. Com um aumento de cota, você pode criar até 500 contas de armazenamento por região. Para obter mais informações, consulte Aumentar as cotas da conta de Armazenamento do Microsoft Azure.

• Atribuições de funções. Uma atribuição de funções dá a um usuário ou principal acesso a um recurso. Azure tem um limite de 2.000 atribuições de função por assinatura.

  Por padrão, o serviço DevTest Labs cria um grupo de recursos para cada VM. O proprietário recebe permissão de proprietário para a VM do DevTest Labs e de leitor ao grupo de recursos. Portanto, cada VM de laboratório usa duas atribuições de função. Conceder permissões de usuário ao laboratório também usa atribuições de função.

• Leituras/gravações de API. Você pode automatizar o Azure e o DevTest Labs usando APIs REST, PowerShell, CLI do Azure e SDK do Azure. Em cada assinatura do Azure, é possível ter até 12.000 solicitações de leitura por hora e 1.200 solicitações de gravação por hora. Ao automatizar o DevTest Labs, você pode atingir o limite de solicitações de API.

Considerações sobre capacidade de gerenciamento

Você pode usar o portal do Azure para gerenciar uma única instância do DevTest Labs por vez, mas as empresas podem ter várias assinaturas do Azure e muitos laboratórios para administrar. Fazer alterações consistentemente em todos os laboratórios requer scripts/automação.

Aqui estão alguns exemplos de como usar scripts em implantações do DevTest Labs:

• Salvando as configurações de laboratório. Atualize uma configuração de laboratório específica em todos os laboratórios usando scripts do PowerShell, CLI do Azure ou APIs REST. Por exemplo, atualize todos os laboratórios para permitir um novo tamanho de instância de VM.

• Atualizando PATs (tokens de acesso pessoal) do repositório de artefatos. Os PATs para repositórios Git normalmente expiram em 90 dias, um ano ou dois anos. Para garantir a continuidade, é importante estender o PAT. Ou crie um novo PAT e use a automação para aplicá-lo a todos os laboratórios.

• Restringir alterações às configurações de laboratório. Para restringir determinadas configurações, como permitir o uso de imagens do marketplace, você pode usar Azure Policy para evitar alterações em um tipo de recurso. Também é possível criar uma função personalizada e concedê-la aos usuários, em vez da função de proprietário do laboratório. Você pode restringir as alterações para a maioria das configurações de laboratório, como suporte interno, anúncios de laboratório e tamanhos de VM permitidos.

• Aplicando uma convenção de nome por VMs. Você pode usar Azure Policy para especificar um padrão de nome entre as VMs que ajudam a identificar VMs em ambientes baseados em nuvem.

Você gerencia os recursos do Azure para DevTest Labs da mesma maneira que para outras finalidades. Por exemplo, Azure Policy se aplica às VMs que você cria em um laboratório. O Microsoft Defender para Nuvem pode relatar a conformidade da VM. O Azure Backup pode fornecer backups regulares para VMs de laboratório.

Considerações de segurança

O DevTest Labs se beneficia automaticamente dos recursos de segurança do Azure integrados. Por exemplo, para exigir que as conexões de área de trabalho remota de entrada sejam originadas somente na rede corporativa, basta adicionar um grupo de segurança de rede à rede virtual no gateway de área de trabalho remota.

Outra consideração de segurança é o nível de permissão concedido aos usuários do laboratório. Os proprietários de laboratório usam o RBAC do Azure (controle de acesso baseado em função do Azure) para atribuir funções aos usuários e definir permissões de nível de acesso e recurso. As permissões mais comuns do DevTest Labs são Proprietário, Colaborador e Usuário. Você também pode criar e atribuir funções personalizadas. Para saber mais sobre essas funções, consulte Adicionar proprietários e usuários no Azure DevTest Labs.

Próximas etapas

Confira o próximo artigo desta série: Fornecer uma prova de conceito.