Azure Container Instances

Azure Container Instances (ACI) constitue le moyen le plus rapide d’exécuter une charge de travail conteneurisée dans Azure sans gérer de serveurs ni d’orchestrateurs. Vous fournissez une image de conteneur, puis Azure l’exécute en quelques secondes sur une infrastructure mutualisée entre plusieurs clients. ACI convient particulièrement aux tâches de courte durée, aux traitements par lots, aux agents de compilation et aux charges de travail déclenchées par des événements, pour lesquelles le déploiement d’un cluster Kubernetes complet représenterait une surcharge excessive.

Lancez un conteneur ACI à l’aide d’une seule commande az container create. Indiquez l’image, le groupe de ressources, le processeur et la mémoire. ACI extrait l’image, alloue les ressources et démarre le conteneur, généralement en 5 à 10 secondes. Chaque instance de conteneur reçoit un nom de domaine complet (FQDN) unique si vous lui attribuez un libellé de nom DNS, ce qui la rend immédiatement accessible depuis Internet.

Transmettez la configuration aux conteneurs ACI à l’aide de variables d’environnement indiquées lors de la création. Pour les valeurs sensibles, telles que les clés d’API ou les mots de passe, utilisez des variables d’environnement sécurisées : elles ne sont plus affichées dans le portail Azure ni dans la sortie de la CLI après le déploiement, ce qui évite leur divulgation accidentelle dans les journaux ou les pistes d’audit. Les valeurs sécurisées restent accessibles à l’intérieur du conteneur au moment de l’exécution, comme des variables d’environnement ordinaires.

ACI facture à la seconde, en fonction des cœurs de processeur et de la mémoire en GB que vous allouez, sans durée minimale de facturation. Vous payez uniquement pendant l’exécution du conteneur : dès qu’il s’arrête, la facturation s’arrête. ACI est ainsi particulièrement économique pour les charges de travail de courte durée. Vous pouvez allouer de 0,1 à 4 cœurs de processeur et de 0,1 à 16 GB de mémoire par groupe de conteneurs, selon les combinaisons prises en charge.

ACI prend en charge trois stratégies de redémarrage qui contrôlent le comportement du conteneur après sa sortie. Always (valeur par défaut) redémarre le conteneur chaque fois qu’il s’arrête, ce qui convient aux services de longue durée. Never exécute le conteneur une seule fois et le laisse dans un état arrêté, ce qui est idéal pour les traitements par lots. OnFailure redémarre le conteneur uniquement lorsque son code de sortie est différent de zéro, ce qui est utile pour les mécanismes de nouvelle tentative en cas d’erreur.

Un groupe de conteneurs est un ensemble de conteneurs qui partagent un cycle de vie, un réseau et un stockage, à l’image d’un Pod Kubernetes. Les conteneurs d’un même groupe partagent une adresse IP locale et un espace de noms de ports, ce qui leur permet de communiquer via localhost. Un schéma courant consiste à réunir un conteneur d’application principal et un conteneur auxiliaire, par exemple un agent de journalisation ou un proxy, dans le même groupe défini à l’aide d’un modèle YAML ou ARM.

Par défaut, les conteneurs ACI sont sans état : les données écrites dans le système de fichiers du conteneur sont perdues lorsque celui-ci redémarre. Montez un partage Azure Files en tant que volume pour conserver les données lors des redémarrages du conteneur ou les partager entre plusieurs conteneurs du même groupe. Indiquez le nom du compte de stockage, sa clé et le nom du partage de fichiers lors de la création de l’instance de conteneur.

ACI prend en charge les instances de conteneurs avec GPU (K80, V100) pour l’inférence en ML, le traitement vidéo et les charges de travail de calcul scientifique. Les instances avec GPU sont disponibles dans certaines régions et nécessitent des conteneurs Linux. Elles sont facturées par GPU et par seconde, ce qui les rend économiques pour les scénarios d’inférence ponctuelle où vous démarrez un conteneur avec GPU, exécutez le modèle, puis le supprimez immédiatement, à un coût bien inférieur à celui d’une VM avec GPU dédiée fonctionnant 24 h/24 et 7 j/7.

Déployez les groupes de conteneurs ACI dans un sous-réseau dédié au sein d’un VNet afin de leur attribuer des adresses IP privées et de leur permettre d’accéder à d’autres ressources connectées au VNet (bases de données, VMs) sans les exposer à Internet. ACI intégré à un VNet nécessite un sous-réseau dédié et délégué (délégué à Microsoft.ContainerInstance/containerGroups) et ne prend pas en charge l’attribution d’une adresse IP publique.

ACI s’intègre à AKS en tant que nœud virtuel grâce au projet open source Virtual Kubelet. Lorsqu’un cluster AKS connaît une demande ponctuelle qui dépasse la capacité de ses nœuds VM, Kubernetes peut planifier des Pods sur un nœud ACI virtuel, ce qui démarre de véritables instances de conteneurs ACI. Cette approche fournit une capacité d’augmentation instantanée illimitée sans préprovisionner de nœuds VM supplémentaires, et vous ne payez le calcul ACI que pendant la période de forte demande.

Choisissez ACI pour les tâches de courte durée, les traitements par lots, les agents de compilation CI et les conteneurs ponctuels lorsqu’il est inutile d’ajouter la surcharge de Kubernetes. Choisissez AKS pour les microservices multconteneurs de longue durée nécessitant la découverte de services, des contrôles d’intégrité, des mises à jour progressives et la mise en réseau d’un cluster. Choisissez App Service si vous souhaitez bénéficier des fonctionnalités pratiques d’une plateforme en tant que service (emplacements de déploiement, certificats managés, authentification intégrée) sans gérer vous-même le réseau des conteneurs.

Vérifiez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) abordés dans cette leçon.

Dans cette leçon, vous avez appris que Azure Container Instances exécutent des conteneurs en quelques secondes sans gestion de serveurs et sont facturées à la seconde pour le processeur et la mémoire, que les groupes de conteneurs permettent à plusieurs conteneurs de partager le réseau et le stockage comme dans un Pod Kubernetes, et que les stratégies de redémarrage (Always, Never, OnFailure) contrôlent le cycle de vie du conteneur après sa sortie. Nous allons maintenant découvrir les concepts Kubernetes pour Azure.