Condividi tramite

Distribuire app Web Python nel servizio app usando GitHub Actions (Linux)

Questo articolo descrive come usare la piattaforma di integrazione continua e recapito continuo (CI/CD) in GitHub Actions per distribuire un'app Web Python nel servizio app di Azure in Linux. Il flusso di lavoro di GitHub Actions compila automaticamente il codice e lo distribuisce nell'istanza del 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

Per completare le procedure descritte in questo articolo, è necessario eseguire il commit di un'app Web Python in un repository GitHub.

Annotazioni

Se l'app usa Django e un database SQLite , non funzionerà per queste procedure. SQLite non è supportato nella maggior parte degli ambienti ospitati nel cloud a causa delle limitazioni di archiviazione locali basate su file. Valutare la possibilità di passare a un database compatibile con il cloud, ad esempio PostgreSQL o Azure Cosmos DB. Per altre informazioni, vedere Esaminare le considerazioni su Django più avanti in questo articolo.

Creare un'istanza del Servizio App di destinazione

Il modo più rapido per creare un'istanza del servizio app consiste nell'usare l'interfaccia della riga di comando di Azure tramite l'interfaccia interattiva di Azure Cloud Shell. La Cloud Shell include Git e l'Azure CLI. Nella procedura seguente si usa il comando az webapp up per creare l'istanza del servizio app ed eseguire la distribuzione iniziale dell'app.

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

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

    Screenshot che mostra come aprire Azure Cloud Shell usando l'azione icona sulla barra degli strumenti del portale di Azure.

  3. In Cloud Shell selezionare l'opzione Bash dal menu a discesa:

    Screenshot che mostra come selezionare l'opzione Bash in Cloud Shell.

  4. In Cloud Shell, clona il repository usando il comando git clone.

    Suggerimento

    Per incollare comandi o testo in Cloud Shell, usare i tasti di scelta rapida CTRL+MAIUSC+V oppure fare clic con il pulsante destro del mouse e scegliere Incolla dal menu di scelta rapida.

    • Per l'app di esempio Flask, è possibile usare il comando seguente. Sostituire la <github-user> parte con il nome dell'account GitHub in cui è stato creato il fork del repository:

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

    • Se l'app si trova in un repository diverso, configurare GitHub Actions per il repository specifico. Sostituire la <github-user> parte con il nome dell'account GitHub in cui è stato creato il fork del repository e specificare il nome effettivo del repository nel <repo-name> segnaposto:

      git clone https://github.com/<github-user>/<repo-name>.git

    Annotazioni

    Cloud Shell è supportato da un account di archiviazione di Azure in un gruppo di risorse denominato cloud-shell-storage-your-region<>. L'account di archiviazione contiene un'immagine del file system di Cloud Shell, che archivia il repository clonato. C'è un piccolo costo per questa archiviazione. È possibile eliminare l'account di archiviazione dopo aver completato questo articolo, insieme ad altre risorse create.

  5. In Cloud Shell modificare la directory nella cartella del repository per l'app Python, quindi il comando az webapp up riconosce l'app come Python. Per l'app di esempio Flask, usare il comando seguente:

    cd python-sample-vscode-flask-tutorial

  6. In Cloud Shell usare il comando az webapp up per creare un'istanza del servizio app ed eseguire la distribuzione iniziale per l'app:

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

    • Per il <app-service-name> segnaposto, specificare un nome univoco di servizio app 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.

    • Per un elenco dei runtime disponibili nel sistema, usare il az webapp list-runtimes comando .

    • Quando si immette il valore di runtime nel comando, usare il PYTHON:X.Y formato , dove X.Y è la versione principale e secondaria di Python.

    • È anche possibile specificare la posizione dell'area dell'istanza del servizio app usando il --location parametro . Per un elenco delle posizioni disponibili, usare il az account list-locations --output table comando .

  7. Se l'app ha uno script di avvio personalizzato, usare il comando az webapp config per avviare lo script.

    • Se l'app non ha uno script di avvio personalizzato, continuare con il passaggio successivo.

    • Per l'app di esempio Flask, è necessario accedere allo script di avvio nel file startup.txt eseguendo il comando seguente:

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

      Fornire il nome del gruppo di risorse e il nome dell'istanza di App Service nei segnaposto <resource-group-name> e <app-service-name>. Per trovare il nome del gruppo di risorse, controllare l'output del comando precedente az webapp up . Il nome del gruppo di risorse include il nome dell'account di Azure seguito dal suffisso _rg , come in <azure-account-name>_rg_.

  8. Per visualizzare l'app in esecuzione, aprire un browser e passare all'endpoint di distribuzione per l'istanza del servizio app. Nell'URL seguente sostituire il segnaposto con il nome dell'istanza <app-service-name> del servizio app:

    http://<app-service-name>.azurewebsites.net

    Se viene visualizzata una pagina generica, attendere alcuni secondi per l'avvio dell'istanza del servizio app e aggiornare la pagina.

    • Se si continua a visualizzare una pagina generica, verificare che sia stata distribuita dalla cartella corretta.
    • Per l'app di esempio Flask, verificare che sia stata distribuita dalla cartella python-sample-vscode-flask-tutorial . Verificare anche di impostare correttamente il comando di avvio.

Configurare la distribuzione continua in App Service

Nella procedura successiva si configura il recapito continuo (CD), il che significa che viene eseguita una nuova distribuzione del codice ogni volta che viene attivato un flusso di lavoro. Il trigger nell'esempio dell'articolo è qualsiasi modifica al branch principale del tuo repository, ad esempio con una pull request (PR).

  1. In Cloud Shell, verificate di essere nella directory radice per il sistema (~) e non in una sottocartella dell'app, ad esempio python-sample-vscode-flask-tutorial.

  2. Aggiungere GitHub Actions con il comando az webapp deployment github-actions add . Sostituite i segnaposto con i valori specifici:

    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 e completare l'autenticazione.

    • Se il sistema rileva un file del flusso di lavoro esistente con lo stesso nome dell'istanza del servizio app, seguire le istruzioni per scegliere se sovrascrivere il flusso di lavoro. È possibile usare il --force parametro con il comando per sovrascrivere automaticamente tutti i flussi di lavoro in conflitto.

    Il add comando completa le attività seguenti:

    • Crea un nuovo file del flusso di lavoro nel percorso .github/workflows/<workflow-name>.yml nel repository. Il nome del file contiene il nome dell'istanza del servizio app.
    • Recupera un profilo di pubblicazione con segreti per l'istanza del servizio app e lo aggiunge come segreto dell'azione GitHub. Il nome del segreto inizia con AZUREAPPSERVICE_PUBLISHPROFILE_. Questo segreto è riferito nel file del flusso di lavoro.

  3. Ottenere i dettagli di una configurazione di distribuzione del controllo del codice sorgente con il comando az webapp deployment source show . Sostituire i parametri segnaposto con i valori specifici:

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

  4. Nell'output del comando, verifica i valori per le proprietà repoUrl e branch. Questi valori devono corrispondere ai valori specificati con il add comando .

Esaminare il flusso di lavoro e le azioni di GitHub

Una definizione del flusso di lavoro viene specificata in un file YAML (.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 e ogni processo è un set di passaggi. Ogni passaggio è uno script della shell o un'azione. Ogni processo ha una sezione Action nel file del flusso di lavoro.

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

Azione Descrizione
cassa Controlla il repository su un runner, un agente GitHub Actions.
setup-python Installare Python sull'esecutore.
appservice-build Compilare l'app Web.
webapps-deploy Distribuire l'applicazione web usando le credenziali del profilo di pubblicazione per l'autenticazione in Azure. Le credenziali vengono archiviate in un segreto GitHub.

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 il servizio app di Azure come app OAuth autorizzata per l'account GitHub. Il servizio app usa l'accesso autorizzato per creare un file YAML dell'azione GitHub nel percorso .github/workflows/<workflow-name>.yml nel repository.

Per visualizzare le app autorizzate e revocare le autorizzazioni con gli account GitHub, passare a Impostazioni>Integrazioni/Applicazioni:

Screenshot che mostra come visualizzare le app OAuth autorizzate per un account GitHub.

Segreto del profilo di pubblicazione del flusso di lavoro

Nel file del flusso di lavoro .github/workflows/<workflow-name>.yml aggiunto al repository è presente 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.

Per visualizzare il segreto, passare a Impostazioni>Sicurezza>Segreto e variabili>Azioni:

Screenshot che mostra come visualizzare i segreti delle azioni per un repository in GitHub.

In questo articolo, l'azione GitHub esegue l'autenticazione con una credenziale del profilo di pubblicazione. Esistono altri modi per eseguire l'autenticazione, ad esempio con un principale del servizio o OpenID Connect. Per altre informazioni, vedere Distribuire su App Service con GitHub Actions.

Eseguire e testare il flusso di lavoro

L'ultimo passaggio consiste nel testare il flusso di lavoro apportando una modifica al repository.

  1. Vai al tuo fork del repository di esempio (o al repository utilizzato) e seleziona il branch che hai impostato come parte del trigger in un browser:

    Screenshot che mostra come passare al repository e al ramo in cui è definito il flusso di lavoro di GitHub Actions.

  2. Apportare una piccola modifica all'app Web Python.

    Per l'esercitazione su Flask, ecco una semplice modifica:

    1. Passare al file /hello-app/templates/home.html del ramo trigger.
    2. Selezionare Modifica (matita).
    3. Nell'editor individuare l'istruzione print <p> e aggiungere il testo "Ridistribuire!"

  3. Esegui il commit della modifica direttamente nel ramo in cui stai lavorando.

    1. Nell'editor selezionare Conferma modifiche in alto a destra. Verrà visualizzata la finestra Applica modifiche.
    2. Nella finestra Commit changes (Modifiche commit) modificare il messaggio di commit in base alle esigenze e selezionare Commit changes (Esegui commit modifiche).

    Il processo di commit attiva il flusso di lavoro di GitHub Actions.

È anche possibile attivare il flusso di lavoro manualmente:

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

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

Risolvere i problemi relativi al flusso di lavoro non riuscito

È possibile controllare lo stato di un flusso di lavoro nella scheda Azioni per il repository dell'app. Quando si esamina il file del flusso di lavoro creato in questo articolo, vengono visualizzati due processi: compilazione e distribuzione. Come promemoria, il flusso di lavoro si basa sul modello Azure/actions-workflow-samples .

Per un processo non riuscito, esaminare l'output dei compiti del processo per identificare un'indicazione del fallimento.

Ecco alcuni problemi comuni da analizzare:

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

  • Se hai effettuato il provisioning del servizio app tramite il portale, l'impostazione dell'azione SCM_DO_BUILD_DURING_DEPLOYMENT di compilazione potrebbe non essere 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 relativo al timeout dell'handshake TLS, eseguire manualmente il flusso di lavoro selezionando Attiva distribuzione automatica nella scheda Azioni del repository dell'app. È possibile determinare se il timeout è un problema temporaneo.

  • Se si configura la distribuzione continua per l'app contenitore, come illustrato in questo articolo, il file del flusso di lavoro iniziale .github/workflows/<workflow-name>.yml viene creato automaticamente. Se il file è stato modificato, rimuovere le modifiche per verificare se causano l'errore.

Eseguire uno script post-distribuzione

Uno script post-distribuzione può completare diverse attività, ad esempio la definizione delle variabili di ambiente previste dal codice dell'app. Aggiungere lo script come parte del codice dell'app ed eseguire lo script usando il comando di avvio.

Per evitare di definire in modo rigido i valori delle variabili nel file YAML del flusso di lavoro, considera di configurare le variabili su GitHub e di fare riferimento ai nomi delle variabili nello script. È possibile creare segreti crittografati per un repository o per un ambiente (repository account). Per altre informazioni, vedere Uso dei segreti in GitHub Actions.

Esaminare le considerazioni su Django

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

L'articolo Configurare l'app Python nel servizio app - Processo di avvio del contenitore descrive come il 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 codice seguente illustra 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 il python manage.py migrate comando dopo aver distribuito il codice dell'app. È possibile eseguire il comando migrate in uno script di post-distribuzione.

Disconnettere GitHub Actions

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

Scollega GitHub Actions utilizzando il comando seguente dell'interfaccia della riga di comando di Azure az webapp deployment github-actions remove. Sostituite i segnaposto con i valori specifici:

az webapp deployment github-actions remove \
  --repo "<github-username>/<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 questo articolo, eliminare il gruppo di risorse che contiene l'istanza del servizio app e il piano di servizio app.

Ovunque sia installata l'interfaccia della riga di comando di Azure, incluso Azure Cloud Shell, è possibile usare il comando az group delete per eliminare un gruppo di risorse:

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

Eliminare l'account di archiviazione

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.

Aggiornare l'account e il repository GitHub

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

  • Nel repository dell'app rimuovere il file .github/workflows/<workflow-name>.yml .
  • Nelle impostazioni del repository dell'app rimuovere la chiave privata AZUREAPPSERVICE_PUBLISHPROFILE_ creata per il flusso di lavoro.
  • Nelle impostazioni dell'account GitHub, rimuovere Azure App Service come app OAuth autorizzata per l'account GitHub.

Contenuti correlati