Informazioni sulle distribuzioni end-to-end
I flussi di lavoro GitHub Actions sono strumenti flessibili che è possibile configurare in molti modi diversi per soddisfare le proprie esigenze. In questa unità si apprenderà come usare i flussi di lavoro per distribuire un'intera soluzione, includendo la configurazione dell'infrastruttura di Azure, e come eseguire altre operazioni di distribuzione.
Quanti flussi di lavoro?
In alcune organizzazioni il team che gestisce l'ambiente di Azure è diverso dal team che sviluppa il codice eseguito nell'ambiente. In queste situazioni, spesso si tenta di creare più flussi di lavoro, ognuno di proprietà del team responsabile della propria area specifica. Ad esempio, è possibile creare un flusso di lavoro per distribuire il codice Bicep che distribuisce le risorse di Azure del sito Web, e un altro flusso di lavoro che distribuisce l'applicazione del sito Web.
Sebbene questo approccio potrebbe offrire una certa flessibilità nel modo in cui si gestiscono i flussi di lavoro, può essere difficile sincronizzare tutti gli elementi. Si supponga, ad esempio, che il team del sito Web abbia bisogno di una nuova impostazione nell'app di Servizio app di Azure per abilitare una funzionalità che si sta creando. Il flusso di lavoro di distribuzione dell'applicazione non può essere eseguito finché il flusso di lavoro di distribuzione dell'infrastruttura non è stata completato correttamente. Inoltre, può diventare complicato inviare i dati, ad esempio i nomi delle risorse di Azure create dal flusso di lavoro dell'infrastruttura, tra i flussi di lavoro.
È invece spesso preferibile creare un singolo flusso di lavoro che distribuisca tutti gli elementi necessari per la soluzione, anche se team diversi o persone diverse gestiscono i componenti. È possibile usare strumenti come Git e GitHub per coordinare il lavoro. Quando viene aggiunta una nuova funzionalità, è possibile usare un ramo per apportare le modifiche necessarie al file Bicep. Quando la modifica è pronta per l’integrazione e il rilascio, un singolo flusso di lavoro esegue tutti i passaggi necessari per compilare e distribuire la soluzione, riducendo così la possibilità di problemi di sincronizzazione.
Suggerimento
Quando si compila il codice per la soluzione, è probabilmente necessario distribuirlo spesso in modo che sia possibile testarne il funzionamento. Si potrebbe scoprire che la distribuzione dell'infrastruttura insieme al codice dell'applicazione rallenta l'esecuzione del flusso di lavoro e impedisce l'avanzamento delle operazioni.
Se ci si trova in questa situazione, è possibile disabilitare la distribuzione dell'infrastruttura per l'ambiente di sviluppo. È possibile usare filtri di percorso, flussi di lavoro riutilizzabili e condizioni per ottenere questo risultato. Tuttavia, è consigliabile non interrompere la sequenza di distribuzione completa degli altri ambienti.
Piano di controllo e piano dati
Molte risorse di Azure offrono due piani diversi per l'accesso. Il piano di controllo distribuisce e configura la risorsa. Il piano dati consente di accedere alle funzionalità della risorsa.
Quando si creano e si distribuiscono i file Bicep, si interagisce con il piano di controllo. In Azure il piano di controllo è Azure Resource Manager. Azure Resource Manager viene usato per definire la configurazione di ognuna delle risorse.
Tuttavia, il flusso di lavoro spesso deve eseguire più operazioni che semplicemente interagire con il piano di controllo. Ad esempio, potrebbe essere necessario eseguire le operazioni seguenti:
- Caricare un BLOB in un account di archiviazione.
- Modificare uno schema di database.
- Effettuare una chiamata API a un servizio di terze parti.
- Attivare un aggiornamento del modello di Machine Learning.
- Distribuire un sito Web in un'app di Servizio app di Azure.
- Distribuire il software in una macchina virtuale.
- Registrare una voce DNS con un provider di terze parti.
Quando si considera un flusso di lavoro end-to-end, in genere è necessario distribuire le risorse di Azure, quindi eseguire una serie di operazioni sui piani dati di tali risorse. A volte, queste operazioni vengono chiamate ultimo miglio della distribuzione, perché la maggior parte della distribuzione viene eseguita usando il piano di controllo, lasciando solo una piccola parte di configurazione.
Nota
Per alcune risorse, la divisione tra il piano di controllo e il piano dati non è ben definita. Tra queste sono inclusi Azure Data Factory e Gestione API di Azure. Entrambi i servizi supportano distribuzioni completamente automatizzate tramite Bicep, ma richiedono considerazioni speciali. Altre informazioni sono disponibili nei collegamenti presenti nella pagina di riepilogo alla fine del modulo.
Come eseguire operazioni del piano dati
Quando si crea un flusso di lavoro di distribuzione che interagisce con il piano dati delle risorse, è possibile usare uno qualsiasi tra tre approcci comuni:
- Script di distribuzione di Resource Manager
- Script del flusso di lavoro
- Azioni flusso di lavoro
Gli script di distribuzione di Resource Manager vengono definiti all'interno del file Bicep. Eseguono script di Bash o PowerShell e possono interagire con comandi dell'interfaccia della riga di comando di Azure e i cmdlet di Azure PowerShell. L'utente crea un'identità gestita per lo script di distribuzione da usare per eseguire l'autenticazione in Azure e Azure esegue automaticamente il provisioning e gestisce le altre risorse necessarie per eseguire lo script di distribuzione.
Gli script di distribuzione sono validi quando è necessario eseguire uno script di base all’interno del processo di distribuzione ma non forniscono facilmente l’accesso ad altri elementi dal flusso di lavoro.
È anche possibile eseguire la propria logica all'interno di un flusso di lavoro distribuzione. GitHub Actions offre un ecosistema ricco di azioni per le operazioni comuni che è necessario eseguire. Se non è possibile trovare un'azione che soddisfi le proprie esigenze, è possibile usare uno script per eseguire il codice di Bash o PowerShell. Le azioni e gli script del flusso di lavoro vengono eseguiti dallo strumento di esecuzione del flusso di lavoro. Spesso è necessario autenticare l’azione o lo script nel piano dati del servizio in uso e il modo in cui si esegue questa operazione dipende dal servizio.
Le azioni e gli script del flusso di lavoro offrono flessibilità e controllo. Consentono anche di accedere agli artefatti del flusso di lavoro che verranno illustrati a breve. In questo modulo ci si concentra sulle azioni del flusso di lavoro. Altre informazioni sugli script di distribuzione di Resource Manager sono disponibili nei collegamenti della pagina di riepilogo alla fine del modulo.
Output
Un flusso di lavoro crea e configura normalmente le risorse di Azure distribuendo un file Bicep. Le parti successive del flusso di lavoro interagiscono quindi con il piano dati di tali risorse. Per poter interagire con le risorse, le attività e i passaggi del flusso di lavoro richiedono informazioni sulla risorsa di Azure creata.
Si supponga, ad esempio, di avere un file Bicep che distribuisce un account di archiviazione. Si desidera che il flusso di lavoro distribuisca l'account di archiviazione e quindi carichi alcuni BLOB in un contenitore BLOB dell'account di archiviazione. L'attività del flusso di lavoro che carica i BLOB deve conoscere il nome dell'account di archiviazione a cui connettersi e il nome del contenitore BLOB in cui caricare il file.
È consigliabile che il file Bicep definisca i nomi delle risorse di Azure. Potrebbe usare parametri, variabili o espressioni per creare i nomi per l'account di archiviazione e il contenitore BLOB. Il file Bicep può quindi esporre un output che definisce il nome di ogni risorsa. I passaggi successivi del flusso di lavoro possono leggere il valore di output. In questo modo, la definizione del flusso di lavoro non deve impostare come hard-coded i nomi o altre informazioni che potrebbero cambiare tra ambienti o essere basate su regole definite nel file Bicep.
Con GitHub Actions, è possibile propagare i valori degli output usando le variabili del flusso di lavoro. L'azione azure/arm-deploy crea automaticamente variabili per ogni output della distribuzione Bicep. È anche possibile creare manualmente variabili del flusso di lavoro negli script. Sono disponibili collegamenti ad altre informazioni nella pagina Riepilogo alla fine di questo modulo.
Quando si accede alle variabili create in un altro processo, è necessario pubblicare la variabile per renderla accessibile al processo che la legge. Si supponga, ad esempio, di creare un processo che distribuisce un file Bicep e di propagare l'output appServiceAppName al flusso di lavoro. Si usa la parola chiave outputs per specificare che la variabile del flusso di lavoro appServiceAppName deve essere impostata sul valore della variabile dell'output appServiceAppName creata dal passaggio deploy:
job1:
runs-on: ubuntu-latest
outputs:
appServiceAppName: ${{ steps.deploy.outputs.appServiceAppName }}
steps:
- uses: actions/checkout@v3
- uses: azure/login@v1
name: Sign in to Azure
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- uses: azure/arm-deploy@v1
id: deploy
name: Deploy Bicep file
with:
failOnStdErr: false
deploymentName: ${{ github.run_number }}
resourceGroupName: Playground1
template: ./deploy/main.bicep
In un processo successivo viene quindi creata una dipendenza esplicita dal processo che ha creato la variabile includendo la parola chiave needs e si fa riferimento alla variabile usando il nome della variabile pubblicata:
job2:
needs: job1
runs-on: ubuntu-latest
steps:
- run: |
echo "${{needs.job1.outputs.appServiceAppName}}"
Usando gli output di Bicep e le variabili del flusso di lavoro, è possibile creare un flusso di lavoro in più fasi che distribuisce il codice Bicep e successivamente esegue varie azioni sulle risorse come parte della distribuzione.