Condividi tramite

Configurare un contenitore personalizzato per il Servizio app di Azure

  • Articolo

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 l'argomento di avvio rapido per il contenitore personalizzato e questa esercitazione.

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 l'argomento di avvio rapido sul contenitore personalizzato e la relativa esercitazione. Sono anche disponibili un argomento di avvio rapido sulle app multi-contenitore e un'esercitazione. Per i contenitori sidecar (anteprima), vedere Esercitazione: Configurare un contenitore sidecar per un contenitore personalizzato nel Servizio app di Azure (anteprima).

Nota

L'entità servizio non è più supportata per l'autenticazione pull di immagini del contenitore di Windows. Il metodo consigliato è usare l'identità gestita sia per i contenitori Windows, sia per i contenitori Linux

Immagini padre supportate

Per l'immagine Windows personalizzata, è necessario scegliere l'immagine padre (di base) corretta 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 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. In questi passaggi viene usata un'identità gestita assegnata dal sistema, ma è anche possibile usare un'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 in base agli argomenti --query e --output) è l'ID dell'entità 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 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 recuperato 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 dell'app Web.

    Suggerimento

    Se si usa la console di PowerShell per eseguire i comandi, è necessario eseguire l'escape delle stringhe nell'argomento --generic-configurations in questo passaggio e nel 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 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>"}'

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

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. L'integrazione rete virtuale è necessaria anche per Registro Azure Container con un endpoint privato. Quando la rete e la risoluzione del DNS sono configurate, è possibile abilitare il routing del pull dell'immagine tramite la rete virtuale configurando 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]

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, il servizio app esegue docker pull, ma esegue solo il pull 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 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, il servizio app 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 farlo in 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. È possibile passarle tramite 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 provenienti 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_USERNAME e 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), vengono inseriti automaticamente dal servizio app in System.ConfigurationManager come impostazioni dell'app .NET e stringhe di connessione. 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 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 permanente è disabilitata, le scritture nella directory C:\home non vengono conservate tra riavvii dell'app o tra più istanze. Quando l'archiviazione permanente è abilitata, tutte le scritture nella directory C:\home vengono conservate e sono accessibili da tutte le istanze di un'app con numero di istanze aumentato. Inoltre, tutti i contenuti all'interno della directory C:\home del contenitore vengono sovrascritti da eventuali file esistenti già presenti nell'archivio permanente all'avvio del contenitore.

L'unica eccezione è la directory C:\home\LogFiles, che viene usata per archiviare i log del contenitore e dell'applicazione. Questa cartella viene sempre conservata al riavvio dell'app se la registrazione delle applicazioni è abilitata con l'opzione File system, indipendentemente dal fatto che l'archiviazione permanente sia 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 Windows. Per abilitarla, configurare il valore dell'impostazione dell'app WEBSITES_ENABLE_APP_SERVICE_STORAGE su true tramite 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 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 permanente è disabilitata, le scritture nella directory /home non vengono conservate tra riavvii dell'app o tra più istanze. Quando l'archiviazione permanente è abilitata, tutte le scritture nella directory /home vengono conservate e sono accessibili da tutte le istanze di un'app con numero di istanze aumentato. Inoltre, tutti i contenuti all'interno della directory /home del contenitore vengono sovrascritti da eventuali file esistenti già presenti nell'archivio permanente all'avvio del contenitore.

L'unica eccezione è la directory /home/LogFiles, che viene usata per archiviare i log del contenitore e dell'applicazione. Questa cartella viene sempre conservata al riavvio dell'app se la registrazione delle applicazioni è abilitata con l'opzione File system, indipendentemente dal fatto che l'archiviazione permanente sia 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 vengono conservati durante i riavvii e 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, configurare il valore dell'impostazione dell'app WEBSITES_ENABLE_APP_SERVICE_STORAGE su true tramite 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/SSL nei front-end. Questo significa che le richieste TLS/SSL non vengono mai inviate all'app. Non è necessario implementare alcun supporto per TLS/SSL nell'app ed è opportuno non farlo.

I front-end si trovano all'interno dei data center di Azure. Se si usa TLS/SSL 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

È possibile connettersi al contenitore Windows direttamente per le attività di diagnostica passando a https://<app-name>.scm.azurewebsites.net/ e scegliendo l'opzione SSH. Viene stabilita una sessione SSH diretta con il contenitore 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.
  • Qualunque modifica apportata al contenitore dall'interno della sessione SSH non viene mantenuta quando l'app viene riavviata (ad eccezione delle modifiche nell'archiviazione condivisa), perché non fa 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 dell'host Docker (log della piattaforma) vengono forniti per impostazione predefinita, ma i log delle applicazioni o i log del server Web all'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 di Docker:

Nel portale di Azure

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

Da Kudu

Passare a https://<app-name>.scm.azurewebsites.net/DebugConsole e selezionare la cartella LogFiles per visualizzare i singoli file di log. Per scaricare l'intera directory LogFiles, selezionare l'icona "Download" 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 permanente 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 e la proprietà href 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 tramite 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. Le informazioni sulla quantità di memoria disponibile per ogni piano tariffario sono disponibili nella sezione Prezzi del servizio app, nella sezione Piano di servizio Premium v3.

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. È possibile ridurre il numero di core usati dallo slot di staging, ad esempio. 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 farlo in 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 un tempo di inattività minimo. 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.

Verificare il numero modificato aprendo una sessione SSH dal portale o tramite il portale Kudu (https://<app-name>.scm.azurewebsites.net/webssh/host) e digitando i comandi seguenti con 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. Le informazioni sulla quantità di core disponibili per ogni piano tariffario sono disponibili nella sezione Prezzi del servizio app, nella sezione Piano di servizio Premium v3.

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 si avvia, ma non risponde ai ping dopo un determinato periodo di tempo, il servizio app registra un evento nel log Docker che indica che il contenitore non si è avviato.

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 farlo in 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 della 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 usato comunemente 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, sono necessari i passaggi seguenti:

  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 del 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 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 e quindi testare la funzionalità SSH dell'app Web nel portale di Azure.

Altre informazioni sulla risoluzione dei problemi sono disponibili nel blog del Servizio app di Azure: Abilitazione di SSH nell'app Web per contenitori Linux

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 le app multi-contenitore

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.

Abilitare l'archiviazione permanente configurando l'impostazione dell'app WEBSITES_ENABLE_APP_SERVICE_STORAGE con 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
  • 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.

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

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 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 un software personalizzato al Servizio app di Azure usando un contenitore personalizzato

Esercitazione: App WordPress multicontenitore

In alternativa, vedere altre risorse: