Condividi tramite

Esercitazione: Configurare la distribuzione continua per un'app web Python in Azure Container Apps

  • Articolo

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:

  • Configurare la distribuzione continua per un'applicazione container usando un GitHub Actions flusso di lavoro.
  • 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 della consegna continua (CI/CD), che automatizza il flusso di lavoro di sviluppo delle app.

Il diagramma seguente illustra le attività in questa esercitazione.

Diagramma dei servizi coinvolti nella distribuzione di un'app Python nelle app Azure Container, con le parti relative alla distribuzione continua evidenziate.

Prerequisiti

Per configurare la distribuzione continua, è necessario:

  • Le risorse (e la relativa configurazione) che hai creato nell'esercitazione precedente, che include un'istanza di Azure Container Registry e un'applicazione container in Azure Container Apps.

  • Un account GitHub in cui hai fatto un fork del codice di esempio (Django o Flask) al quale puoi connetterti da Azure Container Apps. Se hai scaricato il codice di esempio invece di fare 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 Azure Container Apps. Parte della configurazione consisteva nel recuperare un'immagine Docker da un'istanza di Azure Container Registry. 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. Il trigger in questa esercitazione è qualsiasi modifica apportata al ramo principale del repository, ad esempio con una richiesta pull. 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.

È possibile eseguire i comandi dell'interfaccia della riga di comando di Azure in Azure Cloud Shell o in una workstation in cui è installata l'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. Creare un principale del servizio utilizzando 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 :

    • <nome dell'app> è un nome visualizzato facoltativo per il principale del servizio. Se si omette l'opzione --name, viene generato un GUID come nome visualizzato.
    • <ID sottoscrizione> è il GUID che identifica in modo univoco la tua sottoscrizione in Azure. Se non conosci l'ID della sottoscrizione, puoi eseguire il comando az account show e copiarlo dalla proprietà id nell'output.
    • <nome gruppo di risorse> è il nome di un gruppo di risorse che contiene il contenitore di Azure Container Apps. 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 :

    • < > nome-gruppo di risorse è 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.
    • <nome registro> è l'istanza esistente di Azure Container Registry creata nell'esercitazione precedente o un'istanza che è possibile usare.
    • <id client> è il valore della proprietà appId del comando az ad sp create-for-rbac precedente. L'ID è un GUID del formato 00000000-0000-0000-0000-00000000.
    • < > id tenant è il valore della proprietà tenant del comando az ad sp create-for-rbac precedente. L'ID è anch'esso un GUID simile a un ID cliente.
    • <client-segreto> corrisponde al valore della proprietà password del comando az ad sp create-for-rbac precedente.

Nella configurazione della distribuzione continua, un principale del servizio consente a GitHub Actions di accedere e modificare le risorse di Azure. I ruoli assegnati all'entità di servizio limitano l'accesso alle risorse. Al principal del servizio è stato assegnato il ruolo di Collaboratore predefinito nel gruppo di risorse che contiene l'applicazione container.

Se hai seguito i passaggi per il portale, il service principal è stato creato 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. Successivamente, è possibile verificare che la modifica venga distribuita automaticamente nel sito Web.

Se non l'hai già fatto, fai 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.

  1. Vai al fork del repository di esempio e inizia nel branch principale .

    Screenshot che mostra il ramo principale in un fork del repository di esempio.

  2. Apportare una modifica:

    1. Passare al file /templates/base.html. (Per quanto riguarda 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.

    Screenshot che mostra come apportare una modifica in un file modello nel fork del repository di esempio.

  3. Nella parte inferiore della pagina che stai modificando, assicurarsi che sia selezionato Esegui commit direttamente nel ramo principale. Quindi selezionare il pulsante Applica modifiche.

    Screenshot che mostra le selezioni per completare una modifica in un file modello nel fork del repository di esempio.

Il commit avvia il flusso di lavoro di 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.

Informazioni su GitHub Actions

Visualizzazione della cronologia del flusso di lavoro

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

Su GitHub, vai al tuo fork del repository di esempio e apri la scheda Azioni.

Screenshot che mostra i flussi di lavoro nella scheda Azioni per un repository.

Segreti del flusso di lavoro

Il file del flusso di lavoro .github/workflows/<nome-del-flusso-di-lavoro>.yml aggiunto al repository include segnaposto per le credenziali necessarie per le attività di aggiornamento del flusso di lavoro, compresa la compilazione e l'aggiornamento dell'applicazione container. Le informazioni sulle credenziali vengono archiviate crittografate nell'area di Impostazioni del repository, in >segreti e variabili>Azioni.

Screenshot che mostra le credenziali salvate come segreti in GitHub Actions.

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

App autorizzate OAuth

Quando si configura la distribuzione continua, Azure Container Apps viene designato come app OAuth autorizzata per il tuo 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.

Screenshot che mostra la posizione delle app autorizzate per un utente in GitHub.

Risoluzione dei problemi

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

Questa sezione consente di risolvere gli errori che si verificano durante la configurazione di un'entità servizio usando l'istruzione az ad sp create-for-rba della CLI di Azure.

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

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

  • Il nome è già preso per l'entità servizio principale. Scegli un altro nome oppure elimina l'argomento --name. 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, aprire e esaminare il file del flusso di lavoro. Dovrebbero essere presenti due attività: compilazione e distribuzione. Per un lavoro non riuscito, controllare l'output delle attività del lavoro per individuare problemi.
  • Se è presente un messaggio di errore che contiene il timeout dell'handshake TLS, eseguire manualmente il flusso di lavoro. Nel repository, nella scheda Azioni, selezionare Attivare la 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 non mostra le modifiche che hai unito nel branch 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. Passare all'app contenitore e quindi passare a Gestione revisioni><contenitore attivo>>Dettagli revisione>log della console.
    2. Scegliere l'ordine delle colonne da visualizzare Ora generata, Stream_se Log_s.
    3. Ordinare i log in base alle versioni più recenti e cercare i messaggi di stderr Python e stdout nella colonna Stream_s. L'output di Python print consiste in stdout messaggi.

Nella CLI di Azure:

Si desidera interrompere la distribuzione continua

Interrompere la distribuzione continua significa disconnettere l'app container dal repository.

Nel portale di Azure:

  • Passare all'app contenitore. Nel menu del servizio, seleziona Distribuzione continuae quindi seleziona Disconnetti.

Nella CLI di Azure:

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.
  • Azure Container Apps 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 all'istanza di Azure Container Registry, in modo che le nuove revisioni dei contenitori utilizzino l'immagine più recente.
  • In Azure, i principali di servizio che hai creato e utilizzato 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, vedere 'esercitazione su Containerize cleanup.

Contenuto correlato

Se si prevede di eseguire questa esercitazione, ecco alcuni passaggi successivi che è possibile eseguire: