Instances de conteneur - FAQ

Questions générales

Pourquoi utiliser OCI Container Instances plutôt qu'Oracle Container Engine for Kubernetes (OKE) ?

Container Instances est idéal pour exploiter des conteneurs isolés qui ne nécessitent pas de plate-forme d'orchestration de conteneurs telle que Kubernetes. Cette solution est adaptée aux API, aux applications Web, aux tâches CI/CD, aux tâches d'automatisation, au traitement des données/médias, aux environnements DevTest et à d'autres cas d'utilisation. Cependant, elle ne remplace pas les plateformes d'orchestration de conteneurs. Pour les cas d'utilisation nécessitant une orchestration, de conteneur, utilisez OKE.

Quelle est la différence entre l'exécution de conteneurs sur OCI Container Instances par rapport à une machine virtuelle standard ?

Lorsque vous exécutez des conteneurs sur Container Instances, vous n'avez pas besoin de provisionner ni de gérer vous-même des machines virtuelles ou des serveurs. Vous pouvez simplement spécifier les images de conteneurs et la configuration de lancement pour exécuter les conteneurs sur les instances de conteneur. OCI gère le calcul sous-jacent nécessaire à l'exécution de vos conteneurs. Si vous exécutez des conteneurs sur une machine virtuelle, vous êtes responsable de la gestion du serveur, ainsi que de l'installation et de la maintenance de l'exécution du conteneur sur la machine virtuelle.

Quel est le tarif des d'OCI Container Instances ?

Avec les instances de conteneur OCI, vous ne payez que les ressources d'infrastructure utilisées par les instances de conteneur. Le prix des ressources CPU et mémoire allouées à une instance de conteneur est similaire à celui des instances OCI Compute pour la forme choisie. Il n'y a pas de frais supplémentaires pour l'utilisation de Container Instances. Les heures partielles d'OCPU et de gigaoctet (mémoire) consommées sont facturées comme des heures partielles avec un minimum, d'une minute et l'utilisation est agrégée par la seconde. Chaque instance de conteneur obtient 15 Go de stockage éphémère par défaut, sans frais supplémentaires. Pour plus de détails, reportez-vous à la page de tarification de Container Instances.

Combien de cœurs et de mémoire puis-je allouer à une instance de conteneur ?

Lorsque vous créez une instance de conteneur, vous pouvez sélectionner la forme de calcul sous-jacente et allouer jusqu'au maximum de cœurs et de ressources de mémoire fournies par la forme. La limite de cœurs standard est de 8 cœurs sur les formes x86 (AMD) et de 16 cœurs sur les formes Arm (Ampère). Vous pouvez allouer un nombre plus élevé de cœurs pour les workloads exigeants. Par exemple, si vous sélectionnez une forme AMD E4 Flex, vous pouvez allouer jusqu'à 64 cœurs (128 vCPU) et 1 024 Go de mémoire à votre instance de conteneur. La création d'une instance de conteneur avec cœurs étendus peut prendre plus de temps que celle d'une instance de conteneur sans cœurs étendus.

Puis-je exécuter plusieurs conteneurs sur une même instance de conteneur ?

Oui, Lors de la création d'une instance de conteneur, vous pouvez spécifier un ou plusieurs conteneurs et l'image du conteneur. Vous pouvez éventuellement indiquer des variables d'environnement, des limites de ressources, des options de démarrage, etc. pour chaque conteneur.

Une instance de conteneur doit généralement exécuter une seule application. Cependant, votre conteneur d'application peut nécessiter des conteneurs auxiliaires, tels qu'un conteneur de journalisation ou un conteneur de base de données. Vous pouvez choisir d'exécuter plusieurs conteneurs de la même application sur une seule instance de conteneur. Les conteneurs exécutés sur la même instance de conteneur partageront les ressources de processeur/de mémoire, le réseau local et le stockage éphémère. Vous pouvez choisir d'appliquer des limites de ressources CPU/mémoire au niveau du conteneur pour restreindre la quantité de ressources consommées par chaque conteneur.

Quels types de registres de conteneurs sont pris en charge ?

Tous les registres de conteneurs compatibles avec Open Container Initiative, y compris OCI Container Registry, sont pris en charge.

Puis-je exécuter mes applications sur des processeurs Arm à l'aide de Container Instances ?

Oui, Grâce aux processeurs Arm, les clients peuvent exécuter leurs workloads actuels à moindres frais et créer de nouvelles applications plus économiques et plus performantes. OCI Container Instances vous permet d'exécuter vos applications conteneurisées sur des processeurs Arm. Pour ce faire, vous devez sélectionner une forme Ampère, telle que CI.Standard.A1.Flex, lors de la configuration de vos instances de conteneur, et utiliser des images de conteneur compatibles Arm ou multi-architecture pour vos applications. Vous bénéficiez également de 3 000 heures d'OCPU et de 18 000 Go-heures d'utilisation de niveau gratuit avec la forme Ampere A1 Flex. Cette utilisation de niveau gratuit est partagée entre les instances Bare Metal, de machine virtuelle et de conteneur.

Quelles sont les options de stockage disponibles pour les instances de conteneur Container Instances ?

Par défaut, chaque instance de conteneur obtient 15 Go de stockage éphémère. Elle est utilisée à diverses fins, telles que le stockage d'images de conteneur et la sauvegarde du système de fichiers de superposition root de chaque conteneur. Si la taille de l'une des images de conteneur par instance de conteneur dépasse 7,5 Go, la création de l'instance de conteneur peut échouer. Il est recommandé d'utiliser des bases de données externes pour stocker les données d'application qui doivent persister indépendamment du cycle de vie de l'instance de conteneur. Des options d'attachement de volumes persistants avec OCI Block Storage et OCI File Storage (FSS) seront mises à disposition à l'avenir.

Quelle est la durée de vie des instances de conteneur ?

Une instance de conteneur sera inactive dès que tous les conteneurs de cette instance s'arrêteront si la stratégie de redémarrage n'est pas activée. Cela signifie que les instances de conteneur utilisées pour les workloads éphémères, telles que les pipelines d'intégration et de déploiement continus, les tâches d'automatisation pour les opérations cloud, le traitement des données/médias, etc., s'arrêteront une fois le workload exécuté. Les clients ne seront facturés que pour la durée du travail.

Pour les instances de conteneur devant rester actives, telles que celles utilisées pour les applications Web, les clients peuvent configurer des stratégies de redémarrage afin de redémarrer les conteneurs au sein d'une instance de conteneur en cas de panne, en veillant à ce que l'application soit toujours active. Pour bénéficier d'une haute disponibilité de ces applications, il est recommandé de créer plusieurs instances de conteneur dans deux domaines de disponibilité ou domaines de pannes d'une région donnée.