Résoudre les problèmes courants dans Azure Container Instances

Article
10/15/2024

Cet article explique comment résoudre les problèmes courants de gestion ou de déploiement de conteneurs dans Azure Container Instances. Consultez également le Forum aux questions.

Si vous avez besoin d’une assistance supplémentaire, consultez les options d’Aide et support sur le Portail Azure.

Problèmes lors du déploiement d’un groupe de conteneurs

Conventions d’affectation de noms

Lorsque vous définissez la spécification du conteneur, certains paramètres requièrent le respect des restrictions en matière d’affectation de noms. Le tableau suivant présente les exigences spécifiques relatives aux propriétés des groupes de conteneurs. Pour plus d’informations, consultez Conventions d’affectation de noms dans le Centre des architectures Azure, et Règles de nommage et restrictions pour les ressources Azure.

Étendue	Longueur	Casse	Caractères valides	Modèle suggéré	Exemple
Nom du conteneur¹	1-63	Minuscules	Caractères alphanumériques et traits d’union n’importe où sauf en première ou dernière position	`<name>-<role>-container<number>`	`web-batch-container1`
Ports du conteneur	Entre 1 et 65 535	Integer	Entier compris entre 1 et 65 535	`<port-number>`	`443`
Étiquette du nom DNS	5 à 63	Insensible à la casse	Caractères alphanumériques et traits d’union n’importe où sauf en première ou dernière position	`<name>`	`frontend-site1`
Variable d’environnement	1-63	Insensible à la casse	Caractères alphanumériques et trait de soulignement (_) n’importe où sauf en première ou dernière position	`<name>`	`MY_VARIABLE`
Nom du volume	5 à 63	Minuscules	Caractères alphanumériques et traits d’union n’importe où sauf en première ou dernière position. Ne peut pas contenir deux traits d’union consécutifs.	`<name>`	`batch-output-volume`

¹Restriction également pour les noms de groupes de conteneurs quand ils ne sont pas spécifiés indépendamment des instances de conteneur, par exemple, avec des déploiements de commande az container create.

La version du système d’exploitation de l’image n’est pas prise en charge

Si l’image spécifiée n’est pas prise en charge par Azure Container Instances, une erreur OsVersionNotSupported est renvoyée. L’erreur est semblable à ce qui suit, où {0} est le nom de l’image que vous avez tentée de déployer :

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

Cette erreur se produit généralement lors du déploiement d’images Windows basées sur les versions 1709 ou 1803 du canal semi-annuel, qui ne sont pas prises en charge. Pour les images Windows prises en charge dans Azure Container Instances, consultez le Forum aux questions.

Impossible d’extraire l’image

Si Azure Container Instances ne parvient pas à extraire votre image initialement, il réessaie pendant une certaine période, sans succès. Si l’opération d’extraction image continue à échouer, le déploiement ACI risque d’échouer, et vous verrez une erreur Failed to pull image.

Pour résoudre ce problème, supprimez l’instance de conteneur et réessayez votre déploiement. Vérifiez que l’image existe dans le Registre, et que vous avez correctement tapé le nom de l’image.

Des événements tels que les suivants sont alors affichés dans la sortie de 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"
  }
],

Erreur : ressource non disponible

En raison d’une charge de ressources régionales variable dans Azure, vous pouvez recevoir l’erreur suivante quand vous tentez de déployer une instance de conteneur :

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.

Cette erreur indique qu’en raison d’une charge importante dans la région dans laquelle vous tentez de déployer, les ressources spécifiées pour votre conteneur ne peuvent pas être allouées à ce moment-là. Utilisez une ou plusieurs des étapes d’atténuation suivantes pour vous aider à résoudre votre problème.

Vérifier que les paramètres de votre déploiement de conteneur correspondent à ceux définis dans Disponibilité des régions pour Azure Container Instances
Spécifier des paramètres de processeur et de mémoire inférieurs pour le conteneur
Déployer sur une autre région Azure
Déployer plus tard

Problèmes lors de l’exécution du runtime de groupe de conteneurs

Le conteneur redémarrait de manière isolée sans entrée utilisateur explicite

Deux catégories générales expliquent pourquoi un groupe de conteneurs peut redémarrer sans entrée utilisateur explicite. Tout d’abord, les conteneurs peuvent rencontrer des redémarrages provoqués par un incident de processus d’application. Le service ACI recommande d’exploiter des solutions d’observabilité telles que le Kit de développement logiciel (SDK) Application Insights, les métriques de groupe de conteneurs et les journaux de groupe de conteneurs pour déterminer la raison pour laquelle l’application rencontre des problèmes. Deuxièmement, les clients peuvent rencontrer des redémarrages initiés par l’infrastructure ACI en raison d’événements de maintenance. Pour augmenter la disponibilité de votre application, exécutez plusieurs groupes de conteneurs derrière un composant d’entrée tel que Application Gateway ou Traffic Manager.

Le conteneur s’arrête et redémarre en permanence (pas de processus au long cours)

Les groupes de conteneurs sont définis par défaut sur la stratégie de redémarrageToujours, de sorte que les conteneurs du groupe de conteneurs redémarrent toujours après avoir été exécutés. Vous devrez peut-être définir ce paramètre sur OnFailure ou Jamais si vous envisagez d’exécuter des conteneurs basés sur des tâches. Si vous spécifiez OnFailure et constatez encore des redémarrages continus, il peut y avoir un problème avec l’application ou le script exécutés dans votre conteneur.

Lorsque vous exécutez des groupes de conteneurs sans processus au long cours, vous pouvez observer de multiples arrêts et redémarrages avec des images telles que Ubuntu ou Alpine. La connexion via EXEC ne va pas fonctionner, car le conteneur n’a aucun processus pour le maintenir actif. Pour résoudre ce problème, incluez une commande de démarrage telle que l’exemple suivant dans votre déploiement de groupe de conteneurs afin de maintenir le conteneur en cours d’exécution.

## 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 Container Instances et le Portail Azure incluent une propriété restartCount. Pour vérifier le nombre de redémarrages d’un conteneur, vous pouvez utiliser la commande az container show dans Azure CLI. Dans l’exemple suivant, que nous avons raccourci par souci de concision, vous voyez la propriété restartCount à la fin de la sortie.

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

Remarque

La plupart des images conteneur pour les distributions Linux définissent un interpréteur de commandes, tel que bash, comme commande par défaut. Un interpréteur de commandes n’étant pas en soi un service de longue durée, ces conteneurs quittent la procédure immédiatement et entrent dans une boucle de redémarrage lorsqu’ils sont configurés avec la stratégie de redémarrage par défaut (Always).

Le démarrage du conteneur prend beaucoup de temps

Les trois principaux facteurs qui contribuent à l’heure de démarrage dans Azure Container Instances sont :

Taille de l'image
Emplacement de l’image
Images mises en cache

Les images Windows ont des considérations supplémentaires.

Taille de l'image

Si le démarrage de votre conteneur prend beaucoup de temps, commencez par examiner la taille de votre image conteneur. Étant donné qu’Azure Container Instances extrait l’image conteneur à la demande, le temps de démarrage est directement lié à la taille de cette image.

Vous pouvez afficher la taille de l’image de votre conteneur à l’aide de la commande docker images dans l’interface CLI Docker :

docker images

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

Pour que l’image conserve une petite taille, faites en sorte que l’image finale ne contienne aucun élément qui soit superflu au moment de l’exécution. Pour ce faire, vous pouvez utiliser des builds à plusieurs étapes. Grâce aux builds à plusieurs étapes, vous pouvez facilement faire en sorte que l’image finale ne contienne que les artefacts nécessaires à votre application, à l’exclusion de tout contenu supplémentaire qui était requis au moment de la génération.

Emplacement de l’image

Il existe une autre façon de réduire l’impact de l’extraction de l’image sur le temps de démarrage de votre conteneur. Elle consiste à héberger l’image du conteneur dans Azure Container Registry dans la région où vous envisagez de déployer Azure Container Instances. Cette opération raccourcit le chemin réseau que l’image conteneur doit parcourir, réduisant considérablement le temps de téléchargement.

Images mises en cache

Azure Container Instances utilise un mécanisme de mise en cache afin d'accélérer le démarrage des conteneurs pour les images générées à partir d'images Windows courantes, notamment nanoserver:1809, servercore:ltsc2019 et servercore:1809. Les images Linux couramment utilisées, telles que ubuntu:1604 et alpine:3.6, sont également mises en cache. Pour les images Windows et Linux, évitez d’utiliser la balise latest. Pour obtenir de l’aide, consultez les meilleures pratiques relatives aux balises d’image de Container Registry. Pour obtenir une liste à jour des images et balises mises en cache, utilisez l'API Liste des images mises en cache.

Notes

L’utilisation d’images basées sur Windows Server 2019 dans Azure Container Instances est disponible en version préliminaire.

Disponibilité lente du réseau des conteneurs Windows

Lors de la création initiale, les conteneurs Windows peuvent n’avoir aucune connectivité entrante ou sortante pendant 30 secondes (ou plus longtemps dans de rares cas). Si votre application conteneur requiert une connexion Internet, ajoutez un retard et réessayez la logique afin de laisser 30 secondes pour établir la connectivité Interne. Après l’installation initiale, la mise en réseau de conteneur devrait reprendre correctement.

Ne peut pas se connecter à l’API Docker sous-jacent ou exécuter des conteneurs privilégiés

Azure Container Instances n’expose pas un accès direct à l’infrastructure sous-jacente qui héberge les groupes de conteneurs. Cela inclut l’accès au runtime de conteneur, à la technologie d’orchestration et à l’exécution d’opérations de conteneur avec privilèges. Pour connaître les opérations prises en charge par ACI, consultez la documentation de référence REST. S’il manque des informations, envoyez une requête sur le Forum Internet de commentaires ACI.

Il se peut que l’adresse IP d’un groupe de conteneurs soit inaccessible en raison d’une discordance de ports

Azure Container Instances ne prend pas encore en charge le mappage de ports, contrairement à une configuration Docker classique. Si vous constatez que l’adresses IP d’un groupe de conteneurs n’est pas accessible alors que vous pensez qu’elle devrait l’être, vérifiez que vous avez configuré votre image conteneur pour écouter les mêmes ports que ceux que vous exposez dans votre groupe de conteneurs avec la propriété ports.

Si vous souhaitez vérifier qu’Azure Container Instances peut écouter le port que vous avez configuré dans votre image conteneur, testez un déploiement de l’image aci-helloworld qui expose le port. Exécutez également l’application aci-helloworld afin qu’elle écoute le port. aci-helloworld accepte une variable d’environnement facultative PORT pour remplacer le port 80 écouté par défaut. Par exemple, pour tester le port 9000, définissez la variable d’environnement lors de la création du groupe de conteneurs :

Configurez le groupe de conteneurs pour exposer le port 9000 et transmettez le numéro de port comme valeur de la variable d’environnement. L’exemple est mis en forme pour l’interpréteur de commandes Bash. Si vous préférez un autre interpréteur de commandes, PowerShell ou l’invite de commande, vous devez ajuster les variables en conséquence.
```
az container create --resource-group myResourceGroup \
--name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \
--ip-address Public --ports 9000 \
--environment-variables 'PORT'='9000'
```
Recherchez l’adresse IP du groupe de conteneurs dans la sortie de commande de az container create. Recherchez la valeur de ip.
Une fois le conteneur correctement provisionné, accédez à l’adresse IP et au port de l’application conteneur dans votre navigateur, par exemple 192.0.2.0:9000.

Vous devriez voir le message « Bienvenue dans Azure Container Instances ! » s’afficher dans l’application web.
Lorsque vous avez fini d’utiliser le conteneur, vous pouvez le supprimer à l’aide de la commande az container delete :
```
az container delete --resource-group myResourceGroup --name mycontainer
```

Problèmes lors des déploiements de groupes de conteneurs confidentiels

Erreurs de stratégie lors de l’utilisation d’une stratégie CCE personnalisée

Les stratégies CCE personnalisées doivent être générées avec l’extension confcom Azure CLI. Avant de générer la stratégie, assurez-vous que toutes les propriétés spécifiées dans votre modèle ARM sont valides et correspondent à ce que vous attendez d’être représentés dans une stratégie d’informatique confidentielle. Certaines propriétés à valider incluent l’image conteneur, les variables d’environnement, les montages de volumes et les commandes de conteneur.

Hachage manquant dans la stratégie

L’extension confcom Azure CLI utilise des images mises en cache sur votre ordinateur local qui peuvent ne pas correspondre à celles disponibles à distance, ce qui peut entraîner une incompatibilité de couche lors de la validation de la stratégie. Veillez à supprimer les anciennes images et à extraire les dernières images conteneur dans votre environnement local. Une fois que vous êtes sûr de disposer de la dernière SHA, vous devez régénérer la stratégie CCE.

Processus/conteneur arrêté avec le code de sortie : 139

Ce code de sortie se produit en raison des limitations de l’image de base Ubuntu version 22.04. Il est recommandé d’utiliser une image de base différente pour résoudre ce problème.

Étapes suivantes

Apprenez à récupérer les journaux d'activité et les événements de conteneur pour vous aider à déboguer vos conteneurs.

Partage via