Der Container Instances-Service eignet sich hervorragend für den Betrieb isolierter Container, die keine Container-Orchestrierungsplattform, wie z. B. Kubernetes erfordern. Er eignet sich für Anwendungsfälle wie APIs, Web-Apps, CI/CD-Jobs, Automatisierungsaufgaben, Daten-/Medienverarbeitung, Entwicklungs-/Testumgebungen und vieles mehr. Allerdings ersetzt er keine Container-Orchestrierungsplattformen. Und 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 Containerinstanz zugewiesen werden, ist derselbe wie der Tarif für OCI Compute Instances für die gewählte Ausprägung. Für die Nutzung von Containerinstanzen fallen keine zusätzlichen Gebühren an. Teilweise verbrauchte OCPU- und Gigabyte-(Speicher-)Stunden werden als Teilstunden mit einem Minimum von einer Minute abgerechnet und die Nutzung 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 Containerinstanz können Sie die zugrunde liegende Compute-Ausprägung auswählen und das maximale an CPU- und Arbeitsspeicherressourcen zuweisen, die von der Ausprägung bereitgestellt werden. Wenn Sie beispielsweise eine E4- oder E3-Flex-Ausprägung wählen, können Sie Ihrer Containerinstanz bis zu 64 Kerne (128 vCPU) und 1.024 GB Arbeitsspeicher zuweisen.
Ja. Beim Erstellen einer Containerinstanz können Sie einen oder mehrere Container angeben. Außerdem können Sie das Container-Image und optional Umgebungsvariablen, Ressourcenlimits, Startoptionen usw. für jeden Container angeben.
Eine Containerinstanz sollte normalerweise eine einzelne Anwendung ausführen. Für Entwicklungszwecke benötigt Ihr Anwendungscontainer jedoch möglicherweise unterstützende Container, z. B. Logging-Sidecar- oder Datenbankcontainer. Sie können wählen, ob Sie mehrere Container derselben Anwendung auf einer Containerinstanz ausführen möchten. Container, die auf derselben Containerinstanz 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.
Jede Containerinstanz erhält standardmäßig 15 GB flüchtigen Speicher. Optionen zum Anhängen von Persistent Volume mit OCI Block Storage und OCI File Storage (FSS) werden bald verfügbar sein. Container Instances können zudem externe Datenbanken verwenden, um Daten zu speichern, die die Container-Instanz überdauern.
Eine Containerinstanz wird inaktiv, sobald alle Container innerhalb dieser Instanz angehalten werden und die Autorestart-Richtlinie nicht aktiviert ist. Das bedeutet, dass Containerinstanzen, die für flüchtige Workloads verwendet werden, wie CI/CD-Pipelines, Automatisierungsaufgaben für Cloud-Prozesse, Daten-/Medienverarbeitung usw. angehalten werden, sobald die Arbeitslast ausgeführt wird. Den Kunden wird nur die tatsächliche Dauer des Auftrags in Rechnung gestellt.
Für Containerinstanzen, die ständig verfügbar sein müssen, wie z. B. für Webanwendungen, können Kunden Neustart-Richtlinien konfigurieren, um Container innerhalb einer Containerinstanz im Falle eines Ausfalls neu zu starten und so sicherzustellen, dass die Anwendung immer verfügbar ist.