Risolvere i problemi comuni in Istanze di Azure Container

Questo articolo mostra come risolvere i problemi comuni per la gestione o la distribuzione di contenitori in Istanze di Azure Container. Vedere anche Domande frequenti.

Se è necessario ulteriore supporto, vedere le opzioni disponibili Guida e supporto nel portale di Azure.

Problemi durante la distribuzione del gruppo di contenitori

Convenzioni di denominazione

Quando si definisce la specifica del contenitore, determinati parametri devono essere conformi a limitazioni di denominazione. La tabella seguente riporta i requisiti specifici per le proprietà dei gruppi di contenitori. Per altre informazioni, vedere Convenzioni di denominazione nel Centro architetture di Azure e Regole di denominazione e restrizioni per le risorse di Azure.

Ambito Durata Maiuscole/minuscole Caratteri validi Schema consigliato Esempio
Nome contenitore1 1-63 Minuscole Carattere alfanumerico e trattino in un punto qualsiasi, tranne il primo o l'ultimo carattere <name>-<role>-container<number> web-batch-container1
Porte del contenitore Tra 1 e 65535 Intero Numero intero compreso tra 1 e 65535 <port-number> 443
Etichetta del nome DNS 5-63 Nessuna distinzione tra maiuscole e minuscole Carattere alfanumerico e trattino in un punto qualsiasi, tranne il primo o l'ultimo carattere <name> frontend-site1
Variabile di ambiente 1-63 Nessuna distinzione tra maiuscole e minuscole Carattere alfanumerico e carattere di sottolineatura '_' in un punto qualsiasi, tranne il primo o l'ultimo carattere <name> MY_VARIABLE
Nome del volume 5-63 Minuscole Caratteri alfanumerici e trattini in un punto qualsiasi, tranne il primo o l'ultimo carattere. Non può contenere due trattini consecutivi. <name> batch-output-volume

1Restrizione anche per i nomi dei gruppi di contenitori quando non specificato indipendentemente da istanze del contenitore, ad esempio con distribuzioni di comandi az container create.

Versione del sistema operativo dell'immagine non supportata

Se si specifica un'immagine non supportata da Istanze di Azure Container, viene restituito un errore OsVersionNotSupported. L'errore è simile al seguente, dove {0} è il nome dell'immagine che si è tentato di distribuire:

{
  "error": {
    "code": "OsVersionNotSupported",
    "message": "The OS version of image '{0}' is not supported."
  }
}

Questo errore si verifica più spesso durante la distribuzione di immagini Windows basate sul canale semestrale versione 1709 o 1803, che non sono supportate. Per le immagini Windows supportate in Istanze di Azure Container, vedere Domande frequenti.

Non è possibile eseguire il pull dell'immagine

Se non è inizialmente in grado di eseguire il pull dell'immagine, Istanze di Azure Container ripete il tentativo per un determinato tempo. Se l'operazione di pull dell'immagine continua a non riuscire, Istanze di contenitore di Azure non esegue correttamente la distribuzione e potrebbe essere visualizzato un errore Failed to pull image.

Per risolvere questo problema, eliminare l'istanza di contenitore e ripetere la distribuzione. Assicurarsi che l'immagine esista nel registro e che il nome dell'immagine sia stato digitato correttamente.

Se il pull dell'immagine non può essere eseguito, vengono visualizzati eventi simili al seguente nell'output di az container show:

"events": [
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "Pulling",
    "type": "Normal"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "Failed to pull image \"mcr.microsoft.com/azuredocs/aci-hellowrld\": rpc error: code 2 desc Error: image t/aci-hellowrld:latest not found",
    "name": "Failed",
    "type": "Warning"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:20+00:00",
    "lastTimestamp": "2017-12-21T22:57:16+00:00",
    "message": "Back-off pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "BackOff",
    "type": "Normal"
  }
],

Errore di risorsa non disponibile

A causa del carico variabile delle risorse delle aree in Azure, quando si cerca di distribuire un'istanza di contenitore, potrebbe verificarsi l'errore seguente:

The requested resource with 'x' CPU and 'y.z' GB memory is not available in the location 'example region' at this moment. Please retry with a different resource request or in another location.

Questo errore indica che a causa di un carico elevato nell'area in cui si sta tentando di eseguire la distribuzione, le risorse specificate per il contenitore al momento non possono essere allocate. Usare uno o più dei passaggi seguenti per mitigare il problema.

  • Verificare che le impostazioni di distribuzione del contenitore rientrino nei parametri definiti in Disponibilità a livello di area per Istanze di Azure Container
  • Specificare impostazioni di memoria e CPU inferiori per il contenitore
  • Eseguire la distribuzione in un'area di Azure diversa
  • Eseguire la distribuzione in un secondo momento

Problemi durante il runtime del gruppo di contenitori

Il contenitore ha avuto un riavvio isolato senza input esplicito dell'utente

Esistono due categorie generali per cui un gruppo di contenitori può essere riavviato senza input esplicito dell'utente. In primo luogo, i contenitori potrebbero riscontrare riavvii causati da un arresto anomalo del processo dell'applicazione. Il servizio ACI consiglia di applicare soluzioni di osservabilità come Application Insights SDK, metriche del gruppo di contenitori e log dei gruppi di contenitori per determinare il motivo per cui l'applicazione ha riscontrato problemi. In secondo luogo, i clienti possono riscontrare riavvii avviati dall'infrastruttura ACI a causa di eventi di manutenzione. Per aumentare la disponibilità dell'applicazione, eseguire più gruppi di contenitori dietro un componente in ingresso, ad esempio gateway applicazione o Gestione traffico.

Il contenitore viene continuamente chiuso e riavviato (nessun processo a esecuzione prolungata)

I gruppi di contenitori vengono impostati automaticamente sul criterio di riavvioAlways, in modo che i contenitori nel gruppo di contenitori eseguano sempre il riavvio dopo il completamento dell'esecuzione. Potrebbe essere necessario impostare questa opzione su OnFailure oppure Never se si prevede di eseguire i contenitori basati su attività. Se si specifica OnFailure e si riscontra una situazione di riavvio continuo, potrebbe essere presente un problema con l'applicazione o lo script eseguito nel contenitore.

Durante l'esecuzione di gruppi di contenitori senza processi a esecuzione prolungata, è probabile che si verifichino ripetute uscite e riavvii con le immagini, ad esempio Ubuntu o Alpine. La connessione tramite EXEC non funzionerà in quanto il contenitore non dispone di alcun processo che lo mantiene attivo. Per risolvere questo problema, includere un comando simile all'esempio seguente con la distribuzione del gruppo di contenitori per mantenere il contenitore in esecuzione.

## Deploying a Linux container
az container create -g MyResourceGroup --name myapp --image ubuntu --command-line "tail -f /dev/null"
## Deploying a Windows container
az container create -g myResourceGroup --name mywindowsapp --os-type Windows --image mcr.microsoft.com/windows/servercore:ltsc2019
 --command-line "ping -t localhost"

L'API Istanze di Container e il portale di Azure includono una proprietà restartCount. Per controllare il numero di riavvii di un contenitore, è possibile usare il comando az container show nell'interfaccia della riga di comando di Azure. Nell'output di esempio seguente, troncato per brevità, la proprietà restartCount si trova alla fine dell'output.

...
 "events": [
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:06+00:00",
     "lastTimestamp": "2017-11-13T21:20:06+00:00",
     "message": "Pulling: pulling image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Pulled: Successfully pulled image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Created: Created container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Started: Started container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   }
 ],
 "previousState": null,
 "restartCount": 0
...
}

Nota

La maggior parte delle immagini di contenitore per le distribuzioni di Linux imposta una shell, ad esempio bash, come comando predefinito. Poiché una shell non è di per sé un servizio a esecuzione prolungata, questi contenitori vengono chiusi immediatamente e sono soggetti a un riavvio ciclico quando sono configurati in base al criterio di riavvio predefinito Always.

L'avvio di un contenitore richiede molto tempo

I tre principali fattori che contribuiscono al tempo di avvio di un contenitore in Istanze di Azure Container sono:

Per le immagini di Windows sono necessarie altre considerazioni.

Dimensioni dell'immagine

Se per avviare il contenitore è necessario molto tempo, ma alla fine l'operazione ha esito positivo, esaminare innanzitutto la dimensione dell'immagine del contenitore. Poiché Istanze di Azure Container esegue il pull dell'immagine del contenitore su richiesta, il tempo di avvio indicato è direttamente correlato alla dimensione dell'immagine.

Per visualizzare la dimensione dell'immagine del contenitore, è possibile usare il comando docker images nell'interfaccia della riga di comando di Docker:

docker images
REPOSITORY                                    TAG       IMAGE ID        CREATED          SIZE
mcr.microsoft.com/azuredocs/aci-helloworld    latest    7367f3256b41    15 months ago    67.6MB

Il modo per limitare le dimensioni delle immagini è quello di evitare che l'immagine finale contenga elementi che non sono necessari nel runtime. A tale scopo è possibile eseguire compilazioni in più fasi. Le compilazioni di questo tipo consentono di assicurarsi che l'immagine finale contenga solo gli elementi necessari per l'applicazione, escludendo altro contenuto richiesto in fase di compilazione.

Posizione dell'immagine

Un altro modo per ridurre l'impatto del pull dell'immagine sul tempo di avvio del contenitore è quello di ospitare l'immagine del contenitore in Registro Azure Container nella stessa area in cui si intende distribuire le istanze del contenitore. Ciò consente di ridurre il percorso dell'immagine del contenitore attraverso la rete e quindi di limitare notevolmente il tempo di download.

Immagini memorizzate nella cache

Istanze di Azure Container usa un meccanismo di memorizzazione nella cache per velocizzare il tempo di avvio dei contenitori per le immagini basate su immagini di base di Windows comuni, tra cui nanoserver:1809, servercore:ltsc2019 e servercore:1809. Anche le immagini Linux di uso comune, ad esempio ubuntu:1604 e alpine:3.6, vengono memorizzate nella cache. Per le immagini Windows e Linux, evitare di usare il tag latest. Per indicazioni, vedere le procedure consigliate per i tag di immagine del Registro Container. Per un elenco aggiornato di immagini e tag memorizzati nella cache, usare l'API Elenca immagini memorizzate nella cache.

Nota

L'uso di immagini basate su Windows Server 2019 in istanze di Azure Container è disponibile in anteprima.

La rete diventa disponibile lentamente per i contenitori Windows

Al momento della creazione iniziale, è possibile che per i contenitori Windows non sia presente la connettività in ingresso o in uscita per un intervallo massimo di 30 secondi (o più lungo in alcuni rari casi). Se per l'applicazione contenitore è necessaria una connessione Internet, aggiungere un ritardo e ripetere la logica per consentire di stabilire la connettività Internet in un intervallo di 30 secondi. Dopo l'installazione iniziale, le funzionalità di rete per i contenitori dovrebbero riprendere in modo appropriato.

Non è possibile connettersi all'API Docker sottostante o eseguire contenitori con privilegi

Istanze di Azure Container non espone l'accesso diretto all'infrastruttura sottostante che ospita gruppi di contenitori. Ciò include l'accesso al runtime del contenitore, alla tecnologia di orchestrazione e all'esecuzione di operazioni sui contenitori con privilegi. Per informazioni sulle operazioni supportate da ACI, vedere la documentazione di riferimento REST. Se mancano informazioni, inviare una richiesta ai forum di feedback ACI.

Gli indirizzi IP del gruppo contenitore potrebbero non essere accessibili a causa di porte non corrispondenti

Istanze di Azure Container non supporta ancora il mapping delle porte, ad esempio con la normale configurazione docker. Se l'indirizzo IP di un gruppo di contenitori risulta non accessibile quando si ritiene che dovrebbe esserlo, assicurarsi di aver configurato l'immagine del contenitore per l'ascolto sulle stesse porte esposte nel gruppo di contenitori con la proprietà ports.

Per verificare che Istanze di Azure Container sia in ascolto sulla porta configurata nell'immagine del contenitore, testare una distribuzione dell'immagine aci-helloworld che espone la porta. Eseguire anche l'app aci-helloworld in modo che sia in ascolto sulla porta. aci-helloworld accetta una variabile PORT di ambiente facoltativa per eseguire l'override della porta predefinita 80 su cui è in ascolto. Ad esempio, per testare la porta 9000, impostare la variabile di ambiente quando si crea il gruppo di contenitori:

  1. Configurare il gruppo di contenitori per esporre la porta 9000 e passare il numero di porta come valore della variabile di ambiente. L'esempio è formattato per la shell Bash. Se si preferisce un'altra shell, ad esempio PowerShell o il prompt dei comandi, è necessario modificare adeguatamente l'assegnazione delle variabili.

    az container create --resource-group myResourceGroup \
    --name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \
    --ip-address Public --ports 9000 \
    --environment-variables 'PORT'='9000'
    
  2. Trovare l'indirizzo IP del gruppo di contenitori nell'output del comando di az container create. Cercare il valore di ip.

  3. Al termine del provisioning del contenitore, passare all'indirizzo IP e alla porta dell'applicazione contenitore nel browser, ad esempio: 192.0.2.0:9000.

    Verrà visualizzato il messaggio "Ti diamo il benvenuto in Istanze di Azure Container!" dall'app Web.

  4. Al termine dell'operazione con il contenitore, rimuoverlo usando il comando az container delete:

    az container delete --resource-group myResourceGroup --name mycontainer
    

Problemi durante le distribuzioni di gruppi di contenitori riservati

Errori dei criteri durante l'uso di criteri CCE personalizzati

I criteri CCE personalizzati devono essere generati dall'estensione confcom dell'interfaccia della riga di comando di Azure. Prima di generare i criteri, assicurarsi che tutte le proprietà specificate nel modello di Resource Manager siano valide e corrispondano a ciò che si prevede venga rappresentato in un criterio di computing riservato. Alcune proprietà da convalidare includono l'immagine del contenitore, le variabili di ambiente, i montaggi del volume e i comandi del contenitore.

Hash mancante dai criteri

L'estensione confcom dell'interfaccia della riga di comando di Azure usa immagini memorizzate nella cache nel computer locale che potrebbero non corrispondere a quelle disponibili in remoto, che possono causare una mancata corrispondenza del livello quando i criteri vengono convalidati. Assicurarsi di rimuovere le vecchie immagini ed eseguire il pull delle immagini del contenitore più recenti nell'ambiente locale. Dopo aver verificato di avere la versione più recente di SHA, è necessario rigenerare i criteri CCE.

Processo/contenitore terminato con codice di uscita: 139

Questo codice di uscita si verifica a causa di limitazioni con l'immagine di base Ubuntu versione 22.04. Per risolvere il problema, è consigliabile usare un'immagine di base diversa.

Passaggi successivi

Informazioni su come recuperare log ed eventi dei contenitori per facilitare il debug dei contenitori.