Informazioni sugli ambienti

Completato

I flussi di lavoro di distribuzione consentono di automatizzare i passaggi nel processo di distribuzione. Spesso è necessario eseguire i passaggi in più ambienti separati. Nell'azienda di giocattoli presso cui l'utente lavora si desidera esaminare le modifiche apportate al codice prima di distribuirle nell'ambiente di produzione.

In questa unità viene illustrato come gli ambienti in GitHub Actions consentono di supportare i processi personalizzati.

Perché sono presenti più ambienti?

I processi di distribuzione apportano modifiche alle risorse di Azure, incluse le risorse in uso. La modifica delle risorse comporta alcuni rischi, perché le modifiche che si distribuiscono potrebbero non comportarsi come previsto. Si potrebbe persino scoprire che le modifiche interrompono la configurazione corrente.

Per ridurre al minimo il rischio di problemi, è consigliabile provare le modifiche in modo sicuro prima di distribuirle nell'ambiente di produzione. A tale scopo, si distribuiscono le modifiche in un ambiente non di produzione.

Molte organizzazioni configurano più ambienti non di produzione in cui distribuiscono progressivamente le modifiche prima di rilasciarle in produzione. Ogni ambiente non di produzione ha uno scopo specifico e spesso prevede soglie di qualità specifiche che devono essere soddisfatte per procedere all'ambiente successivo. Se si verifica un errore, ad esempio un test non riuscito, la distribuzione si arresta. Man mano che la distribuzione si sposta attraverso ogni ambiente, l'attendibilità delle modifiche aumenta.

Gli ambienti comuni includono:

• Sviluppo: un ambiente di sviluppo viene in genere usato dagli sviluppatori per provare le modifiche apportate e per iterare rapidamente per le proprie attività.

  Gli ambienti di sviluppo prevedono spesso controlli minimi affinché i membri del team possano provare facilmente le idee. È possibile usare un ambiente di sviluppo per testare un'impostazione di configurazione specifica in una risorsa o per vedere come configurare un nuovo sito Web con un database back-end in modo sicuro. Molte di queste modifiche e prove potrebbero non avanzare nel processo di distribuzione, perché si eliminano le idee che non funzionano.

  In alcuni team, è anche possibile configurare un ambiente di sviluppo separato per ogni membro del team affinché non si intralcino l'un l'altro mentre lavorano su nuove funzionalità.

  Gli ambienti di sviluppo sono talvolta chiamati anche ambienti sandbox.

• Test: un ambiente di test è progettato per eseguire test manuali o automatizzati sulle modifiche.

  Gli ambienti di test possono essere usati in un processo di integrazione continua. Dopo aver distribuito una modifica in un ambiente di test, è possibile eseguire test automatizzati sulla modifica. Se tutti i test automatizzati vengono superati, si tratta di una modifica sicura che può essere unita nel ramo principale del progetto. I test automatizzati in genere controllano la funzionalità di base del sistema, unitamente ad altri aspetti, come le violazioni dei criteri nelle risorse appena distribuite.

  È anche possibile creare ambienti di test dedicati per tipi specifici di test, ad esempio test di prestazioni e sicurezza.

• Integrazione: un ambiente di integrazione consente di testare qualsiasi punto di integrazione con altri sistemi.

  In un ambiente di integrazione è possibile simulare transazioni end-to-end. Questi test vengono spesso eseguiti automaticamente, ma molte organizzazioni eseguono anche test manuali su questo ambiente.

  Gli ambienti di integrazione sono talvolta chiamati anche ambienti SIT (System Integration Test).

• Test di accettazione utente: un ambiente di test di accettazione utente (UAT, User Acceptance Test) viene usato per la convalida manuale, in genere da parte degli stakeholder aziendali anziché degli sviluppatori. Nella convalida manuale qualcuno esamina la soluzione e verifica che si comporti come previsto e che soddisfi i requisiti aziendali necessari. Tale persona approva quindi le modifiche affinché la distribuzione possa continuare.

• Pre-produzione: un ambiente di pre-produzione è spesso uno specchio dell'ambiente di produzione, con gli stessi SKU e la stessa configurazione delle risorse. Viene usato come controllo finale per verificare il comportamento della distribuzione di produzione durante e dopo l'applicazione della modifica. Può essere usato anche per verificare se prevedere tempi di inattività durante la distribuzione in produzione.

  Gli ambienti di pre-produzione sono talvolta chiamati anche ambienti di gestione temporanea.

• Produzione: l'ambiente di produzione è quello che useranno gli utenti finali dell'applicazione. Si tratta dell'ambiente live che si vuole proteggere e mantenere il più possibile operativo.

  In alcune organizzazioni potrebbero essere presenti più ambienti di produzione. Ad esempio, potrebbero essere presenti ambienti di produzione in aree geografiche diverse o destinati a gruppi diversi di clienti.

• Demo: il team potrebbe anche creare ambienti dimostrativi (demo) per mostrare l'applicazione agli utenti finali, per il training o per consentire ai team di vendita di mostrare determinate funzionalità ai potenziali clienti. Potrebbero anche essere presenti più ambienti demo per scopi diversi. Un ambiente demo è spesso una replica ridotta dell'ambiente di produzione, con dati dei clienti fittizi.

Ambienti nell'organizzazione

Potrebbero essere presenti varianti di questi ambienti. Alcune organizzazioni usano solo alcuni ambienti e altre ne usano molti di più. Il numero e il tipo di ambienti usati dipendono dalla soluzione distribuita, dalle dimensioni del team che sta creando la soluzione e dall'importanza del carico di lavoro.

In alcuni casi, un singolo ambiente assume il ruolo di molti degli ambienti citati in precedenza. In altri casi, potrebbe essere presente un flusso di lavoro complesso che viene distribuito in più ambienti, alcuni in parallelo e alcuni in sequenza. Alcune organizzazioni eliminano automaticamente o effettuano il deprovisioning degli ambienti quando non vengono più usati e quindi li ridistribuiscono quando sono necessari in futuro.

Indipendentemente dall'elenco di ambienti scelto dall'organizzazione, l'obiettivo consiste nel migliorare la fiducia in una modifica mentre avanza attraverso il flusso di lavoro di distribuzione. Quando una modifica non soddisfa i requisiti di qualità, è necessario poter arrestare la distribuzione di tale modifica in tutti gli ambienti successivi della catena.

Nell'azienda di giocattoli si decide di iniziare con un set di ambienti di base per il sito Web. Oltre all'ambiente di produzione, si creerà un ambiente non di produzione denominato Test:

Il flusso di lavoro verrà aggiornato per distribuire il codice Bicep nell'ambiente di test ed eseguire alcuni test di base. In caso di esito positivo, si può quindi procedere alla distribuzione nell'ambiente di produzione.

Ambienti del flusso di lavoro

Anche GitHub Actions prevede il concetto di ambiente. Si crea un ambiente GitHub Actions per rappresentare l'ambiente disponibile in Azure. Quando si definisce il flusso di lavoro in un file YAML, è possibile collegare processi a un ambiente specifico. Usando gli ambienti, si ottengono alcune funzionalità aggiuntive nel flusso di lavoro.

Regole di protezione

In un ambiente in GitHub Actions è possibile configurare regole di protezione. Ogni volta che l'ambiente viene usato in un processo nel flusso di lavoro, GitHub Actions si assicura che queste regole siano soddisfatte prima dell'avvio dell'esecuzione del processo.

Ad esempio, è possibile configurare revisioni manuali sull'ambiente di produzione. Prima dell'avvio di una distribuzione di produzione, il revisore designato riceve una notifica. Tale persona può verificare manualmente che i criteri e le procedure vengano soddisfatti prima dell'inizio della distribuzione. Ad esempio, il responsabile approvazione potrebbe verificare che tutto funzioni come previsto nell'ambiente di pre-produzione prima di approvare la distribuzione.

È inoltre possibile eseguire un controllo automatizzato per verificare il ramo da cui proviene la modifica. Se la modifica non si trova nel ramo principale, è possibile configurare GitHub per impedire la distribuzione nell'ambiente di produzione.

Segreti

GitHub Actions consente di archiviare segreti che si possono usare solo con un ambiente specifico. Altre informazioni sulla gestione dei segreti verranno fornite più avanti in questo modulo.

Cronologia di distribuzione

GitHub Actions tiene traccia della cronologia delle distribuzioni in un ambiente. Questa cronologia offre un modo semplice per tenere traccia di ciò che accade nell'ambiente nel tempo. Consente anche di tracciare una distribuzione a livello di un commit nel repository. Questa funzionalità può essere utile se si verifica un problema con una distribuzione ed è necessario identificare la modifica che ha causato il problema.

Creazione di ambienti

Si può creare un ambiente usando l'interfaccia Web GitHub.

Quando il flusso di lavoro fa riferimento a un ambiente che non esiste, GitHub Actions lo crea automaticamente. Questa funzionalità può influire sulla sicurezza del repository GitHub perché nel nuovo ambiente non sarà configurata alcuna regola di protezione. È consigliabile creare un ambiente tramite l'interfaccia Web GitHub, in modo da avere il controllo completo sulla sicurezza.

Collegare un processo di distribuzione a un ambiente

Nella definizione del flusso di lavoro di distribuzione è possibile fare riferimento a un ambiente usando la proprietà environment:

jobs:
  deploy:
    environment: Test
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

In questo esempio, il processo denominato deploy viene collegato all'ambiente Test.

Ambienti e connessioni ad Azure

Quando si usano più ambienti, è necessario rendere ogni ambiente indipendente dagli altri. Ad esempio, il sito Web dell'ambiente di sviluppo non deve poter accedere a un database all'interno dell'ambiente di produzione.

Lo stesso principio si applica anche al flusso di lavoro di distribuzione. È necessario creare identità dei carichi di lavoro separate per ogni ambiente. Seguendo questa procedura si aggiunge un altro livello di protezione per assicurarsi che le distribuzioni non di produzione non influiscano sull'ambiente di produzione.

Alle identità dei carichi di lavoro devono essere assegnate autorizzazioni specifiche solo per la distribuzione nella sottoscrizione e nel gruppo di risorse usati da tale ambiente:

Importante

Usare un'identità del carico di lavoro separata per ogni ambiente in cui si prevede di eseguire la distribuzione. Concedere all'identità del carico di lavoro le autorizzazioni minime necessarie per la distribuzione nell'ambiente e nessun'altra.

È anche consigliabile separare gli ambienti in Azure. Come minimo, è necessario creare un gruppo di risorse separato per ogni ambiente. In molte situazioni, è meglio creare sottoscrizioni di Azure separate per ogni ambiente. È quindi possibile creare più gruppi di risorse all'interno della sottoscrizione di ogni ambiente.

Applicare le assegnazioni di ruolo di Azure affinché gli utenti e le identità dei carichi di lavoro possano accedere solo agli ambienti necessari. Limitare l'accesso all'ambiente di produzione a un piccolo gruppo di persone e all'identità del carico di lavoro di distribuzione per tale ambiente.

Credenziali federate per gli ambienti

Quando l'identità del carico di lavoro si connette ad Azure dal flusso di lavoro di distribuzione, usa una credenziale federata per autenticarsi in modo sicuro senza segreti o chiavi. Nei moduli precedenti di questo percorso di apprendimento le credenziali federate hanno concesso l'accesso ai flussi di lavoro di distribuzione quando sono stati distribuiti dal ramo main del repository Git.

Quando si esegue la distribuzione in un ambiente all'interno del flusso di lavoro, è necessario usare una credenziale federata con ambito in tale ambiente.

In questo modulo il flusso di lavoro include numerosi processi, molti dei quali si connettono ed eseguono la distribuzione in Azure. Alcuni dei processi usano gli ambienti, altri no. Si creano quindi due credenziali federate per ognuna delle identità dei carichi di lavoro: una con ambito ambiente e una con ambito ramo main.