Expanda sua infraestrutura do Azure DevTest Labs

Para orquestrar uma implementação bem-sucedida do DevTest Labs em escala empresarial, considere os principais pontos de decisão e o planejamento de uma abordagem para implantação rápida e implementação de 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 essenciais. Conhecer a fundo esses pontos de decisão ajuda uma organização a tomar 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:

• Rede e segurança
• Topologia de assinatura
• Funções e responsabilidades

Rede e segurança

Rede e segurança são os alicerces de todas as organizações. Enquanto uma implantação em toda a empresa requer uma análise muito mais aprofundada, há um número reduzido de requisitos para executar uma prova de conceito com êxito. Algumas áreas de foco principais incluem:

• Assinatura do Azure – para implantar o DevTest Labs, você precisa ter acesso a uma assinatura do Azure com direitos apropriados para criar recursos. Há diversas maneiras de obter acesso às assinaturas do Azure, incluindo um Contrato Enterprise e pago conforme o uso. Para obter mais informações sobre como obter acesso a uma assinatura do Azure, confira Licenciamento do Azure para a empresa.
• 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 para o Azure. É importante definir e configurar uma conexão VPN ou Azure ExpressRoute antes de começar. Para obter mais informações, confira Visão geral de redes virtuais.
• Outros requisitos de segurança – outros requisitos de segurança, tais como políticas de computador, acesso a endereços IP públicos e conexão com a Internet, são cenários que precisam ser revisados antes da implementação de uma prova de conceito.

Topologia de assinatura

A topologia de assinatura é uma consideração de design essencial ao implantar o DevTest Labs para a empresa. No entanto, antes da conclusão de uma prova de conceito, essa topologia não é necessária para consolidar todas as decisões. Ao avaliar o número de assinaturas necessárias para uma implementação empresarial, há dois extremos:

• Uma assinatura para toda a organização
• Assinatura por usuário

Em seguida, destacamos as vantagens de cada abordagem.

Uma assinatura

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

• Previsão dos custos para a empresa. Planejar o orçamento torna-se muito mais fácil em uma assinatura única, porque todos os recursos estão em um único pool. Essa abordagem permite tomada de decisões mais simples quanto a quando exercer medidas de controle de custos em qualquer determinado momento em um ciclo de cobrança.
• O 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 várias assinaturas.
• O esforço referente à rede mais simples em uma assinatura única para empresas em que a conectividade local é um requisito. Conectar redes virtuais entre assinaturas (modelo hub-spoke), necessária com assinaturas adicionadas, requer mais espaço de 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 grupo ou compartilhar recursos da equipe.

Assinatura por usuário

Uma assinatura separada por usuário fornece oportunidades iguais no espectro de alternativas. Os benefícios de ter várias assinaturas incluem:

• As cotas de dimensionamento do Azure não impedem a adoção. Por exemplo, no momento da redação deste artigo, o Azure permite 200 contas de armazenamento por assinatura. Existem cotas operacionais para a maioria dos serviços do Azure (muitas podem ser personalizadas, outras não). Nesse modelo de uma assinatura por usuário, é muito improvável que a maioria das cotas sejam atingidas. Para obter mais informações sobre as cotas de dimensionamento atuais do Azure, confira Assinatura do Azure e limite de serviços, cotas e restrições.
• Estornos a desenvolvedores individuais ou a grupos de desenvolvedores tornam-se muito mais fáceis, permitindo que as organizações contabilizem os custos usando seu modelo atual.
• Os conceitos de propriedade e permissões dos ambientes do DevTest Labs são simples. Você permite aos desenvolvedores acesso em 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 VMs.

Na empresa, pode já haver restrições suficientes nos extremos do espectro. Portanto, talvez você precise configurar assinaturas de uma maneira intermediária a esses 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 que aumentam o número total de assinaturas. Reiterando, a topologia de assinatura é essencial para uma implantação empresarial do DevTest Labs, mas não deve ser motivo para atrasar uma prova de conceito. Há mais detalhes no artigo Governança sobre como decidir sobre granularidade de laboratórios e de assinaturas 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 atribuir usuários, gerenciar políticas, criar e gerenciar a topologia de rede e solicitar aumentos de cota. Para obter 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/artefato. Um proprietário de laboratório também tem todos os direitos de um usuário do DevTest Labs.
• Usuário do DevTest Labs – pode criar e consumir as máquinas virtuais no laboratório. Esses indivíduos têm algumas capacidades administrativas mínimas nas VMs que eles criam (iniciar/parar/excluir/configurar as respectivas VMs). Os usuários não podem gerenciar VMs de outros usuários.

Orquestrar implementação dos Laboratórios de Desenvolvimento/Teste

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 diretrizes prescritivas, observando simultaneamente a flexibilidade para dar suporte a vários cenários e requisitos 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 para implantar recursos em uma assinatura do Azure. Se as cargas de trabalho são apenas de desenvolvimento e teste, é recomendável selecionar a oferta Desenvolvimento/Teste Enterprise para imagens disponíveis adicionais e taxas mais baixas em máquinas virtuais do Windows.
• Acesso local: se necessário, o acesso local já foi configurado. O acesso local pode ser feito por meio de uma conexão VPN site a site ou por meio do ExpressRoute. A conectividade por ExpressRoute normalmente pode levar várias semanas para ser estabelecida, então é recomendável ter o ExpressRoute em vigor antes de iniciar o projeto.
• Equipes-piloto: as equipes de projeto de desenvolvimento inicial que usam o DevTest Labs foram identificadas com atividades de teste ou de desenvolvimento aplicáveis e foram estabelecidos requisitos/objetivos/metas para essas equipes.

Marco 1: estabelecer o design e a topologia de rede iniciais

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

1. Definir intervalos de endereços IP iniciais que são atribuídos à assinatura do DevTest Labs no Azure. Esta etapa requer a previsão do uso esperado em número de VMs, de modo que você possa fornecer um bloco suficientemente grande para expansão futura.
2. Identifique métodos de acesso desejado no DevTest Labs (por exemplo, acesso externo/interno). Um ponto importante nesta etapa é determinar se as máquinas virtuais têm endereços IP públicos (ou seja, acessíveis pela Internet diretamente).
3. Identifique e estabeleça métodos de conectividade localmente e com o restante do ambiente de nuvem do Azure. Se o roteamento forçado com o ExpressRoute estiver habilitado, provavelmente as máquinas virtuais precisarão de configurações de proxy apropriadas para atravessar o firewall corporativo.
4. Se as VMs forem ingressar no domínio, determine se o ingresso será feito em um domínio baseado em nuvem (por exemplo, Microsoft Entra Directory Services) ou em um domínio local. No caso de ser local, determine em qual UO (unidade organizacional) dentro do Active Directory as máquinas virtuais ingressam. Além disso, confirme que os usuários tenham acesso para ingressar (ou estabeleça uma conta de serviço que tenha a capacidade de criar registros de computador no domínio)

Marco 2: Implantar o laboratório piloto

Depois que a topologia de rede está em vigor, o primeiro laboratório/laboratório piloto pode ser criado executando as seguintes etapas:

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

Marco 3: documentação, suporte, aprendizado e melhora

As equipes-piloto iniciais podem exigir suporte detalhado para que possam começar. Use as experiências deles para garantir que a documentação correta e o suporte estejam preparados para distribuição contínua do Azure DevTest Labs.

1. Apresentar as equipes-piloto a seus novos recursos do DevTest Labs (demonstrações, documentação)
2. Com base em experiências das equipes piloto, planeje e forneça documentação conforme necessário
3. Formalizar o processo de integração novas equipes (criação e configuração de laboratórios, fornecimento de acesso etc.)
4. Com base na adoção inicial, verificar se a previsão original de espaço de endereços IP ainda é razoável e precisa
5. Assegurar que as análises de segurança e conformidade apropriadas foram concluídas

Próximas etapas

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