Arquitetura de referência empresarial do DevTest Labs

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

• Conectividade local através do Azure ExpressRoute
• Um gateway de área de trabalho remota para entradas remotas em máquinas virtuais (VMs)
• Conectividade com um repositório privado de artefatos
• Outros componentes de plataforma como serviço (PaaS) que os laboratórios usam

Architecture

O diagrama a seguir mostra uma implantação corporativa 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 para as empresas fornecer acesso aos recursos do Azure. Cada laboratório contém software como serviço (SaaS), infraestrutura como serviço (IaaS) e recursos de PaaS. Os usuários do laboratório podem criar e configurar VMs, ambientes PaaS e artefatos de VM.

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

Connectivity components

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

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

Esta arquitetura usa ExpressRoute para ligar à rede local. Você também pode usar uma VPN de site a site.

No local, um gateway de área de trabalho remota permite conexões de saída RDP (protocolo de área de trabalho remota) para DevTest Labs. As empresas geralmente bloqueiam as conexões de saída no firewall corporativo. Para habilitar a conectividade, você pode:

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

Networking components

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, infraestrutura local, ou um domínio de Serviços de Domínio Microsoft Entra disponível, poderá associar as VMs de laboratório ao 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 a Internet. Essa arquitetura mostra um método comum que as empresas usam para conectar DevTest Labs. Os laboratórios conectam-se a redes virtuais emparelhadas numa configuração hub-spoke, através da ExpressRoute ou de uma conexão VPN site a site, à rede local.

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

Scalability considerations

O DevTest Labs não tem cotas ou limites internos, mas outros recursos do Azure que os laboratórios usam têm cotas de nível de assinatura. Em uma implantação corporativa típica, você precisa de várias assinaturas do Azure para cobrir uma grande implantação do DevTest Labs. Normalmente, as empresas atingem as seguintes quotas:

• Resource groups. O DevTest Labs cria um grupo de recursos para cada nova VM e os usuários do 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 dentro dos limites do grupo de recursos:

  • Coloque todas as VMs no mesmo grupo de recursos. Essa estratégia ajuda você a atingir o limite do grupo de recursos, mas afeta o limite do tipo de recurso por grupo de recursos.
  • Use IPs públicos compartilhados. Se as VMs tiverem 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 pode ajudá-lo a cumprir as cotas de grupo de recursos e as cotas de tipo de recurso por grupo de recursos.

• Recursos por grupo de recursos, por tipo de recurso. O limite padrão para recursos por grupo de recursos, por tipo de recurso, é 800. Se você colocar todas as VMs no mesmo grupo de recursos, atingirá esse limite muito mais cedo, especialmente se as VMs tiverem muitos discos extras.

• Storage accounts. Cada laboratório no DevTest Labs vem com uma conta de armazenamento. A cota do Azure para o número de contas de armazenamento por região por assinatura é 250 por padrão. Portanto, o número máximo de laboratórios DevTest em uma região também é 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 Azure.

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

  Por padrão, o DevTest Labs cria um grupo de recursos para cada VM de laboratório. O criador da VM obtém permissão de proprietário para a VM e permissão de leitor para o grupo de recursos. Assim, cada VM de laboratório usa duas atribuições de função. A concessão de permissões de usuário ao laboratório também usa atribuições de função.

• API reads/writes. Você pode automatizar o Azure e o DevTest Labs usando APIs REST, PowerShell, CLI do Azure e SDK do Azure. Cada assinatura do Azure permite até 12.000 solicitações de leitura e 1.200 solicitações de gravação por hora. Se você automatizar o DevTest Labs, poderá atingir o limite de solicitações de API.

Manageability considerations

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

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

• Alterar as configurações do 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 máquina virtual.

• Atualização de tokens de acesso pessoal (PATs) 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 ampliar o PAT. Ou pode criar uma nova PAT e utilizar a automatização para a aplicar a todos os laboratórios.

• Restringir as alterações às configurações do laboratório. Para restringir determinadas configurações, como permitir o uso de imagens do marketplace, você pode usar a Política do Azure para impedir alterações em um tipo de recurso. Ou pode criar uma função personalizada e atribuir aos utilizadores essa função em vez de uma função de laboratório pré-definida. 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.

• Aplicação de uma convenção de nomenclatura para VMs. Você pode usar a Política do Azure para especificar um padrão de nomenclatura que ajude a identificar VMs em ambientes baseados em nuvem.

Você gerencia os recursos do Azure para o DevTest Labs da mesma maneira que faz para outras finalidades. Por exemplo, a Política do Azure se aplica a VMs que você cria em um laboratório. O Microsoft Defender for Cloud pode relatar a conformidade de VM de laboratório. O Backup do Azure pode fornecer backups regulares para VMs de laboratório.

Security considerations

O DevTest Labs se beneficia automaticamente dos recursos de segurança internos do Azure. Para exigir que as conexões de entrada da área de trabalho remota sejam originadas somente da rede corporativa, você pode adicionar um grupo de segurança de rede à rede virtual no gateway da área de trabalho remota.

Outra consideração de segurança é o nível de permissão que você concede aos usuários do laboratório. Os proprietários do laboratório usam o controle de acesso baseado em função do Azure (Azure RBAC) para atribuir funções aos usuários e definir permissões de nível de recurso e acesso. 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 obter mais informações, consulte Adicionar proprietários e usuários no Azure DevTest Labs.

Next step

Veja o próximo artigo desta série: Entregue uma prova de conceito