Risolvere i problemi comuni in Istanze di Azure Container

Questo articolo illustra come risolvere i problemi comuni relativi alla gestione o alla 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, alcuni parametri richiedono l'adesione alle restrizioni di denominazione. La tabella seguente illustra i requisiti specifici per le proprietà del gruppo di contenitori. Per altre informazioni, vedere Convenzioni di denominazione nel Centro architetture di Azure e regole di denominazione e restrizioni per Azure risorse.

¹Restrizione applicata anche ai nomi dei gruppi di contenitori quando non sono specificati indipendentemente dalle istanze del contenitore, ad esempio con distribuzioni tramite comando az container create.

Versione del sistema operativo dell'immagine non supportata

Se si specifica un'immagine che Istanze di Azure Container non supporta, viene restituito un OsVersionNotSupported errore. 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.

Impossibile eseguire il pull dell'immagine

Se inizialmente Istanze di Azure Container non riesce a recuperare l'immagine, ritenta per un certo periodo di tempo. Se l'operazione di download dell'immagine continua a non riuscire, la distribuzione in ACI alla fine non riesce e potresti visualizzare un errore Failed to pull image.

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

Se l'immagine non può essere estratta, nell'output di az container show vengono visualizzati eventi come i seguenti:

"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 risorsa non disponibile

A causa di un carico di risorse a livello di area variabile in Azure, è possibile che venga visualizzato l'errore seguente quando si tenta di distribuire un'istanza del contenitore:

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 tenta di distribuire, le risorse specificate per il contenitore non possono essere allocate in quel momento. Usare uno o più dei passaggi di mitigazione seguenti per risolvere il problema.

• Verificare che le impostazioni di distribuzione del contenitore siano incluse nei parametri definiti in Disponibilità dell'area per Istanze di Azure Container
• Specificare le impostazioni di CPU e memoria inferiori per il contenitore
• Eseguire la distribuzione in un'area Azure diversa
• Distribuire 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. Innanzitutto, i container possono subire riavvii causati dall'arresto anomalo di un 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, esegui più gruppi di container dietro un componente di ingresso come un Application Gateway o Traffic Manager.

Il contenitore si arresta e si riavvia continuamente (nessun processo di lunga durata)

Per impostazione predefinita, i gruppi di contenitori hanno come criterio di riavvioAlways, quindi i contenitori nel gruppo vengono sempre riavviati dopo aver completato l'esecuzione. Potrebbe essere necessario modificarlo in OnFailure o Never se si intende eseguire container basati su attività. Se si specifica OnFailure e si verificano ancora riavvii continui, potrebbe verificarsi un problema con l'applicazione o lo script eseguito nel contenitore.

Quando si eseguono gruppi di contenitori senza processi a esecuzione prolungata, è possibile che si verifichino uscite ripetute e riavvii con immagini come Ubuntu o Alpine. La connessione tramite EXEC non funzionerà perché il contenitore non ha alcun processo che lo mantiene attivo. Per risolvere questo problema, includi un comando di avvio come nell'esempio seguente nella 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 restartCount proprietà . Per controllare il numero di riavvii per un contenitore, è possibile usare il comando az container show nella interfaccia della riga di comando di Azure. Nell'output di esempio seguente, troncato per brevità, viene visualizzata la restartCount proprietà 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
...
}

L'avvio del contenitore richiede molto tempo

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

• Dimensioni immagine
• Posizione dell'immagine
• Immagini memorizzate nella cache

Le immagini Windows richiedono ulteriori considerazioni.

Dimensioni dell'immagine

Se l'avvio del contenitore richiede molto tempo, ma alla fine ha esito positivo, iniziare esaminando le dimensioni dell'immagine del contenitore. Poiché Istanze di Azure Container esegue il pull dell'immagine del contenitore su richiesta, l'ora di avvio visualizzata è direttamente correlata alle dimensioni.

È possibile visualizzare le dimensioni dell'immagine del contenitore usando il docker images comando 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

La chiave per mantenere le dimensioni delle immagini di piccole dimensioni garantisce che l'immagine finale non contenga elementi non necessari in fase di esecuzione. Un modo per eseguire questa operazione consiste nella compilazione a più fasi. Le compilazioni in più fasi semplificano la verifica che l'immagine finale contenga solo gli artefatti necessari per l'applicazione e non i contenuti aggiuntivi necessari in fase di compilazione.

Posizione dell'immagine

Un altro modo per ridurre l'impatto del pull dell'immagine sul tempo di avvio del contenitore consiste nell'ospitare l'immagine del contenitore in Registro Azure Container nella stessa area in cui si intende distribuire istanze di contenitore. In questo modo viene abbreviato il percorso di rete necessario all'immagine del contenitore, riducendo significativamente 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 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 entrambe le immagini Windows e Linux, evitare di usare il latest tag . Per indicazioni, consulta le procedure consigliate per i tag delle immagini di Container Registry. Per un elenco aggiornato delle immagini e dei tag memorizzati nella cache, utilizzare l'API List Cached Images.

I contenitori Windows rallentano la disponibilità della rete

Alla creazione iniziale, Windows contenitori potrebbero non avere connettività in ingresso o in uscita per un massimo di 30 secondi (o più, in rari casi). Se l'applicazione contenitore richiede una connessione Internet, aggiungere la logica di ritardo e ripetizione dei tentativi per consentire 30 secondi di stabilire la connettività Internet. Dopo la configurazione iniziale, la rete dei contenitori deve essere ripresa 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 visualizzare le operazioni supportate da ACI, vedere la documentazione di riferimento REST. Se manca qualcosa, inviare una richiesta nei forum di feedback di ACI.

L'indirizzo IP del gruppo di contenitori potrebbe non essere accessibile a causa di porte non corrispondenti

Istanze di Azure Container non supporta ancora il mapping delle porte, ad esempio con la normale configurazione di Docker. Se si trova che l'indirizzo IP di un gruppo di contenitori non è accessibile quando si ritiene che sia necessario, assicurarsi di configurare l'immagine del contenitore per ascoltare le stesse porte esposte nel gruppo di contenitori con la ports proprietà .

Se si vuole verificare che Istanze di Azure Container possa ascoltare 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 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. Trova l'indirizzo IP del gruppo di contenitori nell'output del comando az container create. Cerca 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 "Benvenuto in Istanze di Azure Container!" visualizzato dall'app Web.

4. Al termine dell'operazione con il 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 interfaccia della riga di comando di Azure confcom. Prima di generare il criterio, assicurarsi che tutte le proprietà specificate nel modello ARM siano valide e corrispondano a quanto previsto che sia 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 nel criterio

L'estensione confcom di interfaccia della riga di comando di Azure usa immagini memorizzate nella cache nel computer locale che potrebbero non corrispondere a quelle disponibili in remoto, con conseguente mancata corrispondenza dei layer quando il criterio viene convalidato. Assicurarsi di rimuovere tutte le immagini obsolete e di scaricare le immagini del container più recenti nel proprio 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.

Codici di uscita del contenitore

Quando un contenitore in Istanze di Azure Container termina, la piattaforma segnala un codice di uscita che indica il motivo per cui il processo è stato arrestato. È possibile visualizzare i codici di uscita controllando gli eventi del contenitore usando il comando az container show o nel portale di Azure in Eventi contenitori>.

La tabella seguente descrive i codici di uscita comuni che possono verificarsi:

Terminazioni avviate dalla piattaforma (codici di uscita 7147 e 7148)

I codici di uscita 7147 e 7148 sono codici di uscita della piattaforma provenienti dall'infrastruttura sottostante. Questi codici potrebbero non essere sempre visualizzati direttamente nei dettagli del contenitore, ma corrispondono ai messaggi "Killing container (platform initiated)" visualizzati negli eventi del contenitore. Le cause comuni delle interruzioni avviate dalla piattaforma includono:

• Manutenzione dell'infrastruttura: la piattaforma ha rilocato il contenitore come parte della manutenzione di routine o del bilanciamento del carico.
• Limitazioni delle risorse: l'host sottostante ha dovuto recuperare risorse.
• Aggiornamenti della piattaforma: l'infrastruttura è stata aggiornata e richiede il riavvio del contenitore.

Queste terminazioni sono previste in un ambiente cloud. Per aumentare la disponibilità dell'applicazione, esegui più gruppi di container dietro un componente di ingresso come un Application Gateway o Traffic Manager.

Per altre informazioni sulle terminazioni avviate dalla piattaforma, vedere Diagnosticare gli errori comuni del pacchetto di codice tramite Service Fabric.

Passaggi successivi

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