Esercitazione: Configurare la distribuzione continua per un'app Web Python in App contenitore di Azure

Questo articolo fa parte di una serie di esercitazioni su come inserire e distribuire un'app Web Python in App Azure Container. Container Apps consente di distribuire app in contenitori senza la necessità di gestire un'infrastruttura complessa.

In questa esercitazione, imparerai a:

• Configurare la distribuzione continua per un'app contenitore usando un flusso di lavoro GitHub Actions.
• Apportare una modifica a una copia del repository di esempio per attivare il flusso di lavoro di GitHub Actions.
• Risolvere i problemi che possono verificarsi con la configurazione della distribuzione continua.
• Rimuovere le risorse non necessarie al termine della serie di esercitazioni.

La distribuzione continua è correlata alla pratica DevOps dell'integrazione continua e del recapito continuo (CI/CD), che è l'automazione del flusso di lavoro di sviluppo delle app.

Il diagramma seguente illustra le attività in questa esercitazione.

Prerequisiti

Per configurare la distribuzione continua, è necessario:

• Le risorse (e la loro configurazione) che hai creato nella precedente esercitazione, che includono un'istanza di Registro Azure Container e un'app contenitore in App contenitore di Azure.

• Un account GitHub in cui hai fatto un fork del codice di esempio (Django o Flask) al quale puoi connetterti da App contenitore di Azure. (Se hai scaricato il codice di esempio invece di creare un fork, assicurati di fare push del tuo repository locale sul tuo account GitHub.)

• Facoltativamente, Git è installato nell'ambiente di sviluppo per apportare modifiche al codice ed eseguire il push nel repository in GitHub. In alternativa, è possibile apportare le modifiche direttamente in GitHub.

Configurare la distribuzione continua per un contenitore

Nell'esercitazione precedente, hai creato e configurato un'applicazione contenitore in App contenitore di Azure. Parte della configurazione consisteva nel recuperare un'immagine Docker da un'istanza di Registro Azure Container. L'immagine del contenitore viene estratta dal Registro di sistema quando si crea un contenitore revisione, ad esempio quando si configura per la prima volta l'app contenitore.

In questa sezione viene configurata la distribuzione continua usando un flusso di lavoro di GitHub Actions. Con la distribuzione continua, viene creata una nuova immagine Docker e una nuova revisione del contenitore in base a un trigger. L'attivazione in questa esercitazione è qualsiasi modifica al branch main del tuo repository, ad esempio tramite una pull request. Quando il flusso di lavoro viene attivato, crea una nuova immagine Docker, la inserisce nell'istanza di Registro Azure Container e aggiorna l'app contenitore a una nuova revisione usando la nuova immagine.

interfaccia della riga di comando di Azure

È possibile eseguire comandi interfaccia della riga di comando di Azure in Azure Cloud Shell o in una workstation in cui è installato interfaccia della riga di comando di Azure.

Se si eseguono comandi in una shell Git Bash in un computer Windows, immettere il comando seguente prima di procedere:

export MSYS_NO_PATHCONV=1

1. Crea un service principal usando il comando az ad sp create-for-rbac:

   az ad sp create-for-rbac \
   --name <app-name> \
   --role Contributor \
   --scopes "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>"
   

   Nel comando :

   • <app-name> è un nome visualizzato facoltativo per l'entità servizio. Se si omette l'opzione --name, viene generato un GUID come nome visualizzato.
   • <subscription-ID> è il GUID che identifica in modo univoco la sottoscrizione in Azure. Se non si conosce l'ID della sottoscrizione, eseguire il comando az account show e copiarlo dalla proprietà id nell'output.
   • <resource-group-name> è il nome di un gruppo di risorse che contiene il contenitore App contenitore di Azure. Il controllo degli accessi in base al ruolo è a livello di gruppo di risorse. Se sono stati seguiti i passaggi dell'esercitazione precedente, il nome del gruppo di risorse è pythoncontainer-rg.

   Salvare l'output di questo comando per il passaggio successivo. In particolare, salvare l'ID client (proprietàappId), il segreto client ( proprietàpassword) e l'ID tenant ( proprietàtenant).

2. Configurare GitHub Actions usando il comando az containerapp github-action add:

   az containerapp github-action add \
   --resource-group <resource-group-name> \
   --name python-container-app \
   --repo-url <https://github.com/userid/repo> \
   --branch main \
   --registry-url <registry-name>.azurecr.io \
   --service-principal-client-id <client-id> \
   --service-principal-tenant-id <tenant-id> \
   --service-principal-client-secret <client-secret> \
   --login-with-github
   

   Nel comando :

   • <resource-group-name> è il nome del gruppo di risorse. In questa esercitazione si tratta di pythoncontainer-rg.
   • <https://github.com/userid/repo> è l'URL del tuo repository GitHub. In questa esercitazione, è https://github.com/userid/msdocs-python-django-azure-container-apps o https://github.com/userid/msdocs-python-flask-azure-container-apps. In questi URL userid è l'ID utente di GitHub.
   • <registry-name> è l'istanza di Registro Azure Container esistente creata nell'esercitazione precedente o una istanza che è possibile usare.
   • <client-id> è il valore della proprietà del appId comando precedente az ad sp create-for-rbac . L'ID è un GUID del formato 00000000-0000-0000-0000-00000000.
   • <tenant-id> è il valore della tenant proprietà del comando precedente az ad sp create-for-rbac . L'ID è anche un GUID simile all'ID del client.
   • <client-secret> è il valore della password proprietà del comando precedente az ad sp create-for-rbac .

Portale di Azure

1. Nel portale di Azure , passare all'applicazione contenitore per la quale si vuole configurare la distribuzione continua. Nel menu del servizio selezionare Distribuzione continua.

   

2. Autorizzare le App contenitore di Azure ad accedere all'account GitHub:

   1. Selezionare Accedi con GitHub.
   2. Nella finestra di dialogo di autorizzazione selezionare Autorizzare AzureAppService.

   

   Tip

   È possibile revocare l'accesso di Container Apps all'account GitHub nella sezione Sicurezza del tuo account.

3. Configurare i dettagli della distribuzione continua:

   • Organizzazione: usa il tuo nome utente GitHub.
   • Repository: selezionare il fork dell'app di esempio. (Se hai scaricato inizialmente il codice di esempio nel tuo ambiente di sviluppo, effettua il push del repository su GitHub.)
   • Ramo: selezionare main.
   • Origine del repository: Selezionare Registro Azure Container.
   • Registro di sistema: selezionare l'istanza di Registro Azure Container creata nell'esercitazione precedente.
   • Immagine: selezionare il nome dell'immagine Docker. In questa esercitazione si tratta di python-container-app.
   • Entità servizio: lascia Crea nuovo e consenti al processo di creazione di creare una nuova entità servizio.

   Selezionare Avviare la distribuzione continua per completare la configurazione.

   

4. Consulta le informazioni sulla distribuzione continua.

   Le informazioni includono un collegamento al file del flusso di lavoro GitHub Actions creato. App contenitore di Azure ha effettuato il check-in del file nel tuo repository.

   

Nella configurazione della distribuzione continua, un'entità servizio consente a GitHub Actions di accedere alle risorse di Azure e modificarle. I ruoli assegnati all'entità servizio limitano l'accesso alle risorse. All'entità servizio è assegnato il ruolo predefinito Collaboratore per il gruppo di risorse che contiene l'app contenitore.

Se si seguono i passaggi per il portale, l'entità servizio viene creata automaticamente. Se segui i passaggi per interfaccia della riga di comando di Azure, crei esplicitamente il service principal prima di configurare la distribuzione continua.

Ridistribuire l'app Web con GitHub Actions

In questa sezione viene apportata una modifica alla copia tramite fork del repository di esempio. Successivamente, è possibile verificare che la modifica venga distribuita automaticamente nel sito Web.

Se non l'hai già fatto, esegui il fork del repository di esempio (Django o Flask). È possibile apportare la modifica del codice direttamente in GitHub o nell'ambiente di sviluppo da una riga di comando con Git.

GitHub

1. Vai al tuo fork del repository di esempio e parti dal branch main.

   

2. Apportare una modifica:

   1. Passare al file /templates/base.html. Per Django, il percorso è restaurant_review/templates/restaurant_review/base.html.)
   2. Seleziona Modifica e modifica la frase Azure Restaurant Review in Azure Restaurant Review - Redeployed.

   

3. Nella parte inferiore della pagina che si sta modificando, assicurarsi che l'opzione Esegui commit direttamente nel ramo principale sia selezionata. Quindi selezionare il pulsante Conferma modifiche.

   

Il commit avvia il flusso di lavoro GitHub Actions.

Riga di comando

Se non l'hai già fatto, usa git clone per eseguire il pull del repository di cui hai eseguito il fork nel tuo ambiente di sviluppo e passa alla directory del repository. Seguire quindi questa procedura:

1. Iniziare in main:

   git checkout main
   git pull
   

2. Apporta una modifica.

   Vai al file ./templates/base.html (./restaurant_review/templates/restaurant_review/base.html per Django) e cambia la frase Azure Restaurant Review in Azure Restaurant Review - Redeployed.

3. Eseguire il commit e il push della modifica in GitHub:

   git commit -a -m "Redeploy with title change."
   git push
   

La prima volta che si usa Git, potrebbe essere necessario impostare le variabili globali user.name e user.email. Per ulteriori informazioni, consultare l'aiuto per git-config.

Il push delle modifiche al ramo principale avvia il flusso di lavoro GitHub Actions.

Nota

Questa esercitazione illustra come apportare una modifica direttamente nel ramo principale. Nei flussi di lavoro software tipici, si apporta una modifica in un ramo diverso da main e quindi si crea una pull request per unire la modifica nel main. Le pull request avviano anche il flusso di lavoro.

Comprendere GitHub Actions

Visualizzazione della cronologia del flusso di lavoro

Se è necessario visualizzare la cronologia del flusso di lavoro, utilizzare una delle procedure seguenti.

GitHub

In GitHub passare al fork del repository di esempio e aprire la scheda Azioni.

Riga di comando

Questi passaggi usano la CLI di GitHub .

1. Ottenere un riepilogo del flusso di lavoro. Eseguire il comando seguente nella cartella che contiene il clone:

   gh workflow view
   

   Questo comando richiede di selezionare un flusso di lavoro e quindi offre una panoramica delle esecuzioni recenti del flusso di lavoro.

   Nota

   La prima volta che si usa gh, potrebbe essere richiesto di eseguire l'autenticazione. Seguire i prompt di GitHub CLI per l'autenticazione.

   Se hai più di un repository remoto configurato, potrebbe esserti chiesto di eseguire gh repo set-default per selezionare un repository remoto predefinito. Seleziona il tuo fork tra le opzioni disponibili.

   È possibile eseguire il comando gh workflow view da qualsiasi cartella senza la necessità di impostare un repository predefinito aggiungendo il parametro --repo [HOST/]OWNER/REPO.

2. Passare a GitHub per informazioni dettagliate sull'esecuzione di un flusso di lavoro:

   gh workflow view --web
   

Segreti del flusso di lavoro

Il file di workflow .github/workflows/<workflow-name>.yml che aggiungi al repository include segnaposto per le credenziali necessarie ai processi di compilazione e di aggiornamento di Container App del workflow. Archiviare le informazioni sulle credenziali crittografate nell'area Impostazioni del repository, in Segreti di sicurezza>e variabili>Azioni.

Se le informazioni sulle credenziali cambiano, aggiornarla qui. Ad esempio, se le password Registro Azure Container vengono rigenerate, aggiornare il REGISTRY_PASSWORD valore. Per altre informazioni, vedere Encrypted secrets nella documentazione di GitHub.

App autorizzate OAuth

Quando si configura la distribuzione continua, si designa App contenitore di Azure come app OAuth autorizzata per l'account GitHub. Container Apps utilizza l'accesso autorizzato per creare un file YAML di GitHub Actions in .github/workflows/<nome-flusso-di-lavoro>.yml. È possibile visualizzare le app autorizzate e revocare le autorizzazioni nell'account in Integrations>Applications.

Troubleshoot

Si verificano errori durante la configurazione di un principale di servizio tramite la CLI di Azure

Questa sezione può aiutarti a risolvere gli errori che possono verificarsi durante la configurazione di un'entità servizio tramite il comando interfaccia della riga di comando di Azure az ad sp create-for-rbac.

Se ricevi un errore contenente "InvalidSchema: non sono stati trovati adattatori di connessione":

• Verifica quale shell stai usando. Se si utilizza una shell Bash, impostare la variabile MSYS_NO_PATHCONV come export MSYS_NO_PATHCONV=1.

  Per ulteriori informazioni, vedere il problema di GitHub Impossibile creare un'entità principale del servizio con interfaccia della riga di comando di Azure dalla shell Git Bash.

Se viene visualizzato un errore che contiene "Più applicazioni hanno lo stesso nome visualizzato":

• Il nome è già in uso per il service principal. Scegli un altro nome oppure elimina l'argomento --name. Un GUID viene generato automaticamente come nome visualizzato.

Flusso di lavoro di GitHub Actions non riuscito

Per controllare lo stato di un flusso di lavoro, passare alla scheda Azioni del repository:

• Se è presente un flusso di lavoro non riuscito, aprire il file del flusso di lavoro. Verranno visualizzati due processi: compilazione e distribuzione. Per un'operazione non riuscita, verificare l'output delle attività dell'operazione per individuare eventuali problemi.
• Se viene visualizzato un messaggio di errore contenente il timeout dell'handshake TLS, eseguire manualmente il flusso di lavoro. Nel repository, nella scheda Azioni selezionare Attiva distribuzione automatica 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/<nome del flusso di lavoro>.yml) viene creato automaticamente. Non è necessario modificare questo file per questa esercitazione. Se lo hai fatto, annulla le modifiche e prova il flusso di lavoro.

Il sito web non mostra le modifiche che hai unito nel ramo principale

In GitHub:

• Verificare che il flusso di lavoro di GitHub Actions sia stato eseguito e che sia stata verificata la modifica nel ramo che attiva il flusso di lavoro.

Nel portale di Azure:

• Controllare l'istanza di Registro Azure Container per verificare se è stata creata una nuova immagine Docker con un timestamp dopo la modifica al ramo.

• Controllare i log dell'app contenitore per verificare se si verifica un errore di programmazione:

  1. Vai all'app contenitore, quindi vai a Gestione revisioni><contenitore attivo>>Dettagli revisione>Log della console.
  2. Scegli l'ordine delle colonne da visualizzare: Time Generated, Stream_se Log_s.
  3. Ordinare i log in base ai più recenti e cercare i messaggi di Python e nella colonna Stream_s del flusso . L'output di Python print è di stdout messaggi.

Nella CLI di Azure:

• Usare il comando az containerapp logs show .

Vuoi interrompere la distribuzione continua

Interrompere la distribuzione continua significa scollegare l'app contenitore dal repo.

Nel portale di Azure:

• Passare all'app contenitore. Nel menu del servizio selezionare Distribuzione continua e quindi disconnetti.

Nella CLI di Azure:

• Usare il comando az containerapp github-action remove .

Dopo la disconnessione:

• Il file .github/workflows/<nome del flusso di lavoro>.yml viene rimosso dal tuo repository.
• Le chiavi segrete non vengono rimosse dal repository.
• App contenitore di Azure rimangono un'app OAuth autorizzata per il tuo account GitHub.
• In Azure il contenitore viene lasciato con l'ultimo contenitore distribuito. È possibile riconnettere l'app contenitore con l'istanza di Registro Azure Container, in modo che le nuove revisioni del contenitore rilevino l'immagine più recente.
• In Azure, i service principal che hai creato e usato per la distribuzione continua non vengono eliminati.

Rimuovere le risorse

Se hai finito con la serie di esercitazioni e non vuoi sostenere costi aggiuntivi, rimuovi le risorse usate.

La rimozione di un gruppo di risorse rimuove tutte le risorse nel gruppo ed è il modo più rapido per rimuovere le risorse. Per un esempio di come rimuovere i gruppi di risorse, vedi Pulizia dell'esercitazione sulla containerizzazione.

Contenuto correlato

Se prevedi di partire da questa esercitazione, prendi in considerazione i seguenti passi successivi:

• Impostare le regole di ridimensionamento nelle app Azure Container
• Associare nomi di dominio e certificati personalizzati in App Azure Container
• Monitorare un'app in App contenitore di Azure