Configurare un contenitore personalizzato per il 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. Per i contenitori sidecar (anteprima), vedere Esercitazione: Configurare un contenitore sidecar per un contenitore personalizzato nel Servizio app di Azure (anteprima).

Immagini padre supportate

Per l'immagine Windows personalizzata, è necessario scegliere l'immagine padre (di base) corretta 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 app .NET Core, usare un'immagine padre basata sulla versione Semi-Annual Servicing Channel (SAC) di Windows Server 2019 Nano.

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

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.

È 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 è 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:

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

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:

• Azure portal
• Kudu
• API Kudu
• Monitoraggio di Azure

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.

È 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}

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:

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:

   • Debian
   • Alpine

   #!/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:

   • Debian
   • Alpine

   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
• Limiti dell'anteprima
• Opzioni di Docker Compose

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

• Comando
• entrypoint
• dell'ambiente di
• image
• ports
• restart
• services
• volumes (il mapping ad Archiviazione di Azure non è supportato)

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

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.