Configurare un contenitore personalizzato per il Servizio app di Azure

  • Articolo
  • 19 minuti per la lettura

Questo articolo illustra come configurare un contenitore personalizzato per l'esecuzione in Servizio app di Azure.

Questa guida fornisce i concetti chiave e le istruzioni per la containerizzazione delle app di Windows in servizio app. Se non è mai stato usato Servizio app di Azure, seguire prima l'avvio rapido del contenitore personalizzato e l'esercitazione.

Questa guida fornisce i concetti chiave e le istruzioni per la containerizzazione delle app Linux in servizio app. Se non è mai stato usato Servizio app di Azure, seguire prima l'avvio rapido del contenitore personalizzato e l'esercitazione. È disponibile anche una guida introduttiva e un'esercitazione per app multi-contenitore.

Immagini padre supportate

Per l'immagine di Windows personalizzata, è necessario scegliere l'immagine padre corretta (immagine di base) per il framework desiderato:

Il download di un'immagine padre durante l'avvio dell'app richiede tempo. È tuttavia possibile ridurre i tempi di avvio usando una delle immagini padre seguenti, già memorizzate nella cache nel servizio app di Azure.

Modificare l'immagine Docker di un contenitore personalizzato

Per modificare un contenitore personalizzato esistente dall'immagine Docker corrente a una nuova immagine, usare il comando seguente:

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <docker-hub-repo>/<image>

Usare un'immagine da un registro privato

Per usare un'immagine da un registro privato, ad esempio Registro Azure Container, eseguire il comando seguente:

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <image-name> --docker-registry-server-url <private-repo-url> --docker-registry-server-user <username> --docker-registry-server-password <password>

Per <nome utente> e <password>, specificare le credenziali di accesso per l'account del Registro di sistema privato.

Usare l'identità gestita per eseguire il pull dell'immagine da Registro Azure Container

Usare la procedura seguente per configurare l'app Web per eseguire il pull da Registro Azure Container usando l'identità gestita. I passaggi useranno l'identità gestita assegnata dal sistema, ma è anche possibile usare l'identità gestita assegnata dall'utente.

  1. Abilitare l'identità gestita assegnata dal sistema per l'app Web usando il az webapp identity assign comando :

    az webapp identity assign --resource-group <group-name> --name <app-name> --query principalId --output tsv

    Sostituire <app-name> con il nome usato nel passaggio precedente. L'output del comando (filtrato in base agli argomenti --query e --output) è l'ID dell'entità servizio dell'identità assegnata, che viene usata a breve.

  2. Ottenere l'ID risorsa del Registro Azure Container:

    az acr show --resource-group <group-name> --name <registry-name> --query id --output tsv

    Sostituire <registry-name> con il nome del registro. L'output del comando (filtrato in base agli argomenti --query e --output) è l'ID risorsa del Registro Azure Container.

  3. Concedere all'identità gestita l'autorizzazione per accedere al registro contenitori:

    az role assignment create --assignee <principal-id> --scope <registry-resource-id> --role "AcrPull"

    Sostituire i valori seguenti:

    • <principal-id> con l'ID dell'entità servizio del comando az webapp identity assign
    • <registry-resource-id> con l'ID del registro contenitori dal az acr show comando

    Per altre informazioni su queste autorizzazioni, vedere Informazioni sul controllo degli accessi in base al ruolo di Azure.

  4. Configurare l'app per usare l'identità gestita da cui eseguire il pull da Registro Azure Container.

    az webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUseManagedIdentityCreds": true}'

    Sostituire i valori seguenti:

    • <app-name> con il nome dell'app Web.

    Suggerimento

    Se si usa la console di PowerShell per eseguire i comandi, sarà necessario eseguire l'escape delle stringhe nell'argomento --generic-configurations in questo e nel passaggio successivo. ad esempio --generic-configurations '{\"acrUseManagedIdentityCreds\": true'

  5. (Facoltativo) Se l'app usa un'identità gestita assegnata dall'utente, assicurarsi che sia configurata nell'app Web e quindi impostare una proprietà aggiuntiva acrUserManagedIdentityID per specificare l'ID client:

    az identity show --resource-group <group-name> --name <identity-name> --query clientId --output tsv

    Sostituire l'oggetto <identity-name> dell'identità gestita assegnata dall'utente e usare l'output <client-id> per configurare l'ID identità gestita assegnata dall'utente.

    az  webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUserManagedIdentityID": "<client-id>"}'

L'app Web userà ora l'identità gestita per eseguire il pull da Registro Azure Container.

Usare un'immagine da un registro protetto da rete

Per connettersi ed eseguire il pull da un registro all'interno di una rete virtuale o in locale, l'app dovrà essere connessa a una rete virtuale usando la funzionalità di integrazione della rete virtuale. Questa operazione è necessaria anche per Registro Azure Container con endpoint privato. Quando la rete e la risoluzione DNS sono configurate, è possibile abilitare il routing dell'immagine tramite pull attraverso la rete virtuale configurando l'impostazione del vnetImagePullEnabled sito:

az resource update --resource-group <group-name> --name <app-name> --resource-type "Microsoft.Web/sites" --set properties.vnetImagePullEnabled [true|false]

Il contenitore aggiornato non viene visualizzato

Se si modificano le impostazioni del contenitore Docker in modo che punti a un nuovo contenitore, potrebbero essere necessari alcuni minuti prima che l'app gestisca le richieste HTTP dal nuovo contenitore. Durante il pull e l'avvio del nuovo contenitore, servizio app continua a gestire le richieste dal contenitore precedente. Solo quando il nuovo contenitore viene avviato e pronto per ricevere le richieste servizio app avviare l'invio di richieste.

Modalità di archiviazione delle immagini del contenitore

La prima volta che si esegue un'immagine Docker personalizzata in servizio app, servizio app esegue il docker pull pull di tutti i livelli di immagine. Questi livelli vengono archiviati su disco, ad esempio se si usaVa Docker in locale. Ogni volta che l'app viene riavviata, servizio app esegue un'operazione docker pull, ma esegue solo il pull dei livelli modificati. Se non sono state apportate modifiche, servizio app usa livelli esistenti sul disco locale.

Se l'app modifica le istanze di calcolo per qualsiasi motivo, ad esempio aumentare e ridurre i piani tariffari, servizio app deve eseguire di nuovo il pull di tutti i livelli. Lo stesso vale se si aumenta il numero di istanze per aggiungere altre istanze. Esistono anche rari casi in cui le istanze dell'app possono cambiare senza un'operazione di scalabilità.

Configurare il numero di porta

Per impostazione predefinita, servizio app presuppone che il contenitore personalizzato sia in ascolto sulla porta 80 o sulla porta 8080. Se il contenitore è in ascolto di una porta diversa, impostare l'impostazione dell'app WEBSITES_PORT nell'app servizio app. È possibile impostarlo tramite il Cloud Shell. In Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_PORT=8000

In PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_PORT"="8000"}

servizio app attualmente consente al contenitore di esporre una sola porta per le richieste HTTP.

Configurare le variabili di ambiente

Il contenitore personalizzato può usare variabili di ambiente che devono essere fornite esternamente. È possibile passarli tramite il Cloud Shell. In Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings DB_HOST="myownserver.mysql.database.azure.com"

In PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"DB_HOST"="myownserver.mysql.database.azure.com"}

Quando l'app viene eseguita, le impostazioni dell'app servizio app vengono inserite automaticamente nel processo come variabili di ambiente. È possibile verificare le variabili di ambiente del contenitore con l'URL https://<app-name>.scm.azurewebsites.net/Env.

Se l'app usa immagini da un registro privato o da Docker Hub, le credenziali per l'accesso al repository vengono salvate nelle variabili di ambiente: DOCKER_REGISTRY_SERVER_URLe DOCKER_REGISTRY_SERVER_PASSWORDDOCKER_REGISTRY_SERVER_USERNAME . A causa dei rischi per la sicurezza, nessuno di questi nomi di variabili riservate viene esposto all'applicazione.

Per i contenitori basati su IIS o .NET Framework (4.0 o versione successiva), vengono inseriti System.ConfigurationManager come impostazioni dell'app .NET e stringhe di connessione automaticamente da servizio app. Per tutti gli altri linguaggi o framework, vengono forniti come variabili di ambiente per il processo, con uno dei prefissi corrispondenti seguenti:

  • APPSETTING_
  • SQLCONTR_
  • MYSQLCONTR_
  • SQLAZURECOSTR_
  • POSTGRESQLCONTR_
  • CUSTOMCONNSTR_

Questo metodo funziona sia per le app a contenitore singolo che per le app multi-contenitore, in cui le variabili di ambiente vengono specificate nel file docker-compose.yml .

Usare l'archiviazione condivisa permanente

È possibile usare la directory C:\home nel file system del contenitore personalizzato per rendere persistenti i file tra i riavvii e condividerli tra istanze. La C:\home directory viene fornita per consentire al contenitore personalizzato di accedere all'archiviazione permanente.

Quando l'archiviazione persistente è disabilitata, le scritture nella C:\home directory non vengono rese persistenti tra riavvii dell'app o tra più istanze. Quando l'archiviazione permanente è abilitata, tutte le scritture nella C:\home directory vengono rese persistenti e sono accessibili da tutte le istanze di un'app con scalabilità orizzontale. Inoltre, tutti i contenuti all'interno della C:\home directory del contenitore vengono sovrascritti da eventuali file esistenti già presenti nella risorsa di archiviazione permanente all'avvio del contenitore.

L'unica eccezione è la C:\home\LogFiles directory , usata per archiviare i log del contenitore e dell'applicazione. Questa cartella verrà sempre mantenuta al riavvio dell'app se la registrazione delle applicazioni è abilitata con l'opzione File System , indipendentemente dall'archiviazione permanente abilitata o disabilitata. In altre parole, l'abilitazione o la disabilitazione dell'archiviazione permanente non influisce sul comportamento di registrazione delle applicazioni.

Per impostazione predefinita, l'archiviazione permanente è disabilitata nei contenitori personalizzati di Windows. Per abilitarla, impostare il valore dell'impostazione dell'app WEBSITES_ENABLE_APP_SERVICE_STORAGE su true tramite il Cloud Shell. In Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=true

In PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=true}

È possibile usare la /home directory nel file system del contenitore personalizzato per rendere persistenti i file tra i riavvii e condividerli tra istanze. La /home directory viene fornita per consentire al contenitore personalizzato di accedere all'archiviazione permanente. Il salvataggio dei dati all'interno /home contribuirà alla quota di spazio di archiviazione inclusa nel piano di servizio app.

Quando l'archiviazione persistente è disabilitata, le scritture nella /home directory non vengono rese persistenti tra riavvii dell'app o tra più istanze. Quando l'archiviazione permanente è abilitata, tutte le scritture nella /home directory vengono rese persistenti e sono accessibili da tutte le istanze di un'app con scalabilità orizzontale. Inoltre, tutti i contenuti all'interno della /home directory del contenitore vengono sovrascritti da eventuali file esistenti già presenti nella risorsa di archiviazione permanente all'avvio del contenitore.

L'unica eccezione è la /home/LogFiles directory , usata per archiviare i log del contenitore e dell'applicazione. Questa cartella verrà sempre mantenuta al riavvio dell'app se la registrazione delle applicazioni è abilitata con l'opzione File System , indipendentemente dall'archiviazione permanente abilitata o disabilitata. In altre parole, l'abilitazione o la disabilitazione dell'archiviazione permanente non influisce sul comportamento di registrazione delle applicazioni.

È consigliabile scrivere dati in /home o in un percorso di archiviazione di Azure montato. I dati scritti all'esterno di questi percorsi non saranno persistenti durante i riavvii e verranno salvati in spazio su disco host gestito dalla piattaforma separato dalla quota di archiviazione file dei piani di servizio app.

Per impostazione predefinita, l'archiviazione permanente è abilitata nei contenitori personalizzati Linux. Per disabilitarla, impostare il valore dell'impostazione dell'app WEBSITES_ENABLE_APP_SERVICE_STORAGE su false tramite il Cloud Shell. In Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=false

In PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=false}

Nota

È anche possibile configurare la propria risorsa di archiviazione permanente.

Rilevare una sessione HTTPS

servizio app termina TLS/SSL nei front-end. Ciò significa che le richieste TLS/SSL non vengono mai inviate all'app. Non è necessario e non deve implementare alcun supporto per TLS/SSL nell'app.

I front-end si trovano all'interno dei data center di Azure. Se si usa TLS/SSL con l'app, il traffico attraverso Internet verrà sempre crittografato in modo sicuro.

Personalizzare l'inserimento di tasti del computer ASP.NET

Durante l'avvio del contenitore, le chiavi generate automaticamente vengono inserite nel contenitore come chiavi del computer per ASP.NET routine crittografiche. È possibile trovare queste chiavi nel contenitore cercando le variabili di ambiente seguenti: MACHINEKEY_Decryption, MACHINEKEY_DecryptionKey, MACHINEKEY_ValidationKey, MACHINEKEY_Validation.

Le nuove chiavi a ogni riavvio possono reimpostare ASP.NET l'autenticazione dei moduli e lo stato di visualizzazione, se l'app dipende da esse. Per evitare la rigenerazione automatica delle chiavi, impostarle manualmente come impostazioni dell'app servizio app.

Connettersi al contenitore

È possibile connettersi al contenitore windows direttamente per le attività di diagnostica passando a https://<app-name>.scm.azurewebsites.net/DebugConsole. Il funzionamento è il seguente:

  • La console di debug consente di eseguire comandi interattivi, ad esempio l'avvio di sessioni di PowerShell, l'analisi delle chiavi del Registro di sistema e l'esplorazione dell'intero file system del contenitore.
  • Funziona separatamente dal browser grafico sopra di esso, che mostra solo i file nella risorsa di archiviazione condivisa.
  • In un'app con scalabilità orizzontale la console di debug è connessa a una delle istanze del contenitore. È possibile selezionare un'istanza diversa dall'elenco a discesa Istanza nel menu in alto.
  • Qualsiasi modifica apportata al contenitore dall'interno della console non viene mantenuta quando l'app viene riavviata (ad eccezione delle modifiche nell'archiviazione condivisa), perché non fa parte dell'immagine Docker. Per rendere persistenti le modifiche, ad esempio le impostazioni del Registro di sistema e l'installazione del software, renderle parte del Dockerfile.

Accedere ai log di diagnostica

servizio app registra le azioni dall'host Docker e le attività dall'interno del contenitore. I log dall'host Docker (log della piattaforma) vengono forniti per impostazione predefinita, ma i log applicazioni o i log del server Web dall'interno del contenitore devono essere abilitati manualmente. Per altre informazioni, vedere Abilitare la registrazione delle applicazioni e Abilitare la registrazione del server Web.

Esistono diversi modi per accedere ai log Docker:

Nel portale di Azure

I log Docker vengono visualizzati nel portale nella pagina Impostazioni contenitore dell'app. I log vengono troncati, ma è possibile scaricare tutti i log facendo clic su Scarica.

Dalla console Kudu

Passare a https://<app-name>.scm.azurewebsites.net/DebugConsole e fare clic sulla cartella LogFiles per visualizzare i singoli file di log. Per scaricare l'intera directory LogFiles , fare clic sull'icona Download a sinistra del nome della directory. È anche possibile accedere a questa cartella usando un client FTP.

Nel terminale della console non è possibile accedere alla cartella per impostazione predefinita perché l'archiviazione C:\home\LogFiles condivisa persistente non è abilitata. Per abilitare questo comportamento nel terminale della console, abilitare l'archiviazione condivisa permanente.

Se si tenta di scaricare il log Docker attualmente in uso usando un client FTP, è possibile che venga visualizzato un errore a causa di un blocco di file.

Con l'API Kudu

Passare direttamente a https://<app-name>.scm.azurewebsites.net/api/logs/docker per visualizzare i metadati per i log docker. È possibile visualizzare più file di log elencati e la href proprietà consente di scaricare direttamente il file di log.

Per scaricare tutti i log in un unico file ZIP, accedere a https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip.

Personalizzare la memoria del contenitore

Per impostazione predefinita, tutti i contenitori di Windows distribuiti in Servizio app di Azure sono limitati a 1 GB di RAM. È possibile modificare questo valore specificando l'impostazione dell'app WEBSITE_MEMORY_LIMIT_MB tramite il Cloud Shell. In Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITE_MEMORY_LIMIT_MB=2000

In PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_MEMORY_LIMIT_MB"=2000}

Il valore è definito in MB e deve essere minore e uguale alla memoria fisica totale dell'host. Ad esempio, in un piano di servizio app con 8 GB di RAM, il totale cumulativo di WEBSITE_MEMORY_LIMIT_MB per tutte le app non deve superare 8 GB. Informazioni sulla quantità di memoria disponibile per ogni piano tariffario sono disponibili nella sezione Prezzi di servizio app, nella sezione Piano di servizio Premium v3.

Personalizzare il numero di core di calcolo

Per impostazione predefinita, un contenitore Di Windows viene eseguito con tutti i core disponibili per il piano tariffario scelto. È possibile ridurre il numero di core usati dallo slot di staging, ad esempio. Per ridurre il numero di core usati da un contenitore, impostare l'impostazione dell'app WEBSITE_CPU_CORES_LIMIT sul numero preferito di core. È possibile impostarlo tramite il Cloud Shell. In Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --slot staging --settings WEBSITE_CPU_CORES_LIMIT=1

In PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_CPU_CORES_LIMIT"=1}

Nota

L'aggiornamento dell'impostazione dell'app attiva il riavvio automatico, causando tempi di inattività minimi. Per un'app di produzione, valuta la possibilità di scambiarla in uno slot di staging, modificare l'impostazione dell'app nello slot di staging e quindi scambiarla nuovamente nell'ambiente di produzione.

Verificare il numero modificato passando alla console Kudu (https://<app-name>.scm.azurewebsites.net) e digitando i comandi seguenti usando PowerShell. Ogni comando restituisce un numero.

Get-ComputerInfo | ft CsNumberOfLogicalProcessors # Total number of enabled logical processors. Disabled processors are excluded.
Get-ComputerInfo | ft CsNumberOfProcessors # Number of physical processors.

I processori possono essere processori multicore o hyperthreading. Le informazioni sul numero di core disponibili per ogni piano tariffario sono disponibili nella sezione Prezzi di servizio app, nella sezione Piano di servizio Premium v3.

Personalizzare il comportamento del ping di integrità

servizio app considera che un contenitore venga avviato correttamente all'avvio del contenitore e risponda a un ping HTTP. La richiesta ping di integrità contiene l'intestazione User-Agent= "App Service Hyper-V Container Availability Check". Se il contenitore viene avviato ma non risponde a un ping dopo un determinato periodo di tempo, servizio app registra un evento nel log Docker, indicando che il contenitore non è stato avviato.

Se l'applicazione è a elevato utilizzo di risorse, il contenitore potrebbe non rispondere al ping HTTP nel tempo. Per controllare le azioni quando i ping HTTP hanno esito negativo, impostare l'impostazione dell'app CONTAINER_AVAILABILITY_CHECK_MODE . È possibile impostarlo tramite il Cloud Shell. In Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings CONTAINER_AVAILABILITY_CHECK_MODE="ReportOnly"

In PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"CONTAINER_AVAILABILITY_CHECK_MODE"="ReportOnly"}

La tabella seguente illustra i valori possibili:

Valore Descrizioni
Repair Riavviare il contenitore dopo tre controlli di disponibilità consecutivi
ReportOnly Il valore predefinito. Non riavviare il contenitore ma segnalare nei log Docker per il contenitore dopo tre controlli di disponibilità consecutivi.
Disattivato Non verificare la disponibilità.

Supporto per gli account del servizio gestiti del gruppo

Gli account del servizio gestito del gruppo (gMSA) non sono attualmente supportati nei contenitori di Windows in servizio app.

Abilitare SSH

Secure Shell (SSH) viene usato comunemente per eseguire comandi amministrativi in remoto da un terminale della riga di comando. Per abilitare la funzionalità della console SSH portale di Azure con contenitori personalizzati, sono necessari i passaggi seguenti:

  1. Creare un file di sshd_config standard con il contenuto di esempio seguente e inserirlo nella directory radice del progetto dell'applicazione:

    Port 			2222
ListenAddress 		0.0.0.0
LoginGraceTime 		180
X11Forwarding 		yes
Ciphers aes128-cbc,3des-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr
MACs hmac-sha1,hmac-sha1-96
StrictModes 		yes
SyslogFacility 		DAEMON
PasswordAuthentication 	yes
PermitEmptyPasswords 	no
PermitRootLogin 	yes
Subsystem sftp internal-sftp

    Nota

    Questo file configura OpenSSH e deve includere gli elementi seguenti per garantire la conformità alla funzionalità SSH portale di Azure:

    • Port deve essere impostato su 2222.
    • Ciphers deve includere almeno un elemento di questo elenco: aes128-cbc,3des-cbc,aes256-cbc.
    • MACs deve includere almeno un elemento di questo elenco: hmac-sha1,hmac-sha1-96.

  2. Creare uno script del punto di ingresso con il nome entrypoint.sh (o modificare qualsiasi file di punto di ingresso esistente) e aggiungere il comando per avviare il servizio SSH, insieme al comando di avvio dell'applicazione. L'esempio seguente illustra l'avvio di un'applicazione Python. Sostituire l'ultimo comando in base al linguaggio/stack del progetto:

    #!/bin/sh
set -e
service ssh start
exec gunicorn -w 4 -b 0.0.0.0:8000 app:app

  3. Aggiungere al Dockerfile le istruzioni seguenti in base alla distribuzione dell'immagine di base. Lo stesso copia i nuovi file, installa il server OpenSSH, imposta le autorizzazioni appropriate e configura il punto di ingresso personalizzato ed espone le porte richieste rispettivamente dall'applicazione e dal server SSH:

    COPY entrypoint.sh ./

# Start and enable SSH
RUN apt-get update \
    && apt-get install -y --no-install-recommends dialog \
    && apt-get install -y --no-install-recommends openssh-server \
    && echo "root:Docker!" | chpasswd \
    && chmod u+x ./entrypoint.sh
COPY sshd_config /etc/ssh/

EXPOSE 8000 2222

ENTRYPOINT [ "./entrypoint.sh" ]

    Nota

    La password radice deve essere esattamente Docker! come viene usata da servizio app per consentire l'accesso alla sessione SSH con il contenitore. Questa configurazione non consente connessioni esterne al contenitore. La porta 2222 del contenitore è accessibile solo all'interno della rete bridge di una rete virtuale privata e non è accessibile a un utente malintenzionato su Internet.

  4. Ricompilare ed eseguire il push dell'immagine Docker nel Registro di sistema e quindi testare la funzionalità SSH dell'app Web in portale di Azure.

Per altre informazioni sulla risoluzione dei problemi, vedere il blog di Servizio app di Azure OSS: Abilitazione di SSH in App Web Linux per contenitori

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.

Configurare app multi-contenitore

Usare l'archiviazione permanente in Docker Compose

Per funzionare correttamente, le app multi-contenitore come WordPress richiedono l'archiviazione permanente. Per abilitarla, la configurazione di Docker Compose deve puntare a una posizione di archiviazione all'esterno del contenitore. I percorsi di archiviazione all'interno del contenitore non persistono le modifiche oltre il riavvio dell'app.

Abilitare l'archiviazione permanente impostando l'impostazione dell'app WEBSITES_ENABLE_APP_SERVICE_STORAGE usando il comando az webapp config appsettings set in Cloud Shell.

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=TRUE

Nel file docker-compose.yml eseguire il mapping dell'opzione volumes a ${WEBAPP_STORAGE_HOME}.

WEBAPP_STORAGE_HOME è una variabile di ambiente nel servizio app mappata all'archiviazione permanente per l'app. Ad esempio:

wordpress:
  image: <image name:tag>
  volumes:
  - ${WEBAPP_STORAGE_HOME}/site/wwwroot:/var/www/html
  - ${WEBAPP_STORAGE_HOME}/phpmyadmin:/var/www/phpmyadmin
  - ${WEBAPP_STORAGE_HOME}/LogFiles:/var/log

Limiti di anteprima

Il multi-contenitore è attualmente in anteprima. Le funzionalità della piattaforma servizio app seguenti non sono supportate:

  • Autenticazione/Autorizzazione
  • Identità gestite
  • CORS
  • L'integrazione della rete virtuale non è supportata per gli scenari Docker Compose
  • Al momento per Docker Compose in Servizi app di Azure è previsto un limite di 4.000 caratteri.

Opzioni di Docker Compose

Gli elenchi seguenti mostrano le opzioni di configurazione di Docker Compose supportate e non supportate:

Opzioni supportate

Opzioni non supportate

  • build (non consentita)
  • depends_on (ignorato)
  • networks (ignorata)
  • secrets (ignorata)
  • porte diverse da 80 e 8080 (ignorate)
  • variabili di ambiente predefinite come $variable and ${variable} a differenza di docker

Limitazioni della sintassi

  • "version x.x" deve essere sempre la prima istruzione YAML nel file
  • la sezione ports deve usare numeri racchiusi tra virgolette
  • La sezione del volume di immagini > deve essere racchiusa tra virgolette e non può avere definizioni di autorizzazioni
  • La sezione volumes non deve avere una parentesi graffa vuota dopo il nome del volume

Nota

Tutte le altre opzioni non evidenziate in modo esplicito vengono ignorate in anteprima pubblica.

robots933456 nei log

È possibile che nei log del contenitore venga visualizzato il messaggio seguente:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

È possibile ignorare tale errore. /robots933456.txt è un percorso URL fittizio usato dal servizio app per verificare se il contenitore è in grado di gestire le richieste. Una risposta 404 indica semplicemente che il percorso non esiste, ma consente al servizio app di capire che il contenitore è integro e pronto per rispondere alle richieste.

Passaggi successivi

Esercitazione: Eseguire la migrazione di software personalizzato a Servizio app di Azure usando un contenitore personalizzato

Esercitazione: App WordPress multicontenitore

In alternativa, vedere risorse aggiuntive: