Aumente a escala da infraestrutura do Azure DevTest Labs

Orquestrar uma implementação bem-sucedida do DevTest Labs em escala empresarial requer consideração dos principais pontos de decisão e planejamento de uma abordagem para implantação e implementação rápidas do Azure DevTest Labs.

Este artigo descreve os principais pontos de decisão que você deve considerar ao planejar sua implementação e fornece uma abordagem recomendada para implantação.

Principais pontos de decisão

Antes de implementar o DevTest Labs em escala empresarial, há vários pontos de decisão importantes. Entender esses pontos de decisão em um alto nível ajuda uma organização com decisões de design no futuro. No entanto, esses pontos não devem impedir uma organização de iniciar uma prova de conceito.

As três principais áreas para o planejamento inicial de expansão são:

• Redes e segurança
• Topologia de subscrição
• Funções e responsabilidades

Redes e segurança

Rede e segurança são pedras angulares para todas as organizações. Embora uma implantação em toda a empresa exija uma análise muito mais profunda, há um número reduzido de requisitos para realizar com êxito uma prova de conceito. Algumas das principais áreas de enfoque incluem:

• Assinatura do Azure – Para implantar o DevTest Labs, você deve ter acesso a uma assinatura do Azure com direitos apropriados para criar recursos. Há várias maneiras de obter acesso a assinaturas do Azure, incluindo um Enterprise Agreement e o Pay As You Go. Para obter mais informações sobre como obter acesso a uma assinatura do Azure, consulte Licenciando o Azure para empresas.
• Acesso a recursos locais – Algumas organizações exigem que seus recursos no DevTest Labs tenham acesso a recursos locais. Você precisa de uma conexão segura do seu ambiente local com o Azure. É importante configurar uma conexão VPN ou Azure ExpressRoute antes de começar. Para obter mais informações, consulte Visão geral de redes virtuais.
• Outros requisitos de segurança – Outros requisitos de segurança, como políticas de máquina, acesso a endereços IP públicos, conexão à internet são cenários que podem precisar ser revisados antes de implementar uma prova de conceito.

Topologia de subscrição

A topologia de assinatura é uma consideração crítica de design ao implantar o DevTest Labs na empresa. No entanto, não é necessário solidificar todas as decisões até que uma prova de conceito tenha sido concluída. Ao avaliar o número de assinaturas necessárias para uma implementação corporativa, há dois extremos:

• Uma subscrição para toda a organização
• Subscrição por utilizador

A seguir, destacamos as vantagens de cada abordagem.

Uma subscrição

Muitas vezes, a abordagem de uma assinatura não é gerenciável em uma grande empresa. No entanto, limitar o número de assinaturas oferece os seguintes benefícios:

• Previsão de custos para empresas. O orçamento se torna muito mais fácil em uma única assinatura porque todos os recursos estão em um único pool. Essa abordagem permite uma tomada de decisão mais simples sobre quando exercer medidas de controle de custos a qualquer momento em um ciclo de faturamento.
• A capacidade de gerenciamento de VMs, artefatos, fórmulas, configuração de rede, permissões e políticas é mais fácil, pois todas as atualizações são necessárias apenas em uma assinatura, em vez de fazer atualizações em muitas assinaturas.
• O esforço de rede é mais simples em uma única assinatura para empresas onde a conectividade local é um requisito. A conexão de redes virtuais entre assinaturas (modelo hub-spoke), necessária com assinaturas adicionadas, requer mais configuração, gerenciamento e espaços de endereço IP.
• A colaboração em equipe é mais fácil quando todos estão trabalhando na mesma assinatura. Por exemplo, é mais fácil reatribuir uma VM a um colega de trabalho ou compartilhar recursos da equipe.

Subscrição por utilizador

Uma subscrição separada por utilizador proporciona oportunidades iguais para o espectro alternativo. Os benefícios de ter muitas assinaturas incluem:

• As cotas de dimensionamento do Azure não impedirão a adoção. Por exemplo, no momento em que este artigo foi escrito, o Azure permite 200 contas de armazenamento por assinatura. Há cotas operacionais para a maioria dos serviços no Azure (muitos podem ser personalizados, outros não). Neste modelo de subscrição por utilizador, é altamente improvável que a maioria das quotas seja atingida. Para obter mais informações sobre as cotas de dimensionamento atuais do Azure, consulte Limites de assinatura, cotas e restrições de serviço e assinatura do Azure.
• Os estornos para grupos ou desenvolvedores individuais tornam-se muito mais fáceis , permitindo que as organizações contabilizem os custos usando seu modelo atual.
• A propriedade e as permissões dos ambientes do DevTest Labs são simples. Você dá aos desenvolvedores o acesso no nível de assinatura e eles são 100% responsáveis por tudo, incluindo a configuração de rede, políticas de laboratório e gerenciamento de VM.

Na Enterprise, pode haver restrições suficientes nos extremos do espectro. Portanto, você pode precisar configurar assinaturas de uma forma que caia no meio desses extremos. Como prática recomendada, o objetivo de uma organização deve ser usar o número mínimo de assinaturas possível. Tenha em mente as funções forçadas que aumentam o número total de assinaturas. Para reiterar, a topologia de assinatura é crítica para uma implantação corporativa do DevTest Labs, mas não deve atrasar uma prova de conceito. Há mais detalhes no artigo Governança sobre como decidir sobre assinatura e granularidade de laboratório na organização.

Funções e responsabilidades

Uma prova de conceito do DevTest Labs tem três funções principais com responsabilidades definidas – proprietário da assinatura, proprietário do DevTest Labs, usuário do DevTest Labs e, opcionalmente, um colaborador.

• Proprietário da assinatura – O proprietário da assinatura tem direitos para administrar uma Assinatura do Azure, incluindo a atribuição de usuários, o gerenciamento de políticas, a criação e o gerenciamento da topologia de rede e a solicitação de aumentos de cota. Para mais informações, consulte este artigo.
• Proprietário do DevTest Labs – O proprietário do DevTest Labs tem acesso administrativo total ao laboratório. Essa pessoa é responsável por adicionar/remover usuários, gerenciar configurações de custo, configurações gerais de laboratório e outras tarefas baseadas em VM/artefatos. Um proprietário de laboratório também tem todos os direitos de um usuário do DevTest Labs.
• Usuário do DevTest Labs – O usuário do DevTest Labs pode criar e consumir as máquinas virtuais no laboratório. Esses indivíduos têm alguns recursos administrativos mínimos em VMs que criam (iniciar/parar/excluir/configurar suas VMs). Os usuários não podem gerenciar VMs de outros usuários.

Orquestrar a implementação do DevTest Labs

Esta seção fornece uma abordagem recomendada para implantação e implementação rápidas do Azure DevTest Labs. A imagem a seguir enfatiza o processo geral como orientação prescritiva, observando a flexibilidade para dar suporte a vários requisitos e cenários do setor.

Suposições

Este artigo pressupõe que você tenha os seguintes itens em vigor antes de implementar um piloto do DevTest Labs:

• Assinatura do Azure: a equipe piloto tem acesso à implantação de recursos em uma assinatura do Azure. Se as cargas de trabalho forem apenas desenvolvimento e teste, é recomendável selecionar a oferta Enterprise DevTest para obter imagens adicionais disponíveis e taxas mais baixas em máquinas virtuais Windows.
• Acesso local: se necessário, o acesso local já foi configurado. O acesso local pode ser realizado por meio de uma conexão VPN site a site ou via Rota Expressa. A conectividade via Rota Expressa normalmente pode levar muitas semanas para ser estabelecida, recomenda-se ter a Rota Expressa no lugar antes de iniciar o projeto.
• Equipes piloto: A(s) equipe(s) inicial(is) do projeto de desenvolvimento que usa o DevTest Labs foi identificada juntamente com as atividades de desenvolvimento ou teste aplicáveis e estabelece requisitos/metas/objetivos para essas equipes.

Etapa 1: Estabelecer a topologia e o projeto de rede iniciais

A primeira área de foco ao implantar uma solução Azure DevTest Labs é estabelecer a conectividade planejada para as máquinas virtuais. As etapas a seguir descrevem os procedimentos necessários:

1. Defina intervalos de endereços IP iniciais atribuídos à assinatura do DevTest Labs no Azure. Esta etapa requer a previsão do uso esperado em número de VMs para que você possa fornecer um bloco grande o suficiente para expansão futura.
2. Identificar métodos de acesso desejado nos Laboratórios DevTest (por exemplo, acesso externo/interno). Um ponto-chave nesta etapa é determinar se as máquinas virtuais têm endereços IP públicos (ou seja, acessíveis diretamente da Internet).
3. Identifique e estabeleça métodos de conectividade com o restante do ambiente de nuvem do Azure e localmente. Se o roteamento forçado com a Rota Expressa estiver habilitado, é provável que as máquinas virtuais precisem de configurações de proxy apropriadas para atravessar o firewall corporativo.
4. Se as VMs forem ingressadas no domínio, determine se elas ingressam em um domínio baseado em nuvem (Serviços de Diretório do Microsoft Entra, por exemplo) ou em um domínio local. Para o local, determine qual unidade organizacional (UO) dentro do Ative Directory as máquinas virtuais ingressam. Além disso, confirme se os usuários têm acesso para ingressar (ou estabelecer uma conta de serviço que tenha a capacidade de criar registros de máquina no domínio)

Etapa 2: Implantar o laboratório piloto

Uma vez que a topologia de rede esteja em vigor, o primeiro/laboratório piloto pode ser criado seguindo as seguintes etapas:

1. Crie um ambiente inicial do DevTest Labs.
2. Determine imagens e tamanhos de VM permitidos para uso com laboratório. Decida se as imagens personalizadas podem ser carregadas no Azure para uso com o DevTest Labs.
3. Proteja o acesso ao laboratório criando o controle de acesso inicial baseado em função do Azure (Azure RBAC) para o laboratório (proprietários e usuários do laboratório). Recomendamos que você use contas de diretório ativo sincronizadas com o ID do Microsoft Entra para identidade com o DevTest Labs.
4. Configure o DevTest Labs para usar políticas como agendas, gerenciamento de custos, VMs reivindicáveis, imagens personalizadas ou fórmulas.
5. Estabeleça um repositório online, como o Azure Repos/Git.
6. Decidir sobre o uso de repositórios públicos ou privados ou a combinação de ambos. Organize modelos JSON para implantações e sustentação de longo prazo.
7. Se necessário, crie artefatos personalizados. Este passo é opcional.

Etapa 3: Documentar, apoiar, aprender e melhorar

As equipas piloto iniciais podem necessitar de apoio aprofundado para começar. Use suas experiências para garantir que a documentação e o suporte corretos estejam em vigor para a implantação contínua do Azure DevTest Labs.

1. Apresente às equipes piloto seus novos recursos do DevTest Labs (demonstrações, documentação)
2. Com base nas experiências das equipas piloto, planeie e entregue documentação conforme necessário
3. Formalizar processo de integração de novas equipas (criação e configuração de laboratórios, disponibilização de acessos, etc.)
4. Com base na aceitação inicial, verifique se a previsão original do espaço de endereço IP ainda é razoável e precisa
5. Garantir que as revisões de conformidade e segurança apropriadas tenham sido concluídas

Próximos passos

Consulte o próximo artigo desta série: Governança da infraestrutura do Azure DevTest Labs