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 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 Imagespeicherung, 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- oder 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.

Liste der in Compute Engine verfügbaren öffentlichen Images

Sie können die vollständige Liste der öffentlichen Images mit ihren Namen, Versionsnummern und Größen über die Google Cloud Console oder das gcloud-Befehlszeilentool aufrufen. Google aktualisiert öffentliche Images regelmäßig oder dann, wenn ein CVE-Patch für eine bekannte Sicherheitslücke mit kritischen Folgen zur Verfügung steht.

Console

Zur Seite "Images"

gcloud

gcloud compute images list

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.

Unterstützte Betriebssysteme nach Feature

Eine Liste der Features und der öffentlichen Images, für die sie unterstützt werden, finden Sie unter Featureunterstützung nach Betriebssystem.

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 gemäß einem monatlichen Zeitplan. Veröffentlichte Imageupdates enthalten Sicherheitsupdates und andere Updates für Betriebssystemversionen, die sich in der Mainstream-Supportphase 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 Distributions- oder Betriebssystemanbieter (z. B. Microsoft, Red Hat, Canonical) oder die entsprechende Open-Source-Community (z. B. Debian) ab.

Wir portieren im Allgemeinen keine neuen Features für diese Versionen zurück, weder im erweiterten Lebenszyklus noch nach diesem Lebenszyklus.

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:

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 ein oder mehrere Gastbetriebssystem-Features an.

Imagefamilien

Mithilfe von Imagefamilien können Sie Images in Ihrem Projekt so verwalten, dass ähnliche Images zusammengefasst werden und Rollforwards und Rollbacks zwischen bestimmten Imageversionen möglich sind. Eine Imagefamilie 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-cloud die Image-Familie debian-9 immer auf das neueste Debian 9-Image.

Familien von benutzerdefinierten Images

Wenn Sie Ihre benutzerdefinierten Images regelmäßig mit neueren Konfigurationen und neuerer Software aktualisieren, können Sie diese Images zu einer benutzerdefinierten 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 Imageversion aktualisiert werden müssen.

Da die Imagefamilie außerdem nie auf ein verworfenes Image verweist, können Sie die Imagefamilie auf eine vorherige Imageversion zurücksetzen, indem Sie einfach das neueste Image der Familie verwerfen.

Weitere Informationen finden Sie unter Imageversionen in einer Imagefamilie festlegen.

Empfehlungen zu Best Practices für die Arbeit mit Imagefamilien finden Sie unter Best Practices für Imagefamilien.

Details zu Betriebssystemen

Einige Betriebssystemimages sind speziell auf das Ausführen in Compute Engine ausgerichtet und unterscheiden sich erheblich von Standardimages, die direkt vom Anbieter des Betriebssystems stammen. In den folgenden Abschnitten finden Sie weitere Informationen zu diesen Unterschieden.

CentOS

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

Instanz mit einem öffentlichen CentOS-Image starten

Compute Engine bietet den neuesten 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 auf Ihren Instanzen wird von 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 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 Sekunden und nicht alle 5 Minuten ausgefü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 ist entfernt, um zu verhindern, dass MAC-Adressen dauerhaft 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.

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 Folgendes:

  • 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 Distribution zur Bereitstellung von Features, 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 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 CoreOS-Images, die von 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 auf Ihren Instanzen wird von 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 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.
  • Google Cloud SDK ist installiert.
  • Google Cloud-Repositories können Pakete aus der Gastumgebung für 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 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. 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.

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 Computer-Betriebssysteme bereitstellt.

Compute Engine bietet die folgenden Images:

Red Hat Enterprise Linux Red Hat Enterprise Linux for SAP mit HA und Update Services

Instanz mit einem öffentlichen RHEL-Image starten

Compute Engine bietet den neuesten 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 auf Ihren Instanzen wird von 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.

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 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 Sekunden und nicht alle 5 Minuten ausgefü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 ist entfernt, um zu verhindern, dass MAC-Adressen dauerhaft 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 for SAP

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

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:

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 Private Zugriffsoptionen für 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:

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.

Automatische Updates

Das Betriebssystem oder die Software auf Ihren Instanzen wird von 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.

Support

Wenn beim Ausführen der von Google bereitgestellten Ubuntu-Images Probleme auftreten, können Sie diese über einen unserer Supportkanäle melden oder Ihre Frage im Forum gce-discussion posten. Darüber hinaus können auch die 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

Instanz mit einem öffentlichen Windows-Image starten

Automatische Betriebssystemupdates

Windows-Images verwenden standardmäßig den Windows Update-Dienst, um das Windows-Betriebssystem automatisch zu aktualisieren, wenn Sicherheits- und Featureupdates verfügbar sind. Sie können das Verhalten bei der Installation von Updates in Windows-Instanzen nach Ihren Anforderungen konfigurieren. Informationen hierzu finden Sie in der Dokumentation von Microsoft.

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-Computerumgebung 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. Lassen Sie also unbedingt den Zugriff in Ihrem VPC-Netzwerk zu.
  • Google Cloud-Repositories können Pakete aus der Gastumgebung für 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 standardmäßig 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 8 Zeichen lang sein.
  • Das Attribut LocalAccountTokenFilterPolicy ist aktiviert, um Zugriff auf Verwaltungsdateifreigaben 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.

Instanz mit einem SQL Server-Image starten

Automatische Betriebssystemupdates

Windows-Images verwenden standardmäßig den Windows Update-Dienst, um das Windows-Betriebssystem automatisch zu aktualisieren, wenn Sicherheits- und Featureupdates verfügbar sind. Sie können das Verhalten bei der Installation von Updates in Windows-Instanzen nach Ihren Anforderungen konfigurieren. Informationen hierzu finden Sie in der Dokumentation von Microsoft.

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.

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. Lassen Sie also unbedingt den Zugriff in Ihrem VPC-Netzwerk zu.
  • Google Cloud-Repositories können Pakete aus der Gastumgebung für 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 8 Zeichen lang sein.
  • Das Attribut LocalAccountTokenFilterPolicy ist aktiviert, um Zugriff auf Verwaltungsdateifreigaben 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 Compute Engine unterstützt. Die Projekt-Community ist dafür verantwortlich, dass die Images mit den Compute Engine-Features 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 gepflegtes 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