Usare CI/CD con GitHub Actions per distribuire un'app Web Python nel servizio app Azure in Linux

Usare la piattaforma di integrazione continua e recapito continuo (CI/CD) di GitHub Actions per distribuire un'app Web Python in app Azure Servizio in Linux. Il flusso di lavoro di GitHub Actions compila automaticamente il codice e lo distribuisce nel servizio app ogni volta che è presente un commit nel repository. È possibile aggiungere altre automazione nel flusso di lavoro di GitHub Actions, ad esempio script di test, controlli di sicurezza e distribuzione a più fasi.

Creare un repository per il codice dell'app

Se si ha già un'app Web Python da usare, assicurarsi che venga eseguito il commit in un repository GitHub.

Se è necessaria un'app da usare, è possibile creare una copia tramite fork e clonare il repository in https://github.com/Microsoft/python-sample-vscode-flask-tutorial. Il codice proviene dall'esercitazione Flask in Visual Studio Code.

Creare il servizio app Azure di destinazione

Il modo più rapido per creare un'istanza di servizio app consiste nell'usare l'interfaccia della riga di comando di Azure tramite Azure Cloud Shell interattivo. Cloud Shell include Git e l'interfaccia della riga di comando di Azure. Nei passaggi seguenti si userà az webapp up per creare il servizio app ed eseguire la prima distribuzione dell'app.

Passaggio 1: Accedere al portale di Azure all'indirizzohttps://portal.azure.com.

Passaggio 2. Aprire l'interfaccia della riga di comando di Azure selezionando l'icona di Cloud Shell sulla barra degli strumenti del portale.

Passaggio 3. In Cloud Shell selezionare Bash nell'elenco a discesa.

Passaggio 4. In Cloud Shell clonare il repository usando git clone. Ad esempio, se si usa l'app di esempio Flask, il comando è:

git clone https://github.com/<github-user>/python-sample-vscode-flask-tutorial.git

Sostituire <github-user> con il nome dell'account GitHub in cui è stato creato il fork del repository. Se si usa un repository di app diverso, questo repository è la posizione in cui si configurerà GitHub Actions.

Passaggio 5. In Cloud Shell modificare la directory nella cartella del repository con l'app Python in modo che il comando az webapp up riconosca l'app come Python. Ad esempio, per l'app di esempio Flask:

cd python-sample-vscode-flask-tutorial

Passaggio 6. In Cloud Shell usare az webapp up per creare un servizio app e distribuire inizialmente l'app.

az webapp up --name <app-service-name> --runtime "PYTHON:3.9"

Specificare un nome servizio app univoco in Azure. Il nome deve essere lungo 3-60 caratteri e può contenere solo lettere, numeri e trattini. Il nome deve iniziare con una lettera e terminare con una lettera o un numero.

Usare az webapp list-runtimes per ottenere un elenco dei runtime disponibili. Usare il PYTHON|X.Y formato , dove X.Y è la versione di Python.

È anche possibile specificare la posizione del servizio app con il --location parametro . Usare il az account list-locations --output table comando per ottenere un elenco delle posizioni disponibili.

Passaggio 7. Se l'app usa un comando di avvio personalizzato, usare il comando az webapp config . Se l'app non ha un comando di avvio personalizzato, ignorare questo passaggio.

Ad esempio, l'app python-sample-vscode-flask-tutorial contiene un file denominato startup.txt che contiene un comando di avvio che è possibile usare come segue:

az webapp config set \
  --resource-group <resource-group-name> \
  --name <app-service-name> \
  --startup-file startup.txt

È possibile trovare il nome del gruppo di risorse dall'output del comando precedente az webapp up . Il nome del gruppo di risorse inizierà con <azure-account-name>_rg_.

Passaggio 8. Per visualizzare l'app in esecuzione, aprire un browser e passare a http://< app-service-name.azurewebsites.net>.

Se viene visualizzata una pagina generica, attendere alcuni secondi per l'avvio del servizio app e aggiornare la pagina. Se si continua a visualizzare la pagina generica, verificare che sia stata distribuita dalla cartella corretta. Ad esempio, se si usa l'app di esempio Flask, la cartella è python-sample-vscode-flask-tutorial. Inoltre, per l'app di esempio Flask, verificare di impostare correttamente il comando di avvio.

Configurare la distribuzione continua in servizio app

Nei passaggi seguenti si configurerà la distribuzione continua (CD), il che significa che si verifica una nuova distribuzione del codice quando viene attivato un flusso di lavoro. Il trigger in questa esercitazione è qualsiasi modifica al ramo principale del repository, ad esempio con una richiesta pull.

Passaggio 1: Aggiungere GitHub Action con il comando az webapp deployment github-actions add .

az webapp deployment github-actions add \
  --repo "<github-user>/<github-repo>" \
  --resource-group <resource-group-name> \
  --branch <branch-name> \
  --name <app-service-name> \
  --login-with-github

Il --login-with-github parametro usa un metodo interattivo per recuperare un token di accesso personale. Seguire le istruzioni per completare l'autenticazione.

Se è presente un file del flusso di lavoro esistente in conflitto con il nome servizio app usato, verrà chiesto di scegliere se sovrascrivere. Usare il --force parametro per sovrascrivere senza chiedere.

Cosa fa il comando add:

• Crea un nuovo file del flusso di lavoro: .github/workflows/<workflow-name.yml> nel repository. Il nome del file conterrà il nome del servizio app.
• Recupera un profilo di pubblicazione con segreti per il servizio app e lo aggiunge come segreto dell'azione GitHub. Il nome del segreto inizierà con AZUREAPP edizione StandardRVICE_PUBLISHPROFILE_. Questo segreto viene fatto riferimento nel file del flusso di lavoro.

Passaggio 2. Ottenere i dettagli di una configurazione di distribuzione del controllo del codice sorgente con il comando az webapp deployment source show .

az webapp deployment source show \
  --name <app-service-name> \
  --resource-group <resource-group-name>

Nell'output del comando verificare i valori per le repoUrl proprietà e branch . Questi valori devono corrispondere ai valori specificati nel passaggio precedente.

Informazioni sul flusso di lavoro e le azioni di GitHub

Un flusso di lavoro viene definito da un file YAML (con estensione yml) nel percorso /.github/workflows/ nel repository. Questo file YAML contiene i vari passaggi e parametri che costituiscono il flusso di lavoro, un processo automatizzato associato a un repository GitHub. È possibile compilare, testare, creare pacchetti, rilasciare e distribuire qualsiasi progetto in GitHub con un flusso di lavoro.

Ogni flusso di lavoro è costituito da uno o più processi. Ogni processo a sua volta è un set di passaggi. Infine, ogni passaggio è uno script della shell o un'azione.

In termini di flusso di lavoro configurato con il codice Python per la distribuzione in servizio app, il flusso di lavoro ha le azioni seguenti:

Il modello di flusso di lavoro usato per creare il flusso di lavoro è Azure/actions-workflow-samples.

Il flusso di lavoro viene attivato in caso di eventi push nel ramo specificato. L'evento e il ramo vengono definiti all'inizio del file del flusso di lavoro. Ad esempio, il frammento di codice seguente mostra che il flusso di lavoro viene attivato in eventi push nel ramo main :

on:
  push:
    branches:
    - main

App autorizzate OAuth

Quando si configura la distribuzione continua, si autorizza app Azure Servizio come app OAuth autorizzata per l'account GitHub. servizio app usa l'accesso autorizzato per creare un file YML dell'azione GitHub in .github/workflows/<workflow-name.yml>. È possibile visualizzare le app autorizzate e revocare le autorizzazioni con gli account GitHub Impostazioni, in Integrazioni/applicazioni.

Segreto del profilo di pubblicazione del flusso di lavoro

Nel file del flusso di lavoro .github/workflows/<workflow-name.yml> aggiunto al repository verrà visualizzato un segnaposto per le credenziali del profilo di pubblicazione necessarie per il processo di distribuzione del flusso di lavoro. Le informazioni sul profilo di pubblicazione vengono archiviate crittografate nel repository Impostazioni, in Sicurezza/Azioni.

In questo articolo l'azione GitHub esegue l'autenticazione con credenziali del profilo di pubblicazione. Esistono altri modi per eseguire l'autenticazione, ad esempio con un'entità servizio o openID Connessione. Per altre informazioni, vedere Distribuire in servizio app usando GitHub Actions.

Eseguire il flusso di lavoro

A questo punto si testerà il flusso di lavoro apportando una modifica al repository.

Passaggio 1: Passare al fork del repository di esempio (o al repository usato) e selezionare il ramo impostato come parte del trigger.

Passaggio 2. Apportare una piccola modifica.

Ad esempio, se è stata usata l'esercitazione di VS Code Flask, è possibile

• Passare al file /hello-app/templates/home.html del ramo trigger.
• Selezionare Modifica e aggiungere il testo "Ridistribuito!".

Passaggio 3. Eseguire il commit della modifica direttamente nel ramo in cui si sta lavorando.

• Nell'angolo in alto a destra della pagina che si sta modificando, selezionare il pulsante Commit changes ... (Esegui commit modifiche). Verrà visualizzata la finestra Commit changes (Esegui commit modifiche ). Nella finestra Commit changes (Modifiche commit) modificare il messaggio di commit se necessario e quindi selezionare il pulsante Commit changes (Esegui commit modifiche).
• Il commit avvia il flusso di lavoro di GitHub Actions.

È anche possibile avviare manualmente il flusso di lavoro.

Passaggio 1: Passare alla scheda Azioni del repository configurato per la distribuzione continua.

Passaggio 2. Selezionare il flusso di lavoro nell'elenco dei flussi di lavoro e quindi selezionare Esegui flusso di lavoro.

Risoluzione dei problemi relativi a un flusso di lavoro non riuscito

Per controllare lo stato di un flusso di lavoro, passare alla scheda Azioni del repository. Quando si esamina il file del flusso di lavoro creato in questa esercitazione, verranno visualizzati due processi "build" e "deploy". Per un processo non riuscito, esaminare l'output delle attività di processo per indicare l'errore. Alcuni problemi comuni sono:

• Se l'app non riesce a causa di una dipendenza mancante, il file requirements.txt non è stato elaborato durante la distribuzione. Questo comportamento si verifica se l'app Web è stata creata direttamente nel portale anziché usare il az webapp up comando come illustrato in questo articolo.

• Se è stato effettuato il provisioning del servizio app tramite il portale, l'azione di compilazione SCM_DO_BUILD_DURING_DEPLOYMENT impostazione potrebbe non essere stata impostata. Questa impostazione deve essere impostata su true. Il az webapp up comando imposta automaticamente l'azione di compilazione.

• Se viene visualizzato un messaggio di errore con "Timeout handshake TLS", eseguire manualmente il flusso di lavoro selezionando Attiva distribuzione automatica nella scheda Azioni del repository per verificare se il timeout è un problema temporaneo.

• Se si configura la distribuzione continua per l'app contenitore come illustrato in questa esercitazione, il file del flusso di lavoro (.github/workflows/<workflow-name.yml>) viene creato automaticamente automaticamente. Se è stata modificata, rimuovere le modifiche per verificare se causano l'errore.

Eseguire uno script post-distribuzione

Uno script post-distribuzione può, ad esempio, definire le variabili di ambiente previste dal codice dell'app. Aggiungere lo script come parte del codice dell'app ed eseguirlo usando il comando di avvio.

Per evitare valori di variabile hardcoded nel file YML del flusso di lavoro, è possibile usarli nell'interfaccia Web di GitHub e quindi fare riferimento al nome della variabile nello script. È possibile creare segreti crittografati per un repository o per un ambiente (repository account). Per altre informazioni, vedere Segreti crittografati in GitHub Docs.

Considerazioni per Django

Come indicato in precedenza in questo articolo, è possibile usare GitHub Actions per distribuire app Django in app Azure Servizio in Linux, se si usa un database separato. Non è possibile usare un database SQLite perché servizio app blocca il file db.sqlite3, impedendo sia letture che scritture. Questo comportamento non influisce su un database esterno.

Come descritto nell'articolo Configurare l'app Python in servizio app - Processo di avvio del contenitore, servizio app cerca automaticamente un file wsgi.py all'interno del codice dell'app, che in genere contiene l'oggetto app. Quando è stato usato il webapp config set comando per impostare il comando di avvio, è stato usato il --startup-file parametro per specificare il file che contiene l'oggetto app. Il webapp config set comando non è disponibile nell'azione webapps-deploy. È invece possibile usare il startup-command parametro per specificare il comando di avvio. Ad esempio, il frammento di codice seguente mostra come specificare il comando di avvio nel file del flusso di lavoro:

startup-command: startup.txt

Quando si usa Django, in genere si vuole eseguire la migrazione dei modelli di dati usando python manage.py migrate il comando dopo la distribuzione del codice dell'app. È possibile eseguire il comando migrate in uno script di post-distribuzione.

Disconnettere GitHub Actions

La disconnessione di GitHub Actions dal servizio app consente di riconfigurare la distribuzione dell'app. È possibile scegliere cosa accade al file del flusso di lavoro dopo la disconnessione, se salvare o eliminare il file.

az webapp deployment github-actions remove \
  --repo "<github-user>/<github-repo>" \
  --resource-group <resource-group-name> \
  --branch <branch-name> \
  --name <app-service-name> \
  --login-with-github

Pulire le risorse

Per evitare addebiti per le risorse di Azure create in questa esercitazione, eliminare il gruppo di risorse che contiene il servizio app e il piano di servizio app.

az group delete --name <resource-group-name>

Per eliminare l'account di archiviazione che gestisce il file system per Cloud Shell, che comporta un piccolo addebito mensile, eliminare il gruppo di risorse che inizia con cloud-shell-storage-. Se si è l'unico utente del gruppo, è possibile eliminare il gruppo di risorse. Se sono presenti altri utenti, è possibile eliminare un account di archiviazione nel gruppo di risorse.

Se è stato eliminato il gruppo di risorse di Azure, è consigliabile apportare anche le modifiche seguenti all'account GitHub e al repository connessi per la distribuzione continua:

• Nel repository rimuovere il file .github/workflows/<workflow-name.yml>.
• Nelle impostazioni del repository rimuovere la chiave privata AZUREAPP edizione StandardRVICE_PUBLISHPROFILE_ creata per il flusso di lavoro.
• Nelle impostazioni dell'account GitHub rimuovere app Azure Servizio come app Oauth autorizzata per l'account GitHub.