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 della Guida e del supporto disponibili 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. Nella tabella seguente sono disponibili 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.

Scope Length Maiuscole/minuscole Caratteri validi Schema consigliato Esempio
Nome contenitore1 1-63 Lettere 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 Integer Numero intero compreso tra 1 e 65535 <port-number> 443
Etichetta del nome DNS 5-63 Non fa 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 Non fa 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 Lettere minuscole Caratteri alfanumerici e trattini ovunque eccetto il primo o l'ultimo carattere. Non può contenere due trattini consecutivi. <name> batch-output-volume

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

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 su Semi-Annual Channel release 1709 o 1803, che non sono supportate. Per le immagini di Windows supportate in Istanze di Azure Container, vedere Domande frequenti.

Non è possibile eseguire il pull dell'immagine

Se Istanze di Azure Container inizialmente non è in grado di eseguire il pull dell'immagine, viene eseguito un nuovo tentativo per il 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. Verificare 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 cercando di eseguire la distribuzione, le risorse specificate per il contenitore non possono essere al momento 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 l'input esplicito dell'utente. Prima di tutto, 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 del gruppo di contenitori per determinare il motivo per cui l'applicazione ha riscontrato problemi. In secondo luogo, i clienti potrebbero 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 un 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 start simile al 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 portale di Azure includono una restartCount proprietà . 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 è visualizzata 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 fattori principali che contribuiscono al tempo di avvio del contenitore in Istanze di Azure Container sono:

Per le immagini 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 migliore per limitare le dimensioni delle immagini è quello di evitare che l'immagine finale contenga dati che non sono necessari in fase di esecuzione. 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:ltsc2019e servercore:1809. Anche le immagini Linux di uso comune, ad ubuntu:1604 esempio e alpine:3.6 , vengono memorizzate nella cache. Per le immagini Windows e Linux, evitare di usare il latest tag . Per indicazioni, vedere Le procedure consigliate per i tag 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 i gruppi di contenitori. Ciò include l'accesso al runtime del contenitore, alla tecnologia di orchestrazione e all'esecuzione di operazioni del contenitore con privilegi. Per visualizzare le operazioni supportate da ACI, controllare la documentazione di riferimento REST. Se mancano informazioni, inviare una richiesta al forum di commenti e suggerimenti per Istanze di contenitore di Azure.

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 configurazione docker regolare. Se si trova l'indirizzo IP di un gruppo di contenitori non è accessibile quando si ritiene che sia necessario, assicurarsi di aver configurato l'immagine del contenitore per ascoltare le stesse porte esposte nel gruppo di contenitori con la ports proprietà .

Se si vuole confermare che Istanze di Azure Container può essere 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 di ambiente facoltativa per eseguire l'override PORT della porta predefinita 80 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 viene formattato per la shell Bash. Se si preferisce un'altra shell, ad esempio PowerShell o Prompt dei comandi, è necessario modificare di conseguenza 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. Dopo il 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 "Benvenuto in Istanze di Azure Container!" visualizzato dall'app Web.

  4. Al termine del contenitore, rimuoverlo usando il az container delete comando:

    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 il criterio, assicurarsi che tutte le proprietà specificate nel modello di Resource Manager siano valide e corrispondano a ciò che si prevede di essere rappresentato in un criterio di calcolo 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 userà 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 il criterio viene convalidato. Assicurarsi di rimuovere le immagini precedenti e di eseguire il pull delle immagini del contenitore più recenti nell'ambiente locale. Dopo aver verificato 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. La raccomandazione consiste nell'usare un'immagine di base diversa per risolvere questo problema.

Passaggi successivi

Informazioni su come recuperare i log e gli eventi dei contenitori per eseguire il debug dei contenitori.