Configurare la distribuzione continua per un'app Web Python in App Azure Container

Questo articolo fa parte di un'esercitazione su come inserire e distribuire un'app Web Python in App Contenitore di Azure. App contenitore consente di distribuire app in contenitori senza gestire un'infrastruttura complessa.

In questa parte dell'esercitazione si apprenderà come configurare la distribuzione continua o il recapito (CD) per l'app contenitore. Il CD fa parte della pratica DevOps dell'integrazione continua/recapito continuo (CI/CD), che è l'automazione del flusso di lavoro di sviluppo delle app. In particolare, si usa GitHub Actions per la distribuzione continua.

Questo diagramma dei servizi evidenzia i componenti trattati in questo articolo: configurazione di CI/CD.

Prerequisiti

Per configurare la distribuzione continua, è necessario:

• Le risorse e la relativa configurazione sono state create nell'articolo precedente di questa serie di esercitazioni, che include un Registro Azure Container e un'app contenitore in App Azure Container.

• Un account GitHub in cui è stato creato il fork del codice di esempio (Django o Flask) ed è possibile connettersi da App Azure Container. Se è stato scaricato il codice di esempio invece di creare una copia tramite fork, assicurarsi di eseguire il push del repository locale nell'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 il CD per un contenitore

In un articolo precedente di questa esercitazione è stata creata e configurata un'app contenitore in App Azure Container. Parte della configurazione ha eseguito il pull di un'immagine Docker da un Registro Azure Container. L'immagine del contenitore viene estratta dal Registro di sistema durante la creazione di una revisione del contenitore, 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. Il trigger in questa esercitazione è qualsiasi modifica al ramo principale del repository, ad esempio con una richiesta pull. Quando viene attivato, il flusso di lavoro crea una nuova immagine Docker, lo inserisce nella Registro Azure Container e aggiorna l'app contenitore a una nuova revisione usando la nuova immagine.

export MSYS_NO_PATHCONV=1

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

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

Nella configurazione della distribuzione continua viene usata un'entità servizio per consentire a GitHub Actions di accedere e modificare le risorse di Azure. L'accesso alle risorse è limitato dai ruoli assegnati all'entità servizio. All'entità servizio è stato assegnato il ruolo Collaboratore predefinito nel gruppo di risorse contenente l'app contenitore.

Se sono stati eseguiti i passaggi per il portale, l'entità servizio è stata creata automaticamente. Se sono stati eseguiti i passaggi per l'interfaccia della riga di comando di Azure, è stata creata in modo esplicito l'entità servizio 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 e si conferma che la modifica viene distribuita automaticamente nel sito Web.

Se non è già stato fatto, creare un 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.

git checkout main
git pull

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

Informazioni su GitHub Actions

Visualizzazione della cronologia del flusso di lavoro

gh workflow view

gh workflow view --web

Segreti del flusso di lavoro

Nel file del flusso di lavoro .github/workflows/<workflow-name>.yml aggiunto al repository verranno visualizzati i segnaposto per le credenziali necessarie per i processi di aggiornamento dell'app di compilazione e contenitore del flusso di lavoro. Le informazioni sulle credenziali vengono archiviate crittografate nel repository Impostazioni in Segreti di sicurezza/e variabili/Azioni.

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

App autorizzate OAuth

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

Suggerimenti per la risoluzione dei problemi

Errori durante la configurazione di un'entità servizio con il comando dell'interfaccia della riga di comando di Azure az ad sp create-for-rba .

• Viene visualizzato un errore contenente "InvalidSchema: non sono state trovate schede di connessione".

  • Controllare la shell in esecuzione. Se si usa la shell Bash, impostare le variabili di MSYS_NO_PATHCONV come indicato di seguito export MSYS_NO_PATHCONV=1. Per altre informazioni, vedere il problema di GitHub Non è possibile creare un'entità servizio con l'interfaccia della riga di comando di Azure dalla shell git bash, non sono state trovate schede di connessione.

• Viene visualizzato un errore contenente "Più di un'applicazione hanno lo stesso nome visualizzato".

  • Questo errore indica che il nome è già stato preso per l'entità servizio. Scegliere un altro nome o lasciare l'argomento --name e un GUID verrà 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, esaminare il file del flusso di lavoro. Devono essere presenti due processi "build" e "deploy". Per un processo non riuscito, esaminare l'output delle attività del processo per cercare i problemi.
• 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. Non è necessario modificare questo file per questa esercitazione. In caso affermativo, ripristinare le modifiche e provare il flusso di lavoro.

Il sito Web non mostra le modifiche unite 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.
• In portale di Azure: controllare il Registro Azure Container per verificare se è stata creata una nuova immagine Docker con un timestamp dopo la modifica al ramo.
• In portale di Azure: controllare i log dell'app contenitore. Se si verifica un errore di programmazione, verrà visualizzato qui.
  • Passare all'app contenitore | Gestione revisioni | <contenitore> attivo | Dettagli revisione | Log della console
  • Scegliere l'ordine delle colonne per visualizzare "Time Generated", "Stream_s" e "Log_s". Ordinare i log in base alla prima più recente e cercare i messaggi stderr e stdout Python nella colonna "Stream_s". L'output di Python 'print' sarà stdout messages.
• Con l'interfaccia della riga di comando di Azure usare il comando az containerapp logs show .

Cosa accade quando si disconnette la distribuzione continua?

• L'arresto della distribuzione continua significa disconnettere l'app contenitore dal repository. Per disconnettersi:

  • In portale di Azure passare all'app contenitore, selezionare la risorsa distribuzione continua, selezionare Disconnetti.
  • Con l'interfaccia della riga di comando di Azure usare il comando az container app github-action remove .

• Dopo la disconnessione, nel repository GitHub:

  • Il file .github/workflows/<workflow-name>.yml viene rimosso dal repository.
  • Le chiavi segrete non vengono rimosse.
  • App Contenitore di Azure rimane come app OAuth autorizzata per l'account GitHub.

• Dopo la disconnessione, in Azure:

  • Il contenitore viene lasciato con l'ultimo contenitore distribuito. È possibile riconnettere l'app contenitore con il Registro Azure Container, in modo che le nuove revisioni del contenitore rilevino l'immagine più recente.
  • Le entità servizio create e usate per la distribuzione continua non vengono eliminate.

Passaggi successivi

Se l'esercitazione è stata completata e non si vogliono sostenere costi aggiuntivi, rimuovere 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, vedere Pulizia dell'esercitazione Su contenitori.

Se si prevede di basare su questa esercitazione, ecco alcuni passaggi successivi che è possibile eseguire.

• 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 Azure Container