Aumentare l'infrastruttura di Azure DevTestLabs

L'orchestrazione di un'implementazione corretta di DevTest Labs su scala aziendale richiede una considerazione dei punti decisionali chiave e la pianificazione di un approccio per la distribuzione rapida e l'implementazione di Azure DevTest Labs.

Questo articolo descrive i punti decisionali chiave da prendere in considerazione durante la pianificazione dell'implementazione e fornisce un approccio consigliato per la distribuzione.

Punti decisionali chiave

Prima di implementare DevTest Labs su scala aziendale, esistono diversi punti decisionali chiave. La comprensione di questi punti a livello generale aiuta un'organizzazione a progettare le decisioni per il futuro. Tuttavia, questi punti non dovrebbero impedire a un'organizzazione di avviare un modello di verifica.

Di seguito sono elencate le tre aree principali che interessano la pianificazione iniziale della scalabilità verticale:

• Rete e sicurezza
• Topologia della sottoscrizione
• Ruoli e responsabilità

Rete e sicurezza

La rete e la sicurezza sono i fondamenti per tutte le organizzazioni. Mentre una distribuzione a livello aziendale richiede un'analisi molto più approfondita, il numero di requisiti necessari per ottenere un modello di verifica di successo è ridotto. Alcune aree fondamentali di interesse includono:

• Sottoscrizione di Azure: per distribuire DevTest Labs, è necessario avere accesso a una sottoscrizione di Azure con diritti appropriati per creare risorse. Esistono diversi modi per ottenere l'accesso alle sottoscrizioni di Azure, tra cui un Contratto Enterprise e il pagamento in base al consumo. Per altre informazioni su come ottenere l'accesso a una sottoscrizione di Azure, vedere Gestione delle licenze di Azure per l'azienda.
• Accesso a risorse locali: alcune organizzazioni richiedono che le proprie risorse in DevTest Labs abbiano accesso alle risorse locali. È necessaria una connessione sicura dall'ambiente locale ad Azure. È importante configurare e configurare una connessione VPN o Azure ExpressRoute prima di iniziare. Per altre informazioni, vedere Panoramica sulle reti virtuali.
• Altri requisiti di sicurezza: altri requisiti di sicurezza, ad esempio i criteri del computer, l'accesso agli indirizzi IP pubblici, la connessione a Internet sono scenari che potrebbero essere necessari prima di implementare un modello di verifica.

Topologia della sottoscrizione

La topologia di sottoscrizione è una considerazione fondamentale per la progettazione quando si distribuisce DevTest Labs nell'organizzazione. Tuttavia, non è necessario consolidare tutte le decisioni fino al completamento di un modello di verifica. Nella valutazione del numero di sottoscrizioni necessarie per un'implementazione aziendale, si possono considerare due opzioni opposte:

• Un'unica sottoscrizione per l'intera organizzazione
• Una sottoscrizione per utente

Verranno quindi evidenziati i vantaggi di ogni approccio.

Un'unica sottoscrizione

Spesso l'approccio di una sottoscrizione non è gestibile in un'azienda di grandi dimensioni. La scelta di limitare il numero di sottoscrizioni offre tuttavia i benefici seguenti:

• Previsione dei costi per l'azienda. La determinazione del budget diventa molto più semplice con una singola sottoscrizione perché tutte le risorse sono riunite in un unico pool. Questo approccio consente di prendere le decisioni con più facilità in merito a quando esercitare misure di controllo dei costi in una fase specifica del ciclo di fatturazione.
• La gestibilità delle macchine virtuali, degli artefatti, delle formule, della configurazione di rete, delle autorizzazioni e dei criteri è più semplice poiché tutti gli aggiornamenti sono necessari solo in una sottoscrizione anziché eseguire aggiornamenti in più sottoscrizioni.
• Il lavoro di rete è più semplice in una singola sottoscrizione per le aziende in cui la connettività locale è un requisito. Connessione ing di reti virtuali tra sottoscrizioni (modello hub-spoke), necessario con sottoscrizioni aggiunte, richiede più configurazioni, gestione e spazi di indirizzi IP.
• La collaborazione tra team è più semplice quando tutti lavorano nella stessa sottoscrizione. Ad esempio, è più semplice riassegnare una macchina virtuale a un collega o condividere le risorse del team.

Una sottoscrizione per utente

Una sottoscrizione distinta per ogni utente offre pari opportunità nello spettro delle alternative. I vantaggi di disporre di molte sottoscrizioni includono:

• Le quote di scalabilità di Azure non impediranno l'adozione. Al momento della stesura di questo articolo, ad esempio, Azure consente 200 account di archiviazione per ogni sottoscrizione. Esistono quote operative per la maggior parte dei servizi in Azure (molti possono essere personalizzati, alcuni non possono). In questo modello di una sottoscrizione per utente è molto improbabile che venga raggiunta la maggior parte delle quote. Per altre informazioni sulle attuali quote di ridimensionamento di Azure, vedere Sottoscrizione di Azure e limiti, quote e vincoli dei servizi.
• I chargeback a gruppi o singoli sviluppatori diventano molto più semplici e consentono alle organizzazioni di tenere conto dei costi tramite il modello corrente.
• La proprietà e le autorizzazioni degli ambienti DevTest Labs sono semplici. Si offre agli sviluppatori l'accesso a livello di sottoscrizione e questi diventano responsabili al 100% di tutti gli aspetti, inclusi la configurazione di rete, i criteri del lab e la gestione delle macchine virtuali.

Nell'azienda possono essere presenti alcuni limiti agli estremi dello spettro. Può pertanto essere necessario configurare le sottoscrizioni in un modo che rappresenta una via di mezzo tra questi estremi. Come procedura consigliata, l'obiettivo di un'organizzazione deve essere quello di usare il numero minimo di sottoscrizioni possibili. Tenere presente le funzioni forzanti che aumentano il numero totale di sottoscrizioni. Per ribadire, la topologia di sottoscrizione è fondamentale per una distribuzione aziendale di DevTest Labs, ma non deve ritardare un modello di verifica. Sono disponibili altri dettagli nell'articolo Sulla governance su come decidere la granularità della sottoscrizione e del lab nell'organizzazione.

Ruoli e responsabilità

Un modello di verifica di DevTest Labs prevede tre ruoli primari con responsabilità definite: proprietario della sottoscrizione, proprietario di DevTest Labs, utente di DevTest Labs e, facoltativamente, un collaboratore.

• Proprietario della sottoscrizione: il proprietario della sottoscrizione ha i diritti per amministrare una sottoscrizione di Azure, inclusa l'assegnazione di utenti, la gestione dei criteri, la creazione e la gestione della topologia di rete e l'aumento della quota. Per altre informazioni, vedi questo articolo.
• Proprietario di DevTest Labs: il proprietario di DevTest Labs dispone dell'accesso amministrativo completo al lab. Questo ruolo è responsabile dell'aggiunta/rimozione di utenti, delle impostazioni dei costi di gestione, delle impostazioni di lab generali e di altre attività basate su macchine virtuali/artefatti. Un proprietario del lab dispone anche di tutti i diritti di un utente di DevTest Labs.
• Utente di DevTest Labs: l'utente di DevTest Labs può creare e usare le macchine virtuali nel lab. Dispone di alcune capacità amministrative minime sulle macchine virtuali che crea (avvio/arresto/eliminazione/configurazione delle proprie macchine virtuali). Non può gestire le macchine virtuali di altri utenti.

Orchestrare l'implementazione di DevTest Labs

Questa sezione offre un approccio consigliato per la distribuzione rapida e l'implementazione di Azure DevTest Labs. L'immagine seguente evidenzia il processo complessivo come indicazione prescrittiva e al contempo osserva la flessibilità necessaria per supportare vari scenari e requisiti di settore.

Presupposti

Questo articolo presuppone la presenza degli elementi seguenti prima di implementare un progetto pilota di DevTest Labs:

• Sottoscrizione di Azure: il team del progetto pilota ha accesso alla distribuzione delle risorse in una sottoscrizione di Azure. Se i carichi di lavoro sono solo per sviluppo e test, è consigliabile selezionare l'offerta Sviluppo/test Enterprise, che include immagini disponibili aggiuntive e tariffe ridotte per macchine virtuali Windows.
• Accesso in locale: se necessario, l'accesso in locale è già stato configurato. Per l'accesso in locale è possibile configurare una connessione VPN da sito a sito o una connessione ExpressRoute. L'installazione di una connettività tramite ExpressRoute richiede in genere molte settimane, è pertanto consigliato installarla prima di iniziare il progetto.
• Team del progetto pilota: il team del progetto di sviluppo iniziale che usa DevTest Labs è stato identificato insieme alle attività di sviluppo e test e sono stati stabiliti i requisiti, gli scopi e gli obiettivi di tale team.

Attività cardine 1: stabilire il progetto e la topologia di rete iniziali

La prima area su cui concentrarsi quando si distribuisce una soluzione Azure DevTest Labs riguarda l'installazione della connettività pianificata per le macchine virtuali. I passaggi seguenti delineano le procedure necessarie:

1. Definire gli intervalli di indirizzi IP iniziali assegnati alla sottoscrizione di DevTest Labs in Azure. Questo passaggio richiede di prevedere l'utilizzo atteso del numero di macchine virtuali in modo che sia possibile specificare un blocco di dimensioni sufficientemente grandi che consenta una futura espansione.
2. Identificare le modalità di accesso desiderate in DevTest Labs (ad esempio l'accesso esterno o interno). Un punto chiave in questo passaggio consiste nel determinare se le macchine virtuali hanno indirizzi IP pubblici, vale a dire se è possibile accedervi da Internet direttamente.
3. Identificare e stabilire le modalità di connettività con il resto dell'ambiente cloud di Azure e l'ambiente locale. Se è abilitato il routing forzato con ExpressRoute, è probabile che le macchine virtuali necessitino di configurazioni proxy appropriate per attraversare il firewall aziendale.
4. Se le macchine virtuali devono essere aggiunte a un dominio, determinare se si aggiungono a un dominio basato sul cloud (ad esempio, Microsoft Entra Directory Services) o a un dominio locale. Per l'ambiente locale, determinare quale unità organizzativa (OU) all'interno di Active Directory unisce le macchine virtuali. Verificare anche che gli utenti abbiano accesso per eseguire un join (o stabilire un account del servizio che abbia la possibilità di creare record di macchina nel dominio)

Attività cardine 2: distribuire il lab pilota

Dopo avere determinato la topologia di rete, è possibile creare il primo lab o lab pilota seguendo questi passaggi:

1. Creare un ambiente DevTest Labs iniziale.
2. Determinare le immagini di macchine virtuali consentite e le dimensioni per l'uso con il lab. Decidere se è possibile caricare immagini personalizzate in Azure da usare con DevTest Labs.
3. Proteggere l'accesso al lab creando il controllo degli accessi in base al ruolo di Azure iniziale per il lab (proprietari di lab e utenti lab). È consigliabile usare account active directory sincronizzati con l'ID Microsoft Entra per l'identità con DevTest Labs.
4. Configurare DevTest Labs per l'uso di criteri, ad esempio le pianificazioni, gestione dei costi, macchine virtuali richiedibili, immagini personalizzate o formule.
5. Stabilire un repository online, ad esempio Azure Repos/Git.
6. Decidere se usare repository pubblici o privati o una combinazione di entrambi. Organizzare modelli JSON per le distribuzioni e la manutenzione a lungo termine.
7. Creare artefatti personalizzati, se necessario. Questo passaggio è facoltativo.

Attività cardine 3: documentazione, supporto, apprendimento e miglioramento

Il team del progetto pilota iniziale può avere bisogno di un supporto approfondito per affrontare le attività iniziali. Usare la propria esperienza per garantire la documentazione e il supporto appropriati per l'implementazione continuata di Azure DevTest Labs.

1. Introdurre il team del progetto pilota alle nuove risorse di DevTest Labs (demo, documentazione)
2. In base alle esperienze dei team del progetto pilota pianificare e distribuire la documentazione a seconda delle esigenze
3. Formalizzare il processo per l'onboarding di nuovi team (creazione e configurazione di lab, accesso e così via)
4. In base all'utilizzo iniziale verificare se la previsione originale relativa allo spazio di indirizzi IP è ancora sensata e accurata
5. Verificare che siano state completate le verifiche di conformità e sicurezza appropriate

Passaggi successivi

Vedere l'articolo successivo di questa serie: Governance dell'infrastruttura di Azure DevTest Labs