Lebenszyklus von Betriebssystemen

In diesem Dokument werden die Lebenszyklusphasen öffentlicher Betriebssystem-Images (OS-Images) in Compute Engine beschrieben. Anhand dieser Informationen können Sie nachvollziehen, wie Betriebssystemversionen von der allgemeinen Verfügbarkeit (General Availability, GA) über das Ende des Supports (End of Support, EOS) oder das Ende des Lebenszyklus (End of Life, EOL) übergehen. So können Sie Upgradepläne für Ihre Arbeitslasten entwickeln.

In den folgenden Abschnitten werden die Lebenszyklusphasen einer Betriebssystemversion in Compute Engine beschrieben.

Mainstream-Support oder allgemeine Verfügbarkeit (GA)

In dieser Phase finden die folgenden Prozesse statt:

1. Mit der Einführung einer neuen Betriebssystemversion erstellt der Anbieter des Betriebssystem-Images ein neues Betriebssystem-Image und weist ihm einen Namen zu, der der Namenskonvention für diese Betriebssystemdistribution entspricht. Beispiel: debian-11-bullseye-v20230801.

2. Der Image-Anbieter erstellt dann eine neue Image-Familie. Beispiel: debian-11.

   Mithilfe von Image-Familien können Sie Betriebssystem-Images in Ihrem Projekt so verwalten, dass ähnliche Images zusammengefasst werden und Rollforwards und Rollbacks zwischen bestimmten Betriebssystem-Image-Versionen möglich sind. Weitere Informationen finden Sie unter Best Practices für Image-Familien.

   Alle Aufrufe der Image-Familie verweisen auf dieses neu erstellte Betriebssystem-Image. Wenn Sie beispielsweise beim Erstellen einer VM eine Image-Familie angeben, indem Sie das Flag --image-family mit dem entsprechenden --image-project verwenden, wird die neueste Version des Images verwendet.

3. Gelegentlich wendet der Image-Anbieter kritische Sicherheits- oder Fehlerkorrekturen, die vom Betriebssystemanbieter gesendet werden, auf das Betriebssystem-Image an. Bei diesen Updates werden möglicherweise neue Funktionen eingeführt. Wenn ein Update gesendet wird, geschieht Folgendes:

   • Das aktuelle Betriebssystem-Image wird aktualisiert und ein neuer Name wird generiert. Beispiel: das debian-11-bullseye-v20230801 mit den Updates wird zu debian-11-bullseye-v20230901.
   • Die debian-11 Image-Familie verweist jetzt auf das neue debian-11-bullseye-v20230901 Betriebssystem-Image.
   • Das vorherige Betriebssystem-Image (debian-11-bullseye-v20230801) wird als deprecated markiert.

Verworfen oder Ende des Supports (EOS)

Irgendwann erreicht jede Betriebssystemversion die Phase der Verwerfung. Die Termine für die Verwerfung von Betriebssystemversionen finden Sie unter Betriebssystemdetails.

Verworfene Betriebssystemversionen können sich entweder in einer Phase mit erweitertem Support oder am Ende des Lebenszyklus befinden.

In dieser Phase stellen Betriebssystemanbieter keine Image-Updates mehr bereit und die Betriebssystem-Images werden als verworfen markiert. Sie können diese Betriebssystem-Images möglicherweise weiterhin verwenden, sind aber für die Beschaffung von Updates verantwortlich, die je nach Verfügbarkeit von der Betriebssystem-Distribution, dem Anbieter oder der Open-Source-Community zur Verfügung gestellt werden.

Wenn eine Betriebssystemversion das Ende des Supports erreicht, geschieht Folgendes:

• Das neueste Image in der Image-Familie wird entweder gelöscht oder als verworfen markiert.

• Sie können die Image-Familie nicht mehr verwenden. Sie können jedoch einige oder alle Betriebssystem-Images weiterhin verwenden, indem Sie direkt darauf verweisen. Eine Ausnahme ist Windows, wo alle Betriebssystem-Images am Ende des Supports gelöscht werden.

  Wenn Sie eine VM aus einem verworfenen Image erstellen möchten, müssen Sie die Google Cloud CLI oder REST verwenden. Beim Angeben des Images müssen Sie das Flag --image verwenden, da Image-Familien nicht auf verworfene Images verweisen. Weitere Informationen zum Erstellen von VMs finden Sie unter VM-Instanz aus einem öffentlichen Image erstellen.

• Wenn eine Betriebssystemversion die erweiterte Lebenszyklusphase erreicht oder überschreitet, garantiert Google keine Featurekompatibilität mit neuen Maschinenfamilien oder CPU-Plattformen für diese verworfenen Versionen.

  Alle VMs, die Betriebssystem-Images verwenden, die zu dieser Betriebssystemversion gehören, die das Ende des Supports erreicht hat, funktionieren weiterhin in Compute Engine und sind auch nach dem Ende des Supports noch supportberechtigt. Cloud de Confiance by S3NS Support über das EOS-Datum hinaus. Wenn jedoch Probleme mit der VM auftreten, die mit der verworfenen Betriebssystemversion zusammenhängen, kann Google das Problem möglicherweise nicht beheben , da der Support des Betriebssystemanbieters nicht mehr verfügbar ist.

Verworfene Betriebssystemversionen können sich entweder in einer Phase mit erweitertem Support oder am Ende des Lebenszyklus befinden.

Verlängerter Support

Wenn einige Betriebssysteme die Phase der Verwerfung erreichen, bieten Betriebssystemdistributoren ein kostenpflichtiges Wartungs-, erweitertes oder langfristiges Paket an, das auf Ihr Betriebssystem angewendet werden kann:

• Für das Betriebssystem Red Hat Enterprise Linux (RHEL): Support für die Wartung, erweiterte Lebensdauer, Extended Lifecycle Support ELS (Add-on) oder Extended Update Support (EUS)
• Für Rocky Linux: Langfristiger Support kann bei CIQ erworben werden.
• Für das Betriebssystem SUSE Linux Enterprise Server (SLES): Long Term Service Pack Support, Extended Service Pack Overlap Support (ESPOS)
• Für das Betriebssystem Ubuntu Pro: Erweiterte Sicherheitswartung (Extended Security Maintenance, ESM)
• Für das Betriebssystem Windows: Erweiterte Sicherheitsupdates

Weitere Informationen zu diesen erweiterten Lebenszykluspaketen finden Sie in der Dokumentation des Betriebssystemanbieters.

Ende des Lebenszyklus (EOL)

Für Betriebssysteme, die das Ende des erweiterten Supportzeitraums erreicht haben, oder für Betriebssysteme, die keinen erweiterten Supportzeitraum unterstützen, geschieht Folgendes:

• Das neueste Image in der Image-Familie wird als verworfen markiert oder daraus gelöscht aus Cloud de Confiance by S3NS.

• Die von Google bereitgestellte Gastumgebungssoftware wird für Betriebssystemversionen, die das Ende des Lebenszyklus erreicht haben, nicht mehr aktualisiert und die Repositories werden nicht mehr aktualisiert oder gewartet.

• Für vorhandene VMs, die Betriebssystemversionen verwenden, die das Ende des Lebenszyklus erreicht haben, geschieht Folgendes:

  • Die VM kann keine Softwarepakete oder Updates vom Betriebssystemanbieter herunterladen oder installieren und Sicherheitsupdates sind nicht mehr verfügbar. Das liegt daran, dass Inhalte des Betriebssystemanbieters möglicherweise nicht mehr über die vorhandenen Kanäle verfügbar sind, da die konfigurierte Software-Repository-Infrastruktur des Betriebssystemanbieters möglicherweise heruntergefahren oder archiviert wurde.
  • Die VM wird weiterhin ausgeführt, aber die fortgesetzte Kompatibilität ist nicht garantiert. Möglicherweise ist kein aktiver Support vom Betriebssystemanbieter oder von Google verfügbar. Google kann Optionen für die Migration oder Upgrades auf neuere Betriebssystemversionen anbieten.

Namenskonvention für Betriebssystem-Images, Zeitplan für Updates und Einstellungsrichtlinie

In der folgenden Tabelle sind die Namenskonvention für Betriebssystem-Images und Image-Familien, der Zeitplan für Updates und die geltende Einstellungsrichtlinie aufgeführt.

Definitionen

In der Tabelle werden die folgenden Notationen verwendet:

• V ist die numerische Version des Betriebssystems. Beispiel: RHEL-7, wobei 7 die numerische Version ist.
• R ist der Release-String, der manchmal auch als Entwicklungs-Codename für das Betriebssystem bezeichnet wird. Beispiel: debian-12-bookworm-v20240213, wobei bookworm der Release-String ist. Release-Strings gelten nur für Betriebssystem-Images von Debian und Ubuntu.
• N ist die numerische Build-Nummer. Build-Nummern gelten nur für Container-Optimized OS und Fedora CoreOS.
• YYYYMMDD ist das Jahr/der Monat/der Tag, der das Datum angibt, an dem das Betriebssystem-Image erstellt oder veröffentlicht wurde. Bei einigen Betriebssystemen wird dem Datum ein Kleinbuchstabe v vorangestellt. Beispiel: vYYYYMMDD.

Nächste Schritte

• Mehr über die Betriebssysteme erfahren, die in Compute Engine verfügbar sind