Images

Verwenden Sie Betriebssystem-Images, um Bootlaufwerke für Ihre Instanzen zu erstellen. Sie können einen der folgenden Imagetypen verwenden:

• Öffentliche Images werden von Google, Open-Source-Communities und Drittanbietern zur Verfügung gestellt und gewartet. Standardmäßig haben alle Projekte Zugriff auf diese Images und können sie verwenden, um Instanzen zu erstellen.
• Benutzerdefinierte Images sind nur für Ihr Projekt verfügbar. Sie können ein benutzerdefiniertes Image aus Bootlaufwerken und anderen Images erstellen. Anschließend verwenden Sie das benutzerdefinierte Image zum Erstellen einer Instanz.

Sie können die meisten öffentlichen Images ohne zusätzliche Kosten verwenden. Es gibt allerdings einige Premium-Images, die Zusatzkosten für Ihre Instanzen verursachen. Benutzerdefinierte Images, die Sie nach Compute Engine importieren, verursachen keine Kosten für Ihre Instanzen, verursachen jedoch eine Gebühr für Image-Speicherung, solange Sie in Ihrem Projekt ein benutzerdefiniertes Image verwenden.

In einigen Images können Sie Container in Compute Engine ausführen.

Öffentliche Images

Compute Engine bietet zahlreiche vorkonfigurierte öffentliche Images mit kompatiblen Linux- und Windows-Betriebssystemen. Nutzen Sie diese Betriebssystem-Images zum Erstellen und Starten von Instanzen. Compute Engine verwendet Ihr ausgewähltes Image, um ein nichtflüchtiges Bootlaufwerk für jede Instanz zu erstellen. Standardmäßig hat das Bootlaufwerk für eine Instanz dieselbe Größe wie das von Ihnen ausgewählte Image. Wenn Ihre Instanz ein nichtflüchtiges Bootlaufwerk erfordert, das größer als das Image ist, ändern Sie die Größe des Bootlaufwerks.

Die vollständige Liste aller öffentlichen Images mit dem jeweiligen Image-Namen, der Versionsnummer und der Image-Größe finden Sie auf der Seite "Images" in der Konsole. Google aktualisiert öffentliche Images regelmäßig oder wenn ein Patch für ein CVE mit kritischen Folgen zur Verfügung steht.

Zur Seite "Images"

Hinweis: Die Verwendung der Betriebssysteme in diesen Images unterliegt zusätzlichen Lizenzierungsbedingungen. Mehr über die Lizenzierung von Betriebssystemen erfahren Sie in den Google Cloud Platform-Nutzungsbedingungen und der Dokumentation, die von den unten aufgeführten Anbietern von Betriebssystemen bereitgestellt wird.

Support wird vom Compute Engine-Team lediglich für einige Images angeboten. Support für Images können Sie von der Ressource erhalten, die in der Spalte Supportkanal genannt ist.

Images mit Shielded VM-Support

Compute Engine bietet öffentliche Shielded VM-Images mit 64-Bit-Versionen der folgenden Betriebssysteme:

Betriebssystem	Supportkanal	Image-Familie	Image-Projekt	Anmerkungen	Instanz starten
CentOS	Compute Engine	centos-7	gce-uefi-images		Starten
Container-Optimized OS von Google	Compute Engine	cos-69-lts cos-stable cos-beta cos-dev	gce-uefi-images
Red Hat Enterprise Linux (RHEL)	Compute Engine	rhel-7	gce-uefi-images	Premium-Image	Starten
Ubuntu	Compute Engine	ubuntu-1804-lts	gce-uefi-images
Windows Server	Compute Engine	windows-2019 windows-2019-core windows-1809-core windows-1803-core windows-2016 windows-2016-core windows-2012-r2 windows-2012-r2-core	gce-uefi-images	Premium-Image

Images ohne Shielded VM-Support

Compute Engine stellt öffentliche Images mit 64-Bit-Versionen der folgenden Betriebssysteme bereit. Weitere Informationen zu den Betriebssystemen, unter anderem dazu, wie das jeweilige Betriebssystem für die Ausführung auf Compute Engine angepasst wird, finden Sie unter Details zu Betriebssystemen.

Betriebssystem	Supportkanal	Imagefamilie	Imageprojekt	Hinweise	Instanz starten
CentOS	Compute Engine	centos-7 centos-6	centos-cloud		Starten
Container-Optimized OS von Google	Compute Engine	cos-69-lts cos-stable cos-beta cos-dev	cos-cloud		Starten
CoreOS	CoreOS-Support	coreos-stable coreos-beta coreos-alpha	coreos-cloud		Starten
Debian	Compute Engine	debian-10 debian-9	debian-cloud		Starten
Red Hat Enterprise Linux (RHEL)	Compute Engine	rhel-8 rhel-7 rhel-6	rhel-cloud	Premium-Image	Starten
RHEL für SAP	Compute Engine	rhel-7-6-sap-ha rhel-7-4-sap	rhel-sap-cloud	Premium-Image	Starten
SUSE Enterprise Linux Server (SLES)	Compute Engine	sles-15 sles-12	suse-cloud	Premium-Image	Starten
SLES für SAP	Compute Engine	sles-15-sp1-sap sles-15-sap sles-12-sp4-sap sles-12-sp3-sap sles-12-sp2-sap sles-12-sp1-sap	suse-sap-cloud	Premium-Image	Starten
Ubuntu	Compute Engine	ubuntu-1804-lts ubuntu-minimal-1804-lts ubuntu-1604-lts ubuntu-minimal-1604-lts ubuntu-1404-lts ubuntu-1904 ubuntu-minimal-1904	ubuntu-os-cloud		Starten
Windows Server	Compute Engine	windows-2019 windows-2019-for-containers windows-2019-core windows-2019-core-for-containers windows-1809-core windows-1809-core-for-containers windows-1803-core windows-1803-core-for-containers windows-2016 windows-2016-core windows-2012-r2 windows-2012-r2-core windows-2008-r2	windows-cloud	Premium-Image	Starten
SQL Server auf Windows Server	Compute Engine	SQL Server-Image-Familien	windows-sql-cloud	Premium-Image	Starten

SQL Server-Images

Compute Engine bietet Images, in denen SQL Server auf Windows Server vorinstalliert ist. Das Projekt für öffentliche Images windows-sql-cloud enthält Image-Familien für die folgenden SQL Server-Versionen:

• SQL Server Enterprise
  • sql-ent-2017-win-2016
  • sql-ent-2016-win-2016
  • sql-ent-2016-win-2012-r2
  • sql-ent-2014-win-2012-r2
  • sql-ent-2014-win-2016
  • sql-ent-2012-win-2012-r2
• SQL Server Standard
  • sql-std-2017-win-2016
  • sql-std-2016-win-2016
  • sql-std-2016-win-2012-r2
  • sql-std-2014-win-2012-r2
  • sql-std-2012-win-2012-r2
• SQL Server Web
  • sql-web-2017-win-2016
  • sql-web-2016-win-2016
  • sql-web-2016-win-2012-r2
  • sql-web-2014-win-2012-r2
  • sql-web-2012-win-2012-r2
• SQL Server Express
  • sql-exp-2017-win-2016
  • sql-exp-2017-win-2012-r2

Vollständige Details über SQL Server-Images finden Sie in der SQL Server-Übersicht.

Lebenszyklus der Betriebssysteme und Supportrichtlinie

Die Unterstützung der von Compute Engine zur Verfügung gestellten öffentlichen Betriebssystem-Images unterliegt dem Lebenszyklus des jeweiligen Betriebssystems. Sofern nicht anders angegeben, veröffentlicht Google in der Regel aktualisierte Images in einem monatlichen Zeitplan. Veröffentlichte Image-Updates enthalten Sicherheitsupdates und andere Updates für Betriebssystemversionen, die sich in der Phase des Mainstream Supports ihres Lebenszyklus befinden. Wenn eine Betriebssystemversion Phasen des erweiterten Lebenszyklus erreicht, stellt Google keine monatlich aktualisierten Images mehr bereit. Zuvor veröffentlichte Images werden als verworfen markiert. Images, die als verworfen markiert sind, können weiterhin verwendet werden. Allerdings hängt die Verfügbarkeit von Sicherheitsupdates von der Verfügbarkeit über den Vertreiber/Betriebssystemanbieter (z. B. Microsoft, Red Hat, Canonical) oder die entsprechenden Open-Source-Community (z. B. bei Debian) ab.

Google portiert im Allgemeinen keine neuen Funktionen für diese Versionen im erweiterten Lebenszyklus oder nach dem erweiterten Lebenszyklus zurück.

Weitere Informationen zum Lebenszyklus des Betriebssystems, an dem Sie interessiert sind, finden Sie unter "Lebenszyklus" im Abschnitt "Details zu Betriebssystemen".

Benutzerdefinierte Images

Ein benutzerdefiniertes Image ist ein Bootlaufwerk-Image, das Ihnen gehört und dessen Zugriffsrechte Sie verwalten. Benutzerdefinierte Images können Sie für die folgenden Aufgaben verwenden:

• Importieren eines Bootlaufwerk-Images von Ihrer lokalen Umgebung zu Compute Engine oder Importieren virtueller Laufwerke von virtuellen Maschinen, die auf Ihrer lokalen Workstation oder einer anderen Cloudplattform ausgeführt werden.

  Hinweis: Wenn Sie mehrere VMs zu Compute Engine migrieren möchten, verwenden Sie den VM-Migrationsdienst.

• Erstellen eines Images von den Bootlaufwerken der vorhandenen Compute Engine-Instanzen. Dieses Image können Sie dann verwenden, um für die Instanzen neue Bootlaufwerke zu erstellen. Mit diesem Verfahren können Sie neue Instanzen erstellen, die mit den Anwendungen vorkonfiguriert sind, die Sie benötigen. Die komplett neue Konfiguration eines öffentlichen Images ist nicht erforderlich.

• Kopieren eines Images entweder mit dem gcloud-Tool oder mit der API. Dazu nutzen Sie dasselbe Verfahren wie zum Erstellen eines Images, aber geben ein anderes Image als Image-Quelle an. Sie können ein Image auch aus einem benutzerdefinierten Image in einem anderen Projekt erstellen.

Gastbetriebssystem-Features

Einige Gastbetriebssystem-Features stehen nur für bestimmte Images zur Verfügung. So ist zum Beispiel Multi-Queue-SCSI nur bei manchen öffentlichen Images aktiviert.

Wenn Sie diese Features für Ihre benutzerdefinierten Images aktivieren möchten, geben Sie beim Erstellen eines benutzerdefinierten Images eine oder mehrere Gastbetriebssystem-Features an.

Familien von benutzerdefinierten Images

Wenn Sie Ihre benutzerdefinierten Images regelmäßig mit neueren Konfigurationen und Software aktualisieren, können Sie diese Images zu einer Imagefamilie zusammenfassen. Die Imagefamilie verweist immer auf das neueste Image in dieser Familie. Ihre Instanzvorlagen und -skripte können dieses Image daher verwenden, ohne dass Verweise auf eine bestimmte Image-Version aktualisiert werden müssen. Weitere Informationen dazu finden Sie unter Imageversionen in einer Imagefamilie festlegen.

Imagefamilien

Mithilfe von Imagefamilien wird die Verwaltung von Images in Ihrem Projekt dadurch vereinfacht, dass ähnliche Images zusammengefasst und dass Rollforwards und Rollbacks zwischen bestimmten Imageversionen erleichtert werden. Eine Imagefamilie verweist immer auf die neueste, nicht veraltete Version eines Images. Die meisten öffentlichen Images werden zu einer Imagefamilie zusammengefasst. Beispielsweise verweist im Projekt debian-cloud die Imagefamilie debian-9 immer auf das neueste Debian 9-Image.

Sie können einer Imagefamilie Ihre eigenen Images hinzufügen, wenn Sie ein benutzerdefiniertes Image erstellen. Die Imagefamilie verweist auf das neueste Image, das Sie dieser Familie hinzugefügt haben. Da die Imagefamilie nie auf ein veraltetes Image verweist, können Sie die Imagefamilie auf eine vorherige Imageversion zurücksetzen, indem Sie einfach das neueste Image der Familie verwerfen. Weitere Informationen dazu finden Sie unter Imageversionen in einer Imagefamilie festlegen.

Details zu Betriebssystemen

Einige Betriebssystem-Images sind speziell auf die Ausführung in Compute Engine ausgerichtet und unterscheiden sich erheblich von standardmäßigen Images, die direkt vom Anbieter des Betriebssystems stammen. Mehr über diese Unterschiede erfahren Sie unten in den entsprechenden Abschnitten.

CentOS

CentOS ist eine kostenlose Betriebssystemplattform, die auf den Quellen von Red Hat Enterprise Linux (RHEL) basiert. Compute Engine unterstützt CentOS 7- und CentOS 6-Images und bietet diese an. Vollständige Versionshinweise finden Sie in der CentOS 7-Dokumentation und in der CentOS 6-Dokumentation.

Instanz mit einem öffentlichen CentOS-Image starten

Compute Engine bietet den aktuellen Point-Release für CentOS. Wenn Sie eine CentOS-Instanz ausführen, die von einem älteren Point-Release gestartet wurde, wird sie automatisch auf den neuesten Point-Release aktualisiert. Dieses Update wird unter Umständen erst vollständig aktiviert, nachdem Sie einen Neustart durchgeführt haben.

Automatische Updates

Das Betriebssystem oder die Software in Ihren Instanzen wird von Google Compute Engine nicht automatisch aktualisiert. Der CentOS-Paketmanager ist vom Anbieter des Betriebssystems allerdings so vorkonfiguriert, dass in Ihrer CentOS-Instanz Sicherheitspatches und Systemupgrades automatisch angewendet werden.

Instanzen zwischen den Hauptversionen des Betriebssystems werden durch diese automatischen Updates des Betriebssystemanbieters nicht aktualisiert. Bei den Updates werden Systemupgrades nur auf Nebenversionen angewandt. Abgesehen von Sicherheitspatches und Systemupgrades können CentOS-Instanzen ihre installierten Pakete automatisch aktualisieren.

Wichtige Unterschiede zu standardmäßigen CentOS-Images

Von Google Compute Engine bereitgestellte CentOS-Images weisen im Vergleich zu standardmäßigen CentOS-Images die folgenden Unterschiede auf:

• Alle Pakete werden auf das Datum des Images aktualisiert und das Image spiegelt den neuesten CentOS-Point-Release wider.
• Google Cloud-Repositories können Pakete aus der Gastumgebung für Google Compute Engine installieren.
• Das Google Cloud SDK ist installiert.
• Für die eth0-MTU ist der Wert 1460 festgelegt.
• DHCP ist so eingestellt, dass Wiederholungsversuche alle 10 und nicht alle 5 Sekunden durchgeführt werden.
• Für den DHCP-Client ist der persistente statt des einmaligen Modus eingestellt.
• Der Hostname wird durch einen DHCP-Exit-Hook festgelegt und so umkonfiguriert, dass er bei Bereitstellung des Netzwerks immer mit dem Instanznamen übereinstimmt.
• Das Bootzeitlimit wird auf 0 gestellt, um schnelle Starts sicherzustellen, da auf keine GRUB-Konfiguration zugegriffen werden kann.
• Python 2.7 SCL ist zusätzlich zum standardmäßigen Python 2.6-Paket auf EL6 installiert.
• Der SSH-Server ist installiert und aktiviert.
• In der SSH-Serverkonfiguration ist die Passwortauthentifizierung deaktiviert. ServerAliveInterval und ClientAliveInterval sind auf 7 Minuten gestellt, um die Trennung von SSH-Verbindungen zu verhindern. Die Root-Anmeldung über SSH ist deaktiviert.
• /etc/udev/rules.d/75-persistent-net-generator.rules ist deaktiviert und /etc/udev/rules.d/70-persistent-net.rules wurde entfernt, um zu verhindern, dass MAC-Adressen gespeichert werden.
• Der NTP-Server ist so eingestellt, dass der Compute Engine-Metadatenserver verwendet wird.
• Automatische Updates werden über "yum-cron" aktiviert.
• Der gesamte Traffic wird von der Firewall standardmäßig zugelassen. Die Firewall bleibt aktiviert und kann durch standardmäßige CentOS-Methoden konfiguriert werden.
• "rsyslog" ist so konfiguriert, dass Daemon- und Kernel-Nachrichten an die Console gesendet werden.

Lebenszyklus

Imagefamilie	Ende des Mainstream-Supports und Datum der Image-Einstellung
CentOS 6	November 30, 2020
CentOS 7	June 30, 2024

Support

Wenn beim Ausführen der von Google bereitgestellten CentOS-Images ein Problem auftritt, können Sie dies melden oder Ihre Frage im Forum gce-discussion posten.

Wenn beim Ausführen einer anderen CentOS-Version, die nicht von Google bereitgestellt wird, Probleme auftreten, erhalten Sie in der CentOS-Community Support.

Container-Optimized OS

Container-Optimized OS von Google ist ein Betriebssystem-Image für Ihre Compute Engine-Instanzen, das für das Ausführen von Docker-Containern optimiert ist.

Die cos-Images unterstützen:

• Google Compute Engine-Metadaten-Framework
• Gastumgebung für Compute Engine
• cloud-init
• Docker-Laufzeit
• Kubernetes
• Automatische Updates

Weitere Informationen über Container-Optimized OS finden Sie unter Übersicht über Container-Optimized OS.

CoreOS

CoreOS ist eine neue Distribution, die Features bereitstellt, die für das Ausführen moderner Infrastruktur-Stacks erforderlich sind. CoreOS verwendet Linux-Container, um Ihre Dienste auf einer höheren Abstraktionsebene zu verwalten. Compute Engine stellt CoreOS-Images bereit, die von CoreOS erstellt und unterstützt werden.

Informationen zum Erstellen einer Instanz mit einem öffentlichen CoreOS-Image

Support

Eine detaillierte Anleitung zum Verwenden von CoreOS-Images finden Sie unter CoreOS in Google Compute Engine ausführen.

Wenn beim Ausführen dieser CoreOS-Images Probleme auftreten, erhalten Sie im coreos-Forum Support.

Wichtige Unterschiede zu standardmäßigen CoreOS-Images

In CoresOS-Images, die von Google Compute Engine bereitgestellt werden, sind das Google Cloud SDK und die Gastumgebung installiert.

Debian

Debian ist ein kostenloses Betriebssystem, das von der Debian-Community bereitgestellt wird. Compute Engine bietet die folgenden Debian-Images an und unterstützt sie:

• Debian 10 Buster
• Debian 9 Stretch

Instanz mit einem öffentlichen Debian-Image starten

Automatische Updates für Image-Version 20160606 und höher

Das Betriebssystem oder die Software in Ihren Instanzen wird von Google Compute Engine nicht automatisch aktualisiert. Das Tool "unattended-upgrades" ist allerdings installiert und so konfiguriert, dass Software aus dem Debian-Sicherheits-Repository automatisch aktualisiert wird.

Das Sicherheits-Repository enthält manchmal Kernel-Patches, aber diese Patches werden erst wirksam, nachdem Sie Ihre Instanz neu gestartet haben. Ausgeführte Instanzen werden von Google Compute Engine nicht automatisch neu gestartet. Sie müssen Ihre Instanzen also manuell neu starten, um den aktualisierten Kernel verwenden zu können. Das Tool unattended-upgrades stellt einen Mechanismus bereit, der einen Neustart ausführt, wenn dies aufgrund eines kritischen Sicherheitsupdates erforderlich wird. Instanzen zwischen den Hauptversionen des Betriebssystems werden durch automatische Debian-Sicherheitsupdates nicht aktualisiert.

Wichtige Unterschiede zu standardmäßigen Debian-Images

Von Google Compute Engine bereitgestellte Debian-Images weisen im Vergleich zu standardmäßigen Debian-Images die folgenden Unterschiede auf:

• Alle Pakete werden auf das Datum des Images aktualisiert und das Image spiegelt den neuesten Debian-Point-Release wider.
• Die APT-Quellen sind so eingestellt, dass das Debian-CDN verwendet wird.
• Das Google Cloud SDK ist installiert.
• Google Cloud-Repositories können Pakete aus der Gastumgebung für Google Compute Engine installieren.
• Für die eth0-MTU ist der Wert 1460 festgelegt.
• DHCP ist so eingestellt, dass neue Versuche alle 10 und nicht alle 5 Sekunden durchgeführt werden.
• Der Hostname wird durch einen DHCP-Exit-Hook festgelegt und so umkonfiguriert, dass er bei Bereitstellung des Netzwerks immer mit dem Instanznamen übereinstimmt.
• Das Bootzeitlimit wird auf 0 gestellt, um schnelle Starts sicherzustellen, da auf keine GRUB-Konfiguration zugegriffen werden kann.
• OpenSSH ist installiert und aktiviert.
• Das Logging der seriellen Konsole ist über die Kernel-Befehlszeile in GRUB aktiviert.
• Der Standardblockplaner wird über die GRUB-Konfiguration in "noop" geändert, um die Leistung des Compute Engine-Laufwerks zu verbessern.
• In der SSH-Serverkonfiguration ist die Passwortauthentifizierung deaktiviert.
• /etc/udev/rules.d/70-persistent-net.rules wurde entfernt, um zu verhindern, dass MAC-Adressen gespeichert werden.
• Der NTP-Server ist auf die Verwendung des Compute Engine-Metadatenservers eingestellt.
• Das Paket cloud-initramfs-growroot ist installiert, um während des Starts die Erweiterung des Bootlaufwerks durchzuführen.
• Unattended-upgrades ist installiert und konfiguriert, damit täglich Debian-Sicherheitsupdates heruntergeladen und installiert werden können. Dies kann konfiguriert oder deaktiviert werden, indem Sie die Werte in /etc/apt/apt.conf.d/50unattended-upgrades und /etc/apt/apt.conf.d/02periodic ändern.
• Debian 9 Stretch verwendet keine prädiktive Netzwerkschnittstellenbenennung. net.ifnames=0 wird in den Befehlszeilenargumenten des Grub-Kernels festgelegt. Daher verwenden Netzwerkschnittstellen immer noch die herkömmliche ethN-Benennung, wobei die Standardschnittstelle immer eth0 ist.

Lebenszyklus

Imagefamilie	Ende des Mainstream-Supports und Datum der Image-Einstellung
Debian 9 (Stretch)	July 2020

Support

Wenn beim Ausführen der von Google bereitgestellten Debian-Images Probleme auftreten, können Sie diese melden oder Ihre Frage im Forum gce-discussion posten.

Wenn beim Ausführen einer anderen Debian-Version, die nicht von Google bereitgestellt wird, Probleme auftreten, senden Sie Ihre Frage an die Debian-Community.

RHEL

Red Hat Enterprise Linux (RHEL) ist ein Open-Source-Linux-Betriebssystem, das sowohl Server- als auch Desktop-Betriebssysteme bereitstellt.

Compute Engine bietet die folgenden Images:

Red Hat Enterprise Linux

• RHEL 6
• RHEL 7
• RHEL 8

Red Hat Enterprise Linux für SAP mit HA und Update Services

• RHEL für SAP mit HA und Update Services 7.6
• RHEL für SAP mit Update Services 7.4

Hinweis: RHEL-Images sind Premiumressourcen, für die zusätzliche Gebühren anfallen. Ein RHEL-Image in Compute Engine hat eine On-Demand-Lizenz und benötigt kein RHEL-Abo. Wenn Sie ein vorhandenes RHEL-Abo verwenden möchten, können Sie das Red Hat Cloud Access-Feature verwenden.

Hinweis: Google meldet Red Hat gemäß den Lizenzbestimmungen von Red Hat den Namen Ihrer Abrechnungsentität und die Gesamtstunden der RHEL-Image-Nutzung.

Instanz mit einem öffentlichen RHEL-Image starten

Compute Engine bietet den aktuellen Point-Release für RHEL. Wenn Sie eine RHEL-Instanz ausführen, die von einem älteren Point-Release gestartet wurde, wird sie automatisch auf den neuesten Point-Release aktualisiert. Dieses Update wird unter Umständen erst vollständig aktiviert, nachdem Sie einen Neustart durchgeführt haben.

Automatische Updates

Das Betriebssystem oder die Software in Ihren Instanzen wird von Google Compute Engine nicht automatisch aktualisiert. Der RHEL-Paketmanager ist vom Anbieter des Betriebssystems allerdings so vorkonfiguriert, dass in Ihrer RHEL-Instanz Sicherheitspatches und Systemupgrades automatisch angewendet werden.

Instanzen zwischen den Hauptversionen des Betriebssystems werden durch diese automatischen Updates des Betriebssystemanbieters nicht aktualisiert. Bei den Updates werden Systemupgrades nur auf Nebenversionen angewandt. Abgesehen von Sicherheitspatches und Systemupgrades können RHEL-Instanzen ihre installierten Pakete automatisch aktualisieren.

Red Hat Cloud Access: Eigenes RHEL-Abo mitbringen

Ein zusätzlicher Vorteil besteht für Abonnenten von Red Hat Enterprise-Produkten darin, dass Unternehmenskunden mit Red Hat Cloud Access ihre aktuellen Abos für die Nutzung in Google Compute Engine migrieren können. Dadurch können Sie eine andere Version von RHEL verwenden, als derzeit von Google in Ihren Compute Engine-Instanzen angeboten wird, oder Ihr eigenes RHEL-Image zu Compute Engine migrieren. Weitere Informationen finden Sie auf der Seite von Red Hat Cloud Access.

Lebenszyklus

Imagefamilie	Ende des Mainstream-Supports und Datum der Image-Einstellung
RHEL 6	November, 2020
RHEL 7	June, 2024
RHEL 8	May, 2029

Support

Wenn Sie einen Supportvertrag für die Google Cloud Platform haben, können Sie über einen der Supportkanäle einen Bericht einreichen. Wenn Sie keinen Supportvertrag haben, können Sie einen Beitrag in der Gruppe gce-discussion posten.

Wenn Sie bereits ein Abonnent von Red Hat Cloud Access sind, fragen Sie Ihren Red Hat-Vertreter, wie Sie Ihr Abo zu Compute Engine migrieren können.

Wichtige Unterschiede zu Standard-RHEL- und CentOS-Images

Von Google Compute Engine bereitgestellte RHEL-Images weisen im Vergleich zu standardmäßigen RHEL-Images die folgenden Unterschiede auf:

• Alle Pakete werden auf das Datum des Images aktualisiert und das Image entspricht dem neuesten RHEL-Point-Release.
• Google Cloud-Repositories können Pakete aus der Gastumgebung für Google Compute Engine installieren.
• Das Google Cloud SDK ist installiert.
• Für die eth0-MTU ist der Wert 1460 festgelegt.
• DHCP ist so eingestellt, dass neue Versuche alle 10 und nicht alle 5 Sekunden durchgeführt werden.
• Für den DHCP-Client ist der persistente statt des einmaligen Modus eingestellt.
• Der Hostname wird durch einen DHCP-Exit-Hook festgelegt und so umkonfiguriert, dass er bei Bereitstellung des Netzwerks immer mit dem Instanznamen übereinstimmt.
• Das Bootzeitlimit wird auf 0 gestellt, um schnelle Starts sicherzustellen, da auf keine GRUB-Konfiguration zugegriffen werden kann.
• Python 2.7 SCL ist zusätzlich zum standardmäßigen Python 2.6-Paket auf EL6 installiert.
• Der SSH-Server ist installiert und aktiviert.
• In der SSH-Serverkonfiguration ist die Passwortauthentifizierung deaktiviert. ServerAliveInterval und ClientAliveInterval sind auf 7 Minuten gestellt, um die Trennung von SSH-Verbindungen zu verhindern. Die Root-Anmeldung über SSH ist deaktiviert.
• /etc/udev/rules.d/75-persistent-net-generator.rules ist deaktiviert und /etc/udev/rules.d/70-persistent-net.rules wurde entfernt, um zu verhindern, dass MAC-Adressen gespeichert werden.
• Der NTP-Server ist auf die Verwendung des Compute Engine-Metadatenservers eingestellt.
• Automatische Updates werden über yum-cron aktiviert.
• Der gesamte Traffic wird von der Firewall standardmäßig zugelassen. Die Firewall bleibt aktiviert und kann durch standardmäßige RHEL-Methoden konfiguriert werden.
• "rsyslog" ist so konfiguriert, dass Daemon- und Kernel-Nachrichten an die Console gesendet werden.
• Die Updateserver von Red Hat Update Infrastructure (RHUI) werden in Compute Engine gehostet.

SUSE

SUSE Linux Enterprise Server (SLES) ist ein vielseitiges Serverbetriebssystem mit herausragender Leistung und reduziertem Risiko für die Bereitstellung hochverfügbarer IT-Dienste auf Unternehmensniveau in gemischten IT-Umgebungen.

Compute Engine bietet die folgenden Images:

SUSE Linux Enterprise Server

• SLES 15
• SLES 12

SLES für SAP

• SLES 15 SP1
• SLES 15
• SLES 12 SP4
• SLES 12 SP3
• SLES 12 SP2
• SLES 12 SP1

Diese Images sind ähnlich wie die von Google bereitgestellten Debian- und CentOS-Images konfiguriert. Die Compute Engine-Image-Pakete sind vorinstalliert.

Hinweis: SUSE-Images sind Premiumressourcen, für die eine zusätzliche Nutzungsgebühr anfällt.

Instanz mit einem öffentlichen SUSE-Image starten

Lebenszyklus

Eine detailliertere Lebenszyklusrichtlinie finden Sie unter Lebenszyklus von SUSE-Images für öffentliche Clouds.

Imagefamilie	Ende des Mainstream-Supports und Datum der Image-Einstellung
SLES 11	March, 2019
SLES 12	October, 2024
SLES 15	July, 2031
SLES for SAP	Weitere Informationen finden Sie auf der Seite zum SUSE-Produktlebenszyklus.

Support

Wenn Sie einen Supportvertrag für die Google Cloud Platform haben, können Sie über einen der Supportkanäle einen Bericht einreichen. Wenn Sie keinen Supportvertrag haben, können Sie einen Beitrag in der Gruppe gce-discussion posten.

Wichtige Unterschiede zu standardmäßigen SUSE-Images

Von Compute Engine bereitgestellte SUSE-Images unterscheiden sich von standardmäßigen SUSE-Images so:

• Sie enthalten die Gastumgebung für Compute Engine.
• Sie verwenden Updateserver für das in Compute Engine gehostete SUSE-Tool zur Aboverwaltung (Subscription Management Tool, SMT).
  Hinweis: Google stellt SUSE-Lizenzinformationen für die Bestätigung des Supportanspruchs zur Verfügung.

BYOS-Images (Bring Your Own Subscription)

Wenn Sie Ihre vorhandenen SLES-Lizenzen wiederverwenden müssen, um Compute Engine-Instanzen zu erstellen, können Sie BYOS-Images (Bring Your Own Subscription) verwenden. BYOS-Images werden auch als BYOL-Images (Bring Your Own Licenses) bezeichnet. Diese Images sind im Projekt suse-byos-cloud verfügbar. Weitere Informationen finden Sie unter SUSE BYOS.

In privater VPC ohne externe IP-Adresse bereitstellen

Wenn Sie eine SLES-Instanz in einer privaten VPC ohne externe IP-Adresse bereitstellen, richten Sie NAT ein, damit Ihre Instanz die SUSE-Repository-Server erreichen kann. Weitere Informationen zu VPC-Netzwerken finden Sie unter Optionen für den Zugriff auf private Dienste und NAT-Gateways konfigurieren.

UBUNTU

Ubuntu ist ein kostenloses, von Canonical entwickeltes und unterstütztes Betriebssystem. Compute Engine bietet die folgenden Ubuntu LTS-, minimalen und standardmäßigen Releases:

• Bionic Beaver (18.04 LTS)
• Xenial Xerus (16.04 LTS)
• Cosmic Cuttlefish (18.10)
• Disco Dingo (19.04)

Instanz mit einem öffentlichen Ubuntu-Image starten

Ubuntu-LTS-Images (Long Term Support, langfristiger Support) erhalten nach ihrem Releasedatum fünf Jahre lang Fehlerkorrekturen und Sicherheitsupdates. LTS-Images können auf Ihren Instanzen mehrere Jahre ausgeführt werden, ohne dass ein Upgrade auf einen neueren Release erforderlich ist.

Ubuntu-Minimal-Images werden genauso unterstützt wie Ubuntu-LTS-Images.

Standardmäßige Ubuntu-Images (kein LTS) erhalten nach dem Releasedatum neun Monate lang Support. Damit Sie nach Ablauf des Supportzeitraums ein standardmäßiges Ubuntu-Image weiterhin nutzen können, müssen Sie ein Upgrade auf den nächsten standardmäßigen Release oder LTS-Release ausführen, sodass weiterhin Korrekturen und Updates bereitgestellt werden. Compute Engine empfiehlt die Nutzung von Ubuntu-LTS-Images, es sei denn, Sie benötigen Features oder Softwarepakete, die noch nicht in einem LTS-Release enthalten sind. Wenn von Ihren Instanzen nicht mehr unterstützte Ubuntu-Releases ausgeführt werden, sollten Sie ein Upgrade auf einen unterstützten Ubuntu-Release ausführen.

Hinweis: Aufgrund eines bekannten Problems mit "cloud-init" werden SSH-Schlüssel auf Instanzebene ignoriert und immer SSH-Schlüssel auf Projektebene für das Bereitstellen des ubuntu-Nutzers auf einer Instanz verwendet. Weitere Informationen finden Sie im Ubuntu-Wiki-Eintrag zu GoogleComputeEngineSSHKeys.

Automatische Updates

Das Betriebssystem oder die Software in Ihren Instanzen wird von Google Compute Engine nicht automatisch aktualisiert. Der Ubuntu-Paketmanager ist vom Anbieter des Betriebssystems allerdings so vorkonfiguriert, dass in Ihrer Ubuntu-Instanz Sicherheitspatches und Systemupgrades automatisch angewendet werden.

Instanzen zwischen den Hauptversionen des Betriebssystems werden durch diese automatischen Updates des Betriebssystemanbieters nicht aktualisiert. Bei den Updates werden Systemupgrades nur auf Nebenversionen angewandt.

Wichtige Unterschiede zu standardmäßigen Ubuntu-Images

• In Ubuntu-Images, die von Google Compute Engine bereitgestellt werden, ist das Google Cloud SDK installiert.
• Sie enthalten die Gastumgebung für Compute Engine.

Lebenszyklus

Imagefamilie	Ende des Mainstream-Supports und Datum der Image-Einstellung
Ubuntu 14.04 (Trusty Tahr)	April, 2019
Ubuntu 16.04 (Xenial Xerus)	April, 2021
Ubuntu 18.04 (Bionic Beaver)	April, 2023
Ubuntu 18.10 (Cosmic Cuttlefish)	July, 2019
Ubuntu 19.04 (Disco Dingo)	January, 2020

Support

Wenn bei der Nutzung der von Google angebotenen Ubuntu-Images Probleme auftreten, können Sie im Forum gce-discussion eine Frage posten oder in der Ubuntu-Community um Hilfe bitten.

WINDOWS SERVER

Windows Server ist ein von Microsoft entwickeltes und unterstütztes Betriebssystem.

Windows Server-Images auf Compute Engine sind mit den standardmäßigen Windows Server-Betriebssystemen vergleichbar. Informationen zu den Unterschieden

Hinweis: Windows-Images sind Premiumressourcen, für die eine zusätzliche Nutzungsgebühr anfällt.

INSTANZ MIT EINEM ÖFFENTLICHEN WINDOWS-IMAGE STARTEN

Automatische Updates

Windows-Images verwenden den Windows Update-Dienst, um das Windows-Betriebssystem automatisch zu aktualisieren, wenn Sicherheitsupdates verfügbar sind. Sie können automatische Updates so konfigurieren, dass sie nur dann für Windows-Instanzen ausgeführt werden, wenn Sie diese benötigen.

Von Google bereitgestellte Komponenten

Auf Windows Server-Instanzen werden von Google zur Verfügung gestellte Komponenten wie die Agent-, Metadaten- und Sysprep-Skripts automatisch über eine geplante Aufgabe aktualisiert. Informationen darüber, wie diese automatischen Updates deaktiviert werden können, finden Sie unter Automatische Komponentenupdates deaktivieren.

Windows-Features konfigurieren

Sie können mehrere Windows Server-Features mit Konfigurationsdateien für Instanzen oder mit benutzerdefinierten Metadatenwerten für Instanzen und Projekte konfigurieren. Unter Windows-Instanzfunktionen aktivieren und deaktivieren finden Sie Informationen dazu, wie Sie diese Features aktivieren oder deaktivieren können.

Windows Server Core

Compute Engine bietet öffentliche Images für Server Core, eine Option für eine minimale Serverinstallation, die die Wartungsanforderungen, den erforderlichen Speicherplatz auf dem Bootlaufwerk, den verwendeten Instanzspeicher und die potenzielle Angriffsfläche reduziert und somit die Sicherheit optimiert.

Sie können diese Images verwenden, um Windows Server auf kleineren Instanzen auszuführen und so Bootlaufwerkspeicherplatz zu sparen oder um Anwendungen auszuführen, die keine vollständige Windows-Desktopumgebung benötigen. Sie können mit Remote Desktop Protocol (RDP) eine Verbindung zu diesen Windows-Instanzen herstellen, müssen aber hauptsächlich über PowerShell mit dem Server interagieren. Weitere Informationen zu Server Core finden Sie unter Server Core für Windows Server.

Windows Server Datacenter Edition

Compute Engine bietet öffentliche Images für mehrere Versionen von Windows Server einschließlich der Images, die Teil des halbjährlichen Releasezyklus für Windows Server sind. Einmal pro Halbjahr erscheinen aktuelle Versionen mit neuen Windows Server-Features, die im Rahmen der langfristigen Wartungsaktualisierungen nicht erhältlich sind. Für die Images des halbjährlichen Release leistet Microsoft 18 Monate lang Support.

Windows Server für Container

Google bietet ein öffentliches Image für "Windows Server for Containers" an, ein Windows Server Core-Image mit folgenden vorinstallierten Komponenten:

• Docker.
• Microsoft-Container-Images windowsservercore und nanoserver.
• Fehlerkorrekturen für bekannte Probleme. Wenn Sie Docker-Container auf Ihrer Windows Server-Instanz ausführen möchten, beginnen Sie mit diesem Image, um eine Windows Server-Instanz zu erstellen.

Unterschiede zur Basisversion von Windows Server

• Windows Server-Images können nur bei einer bestehenden Netzwerkverbindung zu kms.windows.googlecloud.com aktiviert werden und stellen nach 30 Tagen ihre Funktion ein, wenn sie bis dahin nicht authentifiziert wurden. Erstellen Sie für Ihre Windows-Instanzen eine externe IP-Adresse, damit sie sich authentifizieren können.
• Google Cloud-Repositories können Pakete aus der Gastumgebung für Google Compute Engine installieren.
• Der Windows-Agent wird als Dienst installiert und konfiguriert. Die Funktionen "Kontomanager" und "Adressmanager" können deaktiviert werden.
• Google Compute Engine-Metadaten und sysprep-Skripts sind installiert und dem Standardpfad hinzugefügt.
• Der Windows-Agent hat einen Mechanismus für automatische Updates, um zukünftige Updates für Images nach Version 20150112 zu erhalten. Dieser Mechanismus kann deaktiviert werden.
• Start- und Shutdown-Skripts sind festgelegt und werden beim Starten und Herunterfahren ausgeführt.
• Google Compute Engine-Treiber werden installiert und benötigt, um Windows in Compute Engine zu starten.
• GooGet ist installiert und wird verwendet, um die Windows-Komponentenpakete für Google Compute Engine zu verwalten.
• Alle Windows-Updates bis zum Datum des Images sind installiert und Windows-Updates sind so eingestellt, dass sie automatisch ausgeführt werden.
• .Net 4.7 ist installiert: .Net 4.7.
• Unter Windows Server 2008 R2 ist WMF 4.0 mit PowerShell 4.0 installiert.
• Unter Windows Server 2012 R2 und 2016 ist WMF 5.1 mit PowerShell 5.1 installiert.
• BGInfo ist installiert und aktiviert, sodass Hostinformationen auf dem Desktop angezeigt werden. In Windows Server 2012 R2 werden standardmäßig keine Desktopbilder angezeigt.
• Das Google Cloud SDK ist mit seiner eigenen Python 2.7-Umgebung installiert. Das Google Cloud SDK berücksichtigt Projektdienstkonten und Instanzbereiche und ist außerdem mit PowerShell und CMD kompatibel.
• Der Registrierungsschlüssel RealTimeIsUniversal ist eingestellt. Das BIOS ist eine UTC-Uhr, keine LocalTime.
• Als Zeitzone ist GMT (Greenwich Standard Time) eingestellt, das Äquivalent zur UTC-Zeit.
• NTP ist so eingestellt, dass eine Synchronisierung mit dem Compute Engine-Metadatenserver durchgeführt wird.
• Der Compute Engine-Metadatenserver ist der Hostdatei hinzugefügt.
• Die Windows-Firewall lässt die Kommunikation mit dem Compute Engine-Metadatenserver zu.
• TCP KeepAliveTime ist auf 5 Minuten eingestellt.
• Web Proxy Auto Discovery (WPAD) ist deaktiviert.
• Die Energieeinstellungen sind dahingehend geändert, dass der Monitor nie ausgeschaltet wird.
• Das Attribut BootStatusPolicy ist so eingestellt, dass alle Startfehler ignoriert werden.
• Für den vioscsi-Treiber ist das Attribut EnableQueryAccessAlignment aktiviert.
• Ein KMS-Clientschlüssel ist installiert und der KMS-Client ist so eingestellt, dass er über die Compute Engine-KMS-Server aktiviert wird.
• Remote Desktop (RDP) ist aktiviert und die verknüpften Windows-Firewallports sind geöffnet.
• WinRM over HTTPS ist mit einem selbst signierten Zertifikat konfiguriert und die verknüpften Windows-Firewallports sind geöffnet.
• Das Administratorkonto ist deaktiviert.
• Der netkvm-Adapter ist so eingestellt, dass DHCP verwendet wird.
• Die MTU des netkvm-Adapters ist auf 1460 eingestellt.
• Eine persistente Route für den Compute Engine-Metadatenserver ist zum netkvm-Adapter hinzugefügt.
• Nutzerpasswörter müssen mindestens acht Zeichen lang sein.
• Das Attribut LocalAccountTokenFilterPolicy ist aktiviert, um Zugriff auf geteilte Verwaltungsdateien zu gewähren.
• Die Auslagerungsdatei ist auf eine statische Größe von 1 GB eingestellt.

Lebenszyklus

Weitere Informationen finden Sie in der Microsoft Lifecycle-Richtlinie.

Support

Wenn bei der Nutzung der von Google angebotenen Windows-Images Probleme auftreten, können Sie im Forum gce-discussion eine Frage posten.

SQL Server

SQL Server ist ein von Microsoft entwickeltes und unterstütztes Verwaltungssystem für relationale Datenbanken.

SQL Server-Images sind mit den standardmäßigen Betriebssystem-Images Windows Server 2012 R2 und Windows Server 2016 vergleichbar. Die Unterschiede werden unten beschrieben.

Weitere Informationen über Images, in denen SQL Server vorinstalliert ist, finden Sie in der Dokumentation zu SQL Server.

Hinweis: SQL Server-Images sind Premiumressourcen, für die zusätzliche Gebühren anfallen.

INSTANZ MIT EINEM ÖFFENTLICHEN WINDOWS-IMAGE STARTEN

Automatische Updates

Windows-Images verwenden den Windows Update-Dienst, um das Windows-Betriebssystem automatisch zu aktualisieren, wenn Sicherheitsupdates verfügbar sind. Sie können automatische Updates so konfigurieren, dass sie nur dann für Windows-Instanzen ausgeführt werden, wenn Sie diese benötigen.

Von Google bereitgestellte Komponenten

Auf Windows Server-Instanzen werden von Google zur Verfügung gestellte Komponenten wie die Agent-, Metadaten- und Sysprep-Skripts automatisch über eine geplante Aufgabe aktualisiert. Informationen darüber, wie diese automatischen Updates deaktiviert werden können, finden Sie unter Automatische Komponentenupdates deaktivieren.

Windows-Features konfigurieren

Sie können mehrere Windows Server-Features mit Konfigurationsdateien auf Instanzen oder benutzerdefinierten Metadatenwerten auf Instanzen und Projekten konfigurieren. Unter Windows-Instanzfunktionen aktivieren und deaktivieren finden Sie Informationen dazu, wie Sie diese Features aktivieren oder deaktivieren können.

Unterschiede zur Basisversion von Windows Server

• Windows Server-Images können nur bei einer bestehenden Netzwerkverbindung zu kms.windows.googlecloud.com aktiviert werden und stellen nach 30 Tagen ihre Funktion ein, wenn sie bis dahin nicht authentifiziert wurden. Erstellen Sie für Ihre Windows-Instanzen eine externe IP-Adresse, damit sie sich authentifizieren können.
• Google Cloud-Repositories können Pakete aus der Gastumgebung für Google Compute Engine installieren.
• Der Windows-Agent wird als Dienst installiert und konfiguriert. Die Funktionen "Kontomanager" und "Adressmanager" können deaktiviert werden.
• Google Compute Engine-Metadaten und sysprep-Skripts sind installiert und dem Standardpfad hinzugefügt.
• Der Windows-Agent hat einen Mechanismus für automatische Updates, um zukünftige Updates zu Images nach Version 20150112 zu erhalten. Dieser Mechanismus kann deaktiviert werden.
• Start- und Shutdown-Skripts sind festgelegt und werden beim Starten und Herunterfahren ausgeführt.
• Google Compute Engine-Treiber werden installiert und benötigt, um Windows in Compute Engine zu starten.
• GooGet ist installiert und wird verwendet, um die Windows-Komponentenpakete für Google Compute Engine zu verwalten.
• Alle Windows-Updates bis zum Datum des Images sind installiert und Windows-Updates sind so eingestellt, dass sie automatisch ausgeführt werden.
• Unter Windows Server 2012 R2 ist .Net 4.6.1 installiert.
• Unter Windows Server 2012 R2 ist WMF 5.0 mit PowerShell 5.0 installiert.
• BGInfo ist installiert und aktiviert, sodass Hostinformationen auf dem Desktop angezeigt werden. In Windows Server 2012 R2 werden standardmäßig keine Desktopbilder angezeigt.
• Das Google Cloud SDK ist mit seiner eigenen Python 2.7-Umgebung installiert. Das Google Cloud SDK berücksichtigt Projektdienstkonten und Instanzbereiche und ist außerdem mit PowerShell und CMD kompatibel.
• Der Registrierungsschlüssel RealTimeIsUniversal ist eingestellt. Das BIOS ist eine UTC-Uhr, keine LocalTime.
• Als Zeitzone ist GMT (Greenwich Standard Time) eingestellt, das Äquivalent zur UTC-Zeit.
• NTP ist so eingestellt, dass eine Synchronisierung mit dem Compute Engine-Metadatenserver durchgeführt wird.
• Der Compute Engine-Metadatenserver ist der Hostdatei hinzugefügt.
• Die Windows-Firewall lässt die Kommunikation mit dem Compute Engine-Metadatenserver zu.
• TCP KeepAliveTime ist auf 5 Minuten eingestellt.
• Web Proxy Auto Discovery (WPAD) ist deaktiviert.
• Die Energieeinstellungen sind dahingehend geändert, dass der Monitor nie ausgeschaltet wird.
• Das Attribut BootStatusPolicy ist so eingestellt, dass alle Startfehler ignoriert werden.
• Für den vioscsi-Treiber ist das Attribut EnableQueryAccessAlignment aktiviert.
• Ein KMS-Clientschlüssel ist installiert und der KMS-Client ist so eingestellt, dass er über die Compute Engine-KMS-Server aktiviert wird.
• Remote Desktop (RDP) ist aktiviert und die verknüpften Windows-Firewallports sind geöffnet.
• WinRM over HTTPS ist mit einem selbst signierten Zertifikat konfiguriert und die verknüpften Windows-Firewallports sind geöffnet.
• Das Administratorkonto ist deaktiviert.
• Der netkvm-Adapter ist so eingestellt, dass DHCP verwendet wird.
• Die MTU des netkvm-Adapters ist auf 1430 gestellt.
• Eine persistente Route für den Compute Engine-Metadatenserver ist zum netkvm-Adapter hinzugefügt.
• Nutzerpasswörter müssen mindestens acht Zeichen lang sein.
• Das Attribut LocalAccountTokenFilterPolicy ist aktiviert, um Zugriff auf geteilte Verwaltungsdateien zu gewähren.
• Die Auslagerungsdatei ist auf eine statische Größe von 4 GB eingestellt.

Support

Wenn bei der Nutzung der von Google angebotenen SQL Server-Images Probleme auftreten, können Sie im Forum gce-discussion eine Frage posten.

Von der Community unterstützte Images

Von der Community unterstützte Images werden nicht direkt von Google Compute Engine unterstützt. Die Projekt-Community ist dafür verantwortlich, dass die Images mit den Compute Engine-Funktionen kompatibel sind und dass Sicherheitsupdates durchgeführt werden. Von der Community unterstützte Images werden von den Projekt-Communities, die sie erstellen und warten, wie besehen bereitgestellt.

Debian-Tests

Debian ist ein kostenloses Betriebssystem, das von der Debian-Community bereitgestellt wird. Das Debian-Test-Image wird nach bestem Wissen und Gewissen für Entwicklung und Tests zur Verfügung gestellt. Sie können Debian-Test-Images mit dem folgenden gcloud-Befehl auflisten:

gcloud compute images list --project debian-cloud-testing --no-standard-images

openSUSE

openSUSE ist ein kostenloses, Linux-basiertes Betriebssystem und wird von SUSE gesponsert. openSUSE-Images sind im Projekt opensuse-cloud verfügbar. Sie können openSUSE-Images mit dem folgenden gcloud-Befehl auflisten:

gcloud compute images list --project opensuse-cloud --no-standard-images

FreeBSD

FreeBSD ist ein kostenloses, vom FreeBSD-Projekt gewartetes Betriebssystem. FreeBSD-Images sind im Projekt freebsd-org-cloud-dev verfügbar. Sie können FreeBSD-Images mit dem folgenden gcloud-Befehl auflisten:

gcloud compute images list --project freebsd-org-cloud-dev --no-standard-images

Weitere Informationen

• Mehr über Best Practices für die Verwaltung von Images erfahren
• Instanz erstellen und starten
• Mehr über Compute Engine-Instanzen erfahren
• Benutzerdefiniertes Image erstellen
• Bootlaufwerk-Images in Compute Engine importieren