Image-Versionsverwaltung und -Lebenszyklus

Auf dieser Seite wird beschrieben, wie Image-Versionen der Agent Platform Workbench nummeriert werden und wie Images ihren Lebenszyklus durchlaufen. Dies gilt sowohl für VM-Images als auch für benutzerdefinierte Container-Images.

Informationen zum Erstellen einer Instanz mit einer bestimmten VM-Image-Version finden Sie unter Instanz mit einer bestimmten Image-Version erstellen.

Informationen zu den Änderungen in den einzelnen Releases finden Sie in den Versionshinweisen zu Images.

Versionsverwaltung

Agent Platform Workbench-Images verwenden eine Haupt- und eine Nebenversion.

  • Image-Familie (Hauptversion): verwendet die Kalenderversionierung (YYMM); zum Beispiel workbench-instances-2603 (2603). Eine neue Image-Familie kennzeichnet eine erhebliche Änderung am Image, z. B. ein neues Betriebssystem, eine neue Python-Version oder eine neue Framework-Baseline. Eine größere oder potenziell funktionsgefährdende Änderung wird als neue Image-Familie ausgeliefert, während die vorherige weiterhin Updates erhält. So haben Sie Zeit für die Migration und vermeiden potenzielle funktionsgefährdende Änderungen.
  • Image-Name (Nebenversion): verwendet die Datumsversionierung im Format YYYYMMDD-HHMM-rcX, z. B. 20260629-1557-rc0. Ein Image-Name ist ein Point-Release innerhalb einer Image-Familie, z. B. ein Fehlerbehebung oder ein Sicherheitspatch.

Jede Image-Familie verweist auf ihren neuesten Image-Namen. Informationen zum Aktualisieren oder Ändern von Versionen, siehe Image-Versionen verwalten.

Versionsverwaltung für Legacy-Meilensteine

Releases, die auf Debian 11 und früher basieren, verwenden die Meilensteinversionierung, z. B. m144. Releases, die auf Debian 12 und höher basieren, verwenden die oben beschriebene Kalender- und Datumsversionierung.

Release-Rhythmus

Google aktualisiert aktiv verwaltete Image-Namen (Nebenversionen) regelmäßig, etwa wöchentlich. Der genaue Zeitpunkt eines bestimmten Releases kann variieren und einige Releases enthalten nur Sicherheits- oder Abhängigkeitsupdates. Diese Schrittfrequenz ist ungefähr. Den tatsächlichen Releaseverlauf finden Sie in den Versionshinweisen zu Images.

Wenn Sie für eine Bereitstellung einen bekannten, stabilen Image-Namen benötigen, pinnen Sie ihn an eine bestimmte Nebenversion an, anstatt die Familie zu verfolgen, und führen Sie das Upgrade nach Ihrem eigenen Zeitplan durch.

Lebenszyklus

Ein Image einer Agent Platform Workbench-Instanz durchläuft die folgenden Status:

Aktiv: Die Image-Familie wird vollständig unterstützt und erhält Sicherheits- und Fehlerbehebungen. Die Image-Familie verweist auf ihren neuesten aktiven Image-Namen.

Support eingestellt:Die Image-Familie erhält keine neuen Versionen oder Fehlerbehebungen mehr. Sie können weiterhin Instanzen mit einem bestimmten verworfenen Image-Namen erstellen, sollten aber auf eine aktive Image-Familie aktualisieren.

Jede Image-Familie hat zwei Daten:

  • Releasedatum: Datum, an dem die Hauptversion verfügbar wurde.
  • Datum der Einstellung:Datum, an dem die Image-Familie als verworfen markiert wird. Nach diesem Datum erhält sie keine neuen Versionen oder Fehlerbehebungen mehr.

VM-Images

Agent Platform Workbench-VM-Images sind von Google erstellte Boot-Images, die im cloud-notebooks-managed Image-Projekt unter projects/cloud-notebooks-managed/global/images/family/IMAGE_FAMILY veröffentlicht werden. Jede Image-Familie enthält mehrere Image-Namen, einen pro Release. Den vollständigen Releaseverlauf finden Sie in den Versionshinweisen zu Images. Eine Liste der neuesten verfügbaren Image-Namen finden Sie unter Verfügbare VM-Images auflisten.

Aktive VM-Images

In der folgenden Tabelle sind die aktiven VM-Images aufgeführt:

Image-Familie Betriebssystem Python Kernels CUDA Releasedatum Support eingestellt
workbench-instances-2603 (26.03) Debian 12 3.12 Einzelner Kernel: Python 3.12, TensorFlow 2.21.0, PyTorch 2.12.1 13.0 März 2026 März 2028
workbench-instances (Legacy) Debian 11 3.10 Mehrere Kernels: Python 3.10, TensorFlow 2.11.0, PyTorch 1.13.1 11.8 Juli 2023 März 2027

Benutzerdefinierte Container-Images

Ein benutzerdefinierter Container wird auf zwei Images ausgeführt: dem Basis-Container-Image, das Sie versionieren und erweitern können, und dem von Google verwalteten Container-Host-Image, auf dem es ausgeführt wird.

Basis-Container-Image

Das Basis-Container-Image verwendet dieselbe Versionsverwaltung für Image-Familie (Hauptversion) und Image-Name (Nebenversion) wie VM-Images. Die Image-Familie ist ein Datumssuffix im Containernamen, z. B. workbench-container-2606. Die Image-Name-Version ist ein datumsbasiertes Tag, z. B. workbench-container-2606:20260629-1557-rc0.

Die Agent Platform Workbench bietet von Google erstellte Basis-Container-Images in zwei Varianten: Standard und Slim. Weitere Informationen zum Erstellen einer Agent Platform Workbench-Instanz mit einem benutzerdefinierten Container.

Image-Familie Variante Betriebssystem Python Kernels CUDA Releasedatum Support eingestellt
workbench-container-2606 Standard Ubuntu 24.04 3.12 Einzelner Kernel: Python 3.12, TensorFlow 2.21.0, PyTorch 2.12.1 12.8.1 Juni 2026 Juni 2028
workbench-container-slim-2606 Slim Ubuntu 24.04 3.12 Einzelner Kernel: Python 3.12, TensorFlow 2.21.0, PyTorch 2.12.1 – Juni 2026 Juni 2028
workbench-container Standard Ubuntu 24.04 3.10 Mehrere Kernels: Python 3.10, TensorFlow 2.11.0, PyTorch 1.13.1 12.8.1 August 2024 März 2027
workbench-container-slim Slim Ubuntu 24.04 3.10 Einzelner Kernel: Python 3.10, TensorFlow 2.11.0, PyTorch 1.13.1 – August 2024 März 2027

Container-Host-Image

Der Container-Host hat eine einzelne Image-Familie, die eng an die neueste produktionsreife Version von Container-Optimized OS (COS) angelehnt ist. Sie wird unter der Familie workbench-container-host im Image-Projekt cloud-notebooks-managed veröffentlicht und jede Version verwendet eine Datumsversion, z. B. 20260701-2130-rc0. Sie können die Hostversion beim Erstellen einer Instanz nicht anpinnen. Neue Instanzen verwenden das neueste Host-Image. Informationen zu Änderungen am Hostbetriebssystem finden Sie in den Versionshinweisen zu Container-Optimized OS.

Nächste Schritte