Container Instances eignet sich hervorragend für den Betrieb isolierter Container, die keine Container-Orchestrierungsplattform, wie z. B. Kubernetes erfordern. Es lässt sich für APIs, Web-Apps, CI/CD-Jobs, Automatisierungsaufgaben, die Daten-/Medienverarbeitung, DevTest-Umgebungen und andere Anwendungsfälle verwenden. Allerdings ersetzt es keine Container-Orchestrierungsplattformen. Verwenden Sie für Anwendungsfälle, die eine Container-Orchestrierung erfordern, OKE.
Wenn Sie Container auf Container Instances ausführen, müssen Sie selbst keine VMs oder Server bereitstellen und verwalten. Sie können einfach die Container-Images angeben und die Konfiguration starten, um Container auf Container Instances auszuführen. OCI verwaltet die zugrunde liegende Rechenleistung, die zum Ausführen Ihrer Container erforderlich ist. Wenn Sie Container auf einer virtuellen Maschine ausführen, sind Sie für die Verwaltung des Servers sowie für die Installation und Wartung der Containerlaufzeit auf der virtuellen Maschine verantwortlich.
Bei OCI Container Instances zahlen Sie nur für die Infrastrukturressourcen, die von den Containerinstanzen genutzt werden. Der Tarif für CPU- und Speicherressourcen, die einer Container-Instanz zugewiesen werden, entspricht dem Tarif für OCI Compute Instances für die gewählte Ausprägung. Für die Nutzung von Container Instances fallen keine zusätzlichen Gebühren an. Teilweise verbrauchte OCPU- und Gigabyte-(Speicher-)Stunden werden als Teilstunden mit einem Minimum von einer Minute abgerechnet. Die Nutzung wird dabei sekundengenau aggregiert. Jede Containerinstanz erhält standardmäßig 15 GB flüchtigen Speicher – und das ohne zusätzliche Kosten. Weitere Einzelheiten finden Sie auf der Seite mit den Tarifangaben für Container Instances.
Beim Erstellen einer Container Instance können Sie die zugrunde liegende Compute-Ausprägung auswählen und das maximale an Kernen und Arbeitsspeicherressourcen zuweisen, die von der Ausprägung bereitgestellt werden. Der Grenzwert für reguläre Kerne beträgt 8 Kerne bei x86 (AMD)-Ausprägungen und 16 Kerne bei Arm (Ampere)-Ausprägungen. Sie können für anspruchsvolle Workloads auch eine höhere Anzahl an Kernen zuweisen. Wenn Sie beispielsweise eine AMD E4-Flex-Ausprägung wählen, können Sie Ihrer Containerinstanz bis zu 64 Kerne (128 vCPU) und 1.024 GB Arbeitsspeicher zuweisen. Die Erstellung einer Containerinstanz mit zusätzlichen Kernen kann länger dauern als die einer Container-Instanz ohne zusätzliche Kerne.
Ja. Beim Erstellen einer Container-Instanz können Sie einen oder mehrere Container und das Container-Image festlegen. Optional können Sie Umgebungsvariablen, Ressourcenlimits, Startoptionen und Weiteres für jeden Container angeben.
Eine Container-Instanz sollte üblicherweise eine einzelne Anwendung ausführen. Ihr Anwendungscontainer benötigt jedoch möglicherweise unterstützende Container, z. B. Logging-Sidecar- oder Datenbankcontainer. Sie können mehrere Container mit derselben Anwendung auf einer Container-Instanz ausführen. Container, die auf derselben Container-Instanz ausgeführt werden, teilen sich die CPU-/Speicherressourcen, das lokale Netzwerk und den flüchtigen Speicher. Sie können CPU-/Speicherressourcenlimits auf Containerebene anwenden, um die von jedem Container verbrauchte Ressourcenmenge zu begrenzen.
Jede Container-Registry, die mit der Open Container Initiative kompatibel ist, einschließlich OCI Container Registry, wird unterstützt.
Ja. Mit Arm-basierten Prozessoren können Kunden aktuelle Workloads kostengünstiger ausführen und neue Anwendungen mit erstklassiger Wirtschaftlichkeit und Performance erstellen. OCI Container Instances ermöglicht es Ihnen, Ihre containerisierten Anwendungen auf Arm-basierten Prozessoren auszuführen. Wählen Sie dazu eine Ampere-Ausprägung wie CI.Standard.A1. Flex aus, wenn Sie Ihre Container-Instanzen einrichten, und verwenden Sie mit Arm kompatible oder Multi-Architektur-Container-Images für Ihre Anwendungen. Bei der Ampere A1 Flex-Ausprägung erhalten Sie außerdem 3.000 OCPU-Stunden und 18.000 GB Free Tier-Nutzung. Diese Free Tier-Nutzung wird über Bare-Metal-, VM- und Container-Instanzen hinweg angewendet.
Jede Containerinstanz erhält standardmäßig 15 GB flüchtigen Speicher. Sie wird für eine Vielzahl von Zwecken verwendet, wie etwa dem Speichern von Container-Images und dem Sichern des Root-Overlay-Dateisystems jedes Containers. Wenn die Größe eines Container-Images pro Container-Instanz 7,5 GB überschreitet, kann die Container-Instanz möglicherweise nicht erfolgreich erstellt werden. Es wird empfohlen, dass Sie externe Datenbanken nutzen, um Anwendungsdaten zu speichern, die unabhängig vom Lebenszyklus der Container-Instanz persistieren müssen. In Zukunft werden Optionen zum Anhängen von Persistent Volumes mit OCI Block Storage und OCI File Storage verfügbar sein.
Eine Container-Instanz wird inaktiv, sobald alle Container innerhalb dieser Instanz angehalten werden und die Neustart-Richtlinie nicht aktiviert ist. Das bedeutet, dass Container-Instanzen, die für flüchtige Workloads verwendet werden, wie CI/CD-Pipelines, Automatisierungsaufgaben für Cloud-Prozesse, Daten-/Medienverarbeitung usw. angehalten werden, sobald die Workload ausgeführt wird. Den Kunden wird nur die tatsächliche Dauer des Auftrags in Rechnung gestellt.
Bei Container-Instanzen, die ständig verfügbar sein müssen, wie z. B. für Webanwendungen, können Kunden Neustart-Richtlinien konfigurieren, um Container innerhalb einer Container-Instanz im Falle eines Ausfalls neu zu starten, sodass sichergestellt ist, dass die Anwendung immer verfügbar ist. Um die Hochverfügbarkeit derartiger Anwendungen sicherzustellen, wird empfohlen, mehrere Container-Instanzen in einer bestimmten Region über zwei Availability-Domains oder Faultdomains hinweg zu erstellen.