Architettura di riferimento aziendale di DevTest Labs

Questo articolo fornisce un'architettura di riferimento per la distribuzione di Azure DevTest Labs in un'azienda. L'architettura include gli elementi chiave seguenti:

• Connettività locale tramite Azure ExpressRoute
• Un gateway Desktop remoto per gli accessi remoti alle macchine virtuali
• Connettività a un repository di artefatti privato
• Altri componenti PaaS (Platform as a Service) usati dai lab

Architecture

Il diagramma seguente illustra una tipica distribuzione aziendale di DevTest Labs. Questa architettura connette diversi lab in sottoscrizioni di Azure diverse alla rete locale di una società.

Componenti di DevTest Labs

DevTest Labs semplifica e veloci le aziende per fornire l'accesso alle risorse di Azure. Ogni lab contiene risorse SaaS (Software as a Service), infrastruttura distribuita come servizio (IaaS) e PaaS. Gli utenti del lab possono creare e configurare macchine virtuali, ambienti PaaS e artefatti di macchine virtuali.

Nel diagramma precedente, Team Lab 1 nella sottoscrizione di Azure 1 mostra un esempio di componenti di Azure a cui i lab possono accedere e usare. Per altre informazioni, vedere Informazioni su DevTest Labs.

Connectivity components

È necessaria la connettività locale se i lab devono accedere alle risorse aziendali locali. Scenari comuni sono:

• Alcuni dati locali non possono essere spostati nel cloud.
• Si vuole aggiungere macchine virtuali lab a un dominio locale.
• Si vuole forzare tutto il traffico di rete cloud attraverso un firewall locale per la sicurezza o la conformità.

Questa architettura usa ExpressRoute per la connettività alla rete locale. È anche possibile usare una connessione VPN da sito a sito.

In locale, un gateway Desktop remoto consente connessioni Remote Desktop Protocol (RDP) in uscita a DevTest Labs. Le aziende in genere bloccano le connessioni in uscita nel firewall aziendale. Per abilitare la connettività, è possibile:

• Usare un gateway desktop remoto e consentire l'indirizzo IP statico del servizio di bilanciamento del carico del gateway.
• Usare il tunneling forzato per reindirizzare tutto il traffico RDP tramite la connessione VPN ExpressRoute o da sito a sito. Il tunneling forzato è una funzionalità comune per le distribuzioni di DevTest Labs su scala aziendale.

Networking components

In questa architettura, Microsoft Entra ID fornisce la gestione delle identità e degli accessi in tutte le reti. Le macchine virtuali lab hanno in genere un account amministrativo locale per l'accesso. Se è disponibile un dominio Microsoft Entra ID, locale o Microsoft Entra Domain Services, è possibile aggiungere macchine virtuali lab al dominio. Gli utenti possono quindi usare le identità basate su dominio per connettersi alle macchine virtuali.

La topologia di networking di Azure controlla il modo in cui le risorse del lab accedono e comunicano con le reti locali e Internet. Questa architettura mostra un metodo comune usato dalle aziende per la rete devTest Labs. I lab si connettono con reti virtuali con peering in una configurazione hub-spoke tramite la connessione VPN da sito a sito o ExpressRoute alla rete locale.

Poiché DevTest Labs usa direttamente la rete virtuale di Azure, non esistono restrizioni sulla configurazione dell'infrastruttura di networking. È possibile configurare un gruppo di sicurezza di rete per limitare il traffico cloud in base agli indirizzi IP di origine e di destinazione. Ad esempio, è possibile consentire solo il traffico proveniente dalla rete aziendale nelle reti del lab.

Scalability considerations

DevTest Labs non ha quote o limiti predefiniti, ma altre risorse di Azure usate dai lab hanno quote a livello di sottoscrizione. In una distribuzione aziendale tipica sono necessarie diverse sottoscrizioni di Azure per coprire una distribuzione di DevTest Labs di grandi dimensioni. Le aziende raggiungono in genere le quote seguenti:

• Resource groups. DevTest Labs crea un gruppo di risorse per ogni nuova macchina virtuale e gli utenti del lab creano ambienti in gruppi di risorse. Le sottoscrizioni possono contenere fino a 980 gruppi di risorse, in modo che sia il limite di macchine virtuali e ambienti in una sottoscrizione.

  Due strategie consentono di rimanere entro i limiti del gruppo di risorse:

  • Inserire tutte le macchine virtuali nello stesso gruppo di risorse. Questa strategia consente di soddisfare il limite del gruppo di risorse, ma influisce sul limite resource-type-per-resource-group.
  • Usare indirizzi IP pubblici condivisi. Se le macchine virtuali possono avere indirizzi IP pubblici, inserire tutte le macchine virtuali con le stesse dimensioni e area nello stesso gruppo di risorse. Questa configurazione consente di soddisfare sia le quote del gruppo di risorse che le quote tipo di risorsa per gruppo di risorse.

• Risorse per gruppo di risorse, per tipo di risorsa. Il limite predefinito per le risorse per gruppo di risorse, per tipo di risorsa è 800. Se si inseriscono tutte le macchine virtuali nello stesso gruppo di risorse, si raggiunge questo limite molto prima, soprattutto se le macchine virtuali hanno molti dischi aggiuntivi.

• Storage accounts. Ogni lab in DevTest Labs include un account di archiviazione. La quota di Azure per il numero di account di archiviazione per area per sottoscrizione è 250 per impostazione predefinita. Pertanto, anche il numero massimo di DevTest Labs in un'area è 250. Con un aumento della quota, è possibile creare fino a 500 account di archiviazione per area. Per altre informazioni, vedere Aumentare le quote dell'account di archiviazione di Azure.

• Role assignments. Un'assegnazione di ruolo consente a un utente o a un'entità di accedere a una risorsa. Azure ha un limite di 4.000 assegnazioni di ruolo per ogni sottoscrizione.

  Per impostazione predefinita, DevTest Labs crea un gruppo di risorse per ogni macchina virtuale del lab. L'autore della macchina virtuale ottiene l'autorizzazione di proprietario per la macchina virtuale e l'autorizzazione lettore per il gruppo di risorse. Ogni macchina virtuale del lab usa quindi due assegnazioni di ruolo. La concessione delle autorizzazioni utente al lab usa anche le assegnazioni di ruolo.

• API reads/writes. È possibile automatizzare Azure e DevTest Labs usando LE API REST, PowerShell, l'interfaccia della riga di comando di Azure e Azure SDK. Ogni sottoscrizione di Azure consente fino a 12.000 richieste di lettura e 1.200 richieste di scrittura all'ora. Se si automatizza DevTest Labs, è possibile raggiungere il limite per le richieste API.

Manageability considerations

È possibile usare il portale di Azure per gestire una singola istanza di DevTest Labs alla volta, ma le aziende potrebbero avere più sottoscrizioni di Azure e molti lab da amministrare. Per apportare modifiche in modo coerente a tutti i lab è necessaria l'automazione degli script.

Ecco alcuni esempi di uso dello scripting nelle distribuzioni di DevTest Labs:

• Modifica delle impostazioni del lab. Aggiornare un'impostazione lab specifica in tutti i lab usando script di PowerShell, l'interfaccia della riga di comando di Azure o le API REST. Ad esempio, aggiornare tutti i lab per consentire una nuova dimensione dell'istanza di macchina virtuale.

• Aggiornamento dei token di accesso personali del repository degli artefatti (PAT). Le reti PAT per i repository Git scadono in genere in 90 giorni, un anno o due anni. Per garantire la continuità, è importante estendere il PAT. In alternativa, è possibile creare un nuovo pat e usare l'automazione per applicarla a tutti i lab.

• Limitazione delle modifiche alle impostazioni del lab. Per limitare determinate impostazioni, ad esempio per consentire l'uso delle immagini del Marketplace, è possibile usare Criteri di Azure per impedire modifiche a un tipo di risorsa. In alternativa, è possibile creare un ruolo personalizzato e assegnarlo agli utenti anziché utilizzare un ruolo di laboratorio integrato. È possibile limitare le modifiche per la maggior parte delle impostazioni del lab, ad esempio il supporto interno, gli annunci del lab e le dimensioni consentite delle macchine virtuali.

• Applicazione di una convenzione di denominazione per le macchine virtuali. È possibile usare Criteri di Azure per specificare un modello di denominazione che consente di identificare le macchine virtuali negli ambienti basati sul cloud.

Gestisci le risorse di Azure per DevTest Labs allo stesso modo in cui le gestisci per altri scopi. Ad esempio, i criteri di Azure si applicano alle macchine virtuali che crei in un laboratorio. Microsoft Defender per il cloud può segnalare la conformità delle macchine virtuali del lab. Backup di Azure può fornire backup regolari per le macchine virtuali del lab.

Security considerations

DevTest Labs trae automaticamente vantaggio dalle funzionalità di sicurezza predefinite di Azure. Per richiedere l'origine delle connessioni desktop remoto in ingresso solo dalla rete aziendale, è possibile aggiungere un gruppo di sicurezza di rete alla rete virtuale nel gateway desktop remoto.

Un'altra considerazione sulla sicurezza è il livello di autorizzazione concesso agli utenti del lab. I proprietari dei lab usano il controllo degli accessi in base al ruolo di Azure (Azure RBAC) per assegnare ruoli agli utenti e impostare autorizzazioni a livello di risorsa e di accesso. Le autorizzazioni più comuni di DevTest Labs sono Proprietario, Collaboratore e Utente. È anche possibile creare e assegnare ruoli personalizzati. Per altre informazioni, vedere Aggiungere proprietari e utenti in Azure DevTest Labs.

Next step

Consulta l'articolo successivo in questa serie: Realizzare un proof of concept