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 accedere in remoto alle macchine virtuali (VM)
• Connettività a un repository di artefatti privato
• Altri componenti PaaS (Platform-as-a-Service) usati dai lab

Architettura

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), Infrastructure-as-a-Service (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.

Componenti di connettività

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

• Alcuni dati locali non possono andare al 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 motivi di sicurezza o 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. I firewall aziendali Enterprise bloccano in genere 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.

Componenti di rete

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 modo comune per le aziende che dimostrano 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.

Considerazioni sulla scalabilità

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:

• Gruppi di risorse. 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 sotto i limiti del gruppo di risorse:

  • Tutte le macchine virtuali si trovano 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 resource-type-per-resource-group.

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

• Account di archiviazione. 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 di quota, è possibile creare fino a 500 account di archiviazione per area. Per altre informazioni, vedere Aumentare le quote dell'account di archiviazione di Azure.

• Assegnazioni di ruoli. Un'assegnazione di ruolo consente a un utente o a un'entità di accedere a una risorsa. Azure ha un limite di 2000 assegnazioni di ruolo per 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 di 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.

• Letture/scritture dell'API. È 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. Automatizzando DevTest Labs, è possibile raggiungere il limite per le richieste API.

Considerazioni sulla gestibilità

È 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, 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 concedere agli utenti il ruolo anziché un ruolo lab predefinito. È 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.

Le risorse di Azure per DevTest Labs vengono gestite come per altri scopi. Ad esempio, Criteri di Azure si applica alle macchine virtuali create in un lab. 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.

Considerazioni relative alla sicurezza

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.

Passaggi successivi

Vedere l'articolo successivo di questa serie: Distribuire un modello di verifica.