Configurare un'app Python in Linux per il servizio app di Azure

  • Articolo

Questo articolo descrive come vengono eseguite le app Python nel servizio app di Azure, come eseguire la migrazione delle app esistenti ad Azure e come personalizzare il comportamento del servizio app quando è necessario. Le app Python devono essere distribuite con tutti i moduli pip richiesti.

Il motore di distribuzione servizio app attiva automaticamente un ambiente virtuale e viene eseguito pip install -r requirements.txt automaticamente quando si distribuisce un repository Git o un pacchetto ZIPcon l'automazione della compilazione abilitata.

Questa guida illustra i concetti chiave e le istruzioni per gli sviluppatori Python che usano un contenitore Linux predefinito nel servizio app. Se il servizio app di Azure non è mai stato usato, seguire per prima cosa la guida di avvio rapido su Python e l'esercitazione su Python con PostgreSQL.

Per la configurazione, è possibile usare il portale di Azure o l'interfaccia della riga di comando di Azure:

Nota

Linux è l'unica opzione del sistema operativo per l'esecuzione di app Python in servizio app. Python in Windows non è più supportato. È tuttavia possibile compilare un'immagine del contenitore Windows personalizzata ed eseguirla in servizio app. Per altre informazioni, vedere Usare un'immagine Docker personalizzata.

Configurare la versione di Python

  • Portale di Azure: usare la scheda Impostazioni generali nella pagina Configurazione, come descritto in Configurare le impostazioni generali per contenitori Linux.

  • Interfaccia della riga di comando di Azure:

    • visualizzare la versione corrente di Python con az webapp config show:

      az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

      Sostituire <resource-group-name> e <app-name> con i valori appropriati per l'app Web.

    • Impostare la versione di Python con az webapp config set

      az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "PYTHON|3.11"

    • Visualizzare tutte le versioni di Python supportate nel servizio app di Azure con az webapp list-runtimes:

      az webapp list-runtimes --os linux | grep PYTHON

È possibile eseguire una versione non supportata di Python creando un'immagine del contenitore personalizzata. Per altre informazioni, vedere Usare un'immagine Docker personalizzata.

Personalizzare l'automazione della compilazione

servizio app sistema di compilazione, denominato Oryx, esegue i passaggi seguenti quando si distribuisce l'app se l'impostazione SCM_DO_BUILD_DURING_DEPLOYMENT dell'app è impostata su 1:

  1. Esegue uno script di pre-compilazione personalizzato se specificato dall'impostazione PRE_BUILD_COMMAND. Lo script può eseguire altri script Python e Node.js, i comandi pip e npm e gli strumenti basati su node come yarn, yarn install ad esempio e yarn build.

  2. Eseguire pip install -r requirements.txt. Il file requirements.txt deve essere presente nella cartella radice del progetto. In caso contrario, il processo di compilazione segnala l'errore con un messaggio analogo al seguente: "Non è stato possibile trovare setup.py o requirements.txt; l'installazione di pip non verrà eseguita".

  3. Se nella radice del repository viene trovato manage.py (che indica un'app Django), esegue manage.py collectstatic. Tuttavia, se l'impostazione DISABLE_COLLECTSTATIC è true, questo passaggio viene ignorato.

  4. Esegue uno script di post-compilazione personalizzato se specificato dall'impostazione POST_BUILD_COMMAND. Anche in questo caso, lo script può eseguire altri script Python e Node.js, i comandi pip e npm e gli strumenti basati su Node.

Per impostazione predefinita, le impostazioni PRE_BUILD_COMMAND, POST_BUILD_COMMAND e DISABLE_COLLECTSTATIC sono vuote.

  • Per disabilitare l'esecuzione di collectstatic durante la compilazione di app Django, impostare l'impostazione DISABLE_COLLECTSTATIC su true.

  • Per eseguire i comandi di pre-compilazione, impostare PRE_BUILD_COMMAND in modo che contenga un comando, come echo Pre-build command, o il percorso di un file script relativo alla radice del progetto, ad esempio scripts/prebuild.sh. Tutti i comandi devono usare percorsi relativi alla cartella radice del progetto.

  • Per eseguire i comandi di post-compilazione, impostare POST_BUILD_COMMAND in modo che contenga un comando, come echo Post-build command, o il percorso di un file di script relativo alla radice del progetto, ad esempio scripts/postbuild.sh. Tutti i comandi devono usare percorsi relativi alla cartella radice del progetto.

Per altre impostazioni che personalizzano l'automazione della compilazione, vedere Configurazione di Oryx.

Per accedere ai log di compilazione e distribuzione, vedere Accedere ai log di distribuzione.

Per altre informazioni sull'esecuzione del servizio app e sulla compilazione di app Python in Linux, vedere come vengono rilevate e compilate le app Python in Oryx.

Nota

Le impostazioni PRE_BUILD_SCRIPT_PATH e POST_BUILD_SCRIPT_PATH sono identiche a PRE_BUILD_COMMAND e POST_BUILD_COMMAND e sono supportate per motivi di compatibilità legacy.

Un'impostazione denominata SCM_DO_BUILD_DURING_DEPLOYMENT, se contiene true o 1, attiva una compilazione Oryx durante la distribuzione. L'impostazione è true quando si esegue la distribuzione usando git, il comando az webapp up dell'interfaccia della riga di comando di Azure e Visual Studio Code.

Nota

Usare sempre percorsi relativi negli script di pre- e post-compilazione, perché il contenitore di compilazione in cui viene eseguito Oryx è diverso dal contenitore di runtime in cui viene eseguita l'app. Non fare mai affidamento sul posizionamento esatto della cartella di progetto dell'app all'interno del contenitore, ad esempio che si trova in site/wwwroot.

Eseguire la migrazione delle applicazioni esistenti ad Azure

Le applicazione Web esistenti possono essere ridistribuite in Azure come indicato di seguito:

  1. Repository di origine: mantenere il codice sorgente in un repository adatto, come GitHub, per configurare la distribuzione continua più avanti nel processo.

    • Il file requirements.txt deve trovarsi alla radice del repository affinché il servizio app installi automaticamente i pacchetti necessari.

  2. Database: se l'app dipende da un database, creare anche le risorse necessarie in Azure.

  3. Risorse del servizio app: creare un gruppo di risorse, un piano di servizio app e un app Web del servizio app in cui ospitare l'applicazione. A tale scopo, è possibile eseguire facilmente il comando dell'interfaccia della riga di comando az webapp updi Azure. In alternativa, è possibile creare e distribuire risorse come illustrato in Esercitazione: Distribuire un'app Web Python (Django o Flask) con PostgreSQL. Sostituire i nomi del gruppo di risorse, del piano di servizio app e dell'app Web in base ai requisiti dell'applicazione.

  4. Environment variables (Variabili di ambiente): se l'applicazione richiede variabili di ambiente, creare impostazione applicazione equivalenti del servizio app. Queste impostazioni del servizio app vengono visualizzate nel codice come variabili di ambiente, come descritto in Accedere alle variabili di ambiente.

  5. Avvio dell'app: per informazioni sul modo in cui il servizio app prova a eseguire l'app, vedere la sezione Processo di avvio del contenitore più avanti in questo articolo. Il servizio app usa il server Web Gunicorn per impostazione predefinita, che deve essere in grado di trovare l'oggetto app o la cartella wsgi.py. Se necessario, è possibile personalizzare il comando di avvio.

  6. Distribuzione continua: configurare la distribuzione continua da GitHub Actions, Bitbucket o Azure Repos come descritto nell'articolo Distribuzione continua in Servizio app di Azure. In alternativa, configurare la distribuzione continua da Git locale come descritto nell'articolo Distribuzione Git locale per Servizio app di Azure.

  7. Azioni personalizzate: per eseguire azioni all'interno del contenitore del servizio app che ospita l'app, ad esempio migrazioni di database Django, è possibile connettersi al contenitore tramite SSH. Per un esempio di esecuzione di migrazioni di database Django, vedere Esercitazione: Distribuire un'app Web Django con PostgreSQL - Generare lo schema del database.

Una volta completati questi passaggi, sarà possibile eseguire il commit delle modifiche nel repository di origine e distribuire automaticamente tali aggiornamenti nel servizio app.

Impostazioni di produzione per le app Django

Per un ambiente di produzione come il servizio app di Azure, le app Django devono seguire l'elenco di controllo della distribuzione di Django (djangoproject.com).

La tabella seguente descrive le impostazioni di produzione pertinenti per Azure. Queste impostazioni sono definite nel file setting.py dell'app.

Impostazione di Django Istruzioni per Azure
SECRET_KEY Archiviare il valore in un'impostazione del servizio app, come descritto in Accedere alle impostazioni dell'app come variabili di ambiente. In alternativa, è possibile archiviare il valore come "segreto" in Azure Key Vault.
DEBUG Creare un'impostazione DEBUG nel servizio app con il valore 0 (false), quindi caricare il valore come variabile di ambiente. Nell'ambiente di sviluppo creare una variabile di ambiente DEBUG con il valore 1 (true).
ALLOWED_HOSTS In produzione, Django richiede di includere l'URL dell'app nella matrice ALLOWED_HOSTS di settings-py. È possibile recuperare questo URL in fase di esecuzione con il codice os.environ['WEBSITE_HOSTNAME']. Il servizio app imposta automaticamente la variabile di ambiente WEBSITE_HOSTNAME sull'URL dell'app.
DATABASES Definire le impostazioni nel servizio app per la connessione al database e caricarle come variabili di ambiente per popolare il dizionario DATABASES. In alternativa, è possibile archiviare i valori, in particolare il nome utente e la password, come segreti di Azure Key Vault.

Gestire file statici per le app Django

Se l'app Web Django include file front-end statici, seguire prima di tutto le istruzioni riportate in Gestione dei file statici nella documentazione di Django.

Per servizio app, apportare le modifiche seguenti:

  1. È consigliabile usare le variabili di ambiente (per lo sviluppo locale) e le impostazioni dell'app (durante la distribuzione nel cloud) per impostare dinamicamente django STATIC_URL e STATIC_ROOT variabili. Ad esempio:

    STATIC_URL = os.environ.get("DJANGO_STATIC_URL", "/static/")
STATIC_ROOT = os.environ.get("DJANGO_STATIC_ROOT", "./static/")

    DJANGO_STATIC_URL e DJANGO_STATIC_ROOT possono essere modificati in base alle esigenze per gli ambienti locali e cloud. Ad esempio, se il processo di compilazione per i file statici li inserisce in una cartella denominata django-static, è possibile impostare DJANGO_STATIC_URL su /django-static/ per evitare di usare l'impostazione predefinita.

  2. Se si dispone di uno script di pre-compilazione che genera file statici in una cartella diversa, includere tale cartella nella variabile Django in modo che il processo di collectstatic Django STATICFILES_DIRS li trovi. Ad esempio, se si esegue yarn build nella cartella front-end e yarn genera una build/static cartella contenente file statici, quindi includere tale cartella come indicato di seguito:

    FRONTEND_DIR = "path-to-frontend-folder" 
STATICFILES_DIRS = [os.path.join(FRONTEND_DIR, 'build', 'static')]

    In questo caso, FRONTEND_DIRper compilare un percorso in cui viene eseguito uno strumento di compilazione come yarn. È anche possibile usare una variabile di ambiente e l'impostazione dell'app come desiderato.

  3. Aggiungere whitenoise al file requirements.txt . Whitenoise (whitenoise.evans.io) è un pacchetto Python che semplifica la gestione dei propri file statici da parte di un'app Django di produzione. Whitenoise gestisce in modo specifico i file presenti nella cartella specificata dalla variabile Django STATIC_ROOT .

  4. Nel file settings.py aggiungere la riga seguente per Whitenoise:

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. Modificare anche gli MIDDLEWARE elenchi e INSTALLED_APPS in modo da includere Whitenoise:

    MIDDLEWARE = [                                                                   
    'django.middleware.security.SecurityMiddleware',
    # Add whitenoise middleware after the security middleware                             
    'whitenoise.middleware.WhiteNoiseMiddleware',
    # Other values follow
]

INSTALLED_APPS = [
    "whitenoise.runserver_nostatic",
    # Other values follow
]

Gestire file statici per le app Flask

Se l'app Web Flask include file front-end statici, seguire prima di tutto le istruzioni per la gestione dei file statici nella documentazione di Flask. Per un esempio di gestione di file statici in un'applicazione Flask, vedere l'applicazione Flask di esempio di avvio rapido in GitHub.

Per gestire i file statici direttamente da una route nell'applicazione, è possibile usare il send_from_directory metodo :

from flask import send_from_directory

@app.route('/reports/<path:path>')
def send_report(path):
    return send_from_directory('reports', path)

Caratteristiche del contenitore

Quando vengono distribuite nel servizio app, le app Python vengono eseguite in un contenitore Docker Linux definito nel repository GitHub di Python per il servizio app. È possibile trovare le configurazioni delle immagini all'interno delle directory specifiche della versione.

Questo contenitore presenta le caratteristiche seguenti:

  • Le app vengono eseguite usando il server HTTP Gunicorn WSGI, usando gli argomenti aggiuntivi --bind=0.0.0.0 --timeout 600.

    • È possibile specificare le impostazioni di configurazione per Gunicorn personalizzando il comando di avvio.

    • Per proteggere l'app Web da attacchi DDOS accidentali o intenzionali, Gunicorn viene eseguito dietro un proxy inverso Nginx, come descritto nell'articolo sulla distribuzione di Gunicorn (docs.gunicorn.org).

  • Per impostazione predefinita, l'immagine di base del contenitore include solo il framework Web Flask, ma il contenitore supporta altri framework conformi a WSGI e compatibili con Python 3.6 e versioni successive, come ad esempio Django.

  • Per installare altri pacchetti, ad esempio Django, creare un file requirements.txt nella radice del progetto che specifica le dipendenze dirette. Il servizio app quindi installa automaticamente queste dipendenze quando si distribuisce il progetto.

    Per l'installazione delle dipendenze, il file requirements.txtdeve essere presente nella radice del progetto. In caso contrario, il processo di compilazione segnala l'errore: "Impossibile trovare setup.py o requirements.txt; Non è in esecuzione l'installazione pip." Se si verifica questo errore, controllare il percorso del file dei requisiti.

  • Il servizio app definisce automaticamente una variabile di ambiente denominata WEBSITE_HOSTNAME con l'URL dell'app Web, ad esempio msdocs-hello-world.azurewebsites.net. Definisce anche WEBSITE_SITE_NAME con il nome dell'app, ad esempio msdocs-hello-world.

  • npm e Node.js vengono installati nel contenitore in modo da poter eseguire strumenti di compilazione basati su nodi, ad esempio yarn.

Processo di avvio del contenitore

Durante l'avvio il servizio app in un contenitore Linux esegue i passaggi seguenti:

  1. Usa un comando di avvio personalizzato, se specificato.
  2. Verifica l'esistenza di un'app Django e avvia Gunicorn, se rilevato.
  3. Verifica l'esistenza di un'app Flask e avvia Gunicorn, se rilevato.
  4. Se non vengono trovate altre app, avvia un'app predefinita integrata nel contenitore.

Le sezioni seguenti forniscono dettagli aggiuntivi per ogni opzione.

App Django

Per le app Django il servizio app cerca un file denominato wsgi.py all'interno del codice dell'app e quindi esegue Gunicorn usando il comando seguente:

# <module> is the name of the folder that contains wsgi.py
gunicorn --bind=0.0.0.0 --timeout 600 <module>.wsgi

Se si vuole un controllo più specifico sul comando di avvio, usare un comando di avvio personalizzato, sostituire <module> con il nome della cartella che contiene wsgi.py e aggiungere un --chdir argomento se tale modulo non si trova nella radice del progetto. Ad esempio, se il file wsgi.py si trova in knboard/backend/config rispetto alla radice del progetto, usare gli argomenti --chdir knboard/backend config.wsgi.

Per abilitare la registrazione di produzione, aggiungere i parametri --access-logfile e --error-logfile, come illustrato negli esempi per i comandi di avvio personalizzati.

App Flask

Per Flask il servizio app cerca un file denominato application.py o app.py e avvia Gunicorn come segue:

# If application.py
gunicorn --bind=0.0.0.0 --timeout 600 application:app

# If app.py
gunicorn --bind=0.0.0.0 --timeout 600 app:app

Se il modulo principale dell'app è contenuto in un file diverso, usa un nome diverso per l'oggetto app o vuoi fornire altri argomenti a Gunicorn, usa un comando di avvio personalizzato.

Comportamento predefinito

Se il servizio app non trova un comando personalizzato, un'app Django o un'app Flask, verrà eseguita un'app predefinita di sola lettura che si trova nella cartella opt/defaultsite, come illustrato nell'immagine seguente.

Se il codice è stato distribuito e viene ancora visualizzata l'app predefinita, vedere Risoluzione dei problemi: l'app non viene visualizzata.

Screenshot della pagina Web Servizio app in Linux predefinita.

Anche in questo caso, se ci si aspetta di vedere un'app distribuita invece di quella predefinita, vedere Risoluzione dei problemi: l'app non viene visualizzata.

Personalizzare un comando di avvio

È possibile controllare il comportamento di avvio del contenitore fornendo un comando di avvio personalizzato o più comandi in un file di comando di avvio. Per un file di comandi di avvio è possibile usare qualsiasi nome, ad esempio startup.sh, startup.cmd, startup.txt e così via.

Tutti i comandi devono usare percorsi relativi alla cartella radice del progetto.

Per specificare un comando di avvio o un file di comandi:

  • Portale di Azure: selezionare la pagina Configurazione dell'app, quindi selezionare Impostazioni generali. Nel campo Comando di avvio inserire il testo completo del comando di avvio o il nome del file di comandi di avvio. Quindi selezionare Salva per applicare le modifiche. Vedere Configurare le impostazioni generali per i contenitori Linux.

  • Interfaccia della riga di comando di Azure: usare il comando az webapp config set con il parametro --startup-file per impostare il comando di avvio o il file:

    az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<custom-command>"

    Sostituire <custom-command> con il testo completo del comando di avvio o con il nome del file di comandi di avvio.

Il servizio app ignora gli eventuali errori che possono verificarsi durante l'elaborazione di un comando di avvio o di un file, quindi continua il processo di avvio cercando le app Django e Flask. Se non viene visualizzato il comportamento previsto, verificare che il comando o il file di avvio sia privo di errori e che un file di comando di avvio venga distribuito in servizio app insieme al codice dell'app. È anche possibile controllare i log di diagnostica per altre informazioni. Controllare anche la pagina Diagnostica e risoluzione dei problemi nel portale di Azure.

Comandi di avvio di esempio

  • Argomenti Gunicorn aggiunti: l'esempio seguente aggiunge --workers=4 a una riga di comando di Gunicorn per l'avvio di un'app Django:

    # <module-path> is the relative path to the folder that contains the module
# that contains wsgi.py; <module> is the name of the folder containing wsgi.py.
gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi

    Per altre informazioni, vedere l'articolo relativo all'esecuzione di Gunicorn (docs.gunicorn.org). Se si usano regole di scalabilità automatica per aumentare e ridurre le prestazioni dell'app Web, è anche consigliabile impostare in modo dinamico il numero di lavoratori gunicorn usando la NUM_CORES variabile di ambiente nel comando di avvio, ad esempio: --workers $((($NUM_CORES*2)+1)). Per altre informazioni sull'impostazione del numero consigliato di lavoratori gunicorn, vedere le domande frequenti su Gunicorn

  • Abilitare la registrazione di produzione per Django: aggiungere gli argomenti --access-logfile '-' e --error-logfile '-' alla riga di comando:

    # '-' for the log files means stdout for --access-logfile and stderr for --error-logfile.
gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi --access-logfile '-' --error-logfile '-'

    Questi log verranno visualizzati nel flusso di registrazione del servizio app.

    Per altre informazioni, vedere l'articolo relativo alla registrazione di Gunicorn (docs.gunicorn.org).

  • Modulo principale Flask personalizzato: per impostazione predefinita, servizio app presuppone che il modulo principale di un'app Flask sia application.py o app.py. Se il modulo principale usa un nome diverso, è necessario personalizzare il comando di avvio. Ad esempio, se si ha un'app Flask il cui modulo principale è hello.py e l'oggetto app Flask in tale file è denominato myapp, il comando sarà come segue:

    gunicorn --bind=0.0.0.0 --timeout 600 hello:myapp

    Se il modulo principale è contenuto in una sottocartella, ad esempio website, specificare tale cartella con l'argomento --chdir:

    gunicorn --bind=0.0.0.0 --timeout 600 --chdir website hello:myapp

  • Usare un server non Gunicorn: per usare un server Web diverso, ad esempioaiohttp, usare il comando appropriato come comando di avvio o nel file di comandi di avvio:

    python3.7 -m aiohttp.web -H localhost -P 8080 package.module:init_func

Accedere alle impostazioni dell'app come variabili di ambiente

Le impostazioni dell'app sono valori specificamente archiviati nel cloud, come descritto in Configurare le impostazioni dell'app. Queste impostazioni sono disponibili per il codice dell'app come variabili di ambiente e sono accessibili tramite il modello os.environ standard.

Se ad esempio è stata creata un'impostazione dell'app denominata DATABASE_SERVER, il codice seguente recupera il relativo valore:

db_server = os.environ['DATABASE_SERVER']

Rilevare una sessione HTTPS

In servizio app, la terminazione TLS/SSL (wikipedia.org) avviene nei servizi di bilanciamento del carico di rete, in modo che tutte le richieste HTTPS raggiungano l'app come richieste HTTP non crittografate. Se la logica dell'app deve controllare se le richieste degli utenti sono crittografate o meno, esaminare l'intestazione X-Forwarded-Proto.

if 'X-Forwarded-Proto' in request.headers and request.headers['X-Forwarded-Proto'] == 'https':
# Do something when HTTPS is used

I framework Web più diffusi consentono di accedere alle informazioni X-Forwarded-* nel modello di app standard. Ad esempio in Django, è possibile usare il SECURE_PROXY_SSL_HEADER per indicare a Django di usare l'intestazione X-Forwarded-Proto .

Accedere ai log di diagnostica

È possibile accedere ai log della console generati dall'interno del contenitore.

Prima di tutto attivare la registrazione del contenitore eseguendo questo comando:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Sostituire <app-name> e <resource-group-name> con i valori appropriati per l'app Web.

Dopo che la registrazione del contenitore è attivata, eseguire il comando seguente per visualizzare il flusso di registrazione:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Se i log di console non sono immediatamente visibili, controllare nuovamente dopo 30 secondi.

Per interrompere lo streaming dei log in qualsiasi momento, premere CTRL+C.

È anche possibile ispezionare i file di log in un browser all'indirizzo https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Per accedere ai log tramite il portale di Azure, selezionare Monitoraggio>Flusso di registrazione nel menu sinistro dell'app.

Accedere ai log di distribuzione

Quando si distribuisce il codice, il servizio app esegue il processo di compilazione descritto in precedenza nella sezione Personalizzare l'automazione della compilazione. Poiché la compilazione viene eseguita nel proprio contenitore, i log di compilazione vengono archiviati separatamente dai log di diagnostica dell'app.

Usare la procedura seguente per accedere ai log di distribuzione:

  1. Nel portale di Azure per l'app Web selezionare Centro distribuzione> nel menu a sinistra.
  2. Nella scheda Log selezionare il valore di ID commit relativo al commit più recente.
  3. Nella pagina Dettagli log visualizzata selezionare il collegamento Mostra log visualizzato accanto al messaggio che indica che è in corso l'esecuzione della build oryx.

In questi log verranno visualizzati i problemi di compilazione, ad esempio dipendenze non corrette nel file requirements.txt, ed errori negli script di pre- o post-compilazione. Gli errori vengono visualizzati anche se il file dei requisiti non è esattamente denominato requirements.txt o non viene visualizzato nella cartella radice del progetto.

Aprire una sessione SSH nel browser

Per aprire una sessione SSH diretta con il contenitore, l'app deve essere in esecuzione.

Incollare l'URL seguente nel browser e sostituire <app-name> con il nome dell'app:

https://<app-name>.scm.azurewebsites.net/webssh/host

Se non lo si è già fatto, per connettersi è necessario eseguire l'autenticazione con la sottoscrizione di Azure. Al termine dell'autenticazione viene visualizzata una shell nel browser, in cui è possibile eseguire i comandi all'interno del contenitore.

Connessione SSH

Nota

Le eventuali modifiche apportate all'esterno della directory /home vengono archiviate nel contenitore stesso e non persistono oltre il riavvio dell'app.

Per aprire una sessione SSH remota dal computer locale, vedere Aprire una sessione SSH dalla shell remota.

Una volta stabilita una connessione con la sessione SSH, nella parte inferiore della finestra verrà visualizzato un messaggio analogo a "Connessione SSH stabilita". Se vengono visualizzati errori come "SSH_CONNECTION_CLOSED" o un messaggio che indica che il contenitore verrà riavviato, è possibile che un errore impedisca l'avvio del contenitore dell'app. Per analizzare i possibili problemi, vedere Risoluzione dei problemi.

Risoluzione dei problemi

In generale, il primo passaggio nella risoluzione dei problemi consiste nell'usare la diagnostica del servizio app:

  1. Nella portale di Azure per l'app Web selezionare Diagnosticare e risolvere i problemi dal menu a sinistra.
  2. Selezionare Disponibilità e prestazioni.
  3. Esaminare le informazioni nelle opzioni Log applicazioni, Arresto anomalo del contenitore e Problemi del contenitore , in cui verranno visualizzati i problemi più comuni.

Esaminare quindi i log di distribuzione e i log dell'app per individuare eventuali messaggi di errore. Questi log identificano spesso problemi specifici che possono impedire la distribuzione o l'avvio dell'app. La compilazione può ad esempio non riuscire se il file requirements.txt ha un nome errato o non è presente nella cartella radice del progetto.

Le sezioni seguenti forniscono indicazioni per problemi specifici.

L'app non viene visualizzata

  • Dopo avere distribuito il codice app personalizzato viene visualizzata l'app predefinita. L'app predefinita viene visualizzata perché il codice dell'app personalizzata non è stato distribuito nel servizio app o perché il servizio app non ha trovato il codice dell'app personalizzata e ha quindi eseguito l'app predefinita.

    • Riavviare il servizio app, attendere 15-20 secondi e verifica di nuovo l'app.

    • Usare SSH per connettersi direttamente al contenitore del servizio app e verificare che i file siano presenti in site/wwwroot. Se i file non esistono, seguire questa procedura:

      1. Creare un'impostazione dell'app denominata SCM_DO_BUILD_DURING_DEPLOYMENT con il valore 1, ridistribuire il codice, attendere alcuni minuti, quindi provare di nuovo ad accedere all'app. Per altre informazioni sulla creazione di impostazioni dell'app, vedere Configurare un'app del servizio app nel portale di Azure.
      2. Esaminare il processo di distribuzione, controllare i log di distribuzione, correggere eventuali errori e ridistribuire l'app.

    • Se i file sono presenti, il servizio app non è riuscito a identificare il file di avvio specifico. Verificare che l'app sia strutturata come prevista dal servizio app per Django o Flask oppure usare un comando di avvio personalizzato.

  • Nel browser viene visualizzato il messaggio "Servizio non disponibile". Il browser ha timeout in attesa di una risposta da servizio app, che indica che servizio app avviato il server Gunicorn, ma l'app stessa non è stata avviata. Questa condizione può indicare che gli argomenti di Gunicorn non sono corretti o che si è verificato un errore nel codice dell'app.

    • Aggiornare il browser, in particolare se si usano i piani tariffari inferiori nel piano di servizio app. Ad esempio, l'avvio dell'app potrebbe richiedere più tempo quando si usano i livelli gratuiti e l'app potrebbe rispondere dopo l'aggiornamento del browser.

    • Verificare che l'app sia strutturata come prevista dal servizio app per Django o Flask oppure usare un comando di avvio personalizzato.

    • Esaminare il flusso dei log dell'app per individuare eventuali messaggi di errore. I log visualizzano tutti gli errori del codice dell'app.

Non è stato possibile trovare setup.py o requirements.txt

  • Il flusso di registrazione visualizza un messaggio analogo a "Non è stato possibile trovare setup.py o requirements.txt; l'installazione di pip non verrà eseguita". : il processo di compilazione Oryx non è riuscito a trovare il file requirements.txt.

    • Connettersi al contenitore dell'app Web tramite SSH e verificare che il file requirements.txt abbia il nome corretto e si trovi direttamente in site/wwwroot. Se non è presente, assicurarsi che esista nel repository e che venga incluso nella distribuzione. Se è disponibile in una cartella separata, spostarlo nella radice.

ModuleNotFoundError all'avvio dell'app

Se viene visualizzato un errore simile ModuleNotFoundError: No module named 'example'a , Python non è riuscito a trovare uno o più moduli all'avvio dell'applicazione. Questo errore si verifica più spesso se si distribuisce l'ambiente virtuale con il codice. Gli ambienti virtuali non sono portabili, quindi un ambiente virtuale non deve essere distribuito con il codice dell'applicazione. Lasciare invece che Oryx crei un ambiente virtuale e installi i pacchetti nell'app Web creando un'impostazione dell'app, SCM_DO_BUILD_DURING_DEPLOYMENTe impostandola su 1. Questa impostazione forza Oryx a installare i pacchetti ogni volta che si distribuisce in servizio app. Per altre informazioni, vedere questo articolo sulla portabilità dell'ambiente virtuale.

Il database è bloccato

Quando si tenta di eseguire migrazioni di database con un'app Django, è possibile che venga visualizzato "sqlite3. OperationalError: il database è bloccato." L'errore indica che l'applicazione usa un database SQLite per cui Django è configurato per impostazione predefinita anziché usare un database cloud, ad esempio PostgreSQL per Azure.

Controllare la DATABASES variabile nel file di settings.py dell'app per assicurarsi che l'app usi un database cloud anziché SQLite.

Se si verifica questo errore con l'esempio in Esercitazione: Distribuire un'app Web Django con PostgreSQL, verificare di aver completato la procedura descritta in Verifica delle impostazioni di connessione.

Altri problemi

  • Le password non vengono visualizzate nella sessione SSH quando vengono digitate: per motivi di sicurezza, la sessione SSH mantiene nascosta la password quando si digita. Tuttavia, i caratteri vengono registrati, quindi digitare la password come di consueto e premere INVIO al termine.

  • I comandi visualizzati nella sessione SSH sono troncati: l'editor potrebbe non supportare il ritorno a capo del testo dei comandi, che tuttavia dovrebbero essere eseguiti correttamente.

  • Gli asset statici non vengono visualizzati in un'app Django: assicurarsi di aver abilitato il modulo whitenoise

  • Viene visualizzato il messaggio "Errore irreversibile: è necessaria una connessione SSL" : controllare i nomi utente e le password usati per accedere alle risorse, ad esempio i database, dall'interno dell'app.

Altre risorse