Configurare un contenitore personalizzato per il Servizio app di Azure

  • Articolo

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

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

Questa guida fornisce concetti chiave e istruzioni per la containerizzazione di app Linux in servizio app. Se non si ha una versione di app Azure Servizio, seguire prima la guida introduttiva al contenitore personalizzato e l'esercitazione. È disponibile anche una guida introduttiva e un'esercitazione per app multi-contenitore. Per i contenitori sidecar (anteprima), vedere Esercitazione: Configurare un contenitore sidecar per un contenitore personalizzato nel servizio app Azure (anteprima).

Nota

L'entità servizio non è più supportata per l'autenticazione pull dell'immagine del contenitore di Windows. Il modo consigliato consiste nell'usare l'identità gestita per contenitori Windows e Linux

Immagini padre supportate

Per l'immagine 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.

  • mcr.microsoft.com/windows/servercore:ltsc2022
  • mcr.microsoft.com/windows/servercore:ltsc2019
  • mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2022
  • mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019
  • mcr.microsoft.com/dotnet/runtime:6.0-nanoserver-ltsc2022
  • mcr.microsoft.com/dotnet/runtime:6.0-nanoserver-1809
  • mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-ltsc2022
  • mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-1809

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 (ACR) usando l'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 --query argomenti e --output ) è l'ID 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 --query argomenti 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, è 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, verificare che l'identità sia configurata nell'app Web e quindi impostare la proprietà per specificare l'ID acrUserManagedIdentityID 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 ora usa 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 locale, l'app deve integrarsi con una rete virtuale. L'integrazione della rete virtuale è 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 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, 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 iniziare a inviare 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, come se si usasse 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 presenti 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, il servizio app presuppone che il contenitore personalizzato sia in ascolto sulla porta 80. Se il contenitore è in ascolto di una porta diversa, impostare l'impostazione dell'app WEBSITES_PORT nell'app servizio app. È possibile impostarlo tramite 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 potrebbe usare variabili di ambiente che devono essere fornite esternamente. È possibile passarli 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 da un registro privato o dall'hub Docker, le credenziali per l'accesso al repository vengono salvate nelle variabili di ambiente: DOCKER_REGISTRY_SERVER_URLe DOCKER_REGISTRY_SERVER_USERNAMEDOCKER_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 System.ConfigurationManager come impostazioni dell'app .NET e stringa 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 possono essere 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 il contenitore e i log applicazioni. Questa cartella viene 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 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 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 contribuisce 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 possono essere 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 il contenitore e i log applicazioni. Questa cartella viene 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 sono persistenti 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 è abilitata nei contenitori personalizzati Linux. Per disabilitarla, impostare il valore dell'impostazione dell'app WEBSITES_ENABLE_APP_SERVICE_STORAGE su false tramite 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 arrivano mai 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 viene sempre crittografato in modo sicuro.

Personalizzare l'inserimento di chiavi 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 potrebbero reimpostare ASP.NET l'autenticazione dei moduli e lo stato di visualizzazione, se l'app dipende da essi. Per evitare la rigenerazione automatica delle chiavi, impostarle manualmente come servizio app impostazioni dell'app.

Connettersi al contenitore

È possibile connettersi al contenitore di 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 sopra di esso, che mostra solo i file nella risorsa di archiviazione condivisa.
  • In un'app con scalabilità orizzontale, 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.
  • Qualsiasi 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 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 dalle 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 di Docker vengono visualizzati nel portale, nella pagina Contenitore Impostazioni dell'app. I log vengono 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 "Scarica" a sinistra del nome della directory. È anche possibile accedere a questa cartella usando un client FTP.

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

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 per https://<app-name>.scm.azurewebsites.net/api/logs/docker visualizzare i metadati per i log Docker. Potrebbero essere visualizzati più file di log elencati e la href proprietà consente di scaricare direttamente il file di log.

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

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 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. 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 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, è consigliabile scambiarla in uno slot di staging, modificare l'impostazione dell'app nello slot di staging e quindi scambiarla di nuovo 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 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 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 ai ping dopo un determinato periodo di tempo, servizio app registra un evento nel log Docker, dicendo che il contenitore non è stato avviato.

Se l'applicazione richiede un uso intensivo delle risorse, il contenitore potrebbe non rispondere al ping HTTP in tempo. Per controllare le azioni quando i ping HTTP hanno esito negativo, impostare l'impostazione dell'app CONTAINER_AVAILABILITY_CHECK_MODE . È possibile impostarlo tramite 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 Descrizione
Repair Riavviare il contenitore dopo tre controlli di disponibilità consecutivi
ReportOnly 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 di 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 standard sshd_config 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. Queste istruzioni copiano i nuovi file, installano il server OpenSSH, impostano le autorizzazioni appropriate e 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! 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.

Altre informazioni sulla risoluzione dei problemi sono disponibili nel blog del servizio app 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.

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 il corretto funzionamento delle app multi-contenitore, ad esempio WordPress, è necessario un archivio permanente. Per abilitarla, la configurazione di Docker Compose deve puntare a una posizione di archiviazione all'esterno del contenitore. Archiviazione percorsi all'interno del contenitore non rendere persistenti 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 dell'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} diversamente da docker

Limitazioni della sintassi

  • "version x.x" deve essere sempre la prima istruzione YAML nel file
  • la sezione ports deve usare numeri 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 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 software personalizzato al servizio app Azure usando un contenitore personalizzato

Esercitazione: App WordPress multi-contenitore

In alternativa, vedere altre risorse: