Pianificare gli ambienti

8 minuti

L'infrastruttura di Azure in uso è costituita da molti elementi, tra cui configurazione di base, risorse e impostazioni a livello di organizzazione e carichi di lavoro delle applicazioni. Probabilmente l'infrastruttura è anche diffusa in più ambienti, ognuno con uno scopo diverso.

Questa unità descrive i vantaggi dell'uso coerente del codice per tutte le distribuzioni e configurazioni. Si considereranno quindi i livelli di controllo e automazione che possono essere applicati a ogni ambiente. Si considereranno anche lo stato delle modifiche in ogni fase del processo di distribuzione e i controlli e i tipi di governance necessari per supportare la strategia di distribuzione scelta.

Definire l'infrastruttura come codice

La distribuzione e la configurazione di Azure riguardano molto di più di applicazioni, macchine virtuali, servizi di archiviazione e rete. Ciascuno degli elementi seguenti, ad esempio, è una forma di configurazione, con risorse Azure corrispondenti:

Organizzazione delle risorse tramite la creazione di gruppi di risorse, sottoscrizioni e gruppi di gestione.
Controllo della configurazione di altre risorse, tramite la definizione e l'applicazione di definizioni, iniziative e assegnazioni di Criteri Azure.
Assegnazione di ruoli per consentire a utenti, gruppi e identità dei carichi di lavoro di accedere alle risorse di Azure.
Configurazione del monitoraggio, inclusi gli avvisi, per osservare le risorse di Azure e assicurarsi che si comportino nel modo previsto.

Quando si inizia a definire l'infrastruttura come codice, non sempre si è consapevoli di tutti gli elementi che possono essere definiti nei modelli o nelle definizioni. Quando l'uso dell'automazione diventa più maturo, tuttavia, è opportuno definire tutto ciò che riguarda l'ambiente come codice. In questo modo è possibile usare un processo coerente, testato e approvato per tutta la configurazione di Azure. Poiché il codice è con versione ed è monitorato in un repository Git, è quindi possibile esaminare come l'ambiente Azure cambia nel tempo. È possibile usare il repository Git per tracciare la cronologia di ogni modifica.

Si supponga, ad esempio, che sia necessario configurare gli avvisi di Monitoraggio di Azure. In un primo momento l'uso dell'automazione per distribuire gli avvisi potrebbe non avere senso. Gli avvisi sono tuttavia una parte importante della configurazione di Azure. Se un avviso non viene creato correttamente, le notifiche relative a problemi critici di produzione potrebbero non essere rilevate. Se si definiscono gli avvisi nel codice:

I membri del team possono esaminare gli avvisi e la loro configurazione.
È possibile distribuire prima gli avvisi in ambienti non di produzione, in modo che sia possibile testarli.
È disponibile una tracciabilità completa delle modifiche apportate alla configurazione di Azure.

Ambienti

Quando si prevede di distribuire automaticamente l'infrastruttura, è utile elencare gli ambienti che si useranno. In molte organizzazioni sono presenti vari tipi di ambiente, ognuno con caratteristiche diverse. Ad esempio:

Alcuni ambienti eseguono codice di produzione, mentre altri eseguono versioni non di produzione dello stesso codice, forse con configurazioni diverse.
Alcuni ambienti hanno una lunga durata e non devono mai essere eliminati. Altri ambienti sono effimeri, ovvero creati automaticamente ed eliminati definitivamente quando non vengono più usati.
Alcuni ambienti vengono usati dal team di sviluppo software o dell'infrastruttura. Altri vengono usati dal team di sicurezza o anche dal team di vendita quando è necessario dimostrare un prodotto ai potenziali clienti.

Considerare gli ambienti che l'azienda di giocattoli può usare per il sito Web:

Diagramma che mostra la sequenza di ambienti.

Quando si apportano modifiche all'applicazione o all'infrastruttura e se ne esegue il commit, la pipeline distribuisce le modifiche tramite una sequenza di ambienti non di produzione, ovvero sviluppo, test e gestione temporanea. In alcuni punti possono anche essere presenti passaggi di approvazione manuale in modo che i membri definiti del team possano verificare la configurazione o esaminare il log della pipeline prima che la distribuzione continui. A questo punto la pipeline distribuisce le modifiche all'ambiente di produzione.

Oltre a questi ambienti, il team di vendita dispone di un proprio ambiente demo che usa per parlare con i clienti. Il team di vendita usa una copia dell'ambiente di produzione per creare il proprio ambiente demo. I team di sicurezza e test creano occasionalmente copie temporanee dell'ambiente di produzione per il test di penetrazione e i test delle prestazioni, rispettivamente.

Anche il team di sviluppo dispone dei propri set di ambienti. È incluso l'ambiente sandbox che i membri del team di sviluppo possono usare quando esplorano nuove funzionalità o provano nuovi servizi di Azure. Il team di sviluppo crea anche ambienti di revisione di richiesta pull per ogni richiesta pull GitHub esaminata e unita.

Ambienti controllati

In alcuni di questi ambienti, è consigliabile richiedere un processo formale per rivedere e applicare le modifiche. Gli ambienti di questo tipo vengono definiti ambienti controllati. L'ambiente di produzione deve essere sempre controllato. È consigliabile comunque applicare controlli anche ad alcuni ambienti non di produzione. In questo modo è possibile verificare che le eventuali restrizioni imposte dai controlli vengano comprese e testate prima della distribuzione in un ambiente di produzione.

Al contrario, agli ambienti non controllati non vengono applicati controlli formali o ne vengono applicati pochi. Tali ambienti possono avere lo stesso codice e una configurazione simile ad altri ambienti, ma consentono ulteriori sperimentazioni e modifiche di configurazione ad hoc. In un ambiente non controllato, gli utenti possono essere autorizzati a modificare la configurazione usando il portale di Azure o eseguendo direttamente i comandi dell'interfaccia della riga di comando di Azure o di Azure PowerShell. Possono anche essere in grado di creare risorse senza usare il processo approvato dall'organizzazione. Le modifiche apportate ad ambienti non controllati devono essere acquisite nel codice prima che sia possibile iniziare ad applicarle ad ambienti controllati come l'ambiente di produzione.

Nota

A volte, un ambiente può in realtà rappresentare più ambienti fisici o distribuzioni. Quando si creano ambienti effimeri per le revisioni delle richieste pull, ad esempio, possono essere attivi più ambienti separati contemporaneamente perché il team ha più richieste pull aperte. Per pianificare gli ambienti, tuttavia, è possibile considerarli equivalenti perché hanno le stesse caratteristiche e controlli.

Dopo alcune discussioni con il team, è possibile decidere quali ambienti sono controllati e quali non lo sono. È anche possibile decidere il proprietario di ogni ambiente.

Nome ambiente	Descrizione	Proprietario	Durata	Livello di controllo
Sviluppo	Integra le modifiche apportate da più sviluppatori in un unico ambiente.	Team operativo	Lunga durata	Controllato
Test	Ambiente per l'esecuzione di test manuali e automatizzati in relazione alle modifiche.	Team operativo	Lunga durata	Controllato
Gestione temporanea	Ambiente finale non di produzione in cui le modifiche vengono distribuite prima della produzione, con una configurazione simile all'ambiente di produzione.	Team operativo	Lunga durata	Controllato
Produzione	Esegue i carichi di lavoro di produzione.	Team operativo	Lunga durata	Controllato
Demo	Usato dal team di vendita per illustrare il prodotto ai nuovi clienti.	Team di vendita	Lunga durata	Non controllato
Test delle prestazioni	Creato dinamicamente come duplicato dell'ambiente di produzione per l'esecuzione di test di stress e delle prestazioni, quindi eliminato al termine dei test.	Team di test	Breve durata	Non controllato
Test di penetrazione	Creato dinamicamente come duplicato dell'ambiente di produzione per l'esecuzione di test di sicurezza e di penetrazione, quindi eliminato al termine dei test.	Team di sicurezza	Breve durata	Non controllato
Verifica richiesta pull	Creato dinamicamente per ogni richiesta pull creata da un membro del team per modificare l'applicazione o l'infrastruttura. L'ambiente viene eliminato alla chiusura della richiesta pull.	Team di sviluppo	Breve durata	Non controllato
Sandbox di sviluppo	Creato dai membri del team di sviluppo per provare o esplorare, quindi eliminato quando non è più necessario.	Team di sviluppo	Breve durata	Non controllato

L'elenco precedente di ambienti è solo un esempio. Nella propria organizzazione è necessario decidere quali ambienti usare, quale deve essere la loro durata e quale livello di controllo è necessario per ogni ambiente.

Suggerimento

È molto più semplice eseguire il linting del codice dell'infrastruttura, testarlo e rivederlo quando si applicano tali processi all'inizio delle distribuzioni, invece di aggiungerli in un secondo momento e correggere una certa quantità di codice danneggiato.

Analogamente, è molto più facile usare i controlli di sicurezza quando sono presenti fin dall'inizio e quando vengono applicati anche ad alcuni ambienti non di produzione. In questo modo, il team si abitua a lavorare in un ambiente controllato.

In tutti i percorsi di apprendimento, alcuni di questi concetti sono stati introdotti gradualmente. Spesso è consigliabile aggiungere tali elementi al processo di distribuzione il prima possibile.

Isolamento di ogni ambiente

È importante separare ogni ambiente e renderlo indipendente, ove possibile. L'uso di sottoscrizioni Azure dedicate per ogni ambiente può essere utile, ma è comunque necessario prestare attenzione a tenere separati gli ambienti.

Evitare di connettersi da un ambiente a un altro. Non eseguire ad esempio il peering della rete virtuale di un ambiente di produzione alla rete virtuale di un ambiente non di produzione. In questo caso, è facile che qualcuno modifichi accidentalmente i dati di produzione dall'interno di un ambiente non di produzione o perda dati di produzione sensibili in un ambiente non di produzione.

Verifiche e attività di controllo

Durante il processo di distribuzione viene eseguita una serie di controlli per aumentare la fiducia nel processo stesso. È necessario stabilire i controlli che hanno senso per ogni ambiente in cui le distribuzioni sono in esecuzione.

I controlli per l'infrastruttura includono spesso gli elementi seguenti:

Revisioni del codice.
Distribuzione del codice in revisione in ambienti effimeri ed esecuzione di test automatizzati o manuali negli ambienti.
Linting.
Convalida preliminare.
Test manuali.
Approvazione manuale.
Test funzionali automatizzati.
Smoke test automatizzati.
Attesa di segnali sullo stato da un ambiente precedente prima di passare all'ambiente successivo.

È possibile eseguire alcuni di questi controlli più volte nel processo di distribuzione, ad esempio per ogni ambiente controllato.

Suggerimento

Quando si progetta il processo di distribuzione, elencare tutti i passaggi da eseguire, indipendentemente da quanto siano ovvi o brevi. Usare una descrizione più dettagliata possibile. Anche se si sceglie di non automatizzare tutto inizialmente, seguire questa procedura consente di creare una struttura per i processi di distribuzione automatizzati in futuro.

Un'attività di controllo è una verifica automatizzata o manuale che deve avere esito positivo per continuare la distribuzione.

Intervento manuale

È consigliabile automatizzare il numero massimo di controlli possibile durante la revisione del codice e i processi di distribuzione. L'organizzazione potrebbe richiedere tuttavia l'approvazione manuale per la distribuzione in ambienti di produzione o in altri ambienti controllati.

Se si usano attività di controllo manuali per le distribuzioni, seguire queste procedure consigliate:

Definire chiaramente chi è autorizzato ad approvare una distribuzione. Usare i gruppi di Microsoft Entra per definire i responsabili approvazione anziché specificare singoli utenti. È possibile modificare facilmente l'elenco dei responsabili approvazione in futuro.
Disporre di un processo per le distribuzioni di emergenza. Pianificare chi può approvare una distribuzione se i normali responsabili approvazione non sono disponibili. Può essere necessario eseguire una distribuzione di emergenza durante la notte o durante un periodo di ferie.
Limitare l'intervento umano solo all'approvazione o al rifiuto di una distribuzione. Evitare di richiedere agli utenti di eseguire una delle operazioni di distribuzione, a meno che non ci sia un passaggio che non si può automatizzare.

Governance

Azure offre strumenti e funzionalità che consentono di gestire l'ambiente, tra cui:

Criteri di Azure, per rilevare le risorse configurate in modi che non soddisfano i requisiti dell'organizzazione. Criteri di Azure consente anche di impedire la creazione o la riconfigurazione delle risorse in modo che risultino non conformi.
Blocchi, per impedire modifiche o eliminazioni di risorse importanti.
Gruppi di gestione, per organizzare le sottoscrizioni di Azure e configurare i criteri e il controllo degli accessi in base al ruolo in modo coerente in tutti gli ambienti.
Monitoraggio di Azure, per registrare metriche e log dalle risorse, presentarli nei dashboard e avvisare automaticamente quando deviano dai valori previsti.

Quando si crea l'infrastruttura Azure, è consigliabile usare le zone di destinazione di Azure. Grazie alle zone di destinazione, è possibile integrare la governance nell'ambiente fin dalle fasi iniziali. Molte zone di destinazione includono file Bicep e Terraform predefiniti che consentono di configurare l'ambiente. Nel sommario è disponibile un collegamento ad altre informazioni.