Condividi tramite

Configurare un contenitore personalizzato per il Servizio app di Azure

Questo articolo illustra come configurare un contenitore personalizzato da eseguire nel Servizio app di Azure.

Questa guida fornisce i concetti chiave e le istruzioni per la containerizzazione di app Windows nel servizio app. I nuovi utenti del servizio app di Azure devono prima seguire la guida introduttiva e l'esercitazione sul contenitore personalizzato.

Questa guida fornisce i concetti chiave e le istruzioni per la containerizzazione di app Linux nel servizio app. Se non si ha familiarità con il servizio app di Azure, seguire prima di tutto la guida introduttiva e l'esercitazione sul contenitore personalizzato. Per i contenitori sidecar, vedere Esercitazione: Configurare un contenitore sidecar per un contenitore personalizzato in app Azure Servizio.

Nota

L'entità servizio non è più supportata per l'autenticazione pull di immagini del contenitore di Windows. È consigliabile usare l'identità gestita per i contenitori Windows e Linux

Immagini padre supportate

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

  • Per distribuire app .NET Framework, usare un'immagine padre basata sulla versione Long-Term Servicing Channel (LTSC) di Windows Server 2019 Core.
  • Per distribuire le app .NET Core, usa un'immagine padre basata sulla versione Windows Server 2019 Nano Canale Annuale (AC).

Il download di un'immagine principale durante l'avvio dell'app richiede tempo. È possibile ridurre il tempo 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 attuale 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 il 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 privato.

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

Usare la procedura seguente per configurare l'app Web in modo da eseguire il pull dal Registro Azure Container usando l'identità gestita. I passaggi usano l'identità gestita assegnata dal sistema. È invece possibile usare l'identità gestita assegnata dall'utente.

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

    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 dagli argomenti --query e --output, è l'ID dell'entità principale del servizio dell'identità assegnata.

  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 dagli 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 entità servizio dal comando az webapp identity assign
    • <registry-resource-id> con l'ID del registro contenitori derivato dal comando az acr show

    Per altre informazioni su queste autorizzazioni, vedere Che cos'è il controllo degli accessi in base al ruolo di Azure.

  4. Configurare l'app in modo da usare l'identità gestita per eseguire il pull dal 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 della tua app Web.

    Suggerimento

    Se si usa la console di PowerShell per eseguire i comandi, effettuare l'escape delle stringhe nell'argomento --generic-configurations in questo e il prossimo passaggio. Ad esempio: --generic-configurations '{\"acrUseManagedIdentityCreds\": true'

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

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

    Sostituire il valore <identity-name> dell'identità gestita assegnata dall'utente e usare il valore <client-id> di output 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>"}'

Tutto pronto! L'app Web ora utilizza un'identità gestita per eseguire il pull da Azure Container Registry.

Usare un'immagine da un registro protetto in rete

Per connettersi ed eseguire il pull da un registro all'interno di una rete virtuale o locale, l'app deve integrarsi con una rete virtuale. È necessaria anche l'integrazione della rete virtuale per Registro Azure Container con un endpoint privato. Dopo aver configurato la rete e la risoluzione DNS, abilita il routing dell'immagine mediante 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]

Non viene visualizzato il contenitore aggiornato

Se si modificano le impostazioni del contenitore Docker in modo che punti a un nuovo contenitore, può essere necessario qualche minuto prima che l'app gestisca le richieste HTTP dal nuovo contenitore. Durante il pull e l'avvio del nuovo contenitore, il servizio app continua a gestire le richieste dal contenitore precedente. Solo quando il nuovo contenitore è stato avviato ed è pronto a ricevere richieste, il servizio app inizia a inviargli richieste.

Modalità di archiviazione delle immagini del contenitore

La prima volta che si esegue un'immagine Docker personalizzata nel servizio app, il servizio app esegue un'operazione docker pull ed esegue il pull di tutti i livelli dell'immagine. Questi livelli vengono archiviati su disco, come se si usasse Docker in locale. Ogni volta che l'app viene riavviata, App Service esegue un docker pull. Estrae solo i livelli modificati. Se non sono state apportate modifiche, il servizio app usa i livelli esistenti sul disco locale.

Se l'app modifica le istanze di calcolo per qualsiasi motivo, ad esempio per passare a un piano tariffario superiore o inferiore, il servizio app deve eseguire di nuovo il pull di tutti i livelli. Lo stesso vale se si aumenta il numero di 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, App Service presuppone che il contenitore personalizzato sia in ascolto sulla porta 80. Se il contenitore è in ascolto su una porta diversa, configurare l'impostazione dell'app WEBSITES_PORT nel servizio app. È possibile impostarlo usando 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"}

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

Configurare le variabili di ambiente

Il contenitore personalizzato potrebbe usare variabili di ambiente che devono essere fornite esternamente. Puoi passarli usando 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_URL, DOCKER_REGISTRY_SERVER_USERNAMEe DOCKER_REGISTRY_SERVER_PASSWORD. 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), le credenziali vengono inserite System.ConfigurationManager come impostazioni dell'app .NET e stringhe di connessione automaticamente dal servizio app. Per tutti gli altri linguaggi o framework, vengono forniti come variabili di ambiente per il processo, con uno dei prefissi 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 sono specificate nel file docker-compose.yml.

Usare l'archiviazione condivisa permanente

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

Quando l'archiviazione persistente è disabilitata, le scritture nella directory C:\home non vengono mantenute tra riavvii dell'app o tra più istanze. Quando l'archiviazione permanente è abilitata, tutte le scritture nella directory C:\home vengono mantenute. Tutte le istanze di un'app con scalabilità orizzontale possono accedervi. Tutti i file esistenti già presenti nell'archivio permanente quando il contenitore inizia a sovrascrivere qualsiasi contenuto nella directory C:\home del contenitore.

L'unica eccezione è la directory C:\home\LogFiles . Questa directory archivia i log del contenitore e dell'applicazione. Questa cartella viene sempre mantenuta al riavvio dell'app se la registrazione delle applicazioni è abilitata con l'opzione File System , indipendentemente dal fatto che sia abilitata o meno l'archiviazione permanente. 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 è abilitata nei contenitori personalizzati Windows. Per disabilitarla, impostare il valore dell'impostazione dell'app WEBSITES_ENABLE_APP_SERVICE_STORAGE su false usando 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}

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

Quando l'archiviazione persistente è disabilitata, le scritture nella directory /home non vengono mantenute tra i riavvii dell'app o tra più istanze. Quando è abilitata l'archiviazione permanente, tutte le scritture nella directory /home vengono mantenute. Tutte le istanze di un'app con scalabilità orizzontale possono accedervi. Tutti i file esistenti già presenti nell'archivio permanente quando il contenitore inizia a sovrascrivere qualsiasi contenuto nella directory /home del contenitore.

L'unica eccezione è la directory /home/LogFiles . Questa directory archivia i log del contenitore e dell'applicazione. Questa cartella viene sempre mantenuta al riavvio dell'app se la registrazione delle applicazioni è abilitata con l'opzione File System , indipendentemente dal fatto che sia abilitata o meno l'archiviazione permanente. 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 sono persistenti durante i riavvii. I dati vengono salvati nello spazio su disco dell'host gestito dalla piattaforma separato dalla quota di archiviazione file dei piani di servizio app.

Per impostazione predefinita, l'archiviazione permanente è disabilitata nei contenitori personalizzati Linux. Per abilitarla, impostare il valore dell'impostazione dell'app WEBSITES_ENABLE_APP_SERVICE_STORAGE su true usando 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}

Nota

È anche possibile configurare una propria archiviazione permanente.

Rilevare una sessione HTTPS

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

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

Personalizzare l'inserimento della chiave computer ASP.NET

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

Le nuove chiavi generate a ogni riavvio potrebbero reimpostare l'autenticazione basata su form ASP.NET e lo stato di visualizzazione, se l'app ne è dipendente. Per evitare la rigenerazione automatica delle chiavi, impostarle manualmente come impostazioni dell'app del servizio app.

Connettersi al contenitore

Per connettersi al contenitore di Windows direttamente per le attività di diagnostica, passare a https://<app-name>.scm.azurewebsites.net/ e scegliere l'opzione SSH. Questa opzione stabilisce una sessione SSH diretta in cui è possibile eseguire comandi all'interno del contenitore.

  • Funziona separatamente dal browser grafico soprastante, che mostra solo i file nell'archiviazione condivisa.
  • In un'app con numero di istanze aumentato, la sessione SSH è connessa a una delle istanze del contenitore. È possibile selezionare un'istanza diversa dall'elenco a discesa Istanza nel menu Kudu in alto.
  • Ad eccezione delle modifiche apportate all'archiviazione condivisa, le modifiche apportate al contenitore dall'interno della sessione SSH non vengono mantenute al riavvio dell'app. Tali modifiche non fanno parte dell'immagine Docker. Per conservare le modifiche, ad esempio le impostazioni del Registro di sistema e l'installazione del software, renderle parte del Dockerfile.

Accedere ai log di diagnostica

Il servizio app registra le azioni eseguite dall'host Docker e le attività provenienti dal contenitore. I log dall'host Docker (log della piattaforma) sono abilitati per impostazione predefinita. È necessario abilitare manualmente i log applicazioni o i log del server Web dall'interno del contenitore. Per altre informazioni, vedere Abilitare la registrazione delle applicazioni e Abilitare la registrazione del server Web.

Esistono diversi modi per accedere ai log di Docker:

Nel portale di Azure

I log docker vengono visualizzati nel portale di Azure nella pagina Impostazioni contenitore dell'app. I registri sono troncati. Per scaricare tutti i log, selezionare Scarica.

Da Kudu

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

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

Se si prova a scaricare il log di Docker attualmente in uso usando un client FTP può essere 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 vedere i metadati per i log di Docker. Potrebbero essere elencati più file di log. La href proprietà consente di scaricare direttamente il file di log.

Per scaricare insieme 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 Windows distribuiti nel servizio app di Azure hanno un limite di memoria configurato. Nella seguente tabella sono elencate le impostazioni predefinite per SKU del piano di servizio app.

SKU del piano di servizio app Limite di memoria predefinito per app in MB
P1v3 1024
P1Mv3 1024
P2v3 1536
P2Mv3 1536
P3v3 2048
P3Mv3 2048
P4Mv3 2560
P5Mv3 3072

È possibile modificare questo valore specificando l'impostazione dell'app WEBSITE_MEMORY_LIMIT_MB usando 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. Per altre informazioni sulla quantità di memoria disponibile, vedere la sezione Piano di servizio Premium v3 dei prezzi del servizio app.

Personalizzare il numero di core di calcolo

Per impostazione predefinita, un contenitore Windows viene eseguito con tutti i core disponibili per il piano tariffario scelto. Potresti voler ridurre il numero di core usati dallo slot di staging. Per ridurre il numero di core usati da un contenitore, configurare l'impostazione dell'app WEBSITE_CPU_CORES_LIMIT sul numero preferito di core. È possibile impostarlo usando 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}

Suggerimento

L'aggiornamento dell'impostazione dell'app attiva il riavvio automatico, causando tempi di inattività minimi. Se si tratta di un'app di produzione, è consigliabile spostarla in uno slot di staging, modificare l'impostazione dell'app nello slot di staging e quindi riportarla in produzione.

Per verificare il numero modificato, aprire una sessione SSH dal portale di Azure o usare il portale Kudu (https://<app-name>.scm.azurewebsites.net/webssh/host). Immettere 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 potrebbero essere processori multicore o hyperthreading. Informazioni sul numero di core disponibili, vedere la sezione Piano di servizio Premium v3 dei prezzi del servizio app.

Personalizzare il comportamento del ping di integrità

Il servizio app considera un contenitore correttamente avviato quando il contenitore si avvia e risponde a un ping HTTP. La richiesta del ping di integrità contiene l'intestazione User-Agent= "App Service Hyper-V Container Availability Check". Se il contenitore viene avviato ma non risponde ai ping dopo un determinato periodo di tempo, il servizio app registra un evento nel log Docker.

Se l'applicazione consuma una quantità elevata di risorse, il contenitore potrebbe non rispondere al ping HTTP in tempo. Per controllare le azioni quando i ping HTTP hanno esito negativo, configurare l'impostazione dell'app CONTAINER_AVAILABILITY_CHECK_MODE. È possibile impostarlo usando 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"}

Nella tabella seguente sono illustrati i possibili valori:

Valore Descrizione
repair Riavviare il contenitore dopo tre controlli di disponibilità consecutivi.
ReportOnly Valore predefinito. Non riavviare il contenitore ma segnalare nei log Docker del contenitore dopo tre controlli della disponibilità consecutivi.
Disattivato Non verificare la disponibilità.

Supporto per gli account del servizio gestiti del gruppo

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

Abilitare SSH

Secure Shell (SSH) viene comunemente usato per eseguire comandi amministrativi in remoto da un terminale della riga di comando. Per abilitare la funzionalità della console SSH del portale di Azure con contenitori personalizzati, seguire questa procedura:

  1. Creare un file 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 assicurare la conformità alla funzionalità SSH del 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. 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 o allo 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. Queste istruzioni copiano i nuovi file, installano il server OpenSSH, impostano le autorizzazioni appropriate, configurano il punto di ingresso personalizzato ed espongono rispettivamente le porte richieste 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! perché viene usata dal 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 di bridge di una rete virtuale privata e non è accessibile a un utente malintenzionato tramite Internet.

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

Per altre informazioni sulla risoluzione dei problemi, vedere il blog del Servizio app di Azure: 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.

Per attivare la registrazione dei contenitori, eseguire il comando seguente:

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 nomi appropriati per l'app Web.

Dopo aver attivato la registrazione dei contenitori, eseguire il comando seguente per visualizzare il flusso di log:

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

Se i log della console non vengono visualizzati immediatamente, controllare di nuovo in 30 secondi.

Per arrestare lo streaming dei log in qualsiasi momento, selezionare CTRL+C.

Configurare le app multi-contenitore

Nota

La funzionalità Docker Compose verrà ritirata il 31 marzo 2027. I contenitori sidecar sostituiscono le app multi-contenitore in App Service. Per i nuovi servizi, fare riferimento a Esercitazione: Configurare il contenitore sidecar per un contenitore personalizzato in Azure App Service. Per le app multi-contenitore esistenti nel Servizio App, consultare Migrazione delle applicazioni Docker Compose alla funzionalità Sidecar.

Usare l'archiviazione permanente in Docker Compose

Per il corretto funzionamento delle app multi-contenitore come WordPress è necessaria l'archiviazione permanente. Per abilitarla, la configurazione Docker Compose deve puntare a una posizione di archiviazione esterna al contenitore. Le posizioni di archiviazione all'interno del contenitore non conservano le modifiche oltre il riavvio dell'app.

Per abilitare l'archiviazione permanente, impostare l'impostazione dell'app WEBSITES_ENABLE_APP_SERVICE_STORAGE . Usare 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 dell'anteprima

L'uso di più contenitori è attualmente in anteprima. Le funzionalità della piattaforma del servizio app seguenti non sono supportate:

  • Autenticazione/Autorizzazione
  • Identità gestite
  • Condivisione delle Risorse tra Origini Diverse (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 illustrano le opzioni di configurazione di Docker Compose supportate e non supportate:

Opzioni supportate

Opzioni non supportate

  • build (non consentita)
  • depends_on (ignorata)
  • 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 image > volume 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 indicate in modo esplicito vengono ignorate nell'anteprima pubblica.

Ignorare il messaggio robots933456 nei log

Nei log del contenitore potrebbe essere 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 "-" "-"

Questo messaggio può tranquillamente essere ignorato. /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 che il percorso non esiste e segnala al servizio app che il contenitore è integro e pronto per rispondere alle richieste.

Contenuti correlati

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

Esercitazione: Configurare un contenitore sidecar per un contenitore personalizzato nel servizio app Azure

In alternativa, vedere altre risorse: