Verwaltete Instanzgruppen aktualisieren

Auf dieser Seite wird erklärt, wie Sie Ihre verwalteten Instanzgruppen aktualisieren. Weitere Informationen zu verwalteten Instanzgruppen finden Sie in der Dokumentation zu Instanzgruppen.

Eine verwaltete Instanzgruppe enthält eine oder mehrere VM-Instanzen, die über eine Instanzvorlage gesteuert werden. Zum Aktualisieren der Instanzen in der Gruppe können Sie über die Managed Instance Group Updater-Funktion eine Aktualisierungsanfrage an die gesamte Gruppe stellen.

Mit dem Managed Instance Group Updater können Sie ganz einfach neue Softwareversionen auf Instanzen in Ihren verwalteten Instanzgruppen bereitstellen. Dabei bestimmen Sie selbst, wie schnell dies geschieht, inwiefern Ihr Dienst unterbrochen wird und wie umfangreich die Aktualisierung ausfällt. Der Updater bietet zwei Hauptvorteile:

  • Der Rollout eines Updates erfolgt automatisch nach Ihren Vorgaben, ohne dass nach der anfänglichen Anfrage zusätzliche Nutzereingaben erforderlich sind.
  • Sie können partielle Rollouts ausführen, die Canary-Tests ermöglichen.

Da neue Software in einer vorhandenen verwalteten Instanzgruppe bereitgestellt wird, ist es nicht erforderlich, die Instanzgruppe neu zu konfigurieren oder wieder eine Verbindung zum Lastenausgleich, zur automatischen Skalierung oder zur automatischen Reparatur herzustellen. Ohne den Updater müssen aktualisierte Softwareversionen durch die Erstellung einer neuen verwalteten Instanzgruppe mit einer neuen Softwareversion bereitgestellt werden, wofür jedes Mal zusätzliche Einstellungen erforderlich sind. Alternativ ist eine manuelle, vom Nutzer initiierte Neuerstellung jeder einzelnen Instanz erforderlich. Diese beiden Ansätze erfordern jedoch zahlreiche manuelle Schritte während des gesamten Prozesses.

Vorbereitung

Ein grundlegendes Rolling Update starten

Ein Rolling Update ist ein Update, das nach und nach auf alle Instanzen in einer Instanzgruppe angewendet wird, bis alle Instanzen aktualisiert sind. Sie können verschiedene Aspekte eines Rolling Updates steuern, beispielsweise wie viele Instanzen für die Aktualisierung offline gehen, wie lange zwischen dem Aktualisieren der einzelnen Instanzen gewartet wird, ob alle Instanzen oder nur ein Teil aktualisiert werden sollen usw.

Folgendes sollten Sie bei einem Rolling Update bedenken:

  • Die Updates sind zuerst nur geplant. Wenn Sie eine Updateanfrage stellen, bestätigt die API in ihrer Antwort, dass die Anfrage gültig ist. Dies bedeutet jedoch nicht, dass das Update erfolgreich war. Sie müssen den Status der verwalteten Instanzgruppe prüfen, um herauszufinden, ob das Update erfolgreich bereitgestellt wurde.

  • Die Instance Group Updater API ist eine deklarative API. Die API erwartet eine Anfrage, die angibt, wie die gewünschte Konfiguration der verwalteten Instanzgruppe nach dem Update aussehen soll, keinen Funktionsaufruf.

  • Die Updater-Funktion unterstützt maximal zwei Instanzvorlagenversionen in Ihrer verwalteten Instanzgruppe. Sie können also zwei unterschiedliche Instanzvorlagenversionen für Ihre verwaltete Instanzgruppe angeben, was für Canary Updates hilfreich ist.

Gehen Sie wie unten beschrieben vor, um ein grundlegendes Rolling Update zu starten, das auf alle Instanzen der Gruppe angewendet wird.

Konsole

  1. Gehen Sie in der GCP Console zur Seite "Instanzgruppen".

    Zur Seite "Instanzgruppen"

  2. Wählen Sie die Instanzgruppe aus, die Sie aktualisieren möchten.
  3. Klicken Sie oben auf der Seite auf Rolling Update.
  4. Klicken Sie unter Vorlage auf das Drop-down-Menü und wählen Sie die neue Vorlage für das Update aus.
  5. Geben Sie als Zielgröße 100 % ein, um alle Instanzen zu aktualisieren.
  6. Sie können zwischen Konfigurationsoptionen wechseln, beispielsweise ob das Update umgehend (die Gruppe ersetzt Instanzen aktiv) oder bei Gelegenheit erfolgen soll (die Gruppe ersetzt Instanzen nicht aktiv, sondern wendet das Update an, wenn Instanzen aus anderen Gründen ersetzt werden). Sie können auch Werte für Maximal zu viel, Maximal nicht verfügbar und Mindestwartezeit festlegen.
  7. Klicken Sie auf Aktualisieren, um das Update zu starten.

gcloud

Führen Sie im Tool gcloud den Befehl rolling-action start-update aus:

gcloud beta compute instance-groups managed rolling-action start-update [INSTANCE_GROUP] \
    --version template=[INSTANCE_TEMPLATE] [--zone [ZONE] | --region [REGION]]

Dabei gilt Folgendes:

  • [INSTANCE_GROUP] ist der Name der zu aktualisierenden Instanzgruppe.
  • [INSTANCE_TEMPLATE] ist die neue Instanzvorlage, auf die die Instanzgruppe aktualisiert werden soll.
  • Eine [ZONE] oder eine [REGION] für diese Instanzgruppe ist erforderlich. Wenn es sich um eine zonale Instanzgruppe handelt, geben Sie die Zone an. Ist es dagegen eine regionale Instanzgruppe, geben Sie die Region an.

API

Stellen Sie in der API eine PATCH-Anfrage an die folgende URL:

https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[MANAGED_INSTANCE_GROUP_NAME]

Wenn es sich um eine regionale verwaltete Instanzgruppe handelt, ersetzen Sie zones/[ZONE] durch regions/[REGION].

Die Nutzlast der Anfrage enthält Folgendes:

  • Die Instanzvorlage, auf die die Gruppe aktualisiert werden soll
  • Eine Updaterichtlinie für die Anfrage sowie weitere Updateoptionen

Die folgende Konfiguration ist mindestens nötig, um eine Aktualisierung in der API zu starten. Wenn Sie nichts anderes angeben, werden die Attribute maxSurge und maxUnavailable auf 1 gesetzt. Dies bedeutet, dass während der Aktualisierung immer nur eine Instanz nicht verfügbar ist und dass während des Updates nur eine Instanz mehr als die Zielgröße der Instanzgruppe erstellt wird. Durch die Anfrage werden alle Instanzen auf die neue Instanzvorlage aktualisiert.

Beispiel:

{
  "instanceTemplate": "global/instanceTemplates/example-template",
  "updatePolicy": {
    "type": "proactive"
   }
 }

Nachdem Sie die Anfrage gestellt haben, können Sie das Update überwachen, damit Sie wissen, wann die Aktualisierung beendet ist.

Optionen für das Update konfigurieren

Bei komplexeren Updates können Sie zusätzliche Optionen für eine bestimmte Aktualisierungsanfrage konfigurieren. Diese werden unten näher beschrieben.

Maximal zu viel

Legen Sie einen Wert für das Attribut maxSurge fest, damit der Updater während der Aktualisierung vorübergehend neue Instanzen erstellen kann, deren Zahl den Wert für targetSize überschreitet. Wenn Sie beispielsweise für maxSurge 5 festlegen, erstellt die verwaltete Instanzgruppe bis zu fünf neue Instanzen mit der neuen Instanzvorlage über die Zielgröße hinaus. Durch einen höheren Wert für maxSurge können Sie die Aktualisierung beschleunigen, allerdings werden die zusätzlichen Instanzen gemäß der Compute Engine-Preisliste in Rechnung gestellt. Wenn Sie keinen Wert für maxSurge festlegen, wird standardmäßig maximal eine Instanz zu viel erstellt.

Diese Option wird nur berücksichtigt, wenn sie zusammen mit der Mindestaktion REPLACE konfiguriert wird. Mit der Aktionseinstellung RESTART wird sie nicht unterstützt. Sie können entweder eine feste Anzahl angeben oder einen Prozentsatz, falls die verwaltete Instanzgruppe mindestens 10 Instanzen umfasst. Bei einem Prozentsatz rundet der Updater die Zahl der Instanzen bei Bedarf auf.

maxSurge funktioniert nur, wenn Sie genügend Kontingente oder Ressourcen zur Unterstützung der zusätzlichen Instanzen haben.

Maximal nicht verfügbar

Mit der Konfiguration von maxUnavailable können Sie dafür sorgen, dass während eines Updates immer nur eine bestimmte Anzahl an Instanzen nicht verfügbar ist. Wenn Sie beispielsweise für maxUnavailable 5 festlegen, gehen nur 5 Instanzen gleichzeitig offline, um aktualisiert zu werden. Mit diesem Parameter können Sie steuern, wie stark Ihr Dienst durch das Update gestört wird und wie schnell die Aktualisierung bereitgestellt wird.

Die Zahl beinhaltet auch Instanzen, die aus anderen Gründen nicht verfügbar sind. Wenn zum Beispiel die Instanzgruppe vergrößert wird, sind Instanzen, die gerade erstellt werden, möglicherweise nicht verfügbar. Sie werden dann bei maxUnavailable berücksichtigt. Sie können entweder eine feste Anzahl angeben oder einen Prozentsatz, falls die verwaltete Instanzgruppe mindestens 10 Instanzen umfasst. Bei einem Prozentsatz rundet der Updater die Zahl der Instanzen bei Bedarf ab.

Der Standardwert für maxUnavailable in einer zonal verwalteten Instanzgruppe ist 1. In einer regional verwalteten Instanzgruppe lautet der Standard [NUMBER_OF_ZONES], wobei [NUMBER_OF_ZONES] der Anzahl an ausgewählten Zonen für die regional verwaltete Instanzgruppe entspricht. Der Standardwert ist in diesem Fall 3.

Mindestwartezeit

Durch minReadySeconds legen Sie fest, wie lange gewartet wird, bis eine neu erstellte oder neu gestartete Instanz als aktualisiert gilt. Mit dieser Funktion kontrollieren Sie die Aktualisierungsgeschwindigkeit. Der Timer startet, wenn die beiden folgenden Bedingungen erfüllt sind:

  • Der Status der Instanz ist RUNNING.
  • Die Systemdiagnose gibt, wenn aktiviert, den Wert HEALTHY zurück.

Bei aktivierter Systemdiagnose gelten für den Updater folgende Wartezeiten:

  1. Bis der durch autohealingPolicies.initialDelaySec festgelegte Zeitraum für die Systemdiagnose den Wert HEALTHY zurückgibt
  2. Der durch minReadySeconds festgelegte Zeitraum

Falls die Systemdiagnose nicht innerhalb der durch initialDelaySec bestimmten Frist den Status HEALTHY zurückgibt, betrachtet der Updater die VM-Instanz als fehlerhaft und stoppt unter Umständen die Aktualisierung. Während die VM-Instanz in den durch initialDelaySec und minReadySeconds festgelegten Zeiträumen geprüft wird, hat sie für die verwaltete Instanzgruppe den Status verifying. Der zugrunde liegende VM-Instanzstatus bleibt jedoch RUNNING.

Wenn keine Systemdiagnosen für die Instanzgruppe durchgeführt werden, startet der Timer, sobald die Instanz den Status RUNNING hat. Für das Attribut minReadySeconds kann ein Höchstwert von 3.600 Sekunden (1 Stunde) angegeben werden.

Mindestaktion

Mit einem Wert für das Attribut "Mindestaktion" legen Sie fest, was der Updater mindestens tun muss, um die Instanzen der Gruppe zu aktualisieren. Wenn Sie beispielsweise REPLACE als Mindestaktion einrichten, werden alle betroffenen Instanzen gelöscht und durch eine neue Instanz ersetzt, unabhängig davon, ob das erforderlich ist.

Durch die Mindestaktion ist sichergestellt, dass der Updater diesen Vorgang auf alle Fälle durchführt. Falls dies für die Aktualisierung jedoch nicht ausreicht, kann eine umfangreichere Maßnahme ergriffen werden. Wenn Sie beispielsweise RESTART als Mindestaktion wählen, versucht das Aktualisierungsprogramm, die Instanzen neu zu starten, um das Update anzuwenden. Ist dafür jedoch eine umfassendere Maßnahme erforderlich, wird diese auch ausgeführt. Das Betriebssystem einer Instanz lässt sich zum Beispiel nicht durch einen Neustart ändern. Daher ersetzt der Updater in diesem Fall die VM-Instanzen der Gruppe durch neue.

Zur Auswahl stehen die Aktionen REPLACE und RESTART:

  • RESTART: Startet die Instanz neu (über eine stop- und start-Anfrage). Wenn für die Aktualisierung ein Austausch der Instanz erforderlich ist (für eine Änderung des Image wäre es beispielsweise nötig, die Instanz zu löschen und neu zu erstellen), wird zwangsweise die Aktion REPLACE ausgeführt.

  • REPLACE: Löscht die bestehende Instanz und erstellt eine neue anhand der Zielvorlage. Der Updater erstellt eine ganz neue Instanz mit allen neuen Instanzattributen, z. B. neuen internen und externen IP-Adressen.

Das folgende Diagramm zeigt, wie sich diese Optionen auf Ihre Instanzen auswirken.

Diagramm zu den Auswirkungen unterschiedlicher Aktualisierungsoptionen auf Ihre Anfrage

Weitere Aktualisierungsbeispiele

Hier sehen Sie einige Befehlszeilenbeispiele mit üblichen Konfigurationsoptionen:

Rolling Update aller VM-Instanzen mit bis zu fünf neuen Instanzen über der Zielgröße

gcloud beta compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[NEW_TEMPLATE] --max-surge 5 [--zone [ZONE] | --region [REGION]]

Rolling Update mit maximal drei nicht verfügbaren Maschinen und einer Mindestwartezeit von 3 Minuten, ehe eine neue Instanz als verfügbar gekennzeichnet wird

gcloud beta compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[NEW_TEMPLATE] --min-ready 3m \
    --max-unavailable 3 [--zone [ZONE] | --region [REGION]]

Wenn Sie beispielsweise 1.000 Instanzen haben und diesen Befehl ausführen, erstellt der Updater bis zu 100 neue Instanzen, bevor er Instanzen mit der alten Instanzvorlage entfernt.

Rolling Update aller VM-Instanzen mit bis zu 10 % neuer Instanzen über der Zielgröße

gcloud beta compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[NEW_TEMPLATE] --max-surge 10% [--zone [ZONE] | --region [REGION]]

Ein Canary Update starten

Mit der Instance Group Updater-Funktion können Sie Canary Updates durchführen, um die Aktualisierung an einer beliebigen Teilmenge von Instanzen zu testen, bevor Sie sie endgültig anwenden.

Bei einem Canary Update wird nur ein Teil der Instanzen einer Instanzgruppe aktualisiert. So können Sie neue Funktionen an einigen Instanzen testen und müssen nicht ein Update, das möglicherweise zu Unterbrechungen führt, auf alle Instanzen anwenden. Falls der Test nicht erfolgreich ist, müssen Sie nur für eine geringe Zahl an Instanzen ein Rollback durchführen und können Ausfälle minimieren. Aus Sicht des Servers ist ein Canary Update das gleiche wie ein standardmäßiges Rolling Update, außer dass dabei nicht alle Instanzen der Gruppe aktualisiert werden. Genau wie ein standardmäßiges Rolling Update bedeutet auch ein Canary Update für die betroffenen Instanzen eine Unterbrechung, d. h., sie werden während der Aktualisierung gelöscht und durch neue VM-Instanzen ersetzt.

So starten Sie ein Canary Update:

  • Sie können maximal zwei Instanzvorlagenversionen angeben. Dies sind normalerweise eine neue Instanzvorlage für das Canary Update und die aktuelle Instanzvorlage für die restlichen Instanzen. So können Sie beispielsweise festlegen, dass 20 % der Instanzen basierend auf new-instance-template erstellt werden, während der Rest weiterhin mit old-instance-template ausgeführt wird. Mehr als zwei Instanzvorlagen gleichzeitig sind nicht möglich.

  • Sie müssen immer eine Zielgröße (targetSize) für die Canary-Version angeben. Ohne die Zielgröße für die Canary-Version können Sie kein Canary Update starten. Wenn Sie beispielsweise festlegen, dass 10 % der Instanzen für den Canary-Test verwendet werden sollen, bleiben die restlichen 90 % unberührt und nutzen weiter die aktuelle Instanzvorlage.

Konsole

  1. Gehen Sie in der GCP Console zur Seite "Instanzgruppen".

    Zur Seite "Instanzgruppen"

  2. Wählen Sie die Instanzgruppe aus, die Sie aktualisieren möchten.
  3. Klicken Sie oben auf der Seite auf Rolling Update.
  4. Klicken Sie auf Vorlage hinzufügen und wählen Sie die neue Instanzvorlage für den Canary-Test aus.
  5. Geben Sie unter Zielgröße den Prozentsatz oder die feste Zahl an Instanzen ein, die Sie für den Canary-Test der neuen Instanzvorlage verwenden möchten.
  6. Sie können zwischen Konfigurationsoptionen wechseln, beispielsweise ob das Update umgehend (die Gruppe löscht und ersetzt Instanzen aktiv) oder bei Gelegenheit erfolgen soll (die Gruppe ersetzt Instanzen nicht aktiv, sondern wendet das Update an, wenn Instanzen aus anderen Gründen erstellt werden). Sie können auch Werte für Maximal zu viel, Maximal nicht verfügbar und Mindestwartezeit festlegen.
  7. Klicken Sie auf Aktualisieren, um das Update zu starten.

gcloud

Geben Sie im Befehlszeilentool gcloud sowohl die aktuelle als auch die neue Vorlage an, um genau festzulegen, wie viele Instanzen die jeweilige Vorlage verwenden sollen:

gcloud beta compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[CURRENT_TEMPLATE] \
    --canary-version template=[NEW_TEMPLATE],target-size=[SIZE] \
    [--zone [ZONE] | --region [REGION]]

Dabei gilt Folgendes:

  • [CURRENT_TEMPLATE] ist die aktuelle Vorlage, mit der die Instanzgruppe ausgeführt wird.
  • [NEW_TEMPLATE] ist die neue Vorlage, die Sie testen möchten.
  • [SIZE] ist die Anzahl oder der Prozentsatz der Instanzen, auf die/den die Aktualisierung angewendet werden soll. Sie müssen das Attribut target-size für die Vorlage --canary-version festlegen. Einen Prozentsatz können Sie nur einrichten, wenn die Instanzgruppe mindestens 10 Instanzen umfasst.
  • Eine [ZONE] oder eine [REGION] für diese Instanzgruppe ist erforderlich. Wenn es sich um eine zonale Instanzgruppe handelt, geben Sie die Zone an. Ist es dagegen eine regionale Instanzgruppe, geben Sie die Region an.

Mit dem folgenden Befehl wird ein Canary Update durchgeführt, bei dem my-template-b auf 10 % der Instanzen in der Gruppe angewendet wird:

gcloud beta compute instance-groups managed rolling-action start-update my-ig1 \
        --version template=my-template-A --canary-version template=my-template-B,target-size=10%

API

Stellen Sie in der API eine PATCH-Anfrage an folgenden URI:

https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

Die Nutzlast der Anfrage sollte sowohl die aktuelle Instanzvorlage als auch die neue Vorlage enthalten, die Sie testen möchten. Beispiel:

{
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/[NEW_TEMPLATE]",
   "targetSize": {
    "[percent|fixed]": [NUMBER|PERCENTAGE] # Use `fixed` for a specific number of instances
   }
  },
  {
   "instanceTemplate": "global/instanceTemplates/[CURRENT_TEMPLATE]"
  }
 ]
}

Dabei gilt Folgendes:

  • [NEW_TEMPLATE] ist der Name der neuen Vorlage, die Sie testen möchten.
  • [NUMBER|PERCENTAGE] ist die Anzahl bzw. der Prozentsatz der Instanzen für das Canary Update. Einen Prozentsatz können Sie nur einrichten, wenn die Instanzgruppe mindestens 10 Instanzen umfasst. Wenn dies nicht der Fall ist, legen Sie eine feste Anzahl fest.
  • [CURRENT_TEMPLATE] ist der Name der aktuellen Vorlage, mit der die Instanzgruppe ausgeführt wird.

Rollforward für ein Canary Update durchführen

Nach einem Canary Update können Sie entscheiden, ob Sie die Aktualisierung auf die gesamte Instanzgruppe anwenden oder ein Rollback durchführen möchten.

Konsole

  1. Gehen Sie in der GCP Console zur Seite "Instanzgruppen".

    Zur Seite "Instanzgruppen"

  2. Wählen Sie die Instanzgruppe aus, die Sie aktualisieren möchten.
  3. Klicken Sie oben auf der Seite auf Rolling Update.
  4. Aktualisieren Sie unter Vorlage die Zielgröße der Canary-Vorlage auf 100 %, um sie auf alle Instanzen anzuwenden. Sie können auch die primäre Vorlage durch die Canary-Vorlage ersetzen und die Zielgröße auf 100 % setzen. Dann können Sie das zweite Vorlagenfeld entfernen.
  5. Klicken Sie auf Aktualisieren, um das Update zu starten.

gcloud

Wenn Sie mit dem Canary Update zufrieden sind, führen Sie ein Rollforward der Aktualisierung durch, indem Sie dieselbe Anfrage stellen. Dabei legen Sie einen Wert für version fest und lassen --canary-version weg. Mit dem gcloud-Befehlszeilentool:

gcloud beta compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[NEW_TEMPLATE] [--zone [ZONE] | --region [REGION]]

API

Stellen Sie in der API eine PATCH-Anfrage an folgenden URI:

https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

Geben Sie im Text der Anfrage die neue Instanzvorlage als Wert für version an und nehmen Sie die alte Instanzvorlage heraus. Die Zielgröße lassen Sie ebenfalls weg, um das Update auf alle Instanzen anzuwenden. Der Text der Anfrage sieht dann so aus:

{
"versions": [
   {
   "instanceTemplate": "global/instanceTemplates/[NEW_TEMPLATE]" # New instance template
   }
 ]
}

Ersetzen Sie [NEW_TEMPLATE] durch den Namen der neuen Instanzvorlage, die verwendet werden soll.

Eine opportunistische oder proaktive Aktualisierung starten

Standardmäßig sind Aktualisierungen über das Befehlszeilentool gcloud proaktiv und solche in der API opportunistisch.

Bei proaktiven Aktualisierungen plant Compute Engine aktiv Maßnahmen, um die angeforderten Updates bei Bedarf auf die Instanzen anzuwenden. Dies bedeutet häufig, dass Instanzen vorausschauend gelöscht und neu erstellt werden.

Sie können sich auch für eine opportunistische Aktualisierung entscheiden, wenn eine proaktive zu störend wäre. Ein solches Update wird nur angewendet, wenn die verwaltete Instanzgruppe neue Instanzen erstellt. Dies geschieht meistens, wenn die Größe der Gruppe durch einen anderen Dienst, beispielsweise das Autoscaling, oder manuell durch einen Nutzer angepasst wird. Compute Engine startet hierbei nicht selbst Anfragen, um Aktualisierungen anzuwenden.

In bestimmten Fällen ist eine opportunistische Aktualisierung sinnvoll, um die Stabilität des Systems nicht unnötig zu gefährden. Wenn es sich beispielsweise um ein nicht kritisches Update handelt, das bei Bedarf angewendet werden kann, aber nicht dringend ist, und für die verwaltete Instanzgruppe Autoscaling eingerichtet ist, können Sie eine opportunistische Aktualisierung durchführen, damit Compute Engine Ihre bestehenden Instanzen nicht aktiv löscht, um das Update anzuwenden.

Legen Sie für das Typattribut im Befehlszeilentool gcloud oder der API den Wert OPPORTUNISTIC oder PROACTIVE fest, um eine Aktualisierung als opportunistisch oder proaktiv einzurichten.

Konsole

  1. Gehen Sie in der GCP Console zur Seite "Instanzgruppen".

    Zur Seite "Instanzgruppen"

  2. Wählen Sie die Instanzgruppe aus, die Sie aktualisieren möchten.
  3. Klicken Sie oben auf der Seite auf Rolling Update.
  4. Wählen Sie unter Vorlage eine Vorlage für die Aktualisierung der Instanzgruppe aus und legen Sie eine Zielgröße für die Vorlage fest.
  5. Wählen Sie als Updatemodus zwischen "proaktiv" (umgehend) und "opportunistisch" (bei Gelegenheit).
  6. Klicken Sie auf Aktualisieren, um das Update zu starten.

gcloud

Mit dem gcloud-Befehlszeilentool:

gcloud beta compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[INSTANCE_TEMPLATE] \
    --type [opportunistic|proactive] [--zone [ZONE] | --region [REGION]]

API

Fügen Sie in der Nutzlast der Aktualisierungsanfrage das Attribut type unter updatePolicy ein:

{
"updatePolicy": {
  "type": "PROACTIVE" # Performs a proactive update
},
"versions": [{
  "instanceTemplate": "global/instanceTemplates/[NEW_TEMPLATE]",
  }]
}

Dabei ist [NEW_TEMPLATE] der Name der neuen Vorlage, die Sie testen möchten. Wenn Sie eine opportunistische Aktualisierung vornehmen möchten, ersetzen Sie PROACTIVE durch OPPORTUNISTIC.

Rollierende Ersetzung oder rollierenden Neustart durchführen

Mit den Befehlen restart und replace können Sie auch einen rollierenden Neustart bzw. eine rollierende Ersetzung der VM-Instanzen in einer verwalteten Instanzgruppe durchführen. Ähnlich wie beim Befehl start-update können Sie jede der Konfigurationsoptionen für einen Neustart oder einen Ersetzungsvorgang festlegen. Bei einem rollierenden Neustart oder einer rollierenden Ersetzung ändert sich an der Instanzgruppe nichts. Dies gilt auch für die Instanzvorlage. Dabei werden einfach die Instanzen in der Gruppe mit der von Ihnen gewählten Methode aktualisiert.

Für eine rollierende Ersetzung oder einen rollierenden Neustart gibt es viele Gründe. Eine regelmäßige Aktualisierung der VM-Instanzen ist unter anderem in folgenden Fällen hilfreich:

  • Beheben von Speicherlecks
  • Neustart einer Anwendung, damit sie auf einer neuen virtuellen Maschine ausgeführt werden kann
  • Erzwingen einer regelmäßigen Ersetzung als Best Practice zum Testen von VMs
  • Aktualisierung des Betriebssystem-Images Ihrer VMs oder erneute Ausführung von Startskripts zur Aktualisierung der Software

So führen Sie eine Ersetzung aus, bei der alle Instanzen gelöscht und durch neue ersetzt werden:

Konsole

  1. Gehen Sie in der GCP Console zur Seite "Instanzgruppen".

    Zur Seite "Instanzgruppen"

  2. Wählen Sie die Instanzgruppe aus, die Sie aktualisieren möchten.
  3. Klicken Sie oben auf der Seite auf Schrittweises Neustarten/Ersetzen.
  4. Wählen Sie aus, ob die Instanzen neu gestartet oder ersetzt werden sollen. Bei einem Neustart werden die Methoden stop und start auf den Instanzen ausgeführt, beim Ersetzen werden die Instanzen dagegen aktiv gelöscht und neu erstellt.
  5. Optional können Sie die Werte für Konfigurationsoptionen wie Maximal zu viel, Maximal nicht verfügbar und Mindestwartezeit festlegen.
  6. Klicken Sie auf Neu starten oder Ersetzen, um das Update zu starten.

gcloud

gcloud beta compute instance-groups managed rolling-action replace [INSTANCE_GROUP]

Mit diesem Befehl werden alle Instanzen in der verwalteten Instanzgruppe nacheinander ersetzt. Falls ein vollständiges Ersetzen zu abrupt ist, können Sie stattdessen einen rollierenden Neustart durchführen. Dabei werden die Instanzen nicht gelöscht, sondern nur neu gestartet.

gcloud beta compute instance-groups managed rolling-action restart [INSTANCE_GROUP]

Diese Befehle lassen sich mit den Optionen für Aktualisierungen (z. B.: maxSurge, maxUnavailable, min-ready) weiter anpassen.

API

Stellen Sie in der API eine PATCH-Anfrage für die Gruppe und legen Sie eine proaktive updatePolicy fest, wobei für minimalAction entweder RESTART oder REPLACE gewählt wird. Dies hängt davon ab, ob Sie eine rollierende Ersetzung durchführen möchten, bei der jede Instanz gelöscht und durch eine neue ersetzt wird, oder einen rollierenden Neustart, bei dem jede Instanz gestoppt und neu gestartet wird. Sowohl für RESTART als auch für REPLACE müssen Sie die Attribute versions.instanceTemplate und versions.name angeben (zum Beispiel v2), um die Aktion zu starten.

Eine rollierende Ersetzung kann wie folgt aussehen:

PATCH https://www.googleapis.com/compute/beta/projects/myproject/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

{
 "updatePolicy": {
  "minimalAction": "REPLACE",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/example-template",
   "name": "v2"
  }
 ]
}

Ein rollierender Neustart kann folgendermaßen durchgeführt werden:

PATCH https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

{
 "updatePolicy": {
  "minimalAction": "RESTART",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/example-template",
   "name": "v2"
  }
 ]
}

Weitere Beispiele für Ersetzung/Neustart

Rollierender Neustart aller virtuellen Maschinen, wobei immer zwei gleichzeitig neu gestartet werden

Durch diesen Befehl werden immer zwei virtuelle Maschinen der Instanzgruppe gleichzeitig neu gestartet. Hierbei wird keine neue Instanzvorlage angegeben.

gcloud beta compute instance-groups managed rolling-action restart [INSTANCE_GROUP_NAME] \
    --max-unavailable 2 [--zone [ZONE] | --region [REGION]]

Rollierender Neustart aller VMs so schnell wie möglich

gcloud beta compute instance-groups managed rolling-action restart [INSTANCE_GROUP_NAME] \
    --max-unavailable 100% [--zone [ZONE] | --region [REGION]]

Rollierendes Ersetzen aller VMs so schnell wie möglich

gcloud beta compute instance-groups managed rolling-action replace [INSTANCE_GROUP_NAME]  \
    --max-unavailable 100% [--zone [ZONE] | --region [REGION]]

Regionale verwaltete Instanzgruppe aktualisieren

Eine regionale verwaltete Instanzgruppe enthält VM-Instanzen, die über mehrere Zonen innerhalb einer Region verteilt sind. Eine zonale verwaltete Instanzgruppe umfasst dagegen nur Instanzen innerhalb einer Zone. Mit einer regionalen verwalteten Instanzgruppe haben Sie die Möglichkeit, Ihre Instanzen über mehre Zonen zu verteilen, um die Verfügbarkeit Ihrer Anwendung zu erhöhen. Dies gilt insbesondere in extremen Fällen, in denen eine Zone ausfällt oder eine ganze Gruppe von Instanzen nicht mehr reagiert.

Die Aktualisierung einer regionalen verwalteten Instanzgruppe mit der Instance Group Updater-Funktion läuft im Prinzip genauso ab wie bei einer zonalen verwalteten Instanzgruppe. Die wenigen Unterschiede werden unten beschrieben. Wenn Sie die Aktualisierung einer regionalen Instanzgruppe starten, aktualisiert der Updater die Instanzen immer proportional und gleichmäßig über alle Zonen hinweg. Es ist nicht möglich auszuwählen, welche Instanzen in welchen Zonen zuerst aktualisiert werden, oder nur Instanzen in einer Zone zu aktualisieren.

Unterschiede zwischen der Aktualisierung einer regionalen und einer zonalen verwalteten Instanzgruppe

Bevor Sie mit der Aktualisierung einer regionalen verwalteten Instanzgruppe beginnen, sollten Sie sich mit den Unterschieden zum Update einer zonalen verwalteten Instanzgruppe vertraut machen:

  • Die Standardaktualisierungsparameter für regional verwaltete Instanzgruppen sind maxUnavailable=[NUMBER_OF_ZONES] und maxSurge=[NUMBER_OF_ZONES], wobei [NUMBER_OF_ZONES] die Anzahl der Zonen ist, die für die regional verwaltete Instanzgruppe ausgewählt wurde. Der Standardwert ist in diesem Fall 3.

  • Wenn Sie bei der Definition einer Aktualisierung feste Zahlen verwenden, müssen sie entweder 0 oder gleich bzw. größer als die Anzahl der Zonen sein, die der regionalen verwalteten Instanzgruppe zugeordnet sind. Wenn die Instanzgruppe zum Beispiel auf drei Zonen verteilt ist, können Sie maxSurge nicht auf 1 oder 2 setzen, weil der Updater jeder der drei Zonen eine zusätzliche Instanz erstellen muss.

Feste Zahlen oder Prozentsätze in Aktualisierungsanfragen verwenden

Wenn Sie in Ihrer Aktualisierungsanfrage eine feste Zahl angeben, wird diese durch die Anzahl der Zonen in der regionalen verwalteten Instanzgruppe dividiert und gleichmäßig darauf verteilt. Legen Sie beispielsweise maxSurge=10 fest, teilt der Updater 10 durch die Anzahl der Zonen in der Region und erstellt auf dieser Grundlage neue Instanzen. Falls sich die Anzahl der Instanzen nicht gleichmäßig auf die Zonen verteilen lässt, fügt der Updater die zusätzlichen Instanzen einer beliebigen Zone hinzu. Bei 10 Instanzen in drei Zonen befinden sich also in zwei Zonen drei Instanzen und in einer Zone vier. Für Canary Updates wird die gleiche Logik auf die Parameter maxUnavailable und targetSize angewendet.

Einen Prozentsatz können Sie nur angeben, wenn Ihre verwaltete Instanzgruppe mindestens 10 VM-Instanzen umfasst. Prozentsätze werden je nach Situation unterschiedlich behandelt:

  • Wenn Sie bei einem Canary Update einen Prozentsatz an VM-Instanzen festlegen, versucht der Updater, die Instanzen gleichmäßig auf die Zonen zu verteilen. Der Rest wird in jeder Zone auf- oder abgerundet, aber die Gesamtdifferenz beträgt nicht mehr als eine VM-Instanz pro Gruppe. Bei einer verwalteten Instanzgruppe mit 10 Instanzen und einem Prozentsatz für die Zielgröße von 25 % wird die Aktualisierung zum Beispiel auf zwei bis drei VM-Instanzen angewendet.

  • Wenn Sie für Aktualisierungsoptionen wie maxSurge und maxUnavailable einen Prozentsatz angeben, wird dieser unabhängig für jede Zone gerundet. Hier gelten dieselben Regeln wie für die Aktualisierung zonal verwalteter Instanzgruppen.

Rolling Updates überwachen

Ein Rolling Update kann einige Zeit dauern. Sie können den Stand der Aktualisierung überwachen, indem Sie eine Liste der Instanzen, die der verwalteten Instanzgruppe angehören, abrufen. Die Compute Engine API gibt den Instanzstatus zusammen mit einer Liste der Instanzen zurück.

Konsole

Ein Rolling Update für eine Gruppe können Sie auf der Detailseite der jeweiligen Instanzgruppe überwachen.

  1. Rufen Sie in der GCP Console die Seite "Instanzgruppen" auf.

    Zur Seite "Instanzgruppen"

  2. Wählen Sie die Instanzgruppe aus, die Sie aktualisieren möchten. Auf der Übersichtsseite der Instanzgruppe sehen Sie die Vorlagen, die die einzelnen Instanzen verwenden.
  3. Klicken Sie auf den Tab Details, um Einzelheiten anzuzeigen.

Auf der Seite Details sehen Sie die aktuelle und die angestrebte Anzahl der aktualisierten Instanzen für jede Instanzvorlage sowie die Aktualisierungsparameter.

gcloud

gcloud beta compute instance-groups managed list-instances [INSTANCE_GROUP_NAME] [--filter="zone:([ZONE])" | --filter="region:([REGION])"]

gcloud gibt eine Liste der Instanzen in der Gruppe und ihren jeweiligen Status zurück. Beispiel:

NAME               ZONE           STATUS   ACTION    INSTANCE_TEMPLATE  LAST_ERROR
vm-instances-9pk4  us-central1-f           CREATING  my-new-template
vm-instances-h2r1  us-central1-f           DELETING  my-old-template
vm-instances-j1h8  us-central1-f  RUNNING  NONE      my-old-template
vm-instances-ngod  us-central1-f  RUNNING  NONE      my-old-template

API

Stellen Sie in der API eine POST-Anfrage an den folgenden URI:

POST https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/listManagedInstances

Wenn es sich um eine regionale verwaltete Instanzgruppe handelt, ersetzen Sie zones/[ZONE] durch regions/[REGION].

Die API gibt eine Liste der Instanzen in der Gruppe mit ihrem jeweiligen Status und der aktuellen Aktion zurück.

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-j701",
   "id": "4251656203855893170",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  }
 ]
}

Gruppenstatus sowie ausstehende und aktuelle Aktionen

Der aktuelle Status jeder Instanz in einer verwalteten Instanzgruppe ist im Feld instanceStatus der jeweiligen Instanz angegeben. Wird eine Änderung an der Instanz vorgenommen, enthält auch das Feld currentAction einen Wert, damit Sie den Status der Aktualisierungen verfolgen können. Sobald die Instanz erfolgreich aktualisiert wurde, zeigt das Feld instanceStatus den derzeitigen Zustand der Instanz. Eine Liste gültiger Werte für das Feld instanceStatus finden Sie in der Dokumentation Instanzstatus prüfen.

Wenn eine Änderung an einer Instanz vorgenommen wird, enthält das Feld currentAction eine der folgenden Statusangaben. Andernfalls enthält das Feld currentAction den Wert NONE.

Mögliche Werte für currentAction:

  • ABANDONING: Die Instanz wird gerade aus der verwalteten Instanzgruppe entfernt.
  • CREATING: Die Instanz wird gerade erstellt.
  • CREATING_WITHOUT_RETRIES: Die Instanz wird ohne Neuversuche erstellt. Falls die Instanz nicht beim ersten Versuch erstellt werden kann, versucht die verwaltete Instanzgruppe nicht noch einmal, sie zu ersetzen.
  • DELETING: Die Instanz wird gerade gelöscht.
  • RECREATING: Die Instanz wurde gelöscht und wird gerade ersetzt.
  • REFRESHING: Die Instanz wird gerade aus den aktuellen Zielpools entfernt und anschließend zu den in der Liste enthaltenen Zielpools wieder hinzugefügt (diese Liste kann mit den bestehenden Zielpools identisch sein oder davon abweichen).
  • RESTARTING: Die Instanz wird gerade mit den Methoden stop und start neu gestartet.
  • VERIFYING : Die Instanz wurde erstellt und wird gerade verifiziert.

Auf Ebene der verwalteten Instanzgruppe fügt Compute Engine Werte in das Feld pendingActions ein, das angibt, für wie viele Instanzen derzeit bestimmte Aktionen ausstehen. Das Feld pendingActions kann beispielsweise folgende pendingActions-Werte enthalten:

CREATING: 3
DELETING: 3
RECREATING: 2
RESTARTING: 1

Dies bedeutet, dass drei Instanzen gelöscht, zwei ersetzt, eine neu gestartet und drei erstellt werden.

Aktualisierung rückgängig machen

Es gibt keinen eigenen Befehl, um eine Aktualisierung rückgängig zu machen und das System auf eine vorherige Version zurückzusetzen. Wenn Sie jedoch für ein Update (sei es ein vollständiges oder ein Canary Update) ein Rollback durchführen möchten, können Sie eine neue Aktualisierungsanfrage mit der Instanzvorlage stellen, auf die die Instanzen zurückgesetzt werden sollen.

Der folgende Befehl sorgt zum Beispiel dafür, dass eine Aktualisierung so schnell wie möglich rückgängig gemacht wird:

gcloud beta compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[OLD_INSTANCE_TEMPLATE] --max-unavailable 100% [--zone [ZONE] | --region [REGION]]

Ersetzen Sie [OLD_INSTANCE_TEMPLATE] durch den Namen der alten Instanzvorlage, auf die die Instanzgruppe zurückgesetzt werden soll.

Stellen Sie in der API eine PATCH-Anfrage an folgenden URI:

https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

Wenn es sich um eine regionale verwaltete Instanzgruppe handelt, ersetzen Sie zones/[ZONE] durch regions/[REGION].

Geben Sie im Text der Anfrage die alte Instanzvorlage als Wert für version an:

{ "updatePolicy":
  {
    "maxUnavailable":
    {
      "percent": 100
    }
  },
 "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/[OLD_TEMPLATE]" # Old instance template
    }
   ]
}

Der Instance Group Updater-Dienst behandelt dies als reguläre Aktualisierungsanfrage. Daher können Sie alle in diesem Dokument beschriebenen Aktualisierungsoptionen angeben.

Die Aktualisierungsgeschwindigkeit steuern

Standardmäßig werden Aktualisierungen nach einer entsprechenden Anfrage so schnell wie möglich durchgeführt. Wenn Sie sich nicht sicher sind, ob Sie ein Update vollständig anwenden möchten, oder wenn Sie Änderungen vorsichtig testen möchten, können Sie die Aktualisierung wie folgt verlangsamen:

  1. Starten Sie statt einer vollständigen Aktualisierung ein Canary Update.
  2. Legen Sie für minReadySeconds einen hohen Wert fest. Hiermit bestimmen Sie, wie viele Sekunden der Dienst wartet, bevor er eine Instanz als erfolgreich aktualisiert betrachtet und mit der nächsten Instanz fortfährt.
  3. Legen Sie für maxUnavailable und maxSurge einen niedrigen Wert fest. Damit sorgen Sie dafür, dass immer nur wenige Instanzen gleichzeitig aktualisiert werden.

Sie können die Aktualisierungsgeschwindigkeit auch mithilfe einer Kombination dieser Parameter steuern.

Aktualisierung anhalten

Es gibt keine eigene Methode bzw. keinen Befehl, um eine Aktualisierung anzuhalten. Sie können aber ein Update von proaktiv in opportunistisch ändern. Wenn die Größe der verwalteten Instanzgruppe nicht gerade von einem anderen Dienst wie Autoscaling angepasst wird, bedeutet der Wechsel zur opportunistischen Aktualisierung, dass diese "angehalten" wird.

Führen Sie den folgenden Befehl aus, um aus einer proaktiven Aktualisierung eine opportunistische zu machen:

gcloud alpha compute instance-groups managed rolling-action stop-proactive-update [INSTANCE_GROUP_NAME] \
    [--zone [ZONE] | --region [REGION]]

Die Aktualisierung anschließend vollständig anzuhalten, funktioniert folgendermaßen:

  1. Stellen Sie eine Anfrage, um zu ermitteln, wie viele Instanzen aktualisiert wurden.

    gcloud beta compute instance-groups managed list-instances [INSTANCE_GROUP_NAME] \
        [--zone [ZONE] | --region [REGION]]

    Das Tool gcloud gibt eine Liste der Instanzen in der Gruppe und ihren aktuellen Status zurück.

    NAME               ZONE           STATUS   ACTION    INSTANCE_TEMPLATE  LAST_ERROR
    vm-instances-9pk4  us-central1-f  RUNNING  NONE      my-new-template
    vm-instances-j1h8  us-central1-f  RUNNING  NONE      my-new-template
    vm-instances-ngod  us-central1-f  RUNNING  NONE      my-old-template
    

    In diesem Beispiel wurden zwei Instanzen bereits aktualisiert.

  2. Stellen Sie nun eine Anfrage für ein weiteres "Update". Geben Sie dabei die Zahl der schon aktualisierten Instanzen als Zielgröße an:

    gcloud beta compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
        --version template=my-old-template \
        --canary-version template=my-new-template,target-size=2 \
        [--zone [ZONE] | --region [REGION]]

    Der Updater-Dienst betrachtet diese Aktualisierung als abgeschlossen. Daher werden keine weiteren Instanzen aktualisiert und das Update wird angehalten.

Beziehung zwischen den Attributen "versions" und "instanceTemplate" einer verwalteten Instanzgruppe

Das Feld versions und das übergeordnete Feld instanceTemplate überschneiden sich in ihrer Funktion, da Sie durch beide Felder festlegen können, welche Instanzvorlage die verwaltete Instanzgruppe für das Erstellen neuer Instanzen verwenden soll. Der Unterschied zwischen instanceTemplate und versions besteht darin, dass Nutzer mit dem neuen Feld versions eine erweiterte (Canary-)Konfiguration mit zwei Vorlagen definieren können.

Aus Gründen der Abwärtskompatibilität unterstützen verwaltete Instanzgruppen auch weiterhin das übergeordnete Feld instanceTemplate. Sie sollten jedoch in Zukunft nur noch das Feld versions verwenden, da es die Funktionen von instanceTemplate mit einschließt. Beide Felder gleichzeitig zu nutzen, kann zu Unklarheiten und Verwirrung führen.

Wenn Sie beim Aufrufen der Methoden update() und patch() sowohl das Feld instanceTemplate als auch das Feld versions verwenden, gibt es drei verschiedene Möglichkeiten:

  • Sie legen für beide Felder den gleichen Wert fest.

    Dies ist eine gültige Anfrage. In diesem Fall entsteht keine Mehrdeutigkeit und die neue Instanzvorlage wird auf die verwaltete Instanzgruppe angewendet.

    Beispiel: In der folgenden Anfrage verweisen das übergeordnete Feld instanceTemplate und das Feld versions auf dieselbe Instanzvorlage, die sich von der aktuellen Vorlage unterscheidet. Die verwaltete Instanzgruppe wird auf die neue Instanzvorlage aktualisiert:

    {
     "instanceTemplate": "global/instanceTemplates/new-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • Sie legen für beide Felder abweichende Werte fest, aber nur einer unterscheidet sich von der aktuellen Instanzvorlage in der verwalteten Instanzgruppe.

    Dies ist eine gültige Anfrage. Das Feld, das von der aktuellen Einstellung abweicht, wird als der gewünschte Wert angewendet. Beispiel: Sie rufen die Methode get() auf, ändern eines der Felder und rufen dann die Methode update() mit nur einem geänderten Feld auf:

    {
     "instanceTemplate": "global/instanceTemplates/current-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • Sie legen für beide Felder Werte fest, die sich voneinander und von der aktuellen Instanzvorlage in der verwalteten Instanzgruppe unterscheiden.

    Diese Einstellung ist ungültig und gibt einen Fehler zurück, da keine klare Absicht erkennbar ist.

    {
     "instanceTemplate": "global/instanceTemplates/new-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/a-different-new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    

Die Felder versions und instanceTemplate sowie die Methode get()

Wenn Sie nur eine Instanzvorlage angeben – entweder über das übergeordnete Feld instanceTemplate oder über das Feld versions oder über beide – , gibt die Methode get() in ihrer Antwort beide Felder zurück. Dadurch ist das neue Feld versions abwärtskompatibel. Solange Sie nur eine Instanzvorlage in einem dieser Felder angeben, ändert sich an der Rückgabe der Methode get() im Feld instanceTemplate nichts.

Enthält das Feld versions dagegen zwei Instanzvorlagen, gibt die Methode get() ein leeres übergeordnetes Feld instanceTemplate zurück. Da es nicht möglich ist, im übergeordneten Feld instanceTemplate eine Canary-Konfiguration mit zwei Instanzvorlagen eindeutig anzugeben, wird dieses bei Canary Updates nicht verwendet.

Das Feld versions und die Methode setInstanceTemplate()

Aus Gründen der Abwärtskompatibilität wurde das Verhalten der Methode setInstanceTemplate() nicht geändert. Sie können weiterhin die Vorlage ändern, die die verwaltete Instanzgruppe verwendet, um neue Instanzen zu erstellen. Wenn Sie diese Methode aufrufen, wird das Feld versions mit der Instanzvorlage überschrieben, die durch die Methode setInstanceTemplate() angegeben wird.

Außerdem setzt die Methode die updatePolicy auf OPPORTUNISTIC. Dadurch wird verhindert, dass die verwaltete Instanzgruppe eine Instanzvorlage aktiv bereitstellt, die im Feld versions nicht explizit angegeben wurde.

Feedback und Fragen

Wir freuen uns über Feedback und nehmen gern Ihre Fragen entgegen. Bitte senden Sie Ihre Fragen an cloud-updater-feedback@google.com.

Weitere Informationen

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

Feedback geben zu...

Compute Engine-Dokumentation