In diesem Dokument wird beschrieben, wie Sie eine Canary-Bereitstellungsstrategie konfigurieren und verwenden.
Was ist ein Canary-Deployment?
Ein Canary-Deployment ist ein schrittweises Roll-out einer Anwendung, die Traffic zwischen einer bereits bereitgestellten Version und einer neuen Version, für eine Untergruppe von Nutzern verfügbar, bevor sie vollständig eingeführt werden.
Unterstützte Zieltypen
Die Canary-Bereitstellung in Cloud Deploy unterstützt alle Zieltypen, einschließlich der folgenden:
- Google Kubernetes Engine
- Cloud Run (nur Dienste, nicht jobs.)
- GKE Enterprise
Canary funktioniert auch mit mehrere Ziele.
Vorteile einer Canary-Bereitstellungsstrategie
Bei einem Canary-Deployment haben Sie die Möglichkeit, Ihre Anwendung teilweise freizugeben. In So können Sie sicher sein, dass die neue Version Ihrer Anwendung zuverlässig ist, allen Nutzenden bereitstellen.
Wenn Sie eine Bereitstellung in GKE oder GKE Enterprise vornehmen, Sie die neue Version Ihrer Anwendung beispielsweise auf einem eingeschränkten Anzahl der Pods. Die alte Version würde weiterhin funktionieren, aber mit mehr an die neuen Pods gesendet wird.
Wenn Sie die Bereitstellung in Cloud Run, Cloud Run teilt den Traffic zwischen der alten und der neuen Überarbeitung auf Prozentsätze, die Sie konfigurieren.
Canary-Typen
Mit Cloud Deploy können Sie die folgenden Canary-Typen konfigurieren Bereitstellung:
Automatisiert
Mit einem automatisiertes Canary konfigurieren Sie Cloud Deploy mit einer Reihe von die eine progressive Bereitstellung ausdrücken. Cloud Deploy weitere Vorgänge in Ihrem Namen ausführen, um Traffic aufzuteilen Prozentsätze zwischen der alten und der neuen Version.
Benutzerdefiniert – automatisiert
Für eine benutzerdefiniert automatisierte Canary-Version können Sie die Folgendes:
- Der Phasenname
- Das prozentuale Ziel
- Das für die Phase zu verwendende Skaffold-Profil
- Ob ein Prüfjob eingefügt werden soll oder nicht
Sie müssen jedoch keine Informationen zum Traffic-Balancing bereitstellen. Cloud Deploy erstellt die erforderlichen Ressourcen, wie beschrieben hier.
Benutzerdefiniert
Bei einem benutzerdefinierten Canary können Sie jede Canary-Phase separat konfigurieren. einschließlich der folgenden:
- Der Phasenname
- Das prozentuale Ziel
- Das für die Phase zu verwendende Skaffold-Profil
- Ob ein Prüfjob eingefügt werden soll oder nicht
Für eine vollständig benutzerdefinierte Canary-Version Konfiguration des Traffic-Balancing, wie beschrieben hier.
Phasen einer Canary-Bereitstellung
Wenn Sie einen Release für ein Canary-Deployment erstellen, wird das Roll-out mit
eine Phase für jedes Canary-Inkrement sowie eine letzte stable
-Phase für 100%.
Wenn Sie beispielsweise einen Canary-Test mit den Schritten 25%, 50 % und 75% konfigurieren, Die Einführung umfasst folgende Phasen:
canary-25
canary-50
canary-75
stable
Weitere Informationen zu Roll-out-Phasen, Jobs und Jobausführungen finden Sie unter Roll-outs verwalten
Was passiert während eines automatisierten oder benutzerdefinierten automatisierten Canary-Tests?
Zur Unterstützung Ihrer Canary-Bereitstellung umfasst Cloud Deploy spezielle beim Rendern Ihres Kubernetes-Manifests oder Konfiguration des Cloud Run-Dienstes:
GKE/Enterprise
So führt Cloud Deploy ein Canary-Deployment in netzwerkbasierte GKE und GKE Enterprise:
Sie geben den Namen der Bereitstellungsressource und der Dienstressource an.
Cloud Deploy erstellt eine zusätzliche Deployment-Ressource mit den Namen Ihres aktuellen Deployments plus
-canary
.Cloud Deploy ändert den Dienst so, dass die Auswahl auf die Pods im aktuellen Deployment und die Canary-Pods auswählen.
Cloud Deploy berechnet die Anzahl der Pods, die für den Canary-Version basierend auf der beschriebenen Berechnung hier. Diese Berechnung unterscheidet sich je nach ob Sie die Pod-Überbereitstellung aktivieren oder deaktivieren.
Wenn wir in die
stable
-Phase übergehen Cloud Deploy fügt die Labels hinzu, die zum Abgleichen von Pods verwendet werden sollen. sind sie für nachfolgende Canary-Läufe verfügbar.Cloud Deploy erstellt ein Deployment, das die phasenspezifischen Prozentsatz der Pods und aktualisiert ihn für jede Phase. Dies ist indem wir die Anzahl der Pods als Prozentsatz des Originals Anzahl der Pods. Dies kann zu einer ungenauen Aufteilung der Zugriffe führen. Bei Bedarf eine exakte Aufteilung der Zugriffe, können Sie diese mit der Gateway API erreichen.
Außerdem werden Secrets und ConfigMaps ebenfalls kopiert und mit
-canary
umbenannt.Während der
stable
-Phase wird das-canary
-Deployment auf null und das ursprüngliche Deployment wird durch das neue Deployment ersetzt.Cloud Deploy ändert das ursprüngliche Deployment erst, wenn
stable
.
Cloud Deploy stellt Pods bereit, um den angeforderten Canary-Test zu erreichen Prozent so genau wie möglich. Dies basiert auf der Anzahl der Pods, nicht auf Traffic zu den Pods. Wenn Sie möchten, dass die Canary-Version auf Traffic basiert, müssen die Gateway API verwenden.
Für die netzwerkbasierte GKE-Canary-Version haben Sie folgende Möglichkeiten: Aktivieren oder deaktivieren Sie die Pod-Überbereitstellung. In den folgenden Abschnitten wird beschrieben, wie Cloud Deploy die Anzahl der Pods, die für das Canary-Deployment in jeder Canary-Phase bereitgestellt werden.
Pod-Bereitstellung mit aktivierter Überbereitstellung
Überbereitstellung wird aktiviert (disablePodOverprovisioning: false
)
ermöglicht es Cloud Deploy, genügend zusätzliche Pods zu erstellen, um die
Gewünschter Canary-Prozentsatz basierend auf der Anzahl der Pods, die Ihre
bereits vorhandener Bereitstellung. Die folgende Formel zeigt,
Cloud Deploy berechnet die Anzahl der Pods, die für den
Canary-Deployment für jede Canary-Phase, wenn die Pod-Überbereitstellung
aktiviert:
math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))
Mit dieser Formel kann die aktuelle Anzahl der Replikate (die Anzahl der Pods, die Sie bereits vor diesem Canary-Test mit dem Canary-Prozentsatz multipliziert und das Ergebnis wird durch (100 minus den Prozentsatz) dividiert.
Wenn Sie z. B. 4 Pods aleady haben und die Canary-Phase 50 % beträgt, dann:
die Anzahl der Canary-Pods 4 beträgt. (Das Ergebnis von 100-percentage
wird als
Prozentsatz: 100-50=50
, behandelt als .50
.)
Die Pod-Überdimensionierung ist das Standardverhalten.
Pod-Bereitstellung mit deaktivierter Überbereitstellung
Sie können die Überbereitstellung deaktivieren (disablePodOverprovisioning: true
),
damit Cloud Deploy die Anzahl Ihrer Replikate nicht erhöht.
Die folgende Formel zeigt, wie Cloud Deploy den Pod berechnet Bereitstellung für das Canary-Deployment für jede Canary-Phase, wenn der Pod Überdimensionierung ist deaktiviert:
math.Ceil( (ReplicaCountOfDeploymentOnCluster + ReplicaCountOfCanaryDeploymentOnCluster) * percentage)
In dieser Formel ist ReplicaCountOfCanaryDeploymentOnCluster
nur vorhanden, wenn
gab es bereits eine Canary-Phase. Wenn dies die erste Canary-Phase ist,
ist keine ReplicaCountOfCanaryDeploymentOnCluster
.
Wenn Sie mit vier Pods beginnen, wird diese Zahl mit dem Canary-Prozentsatz multipliziert.
(z. B. 50 % oder .5
), um 2
zu erhalten. Die ursprüngliche Bereitstellung ist also
und zwei neue Pods für das Canary-Deployment erstellt. Wenn
Dann haben Sie eine Canary-Phase von 75 %, Sie haben 2
(ursprüngliche Bereitstellung) +2
(erste Canary-Phase), *.75
, um 3
Canary-Pods und den 1
-Pod zu erhalten, auf dem die
der ursprünglichen Bereitstellung.
Gateway GKE/Enterprise
So führt Cloud Deploy ein Canary-Deployment in GKE und GKE Enterprise mit der Gateway API:
Zusätzlich zu den Referenzen für das Deployment und den Dienst geben Sie HTTPRoute-Ressource mit einer
backendRefs
-Regel, die auf den Dienst verweist.Cloud Deploy erstellt ein neues Deployment mit dem Namen Ihrer ursprüngliches Deployment plus
-canary
und einen neuen Service mit dem ursprünglichen Dienstname plus-canary
.Außerdem werden Secrets, ConfigMaps und horizontale Pod-Autoscalings kopiert. und in
-canary
umbenannt.Cloud Deploy ändert für jede Canary-Phase die HTTP-Route um die Gewichtung zwischen den ursprünglichen Deployment-Pods und den Canary-Deployment-Pods basierend auf dem Prozentsatz für diese Phase.
Weil es bei der Übertragung von Änderungen an „
HTTPRoute
“ zu Verzögerungen kommen kann Ressourcen, können Sie die PropertyrouteUpdateWaitTime
in Ihr Konfiguration, sodass das System eine bestimmte Zeit Verbreitung können.Während der
stable
-Phase wird das-canary
-Deployment auf null und das ursprüngliche Deployment wird aktualisiert, um die Bereitstellung.Außerdem wird die HTTPRoute nun auf das von Ihnen angegebene Original zurückgesetzt.
Cloud Deploy ändert das ursprüngliche Deployment oder Dienst bis zur
stable
-Phase.
Cloud Run
So führt Cloud Deploy ein Canary-Deployment für Cloud Run:
Geben Sie für ein Canary-Deployment in Cloud Run
traffic
stanza in die YAML-Datei Ihres Dienstes ein.Beim Erstellen eines neuen Roll-outs für die Canary-Version teilt Cloud Deploy auf zwischen der vorherigen Version, die erfolgreich von Cloud Deploy und eine neue Version.
Wenn Sie die Unterschiede zwischen den Phasen einer Canary-Bereitstellung sehen möchten, können Änderungen im gerenderten Manifest pro Phase sehen, das im Release Inspector. Sie können das bereits tun, Einführung hat begonnen. Wenn Sie eine parallelen Bereitstellung aktiviert haben, können Sie auch die gerendertes Manifest.
Canary-Deployment konfigurieren
In diesem Abschnitt wird beschrieben, wie Sie die Bereitstellungspipeline und Ziele für Canary-Deployment.
Die hier aufgeführten Anleitungen beziehen sich nur auf die Canary-Konfiguration. Die Das Dokument Anwendung bereitstellen enthält allgemeine Anweisungen zum Konfigurieren und Ausführen der Bereitstellungspipeline.
Prüfen Sie, ob Sie die erforderlichen Berechtigungen haben
Zusätzlich zu den anderen Identity and Access Management-Berechtigungen, die Sie für die Verwendung von Cloud Deploy benötigen Sie die folgenden Berechtigungen, um weitere Aktionen ausführen, die möglicherweise für ein Canary-Deployment erforderlich sind:
clouddeploy.rollouts.advance
clouddeploy.rollouts.ignoreJob
clouddeploy.rollouts.cancel
clouddeploy.rollouts.retryJob
clouddeploy.jobRuns.get
clouddeploy.jobRuns.list
clouddeploy.jobRuns.terminate
Siehe IAM-Rollen und -Berechtigungen finden Sie weitere Informationen dazu, welche verfügbaren Rollen diese Berechtigungen enthalten.
skaffold.yaml
vorbereiten
Wie bei einer Standardbereitstellung benötigt auch die Canary-Version eine skaffold.yaml
-Datei, die
definiert, wie Manifeste und Dienstdefinitionen gerendert und bereitgestellt werden.
Die skaffold.yaml
, die Sie für ein Canary-Deployment erstellen, hat keine spezielle
über die Anforderungen für Standard-
Bereitstellung.
Manifest- oder Dienstdefinition vorbereiten
Wie bei einer Standardbereitstellung benötigt auch Ihre Canary-Version ein Kubernetes-Manifest oder ein Cloud Run-Dienstdefinition.
GKE und GKE Enterprise
Für Canary muss das Manifest Folgendes enthalten:
Ein Deployment und einen Dienst.
Der Dienst muss einen
app
-Selektor definieren und die Pods der Bereitstellung angegeben.Wenn Sie eine Gateway API-basierte Canary-Version verwenden, muss das Manifest auch ein HTTPRoute
Cloud Run
Für Canary in Cloud Run
Cloud Run-Dienstdefinitionsdatei ist ausreichend,
ohne eine traffic
-Stanza. Cloud Deploy verwaltet Aufteilung
zwischen der letzten erfolgreichen und der neuen Version.
Automatisiertes Canary konfigurieren
Die folgende Anleitung gilt für Cloud Run und Dienstbasiertes Netzwerk in GKE und GKE Enterprise Ziele. Wenn Sie die Kubernetes Gateway API mit GKE oder Informationen zu GKE Enterprise finden Sie in dieser Dokumentation.
Die automatisierte Canary-Version wird in der Definition der Bereitstellungspipeline konfiguriert:
GKE und GKE Enterprise
Fügen Sie in der Pipelinephase das Attribut strategy
so ein:
serialPipeline:
stages:
- targetId: prod
profiles: []
strategy:
canary:
runtimeConfig:
kubernetes:
serviceNetworking:
service: "SERVICE_NAME"
deployment: "DEPLOYMENT_NAME"
canaryDeployment:
percentages: [PERCENTAGES]
verify: true|false
In dieser Konfiguration...
SERVICE_NAME ist der Name des Kubernetes-Dienstes. die du in deinem Manifest definiert hast.
DEPLOYMENT_NAME ist der Name Ihrer Kubernetes-Instanz Bereitstellung, die in Ihrem Manifest definiert ist.
PERCENTAGES ist eine durch Kommas getrennte Liste mit Prozentsätzen Werte, die Ihre Canary-Inkremente darstellen, z. B.
[5, 25, 50]
.Außerdem ist
100
nicht enthalten, da eine Bereitstellung zu 100 % in der Canary-Version vorausgesetzt und vomstable
-Phase.Sie können die Bereitstellungsprüfung aktivieren (
verify: true
). In diesem Fall wird für jede Phase einverify
-Job aktiviert.
Cloud Run
Fügen Sie in der Pipelinephase das Attribut strategy
so ein:
serialPipeline:
stages:
- targetId: prod
profiles: []
strategy:
canary:
runtimeConfig:
cloudRun:
automaticTrafficControl: true
canaryDeployment:
percentages: [PERCENTAGES]
verify: true|false
In dieser Konfiguration...
- PERCENTAGES ist eine durch Kommas getrennte Liste mit Prozentsätzen
Werte, die Ihre Canary-Inkremente darstellen, z. B.
[25, 50, 75]
. Hinweis dass100
dabei nicht enthalten ist, weil eine Bereitstellung zu 100 % in der Canary-Version vorausgesetzt und vomstable
-Phase. - Sie können die Bereitstellungsprüfung aktivieren
(
verify: true
). In diesem Fall wird jedem Jobverify
ein Job hinzugefügt. Canary-Phase.
Benutzerdefinierte Canary-Version konfigurieren
Sie können die Canary-Version manuell konfigurieren, anstatt sich vollständig auf das die von Cloud Deploy bereitgestellt wird. Mit benutzerdefiniertem Canary Konfiguration angeben, geben Sie in der Definition der Bereitstellungspipeline Folgendes an:
Namen der Roll-out-Phasen
In einer vollständig automatisierten Canary-Version benennt Cloud Deploy die Phasen für Sie (z. B.
canary-25
,canary-75
oderstable
). Mit einem benutzerdefinierten Canary-Code Sie können jeder Phase einen beliebigen Namen geben, solange dieser noch einmalig ist. für diese Canary-Phase und berücksichtigt Einschränkungen für Ressourcennamen. Aber die letzte (100%) mussstable
sein.Prozentziele für jede Phase
Geben Sie die Prozentsätze separat pro Phase an.
Skaffold-Profile für die Phase
Sie können für jede Phase ein separates Skaffold-Profil oder dasselbe Profil verwenden. oder eine beliebige Kombination. Jedes Profil kann ein anderes Kubernetes-Manifest verwenden. oder Cloud Run-Dienstdefinition. Sie können auch mehr als für eine bestimmte Phase. Cloud Deploy kombiniert sie.
Ob es für die Phase einen Verifizierungsjob gibt
Wenn Sie die Überprüfung aktivieren,
skaffold.yaml
konfigurieren für zu überprüfen.
Alle Zieltypen für benutzerdefinierte Canary-Versionen unterstützt.
Benutzerdefinierte Canary-Konfigurationselemente
Die folgende YAML-Datei zeigt die Konfiguration für die Phasen der vollständig benutzerdefinierten Canary-Version Bereitstellung:
strategy:
canary:
# Custom configuration for each canary phase
customCanaryDeployment:
phaseConfigs:
- phaseId: "PHASE1_NAME"
percentage: PERCENTAGE1
profiles: [ "PROFILE_NAME" ]
verify: true | false
- …
- phaseId: "stable"
percentage: 100
profiles: [ "LAST_PROFILE_NAME" ]
verify: true|false
In dieser YAML-Datei
PHASE1_NAME
Der Name der Phase. Jeder Phasenname muss eindeutig sein.
[ "PROFILE_NAME" ]
Der Name des Profils, das für die Phase verwendet werden soll. Sie können dasselbe Profil verwenden, für jede Phase, eine andere für jede Phase oder eine beliebige Kombination. Außerdem können Sie mehrere Profile angeben. Cloud Deploy verwendet alle von Ihnen angegebene Profile sowie das Profil oder Manifest, das vom allgemeinen .
PERCENTAGE1
Entspricht dem Prozentsatz, der in der ersten Phase bereitgestellt werden soll. Jede Phase muss eine eindeutige Prozentsatz, der ein ganzer Prozentwert sein muss (nicht
10.5
für ) und die Phasen müssen in aufsteigender Reihenfolge sein.verify: true|false
Gibt Cloud Deploy an, ob ein Prüfjob für die Phase eingefügt werden soll. Skaffold verwendet in jeder Phase zur Verwendung der Verifizierung das gleiche Profil für Überprüfen Sie, ob für diese Phase für Rendering und Bereitstellung angegeben ist.
stable
Die letzte Phase muss den Namen
stable
haben.
Der Prozentsatz für die letzte Phase muss 100
sein. Phasen werden nach
in der Reihenfolge, in der Sie sie in dieser customCanaryDeployment
-Stanza konfigurieren, aber wenn
nicht in aufsteigender Reihenfolge, wird der Befehl zum
Bereitstellungspipeline registrieren
schlägt mit einem Fehler fehl.
Die Konfiguration für eine benutzerdefinierte Canary-Version enthält kein
runtimeConfig
Stanza. Das Hinzufügen von runtimeConfig
gilt als
benutzerdefinierten automatisierten Canary-Test.
Benutzerdefinierte automatisierte Canary-Version konfigurieren
Ein benutzerdefiniertes automatisiertes Canary ähnelt einem benutzerdefinierten Canary. da Sie die separaten Canary-Phasen mit benutzerdefinierten Phasennamen angeben, Prozentwerte, Skaffold-Profile und Verifizieren von Jobs. Bei einem benutzerdefinierten Canary-Code Sie stellen nicht die Konfigurationen bereit, die die Traffic-Aufteilung definieren – Cloud Deploy macht das für Sie erstellen, aber Sie bieten Skaffold-Profile die für jede Phase verwendet werden.
Fügen Sie zum Konfigurieren einer benutzerdefinierten automatisierten Canary-Version eine runtimeConfig
-Stanza wie folgt ein:
hier sehen,
und enthalten die customCanaryDeployment
-Stanza, wie gezeigt.
hier.
Canary-Deployment mit dem Service Mesh der Kubernetes Gateway API konfigurieren
Mit einer Cloud Deploy-Canary-Bereitstellung können Sie Anwendung in einem dienstbasierten Kubernetes-Netzwerk bereitstellen Alternativ können Sie das Service Mesh der Kubernetes Gateway API verwenden. In diesem Abschnitt wird dies beschrieben.
Sie können die Gateway API mit Istio oder anderen unterstützte Implementierung.
Richten Sie die Gateway API-Ressourcen ein:
Hierbei handelt es sich lediglich um Beispiele.
Im Kubernetes-Manifest, das an Cloud Deploy bei folgenden Aktionen bereitgestellt wird: die den Release erstellt haben und Folgendes enthalten:
Ein
HTTPRoute
die auf Ihre Gateway-Ressource verweistEine Bereitstellung
Ein Dienst
Bereitstellungspipeline und das Ziel konfigurieren, das Sie im Rahmen eines Canary-Deployments bereitstellen möchten in:
Die Konfiguration für das Ziel ist dieselbe wie für alle anderen Ziele.
Konfiguration der Bereitstellungspipeline in der Fortschrittsreihenfolge für die spezifisches Ziel, enthält eine
gatewayServiceMesh
-Stanza als Referenz auf Ihre DieHTTPRoute
-Konfiguration der Kubernetes Gateway API sowie Ihr Deployment und Service.strategy: canary: runtimeConfig: kubernetes: gatewayServiceMesh: httpRoute: "ROUTE" service: "SERVICE" deployment: "DEPLOYMENT" routeUpdateWaitTime: "WAIT_TIME" canaryDeployment: percentages: - 50
Wobei:
ROUTE ist Ihre httpRoute-Konfiguration, die das Routing definiert das gewünschte Verhalten.
SERVICE ist Ihre Dienstkonfiguration, die Cloud Deploy erfordert Canary-Bereitstellungen, um GKE und GKE Enterprise
DEPLOYMENT ist Ihre Deployment-Konfiguration, Cloud Deploy erfordert Canary-Bereitstellungen, um GKE und GKE Enterprise
WAIT_TIME ist die Zeitspanne, in der Cloud Deploy für Warten Sie, bis die Änderungen an der Ressource
HTTPRoute
vollständig übernommen wurden. verworfene Anfragen zu vermeiden. Beispiel:routeUpdateWaitTime: 60s
.Wenn Sie Canary mit der Gateway API ohne Istio und dem Gateway ausführen ist die API mit einem Google Cloud-Load-Balancer kann Traffic verloren gehen, wenn die Canary-Instanz herunterskaliert wird. Sie können konfigurieren Sie diese Einstellung, wenn Sie dieses Verhalten beobachten.
Parallele Bereitstellung mit einer Canary-Bereitstellungsstrategie verwenden
Sie können ein Canary-Deployment mit einer parallelen Bereitstellung ausführen. Das heißt, das Ziel, für das Sie die Bereitstellung schrittweise vornehmen, kann zwei oder mehr untergeordneten Zielen. Beispielsweise können Sie die Bereitstellung schrittweise in Clustern in separaten in verschiedenen Regionen.
Wie unterscheidet sich ein paralleler Canary von einem Canary mit einem einzelnen Ziel?
Wie beim Canary-Deployment mit einem einzelnen Ziel gilt auch hier Folgendes: GKE-Ziele benötigen Sie eine Kubernetes-Deployment-Konfiguration und eine Kubernetes-Dienstkonfiguration in Ihrem Manifest.
Wie bei Canary-Deployments mit einem einzelnen Ziel muss die Konfiguration der Bereitstellungspipeline muss eine
strategy.canary
-Stanza in der Phasendefinition für die entsprechenden Phase.Außerdem müssen Sie mehrere Ziele konfigurieren, und Sie müssen untergeordnete Ziele konfigurieren die auf mehrere Ziele verweist.
Wenn du einen Release erstellst, wird ein Controller-Roll-out und die untergeordneten Roll-outs werden erstellt.
Beide Roll-out-Typen – Verantwortliche und untergeordnete Rolle – haben separate Phasen für alle konfigurierten Canary-Prozentsätze und eine
stable
-Phase für die Canary 100%.Du kannst nicht fortfahren. ein untergeordnetes Roll-out.
Sie können nur Controller-Roll-outs fortsetzen. Wenn du zum nächsten Schritt übergehst werden die untergeordneten Rollouts ebenfalls fortgeführt, Cloud Deploy:
Du kannst es nicht wiederholen fehlgeschlagenen Jobs im Controller-Roll-out.
Sie können einen Job nur in untergeordneten Roll-outs wiederholen.
Sie können nicht ignorieren. fehlgeschlagenen Jobs im Controller-Roll-out.
Fehlgeschlagene Jobs können nur in untergeordneten Roll-outs ignoriert werden.
Sie können ein Controller-Roll-out abbrechen. Untergeordnete Roll-outs können jedoch nicht abgebrochen werden.
Sie können Jobausführungen beenden nur für ein untergeordnetes Roll-out und nicht für ein Controller-Roll-out.
Vorgehensweise, wenn ein paralleles Roll-out in der Canary-Version fehlschlägt
Wenn ein untergeordnetes Roll-out fehlschlägt, kann das Controller-Roll-out zu einem anderen Roll-out je nachdem, was mit den untergeordneten Roll-outs geschieht:
Wenn ein oder mehrere untergeordnete Roll-outs fehlschlagen, aber immer noch mindestens ein untergeordnetes Roll-out erhalten ist
IN_PROGRESS
, das Controller-Roll-out bleibtIN_PROGRESS
.Wenn ein oder mehrere untergeordnete Roll-outs fehlschlagen, aber mindestens ein untergeordnetes Roll-out erfolgreich ist, Das Controller-Roll-out ist
HALTED
, wenn es nach dem aktuellen Status weitere Phasen gibt eins.Wenn dies die
stable
-Phase ist, ist das Controller-Roll-outFAILED
.HALTED
gibt Ihnen die Möglichkeit, entweder ignore, wiederholen Fehlgeschlagene Jobs innerhalb des fehlgeschlagenen untergeordneten Roll-outs oder Controller-Roll-out abbrechen und verhindern, dass weitere Aktionen an den untergeordneten Roll-outs ausgeführt werden.Wenn das Controller-Roll-out aufgrund eines fehlerhaften untergeordneten Elements den Status
HALTED
hat und Sie ignorieren den fehlgeschlagenen Job im untergeordneten Roll-out, wird der Controller Roll-out wird in den StatusIN_PROGRESS
zurückgesetzt.
Konfigurierte Canary-Version ausführen
So führen Sie das Canary-Deployment aus:
Registrieren Sie die konfigurierte Bereitstellungspipeline und -ziele.
gcloud deploy apply --file=PIPELINE
Die Bereitstellungspipeline umfasst die automatisierte oder benutzerdefinierte Canary-Konfiguration, für die gewählte Laufzeit.
Bei diesem Befehl wird davon ausgegangen, dass Ihre Ziele in derselben Datei definiert sind oder die andernfalls bereits registriert sind. Wenn nicht, registrieren Sie Ihre Ziele .
Release erstellen:
gcloud deploy releases create RELEASE_NAME \ --delivery-pipeline=PIPELINE_NAME \ --region=REGION
Die von
PIPELINE_NAME
identifizierte Bereitstellungspipeline die in diesem Dokument beschriebene automatisierte oder benutzerdefinierte Canary-Konfiguration enthält. Dokument.Canary-Version fortsetzen:
gcloud-CLI
gcloud deploy rollouts advance ROLLOUT_NAME \ --release=RELEASE_NAME \ --delivery-pipeline=PIPELINE_NAME \ --region=REGION
Wobei:
ROLLOUT_NAME
ist der Name des aktuellen Roll-outs. mit der nächsten Phase fortfahren.RELEASE_NAME
ist der Name des Release, der Teil dieses Rollouts ist.PIPELINE_NAME
ist der Name der Übermittlung mit der Sie die Bereitstellung dieses Release verwalten.REGION
ist der Name der Region, in der die Release erstellt wurde, z. B.us-central1
. Das ist ein Pflichtfeld.In der Google Cloud SDK-Referenz finden Sie weitere Informationen zu den
gcloud deploy rollouts advance
-BefehlGoogle Cloud Console
Klicken Sie auf Ihre Pipeline, die in der Liste der Lieferpipelines angezeigt wird.
Die Detailseite der Bereitstellungspipeline zeigt eine grafische Darstellung der den Fortschritt Ihrer Bereitstellungspipeline anzuzeigen.
Klicken Sie auf dem Tab Rollouts unter Details zur Bereitstellungspipeline auf den Namen des Roll-outs.
Die Seite mit den Roll-out-Details für dieses Roll-out wird angezeigt.
Beachten Sie, dass das Roll-out in diesem Beispiel eine
canary-50
-Phase und einenstable
. Ihr Roll-out kann mehr Phasen oder andere Phasen umfassen Phasen.Klicken Sie auf Einführung fortsetzen.
Die Einführung geht in die nächste Phase über.
Übersprungene Phasen
Wenn Sie eine Canary-Version bereitstellen und Ihre Anwendung noch nicht dort bereitgestellt wurde: überspringt Cloud Deploy die Canary-Phase und führt die stabile . Weitere Informationen finden Sie unter Phasen das erste Mal überspringen. um die Ursache zu ermitteln.