Partilhar via


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 entrar remotamente 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

Arquitetura

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.

Diagrama que mostra uma arquitetura de referência para uma implantação corporativa do DevTest Labs.

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 recursos de software como serviço (SaaS), infraestrutura como serviço (IaaS) e 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.

Componentes de conectividade

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 por motivos de segurança ou conformidade.

Essa arquitetura usa a Rota Expressa para conectividade com a rede local. Você também pode usar uma VPN site a site.

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

  • Use um gateway de área de trabalho remota e permita 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 Rota Expressa ou conexão VPN site a site. O túnel forçado é uma funcionalidade comum para implantações do 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 uma ID do Microsoft Entra, local ou domínio dos Serviços de Domínio Microsoft Entra disponível, você poderá associar 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 uma maneira comum de as empresas conectarem o DevTest Labs. Os laboratórios se conectam a redes virtuais emparelhadas em uma configuração hub-spoke, por meio da Rota Expressa ou 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.

Considerações de escalabilidade

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:

  • Grupos de recursos. 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 abaixo dos limites do grupo de recursos:

    • Todas as VMs vão 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 ajuda a atender às cotas de 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 para recursos por grupo de recursos por tipo de recurso é 800. Colocar todas as VMs no mesmo grupo de recursos atinge esse limite muito mais cedo, especialmente se as VMs tiverem muitos discos extras.

  • Contas de armazenamento. 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.

  • Atribuições de funções. Uma atribuição de função dá a um usuário ou principal acesso a um recurso. O Azure tem um limite de 2.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 para o laboratório também usa atribuições de função.

  • A API lê/grava. 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. Ao automatizar o DevTest Labs, você pode atingir o limite de solicitações de API.

Considerações sobre a capacidade de gestão

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 VM.

  • 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 crie uma nova PAT e use a automação para aplicá-la 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 você pode criar uma função personalizada e conceder aos usuários essa função em vez de uma função de laboratório interna. 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 DevTest Labs da mesma maneira que para outras finalidades. Por exemplo, a Política do Azure se aplica às VMs criadas 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.

Considerações de segurança

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.

Próximos passos

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