Configurare applicazioni e macchine virtuali
È frequente compilare app e altro codice personalizzato per la soluzione Azure. Le app personalizzate possono includere siti Web, API e app in background che vengono eseguite senza alcuna interazione umana. In questa unità si apprenderà come progettare un flusso di lavoro per compilare e distribuire un'app insieme all'infrastruttura.
Compilazione di app
Molte app devono essere tradotte in linguaggio macchina o compilate prima di poter essere usate. Il processo di compilazione prende il codice sorgente per l’app, esegue una sequenza di attività su di esso e quindi crea un set di file distribuibili.
Con il processo di compilazione viene compilato il codice sorgente in file binari o eseguibili. Un processo di compilazione include normalmente altre attività, tra cui la compressione dei file di immagine che verranno forniti agli utenti del sito Web, il linting del codice per verificare che sia conforme alle procedure di codifica consigliate e l'esecuzione di unit test che verificano il comportamento delle singole parti dell'app. È anche possibile eseguire passaggi come la firma digitale dei file per assicurarsi che non possano essere modificati.
Qualunque sia la serie di passaggi, l'output del processo di compilazione è un artefatto distribuibile. L'artefatto viene normalmente salvato nel file system dello strumento di esecuzione del flusso di lavoro. Nelle parti successive del flusso di lavoro è necessario usare l'artefatto per distribuirlo attraverso gli ambienti e testarlo man mano che affronta i controlli di qualità definiti nella definizione del flusso di lavoro.
Nota
Probabilmente si è sentito parlare dei termini integrazione continua e distribuzione continua o CI/CD (integrazione continua e recapito continuo). Un processo di compilazione si trova all'interno della parte di integrazione continua del flusso di lavoro.
Artefatti del flusso di lavoro
Gli artefatti generati nel flusso di lavoro non vengono archiviati nel repository Git. Sono derivati dal codice sorgente ma non sono essi stessi codice, quindi non appartengono a un repository di controllo del codice sorgente. Vengono creati nel file system dello strumento di esecuzione del flusso di lavoro. Viene creato un nuovo strumento di esecuzione per ogni processo del flusso di lavoro, quindi è necessario condividere i file tra processi e strumenti di esecuzione.
Gli artefatti del flusso di lavoro forniscono un modo di archiviare file in GitHub Actions e sono associati all’esecuzione specifica del flusso di lavoro. Si usa l'azione actions/upload-artifact del flusso di lavoro per indicare a GitHub Actions di caricare un file o una cartella dal file system dello strumento di esecuzione come artefatto del flusso di lavoro:
- name: Upload folder as a workflow artifact
uses: actions/upload-artifact@v3
with:
name: my-artifact-name
path: ./my-folder
La proprietà path è la posizione che contiene il codice compilato o i file di output nel file system dello strumento di esecuzione del processo. I contenuti in questa posizione verranno caricati nell'artefatto. È possibile specificare un singolo file, più file o una cartella.
Ogni artefatto ha un nome, specificato usando la proprietà name. Si usa il nome dell'artefatto per farvi riferimento più avanti nel flusso di lavoro. Nei processi successivi del flusso di lavoro si può scaricare l'artefatto in modo che possa essere usato, ad esempio, per distribuire il sito Web nel server che lo ospita:
Usare l'azione actions/download-artifact per scaricare tutti gli artefatti del flusso di lavoro:
- uses: actions/download-artifact@v3
In alternativa, specificare un nome dell'artefatto per scaricare solo un artefatto specifico:
- uses: actions/download-artifact@v3
with:
name: my-artifact-name
Distribuire app
Il processo di compilazione per un'app genera e carica un artefatto distribuibile. Nei processi successivi del flusso di lavoro viene distribuito l'artefatto. Il modo in cui si distribuisce un’app dipende dal servizio usato per ospitarla.
Distribuire nel Servizio app di Azure
L'azienda di giocattoli usa Servizio app di Azure per ospitare il suo sito Web. È possibile creare e configurare un’app del servizio app usando Bicep, ma quando si tratta di distribuirla, sono disponibili diverse opzioni per spostare l’app compilata nell’infrastruttura di hosting. Queste opzioni vengono gestite come parte del piano dati di Servizio app di Azure.
L'approccio più comune consiste nell'usare l'azione azure/webapps-deploy:
- uses: azure/webapps-deploy@v2
with:
app-name: my-app-service
package: my-artifact-name/website.zip
È necessario fornire diverse informazioni per distribuire l'app in Servizio app di Azure. Queste informazioni includono il nome della risorsa dell’app del servizio app specificato usando la proprietà app-name. Come si è appreso nell'unità precedente, è necessario aggiungere un output al file Bicep e usare una variabile del flusso di lavoro per propagare il nome dell'app attraverso il flusso di lavoro. È anche necessario specificare un file .ZIP con l'app da distribuire usando la proprietà package. Questo è in genere il percorso di un artefatto del flusso di lavoro.
Servizio app di Azure dispone di un proprio sistema di autenticazione del piano dati usato per le distribuzioni. L'azione azure/webapps-deploy gestisce automaticamente il processo di autenticazione:
L'azione azure/webapps-deploy usa l'identità associata alla sessione di Azure attiva del processo, a cui è stato eseguito l'accesso usando un'identità del carico di lavoro
. L'azione crea e scarica le credenziali necessarie per la distribuzione
. Usa quindi le credenziali di distribuzione quando comunica con l'API del piano dati di Servizio app di Azure
.
Servizio app di Azure offre anche altre funzionalità correlate alla distribuzione, inclusi gli slot di distribuzione. Gli slot consentono di distribuire in modo sicuro nuove versioni delle app senza tempi di inattività. Consentono anche di preparare e modificare la nuova versione dell'applicazione prima di inviare il traffico di produzione. In questo modulo non vengono usati slot ma viene fornito un collegamento che porta ad altre informazioni su di essi nella pagina Riepilogo del modulo.
Distribuire app in altri servizi di Azure
Azure offre molte altre opzioni per ospitare le app, ognuna delle quali ha un proprio approccio alla distribuzione.
Funzioni di Azure si basa sul servizio app e usa un processo di distribuzione simile a quello descritto in precedenza.
Se si distribuisce in una macchina virtuale, è solitamente necessario connettersi all'istanza della macchina virtuale per installare l'app. Spesso è necessario usare strumenti specializzati, ad esempio Chef, Puppet o Ansible per orchestrare una distribuzione nelle macchine virtuali.
Se si usa Kubernetes o il servizio Azure Kubernetes, si userebbe in genere un approccio leggermente diverso per compilare e distribuire la soluzione. Dopo aver compilato l'app, il flusso di lavoro crea un'immagine del contenitore e la pubblica in un registro contenitori, da cui viene letto il cluster Kubernetes. Poiché il registro contenitori contiene l'applicazione compilata, in genere non si usa un artefatto del flusso di lavoro.
In questo modulo ci si concentra su Servizio app di Azure per illustrare i concetti usati del flusso di lavoro. Nella pagina Riepilogo alla fine del modulo vengono forniti collegamenti per altre informazioni sulla distribuzione in altri servizi di hosting.
Testare le app nel flusso di lavoro
In un modulo precedente si sono appresi il valore e l'importanza di eseguire test automatizzati dal flusso di lavoro. Quando si distribuisce un'app, è consigliabile che il flusso di lavoro esegua alcuni test che richiamano il codice dell'app. Tali test riducono il rischio che un errore dell'app o di distribuzione possa causare tempi di inattività. In scenari più avanzati è anche possibile eseguire un set di test case sull'app, ad esempio richiamando API o inviando e monitorando una transazione sintetica.
Molte app implementano endpoint di controllo dell'integrità. Quando un endpoint di controllo dell'integrità riceve una richiesta, esegue una serie di controlli sul sito Web, ad esempio per garantire che i database e i servizi di rete siano raggiungibili dall'ambiente dell'app. La risposta restituita dal sito indica se l'app è integra. Gli sviluppatori possono scrivere e personalizzare i propri controlli dell'integrità in base ai requisiti dell'app. Se l'app ha un endpoint di controllo dell'integrità, spesso è consigliabile monitorarlo dal flusso di lavoro al termine del processo di distribuzione.
Flusso di lavoro per la distribuzione
Nell'esercizio successivo si aggiornerà il flusso di lavoro di distribuzione per aggiungere nuovi processi che consentono di compilare l'applicazione del sito Web e di distribuirla in ogni ambiente:
