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.

Interfaccia della riga di comando di Azure

I comandi dell'interfaccia della riga di comando di Azure possono essere eseguiti in Azure Cloud Shell o in una workstation con l'interfaccia della riga di comando di Azure installata.

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

Passaggio 1: Creare un'entità servizio con 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>"

Dove:

• <app-name> è un nome visualizzato facoltativo per l'entità servizio. Se si lascia 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 sottoscrizione, è possibile eseguire il comando az account show e copiarlo dalla id proprietà nell'output.
• <resource-group-name> è il nome di un gruppo di risorse che contiene il contenitore App Azure Container. Il controllo degli accessi in base al ruolo è a livello di gruppo di risorse. Se sono stati seguiti i passaggi descritti nell'articolo precedente di questa esercitazione, il nome del gruppo di risorse è pythoncontainer-rg.

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

Passaggio 2. Configurare GitHub Actions con 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

Dove:

• <resource-group-name> è il nome del gruppo di risorse. Se si segue questa esercitazione, si tratta di "pythoncontainer-rg".
• <https://github.com/userid/repo> è l'URL del repository GitHub. Se si seguono i passaggi di questa esercitazione, sarà https://github.com/userid/msdocs-python-django-azure-container-apps o https://github.com/userid/msdocs-python-flask-azure-container-apps; dove userid è l'ID utente di GitHub.
• <registry-name> è il Registro Container esistente creato per questa esercitazione o uno 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 000000000-0000-0000-0000-000000000.
• <tenant-id> è il valore della tenant proprietà del comando precedente az ad sp create-for-rbac . L'ID è anche un GUID simile all'ID client.
• <client-secret> è il valore della password proprietà del comando precedente az ad sp create-for-rbac .

Azure portal

Passaggio 1: Nella portale di Azure passare all'app contenitore per cui si vuole configurare la distribuzione continua e selezionare la risorsa distribuzione continua.

Passaggio 2. Autorizzare App Azure Container ad accedere all'account GitHub.

• Selezionare Accedi con GitHub.
• Nella finestra popup di autorizzazione selezionare AuthorizeAppService.

L'accesso all'app contenitore al acconto GitHub può essere revocato passando alla sezione relativa alla sicurezza dell'account e revocando l'accesso.

Passaggio 3. Dopo l'accesso con GitHub, configurare i dettagli della distribuzione continua.

• Organizzazione → Usare il nome utente di GitHub.
• Repository → Selezionare il fork dell'app di esempio. Se il codice di esempio è stato originariamente scaricato nell'ambiente di sviluppo, eseguire il push del repository in GitHub.
• Ramo → Selezionare main.
• Origine repository → Selezionare Registro Azure Container.
• Registro di sistema → Selezionare il Registro Azure Container creato in precedenza nell'esercitazione.
• Immagine → Selezionare il nome dell'immagine Docker. Se si segue l'esercitazione, si tratta di "python-container-app".
• Entità servizio → Lasciare Crea nuovo e consentire al processo di creazione di creare una nuova entità servizio.

Selezionare Avvia distribuzione continua per completare la configurazione.

Passaggio 4. Esaminare le informazioni sulla distribuzione continua.

Dopo aver configurato la distribuzione continua, è possibile trovare un collegamento al file del flusso di lavoro GitHub Actions creato. App Azure Container ha controllato il file nel repository.

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.

GitHub

Passaggio 1: Passare al fork del repository di esempio e iniziare nel ramo principale .

Passaggio 2. Apportare una modifica.

• Passare al file /templates/base.html . Per Django, il percorso è restaurant_review /templates/restaurant_review/base.html.
• Selezionare Modifica e modificare la frase "Revisione ristorante di Azure" in "Revisione del ristorante di Azure - Ridistribuire".

Passaggio 3. Eseguire il commit della modifica direttamente nel ramo main .

• Nella parte inferiore della pagina che si modifica selezionare il pulsante Commit .
• Il commit avvia il flusso di lavoro di GitHub Actions.

Riga di comando

Se non è già stato fatto, usare git clone per eseguire il pull del repository copiato tramite fork nell'ambiente di sviluppo e passare alla directory nel repository.

Passaggio 1: Iniziare in main.

git checkout main
git pull

Passaggio 2. Apportare una modifica.

Passare al file ./templates/base.html (./restaurant_review/templates/restaruant_review/base.html per Django) e modificare la frase "Revisione ristorante di Azure" in "Revisione ristorante di Azure - Ridistribuita".

Passaggio 3. Eseguire il commit e il push delle modifiche 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 altre informazioni, vedere la Guida per git-config.

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

Nota

Abbiamo mostrato di 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 richiesta pull per unire tali modifiche in main. Le richieste pull avviano anche il flusso di lavoro.

Informazioni su GitHub Actions

Visualizzazione della cronologia del flusso di lavoro

GitHub

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

Riga di comando

Questi passaggi usano l'interfaccia della riga di comando di GitHub.

Passaggio 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 le istruzioni dell'interfaccia della riga di comando di GitHub per l'autenticazione.

Se sono configurati più di un remoto, potrebbe essere richiesto di eseguire gh repo set-default per selezionare un repository remoto predefinito. Selezionare la fork dalle opzioni presentate.

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

Passaggio 2. Passare a GitHub per informazioni dettagliate sull'esecuzione del flusso di lavoro.

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