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.

Informazioni sui concetti chiave e istruzioni per la containerizzazione delle app di Windows nel servizio app. I nuovi utenti devono prima seguire l'avvio rapido e l'esercitazione sui contenitori personalizzati.

Informazioni sui concetti chiave e istruzioni per la containerizzazione di app Linux nel servizio app. I nuovi utenti devono prima seguire l'avvio rapido e l'esercitazione sui contenitori personalizzati. Per i contenitori sidecar, vedere Esercitazione: Configurare un contenitore sidecar per un contenitore personalizzato nel Servizio app di Azure.

Note

L'uso di un'entità servizio per l'autenticazione pull dell'immagine del contenitore di Windows non è più supportato. È consigliabile usare l'identità gestita per i contenitori Windows e Linux.

Immagini padre supportate

Selezionare l'immagine padre destra (immagine di base) per il framework desiderato per l'immagine Windows personalizzata:

  • Per distribuire app .NET Framework, usare un'immagine principale basata sulla versione Windows Server 2019 Core Long-Term Servicing Channel.
  • Per distribuire app .NET Core, usare un'immagine primaria basata sulla release Annual Channel della versione Windows Server 2019 Nano.

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

Usare il comando seguente per modificare l'immagine Docker corrente in una nuova immagine in un contenitore personalizzato esistente:

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>

Specificare le credenziali di accesso per l'account del registro privato nei campi \<username> e \<password>.

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

Usare la procedura seguente per configurare l'app Web per effettuare il pull da Azure Container Registry utilizzando un'identità gestita. I passaggi usano 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 entità servizio dell'identità assegnata.

  2. Ottenere l'ID risorsa del Registro 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 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 PowerShell per eseguire i comandi, è necessario eseguire l'escape delle stringhe nell'argomento --generic-configurations in questo passaggio e in quello successivo. 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 <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>"}'

L'app Web ora usa l'identità gestita per eseguire il pull dal 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 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, abilitare il routing dell'immagine tramite la rete virtuale. Configurare l'impostazione del sito vnetImagePullEnabled.

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

Risolvere i problemi relativi alle operazioni da eseguire se 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 caricamento e l'avvio del nuovo contenitore, il servizio app continua a servire le richieste dal contenitore precedente. Il servizio app invia solo richieste al nuovo contenitore dopo l'avvio ed è pronto per ricevere le richieste.

Informazioni su come vengono archiviate le immagini del contenitore

La prima volta che si esegue un'immagine Docker personalizzata nel Servizio App, il Servizio App esegue il comando docker pull e effettua il pull di tutti i livelli dell'immagine. I livelli vengono archiviati su disco, come quando si usa Docker in locale. Ogni volta che l'app viene riavviata, il servizio app esegue il docker pull comando . Esegue il pull solo dei 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 la modifica dei piani tariffari), il servizio app deve eseguire di nuovo il pull di tutti i livelli. Lo stesso vale se si aumenta il numero di istanze. Inoltre, in rari casi, le istanze dell'app potrebbero 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 nell'app Servizio app. È possibile impostarlo usando Azure Cloud Shell. In Bash usare il comando seguente:

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

In PowerShell usare il comando seguente:

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 è necessario fornire esternamente. È possibile trasferirli utilizzando Cloud Shell. In Bash usare il comando seguente:

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

In PowerShell usare il comando seguente:

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

Quando l'app viene eseguita, le impostazioni del 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.

Quando si esegue SSH in un contenitore con immagini Docker personalizzate, è possibile che vengano visualizzate solo alcune variabili di ambiente se si tenta di usare comandi come env o printenv. Per visualizzare tutte le variabili di ambiente all'interno del contenitore, come quelle che vengono passate all'applicazione per l'utilizzo durante il runtime, aggiungere questa riga allo script del punto di ingresso:

eval $(printenv | sed -n "s/^\([^=]\+\)=\(.*\)$/export \1=\2/p" | sed 's/"/\\\"/g' | sed '/=/s//="/' | sed 's/$/"/' >> /etc/profile)

Vedere un esempio completo.

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 di Internet Information Services (IIS) o .NET Framework (versione 4.0 o successiva), le credenziali vengono automaticamente iniettate in System.ConfigurationManager come impostazioni dell'app .NET e stringhe di connessione dal servizio App Service. 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_

È possibile usare questo metodo per le app a contenitore singolo o multi-contenitore, in cui le variabili di ambiente vengono specificate nel docker-compose.yml file.

Usare l'archiviazione condivisa permanente

È possibile usare la C:\home directory nel file system del contenitore personalizzato per rendere persistenti i file tra i riavvii e condividerli tra istanze. Quando si usa la C:\home directory, il contenitore personalizzato può accedere all'archiviazione permanente.

Quando l'archiviazione persistente è disabilitata, le scritture nella C:\home directory non vengono mantenute tra i riavvii dell'app o tra più istanze. Quando l'archiviazione permanente è abilitata, tutte le scritture nella C:\home directory vengono mantenute. Tutte le istanze di un'app con scalabilità orizzontale possono accedervi. All'avvio del contenitore, se sono presenti file nella risorsa di archiviazione permanente, sovrascrivono qualsiasi contenuto nella C:\home directory del contenitore.

L'unica eccezione è la C:\home\LogFiles directory. Questa directory archivia i log del contenitore e dell'applicazione. La 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, quando si abilita o disabilita l'archiviazione persistente, non influisce sul comportamento di registrazione delle applicazioni.

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

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

In PowerShell usare il comando seguente:

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

È possibile usare la /home directory nel file system del contenitore personalizzato per rendere persistenti i file tra i riavvii e condividerli tra istanze. Quando si usa la C:\home directory, il contenitore personalizzato può accedere all'archiviazione permanente. Tenere presente che i dati salvati all'interno /home contribuiscono alla quota di spazio di archiviazione inclusa nel piano di servizio app.

Quando l'archiviazione persistente è disabilitata, le scritture nella C:\home directory non vengono mantenute tra i riavvii dell'app o tra più istanze. Quando l'archiviazione permanente è abilitata, tutte le scritture nella C:\home directory vengono mantenute. Tutte le istanze di un'app con scalabilità orizzontale possono accedervi. All'avvio del contenitore, se sono presenti file nella risorsa di archiviazione permanente, sovrascrivono qualsiasi contenuto nella C:\home directory del contenitore.

L'unica eccezione è la C:\home\LogFiles directory. Questa directory archivia i log del contenitore e dell'applicazione. La 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, quando si abilita o disabilita l'archiviazione persistente, non influisce sul comportamento di registrazione delle applicazioni.

Si consiglia di scrivere dati in /home o in un percorso di archiviazione 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 usare il comando seguente:

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

In PowerShell usare il comando seguente:

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

Note

È anche possibile configurare una propria archiviazione permanente.

Rilevare una sessione HTTPS

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 vengono generate e inserite automaticamente 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_ValidationKeye 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 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 selezionare 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 scalabilità orizzontale, la sessione SSH si connette 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, qualsiasi modifica apportata al contenitore dall'interno della sessione SSH non viene mantenuta al riavvio dell'app. Queste modifiche non fanno 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

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.

È possibile accedere ai log Docker in diversi modi:

Portale di Azure

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

Kudu

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

Per impostazione predefinita, non è possibile accedere alla C:\home\LogFiles cartella nel terminale SSH perché l'archiviazione 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.

Kudu API

Vai direttamente a https://<app-name>.scm.azurewebsites.net/api/logs/docker per visualizzare i metadati dei log Docker. Potrebbero essere elencati più file di log. È possibile usare la href proprietà per 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 di Windows distribuiti nel servizio app di Azure hanno un limite di memoria configurato. La tabella seguente elenca le impostazioni predefinite per ogni SKU del piano di servizio app.

SKU del piano 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 in Cloud Shell. In Bash usare il comando seguente:

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

In PowerShell usare il comando seguente:

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

Il valore è definito in megabyte (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 può superare 8 GB. Per altre informazioni sulla quantità di memoria disponibile, vedere il piano di servizio Premium v3 nei prezzi del servizio app.

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. Potrebbe essere opportuno ridurre il numero di core usati dallo slot di staging. 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 usando Cloud Shell. In Bash usare il comando seguente:

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

In PowerShell usare il comando seguente:

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. Per un'app di produzione, è consigliabile scambiarla in uno slot di staging. Modificare l'impostazione dell'app nello slot di staging e quindi convertirla di nuovo in produzione.

Per verificare il numero modificato, aprire una sessione SSH usando il portale di Azure o 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 possono essere processori multicore o hyper-threading. Per informazioni sul numero di core disponibili, vedere il piano di servizio Premium v3 nei 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 richiede un uso intensivo delle risorse, il contenitore potrebbe non rispondere al ping HTTP in tempo. Per controllare cosa accade quando i ping HTTP hanno esito negativo, impostare l'impostazione dell'app CONTAINER_AVAILABILITY_CHECK_MODE . È possibile impostarlo usando Cloud Shell. In Bash usare il comando seguente:

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

In PowerShell usare il comando seguente:

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

Nella tabella seguente sono illustrati i possibili valori:

valore Description
Repair Riavviare il contenitore dopo tre controlli di disponibilità consecutivi.
ReportOnly Valore predefinito. Segnalare il contenitore nei log Docker dopo tre controlli di disponibilità consecutivi, ma non riavviarlo.
Off Non verificare la disponibilità.

Supporto per gli account del servizio gestito del gruppo

Gli account del servizio gestito di gruppo non sono supportati nei contenitori di Windows nel servizio app.

Abilitare SSH

È possibile usare Secure Shell (SSH) per eseguire in remoto comandi amministrativi 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

    Note

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

    • Il Port valore deve essere impostato su 2222.
    • I Ciphers valori devono includere almeno un elemento nell'elenco: aes128-cbc, 3des-cbco aes256-cbc.
    • I MACs valori devono includere almeno un elemento nell'elenco: hmac-sha1 o hmac-sha1-96.

  2. Creare uno script del punto di ingresso denominato 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 le istruzioni seguenti al Dockerfile in base alla distribuzione dell'immagine di base. Queste istruzioni copiano i nuovi file, installano il server OpenSSH, impostano le autorizzazioni appropriate e configurano il punto di ingresso personalizzato ed espongono 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" ]

    Note

    La password radice deve essere esattamente Docker! perché il servizio app lo usa per concedere 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. Un utente malintenzionato su Internet non può accedervi.

  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: Abilitare SSH in un'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 i valori <app-name> e <resource-group-name> con i nomi appropriati per la tua applicazione 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, usare i tasti di scelta rapida CTRL+C.

Configurare app multi-contenitore

Note

La funzionalità Docker Compose verrà ritirata il 31 marzo 2027. I contenitori sidecar hanno esito positivo nelle app multi-contenitore in Servizio app. Per i nuovi servizi, vedere Esercitazione: configurare un contenitore sidecar per un contenitore personalizzato nel Servizio app di Azure. Per le app multi-contenitore esistenti nel servizio app, vedere Eseguire la 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 abilitare l'archiviazione permanente, la configurazione di Docker Compose deve puntare a una posizione di archiviazione all'esterno del 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 az webapp config appsettings set comando 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, mappare l'opzione volumes su ${WEBAPP_STORAGE_HOME}.

WEBAPP_STORAGE_HOME è una variabile di ambiente nel servizio app che esegue il mapping 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

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

  • Autenticazione o autorizzazione.
  • Identità gestite.
  • Condivisione di risorse tra le origini (CORS).
  • Integrazione della rete virtuale con scenari Docker Compose.

Docker Compose nel servizio app di Azure ha attualmente un limite di 4.000 caratteri.

Opzioni di Docker Compose

Le sezioni seguenti illustrano le opzioni di configurazione di Docker Compose supportate e non supportate.

Opzioni supportate

Opzioni non supportate

  • build (non consentito)
  • depends_on (ignorato)
  • networks (ignorato)
  • secrets (ignorato)
  • Porte diverse rispetto a 80 e 8080 (ignorate)
  • Variabili di ambiente predefinite come $variable e ${variable} (a differenza di Docker)

Limitazioni della sintassi

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

Note

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

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 "-" "-"

È possibile ignorare tale errore. /robots933456.txt è un percorso URL fittizio. Il servizio app lo usa per verificare se il contenitore è in grado di gestire le richieste. Una risposta di errore "404" indica che il percorso non esiste e segnala al servizio app che il contenitore è integro e pronto per rispondere alle richieste.

Contenuti correlati

  • Last updated on