Images

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

Sie können die meisten öffentlichen Images ohne zusätzliche Kosten verwenden. Es gibt allerdings einige Premium-Images, die zusätzliche Kosten für Ihre Instanzen verursachen. Benutzerdefinierte Images, die Sie in 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 zum Erstellen und Starten von Instanzen diese Betriebssystem-Images. 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. Abonnieren Sie gce-image-notifications, um Benachrichtigungen über Update-Releases zu erhalten.

Weiter zur Seite "Images"

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 wird.

Images mit Shielded VM-Support

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

Betriebssystem Supportkanal Image-Familie Image-Projekt Hinweise
Container-Optimized OS von Google Compute Engine cos-69-lts
cos-stable
cos-beta
cos-dev
gce-uefi-images
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-1709-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 jedem Betriebssystem, einschließlich Informationen dazu, wie jedes Betriebssystem für die Ausführung in Compute Engine angepasst wird, finden Sie unter Details zu Betriebssystemen.

Betriebssystem Supportkanal Image-Familie Image-Projekt 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-9 debian-cloud Starten
Red Hat Enterprise Linux (RHEL) Compute Engine 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-sap
sles-12-sp4-sap
sles-12-sp3-sap
sles-12-sp2-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-1810
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-1709-core
windows-1709-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 längere Phasen des 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 des Vertreibers/Betriebssystemanbieters (z. B. Microsoft, Red Hat, Canonical) oder der entsprechenden Open-Source-Community (z. B. 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 steuern. Benutzerdefinierte Images können Sie für die folgenden Aufgaben verwenden:

  • Aus Ihrer lokalen Umgebung in Compute Engine müssen Sie ein Bootlaufwerk-Image importieren oder aus virtuellen Maschinen auf Ihrer lokalen Workstation oder einer anderen Cloud-Plattform virtuelle Laufwerke importieren.

  • Aus den Bootlaufwerken der vorhandenen Compute Engine-Instanzen erstellen Sie ein Image. Verwenden Sie dann dieses Image, 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.

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

Gastbetriebssystem-Funktionen

Einige Gastbetriebssystem-Funktionen 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 Funktionen für Ihre benutzerdefinierten Images aktivieren möchten, geben Sie beim Erstellen eines benutzerdefinierten Images eine oder mehrere Gastbetriebssystem-Funktionen an.

Benutzerdefinierte Image-Familien

Wenn Sie Ihre benutzerdefinierten Images regelmäßig mit neueren Konfigurationen und Software aktualisieren, können Sie diese Images zu einer Image-Familie zusammenfassen. Die Image-Familie 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 Image-Versionen in einer Image-Familie festlegen.

Image-Familien

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

Sie können einer Image-Familie Ihre eigenen Images hinzufügen, wenn Sie ein benutzerdefiniertes Image erstellen. Die Image-Familie verweist auf das neueste Image, das Sie dieser Familie hinzugefügt haben. Da die Image-Familie nie auf ein veraltetes Image verweist, können Sie die Image-Familie auf eine vorherige Image-Version zurücksetzen, indem Sie einfach das neueste Image der Familie verwerfen. Weitere Informationen dazu finden Sie unter Image-Versionen in einer Image-Familie 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

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 das letzte Point-Release für CentOS. Wenn Sie eine CentOS-Instanz ausführen, die von einem älteren Point-Release gestartet wurde, wird sie automatisch auf das neueste 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. Diese Updates wenden Systemupgrades nur für untergeordnete Versionen an. 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 entspricht dem neuesten CentOS-Point-Release.
  • Google Cloud-Repositories können Pakete aus der Linux-Gastumgebung für Google Compute Engine installieren.
  • Google Cloud SDK ist installiert.
  • IPv6 ist deaktiviert, da es noch nicht in Compute Engine unterstützt wird.
  • 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 neu konfiguriert, damit er immer mit dem Instanznamen übereinstimmt, wenn das Netzwerk bereitgestellt wird.
  • 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 ist 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 CentOS-Methoden konfiguriert werden.
  • rsyslog ist so konfiguriert, dass Daemon- und Kernel-Nachrichten an die Konsole gesendet werden.

Lebenszyklus

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

Support

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

Wenn bei der Ausführung 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 die Ausführung von Docker-Containern optimiert ist.

Die cos-Images unterstützen:

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

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

CoreOS

CoreOS

CoreOS ist ein neuer Vertrieb, der Funktionen bereitstellt, die für die Ausführung moderner Infrastrukturstapel 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.

Mehr über die Erstellung einer Instanz mit einem öffentlichen CoreOS-Image erfahren

Support

Mehr über die Verwendung von CoreOS-Images erfahren Sie unter CoreOS in Google Compute Engine ausführen.

Wenn bei der Ausführung dieser CoreOS-Images Probleme auftreten, erhalten Sie im coreos-Forum Support.

Wichtige Unterschiede zu standardmäßigen CoreOS-Images

In CoresOS-Images, die von der Google Compute Engine bereitgestellt werden, ist das Google Cloud SDK installiert.

Debian

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 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, doch 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 durch ein kritisches Sicherheitsupdate 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 entspricht dem neuesten Debian-Point-Release.
  • Die APT-Quellen sind so eingestellt, dass das Debian-CDN verwendet wird.
  • Google Cloud SDK ist installiert.
  • Google Cloud-Repositories können Pakete aus der Linux-Gastumgebung für Google Compute Engine installieren.
  • IPv6 ist deaktiviert, da es noch nicht in Compute Engine unterstützt wird.
  • 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 neu konfiguriert, damit er immer mit dem Instanznamen übereinstimmt, wenn das Netzwerk bereitgestellt wird.
  • 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 ist 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. Sie können dies durch Ändern der Werte in /etc/apt/apt.conf.d/50unattended-upgrades und /etc/apt/apt.conf.d/02periodic konfigurieren oder deaktivieren
  • 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 Benennung nach ethN, wobei die Standardschnittstelle immer eth0 ist.

Lebenszyklus

Image-Familie Ende des Mainstream-Supports und Datum der Image-Einstellung
Debian 9 (Stretch) approx. 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 bei der Ausführung 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)

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

Compute Engine bietet die folgenden Images:

Instanz mit einem öffentlichen RHEL-Image starten

Compute Engine bietet das letzte Point-Release für RHEL. Wenn Sie eine RHEL-Instanz ausführen, die von einem älteren Point-Release gestartet wurde, wird sie automatisch auf das neueste 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. Diese Updates wenden Systemupgrades nur für untergeordnete Versionen an. 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 Enterprise-Kunden 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 Instanzen der Compute Engine angeboten wird, oder Ihr eigenes RHEL-Image zu Compute Engine migrieren. Mehr erfahren Sie auf der Seite Red Hat Cloud Access.

Lebenszyklus

Image-Familie Ende des Mainstream-Supports und Datum der Image-Einstellung
RHEL 6 November, 2020
RHEL 7 June, 2024

Support

Wenn Sie über einen Supportvertrag für Google Cloud Platform verfügen, können Sie über einen der Supportkanäle einen Bericht einreichen. Wenn Sie über keinen Supportvertrag verfügen, 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-Mitarbeiter, 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 Linux-Gastumgebung für Google Compute Engine installieren.
  • Google Cloud SDK ist installiert.
  • IPv6 ist deaktiviert, da es noch nicht in Compute Engine unterstützt wird.
  • 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 neu konfiguriert, damit er immer mit dem Instanznamen übereinstimmt, wenn das Netzwerk bereitgestellt wird.
  • 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 ist 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 Konsole gesendet werden.
  • Die Updateserver von Red Hat Update Infrastructure (RHUI) werden in Compute Engine gehostet.

SUSE

SUSE

SUSE Linux Enterprise Server (SLES) ist ein vielseitiges Serverbetriebssystem zur Bereitstellung hochverfügbarer IT-Dienste der Enterprise-Klasse in gemischten IT-Umgebungen mit herausragender Leistung und reduziertem Risiko.

Compute Engine bietet die folgenden Images:

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

Instanz mit einem öffentlichen SUSE-Image starten

Lebenszyklus

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

Support

Wenn Sie über einen Supportvertrag für Google Cloud Platform verfügen, können Sie über einen der Supportkanäle einen Bericht einreichen. Wenn Sie über keinen Supportvertrag verfügen, 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:

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 privaten VPC ohne externe IP-Adresse bereitstellen

Wenn Sie eine SLES-Instanz in einer privaten VPC ohne externe IP-Adresse bereitstellen, richten Sie eine 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

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

Instanz mit einem öffentlichen Ubuntu-Image starten

Ubuntu LTS-Images (Long Term Support – Langfristiger Support) erhalten nach ihrem Releasedatum fünf Jahre Fehlerkorrekturen und Sicherheitsupdates. LTS-Images können auf Ihren Instanzen mehrere Jahre ausgeführt werden, ohne dass ein Upgrade auf ein neueres 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 Support. Damit Sie nach Ablauf des Supportzeitraums ein standardmäßiges Ubuntu-Image weiterhin nutzen können, müssen Sie ein Upgrade auf das nächste standardmäßige Release oder LTS-Release ausführen, damit weiterhin Korrekturen und Updates bereitgestellt werden. Compute Engine empfiehlt die Nutzung von Ubuntu-LTS-Images, es sei denn, Sie benötigen Funktionen 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.

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. Diese Updates wenden Systemupgrades nur für untergeordnete Versionen an.

Wichtige Unterschiede zu standardmäßigen Ubuntu-Images

Lebenszyklus

Image-Familie 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

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

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. Weitere Informationen zu den Unterschieden

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 für Windows-Instanzen ausgeführt werden, wenn Sie sie benötigen.

Von Google bereitgestellte Komponenten

Auf Windows Server-Instanzen werden von Google zur Verfügung gestellte Komponenten wie die Agenten-, 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-Funktionen konfigurieren

Sie können mehrere Windows Server-Funktionen mit Konfigurationsdateien auf Instanzen oder benutzerdefinierten Metadatenwerten auf Instanzen und Projekten konfigurieren. Unter Windows-Instanzfunktionen konfigurieren finden Sie Informationen dazu, wie Sie diese Funktionen 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 Apps 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 Images, die Teil des halbjährlichen Releasezyklus für Windows Server sind. Einmal pro Halbjahr erscheinen aktuelle Versionen mit neuen Windows Server-Funktionen, 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 für Container" an, ein Core-Image von Windows Server 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 nicht bis dahin authentifiziert worden sind. Erstellen Sie eine externe IP für Ihre Windows-Instanzen, damit diese sich authentifizieren können.
  • Der Windows-Agent ist 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 verfügt über 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 sind installiert und werden 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.
  • In Windows Server 2008 R2 ist WMF 4.0 mit PowerShell 4.0 installiert.
  • In 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.
  • Google Cloud SDK ist mit seiner eigenen Python 2.7-Umgebung installiert. 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 auf die UTC-Zeit eingestellt, nicht auf 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.
  • IPv6 ist deaktiviert, da es noch nicht in Compute Engine unterstützt wird.
  • Web Proxy Auto Discovery (WPAD) ist deaktiviert.
  • Die Energieeinstellungen werden geändert, damit 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 8 Zeichen lang sein.
  • Das Attribut LocalAccountTokenFilterPolicy ist aktiviert, um Zugriff auf administrative Dateifreigaben 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

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.

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 für Windows-Instanzen ausgeführt werden, wenn Sie sie 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-Funktionen konfigurieren

Sie können mehrere Windows Server-Funktionen mit Konfigurationsdateien auf Instanzen oder benutzerdefinierten Metadatenwerten auf Instanzen und Projekten konfigurieren. Unter Windows-Instanzfunktionen konfigurieren finden Sie Informationen dazu, wie Sie diese Funktionen 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 nicht bis dahin authentifiziert worden sind. Erstellen Sie eine externe IP für Ihre Windows-Instanzen, damit diese sich authentifizieren können.
  • Der Windows-Agent ist 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 verfügt über 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 sind installiert und werden 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.
  • In Windows Server 2012 R2 ist .Net 4.6.1 installiert.
  • In 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.
  • Google Cloud SDK ist mit seiner eigenen Python 2.7-Umgebung installiert. 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 auf die UTC-Zeit eingestellt, nicht auf 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.
  • IPv6 ist deaktiviert, da es noch nicht in Compute Engine unterstützt wird.
  • Web Proxy Auto Discovery (WPAD) ist deaktiviert.
  • Die Energieeinstellungen werden geändert, damit 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 8 Zeichen lang sein.
  • Das Attribut LocalAccountTokenFilterPolicy ist aktiviert, um Zugriff auf administrative Dateifreigaben zu gewähren.
  • Die Auslagerungsdatei ist auf eine statische Größe von 4 GB gestellt.

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

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Compute Engine-Dokumentation