Kontinuierliche Bereitstellung in Compute Engine unter Verwendung von Ansible mit Spinnaker

In dieser Anleitung wird beschrieben, wie eine Pipeline für kontinuierliche Bereitstellung mit Ansible, Spinnaker und Google Compute Engine eingerichtet wird (siehe folgendes Diagramm). Bei dieser Architektur wird das Verankern und Bereitstellen unveränderlicher Images als Beispiel verwendet.

architecture for baking and deploying immutable images

Spinnaker ist ein Open-Source-Tool für die Orchestrierung von Continuous Delivery Pipelines, die Software für Cloud-Ressourcen bereitstellen. Es wird in der Regel für Bereitstellungen verwendet, die auf Debian-Paketen basieren. Mithilfe von Packer-Vorlagen können Sie Spinnaker aber so konfigurieren, dass die Bereitstellung Ihrer Wahl unterstützt wird.

Falls Sie das Open-Source-Konfigurations-Tool Ansible bereits verwenden, sind Sie mit Infrastruktur als Code vertraut. Bei Spinnaker kombinieren Sie Infrastruktur als Code mit unveränderlicher Infrastruktur. Bei unveränderlicher Infrastruktur werden Änderungen in Artefakte wie Virtual Machine-(VM)- oder Container-Images verankert, anstatt sie inkrementell auf Server mit langer Ausführungszeit anzuwenden.

Ziele

  • Bereitstellung von Spinnaker in Compute Engine mithilfe von Google Cloud Deployment Manager
  • Vorbereitung eines GitHub-Repositorys für die Verwendung mit der Spinnaker-Pipeline
  • Erstellung einer dreistufigen Spinnaker-Pipeline: Testen, Verankern und Bereitstellen
  • Ausführung der Pipeline auf zwei Arten: manuell und mithilfe einer GitHub-pull-Anfrage
  • Rollback von Änderungen mithilfe einer Rot-Schwarz-Bereitstellungsstrategie

Kosten

In dieser Anleitung werden kostenpflichtige Komponenten der Cloud Platform verwendet, darunter:

  • Compute Engine
  • Google Cloud Load Balancing
  • Google Cloud Storage
  • Google Cloud IAM

Sie können mithilfe des Preisrechners eine Kostenschätzung für Ihre voraussichtliche Nutzung erstellen.

Neuen Nutzern der Cloud Platform steht möglicherweise eine kostenlose Testversion zur Verfügung.

Vorbereitung

  1. Melden Sie sich in Ihrem Google-Konto an.

    Wenn Sie noch kein Konto haben, registrieren Sie sich hier für ein neues Konto.

  2. Wählen Sie ein GCP-Projekt aus oder erstellen Sie eines.

    Zur Seite "Ressourcen verwalten"

  3. Prüfen Sie, ob die Abrechnung für Ihr Google Cloud Platform-Projekt aktiviert ist.

    Informationen zum Aktivieren der Abrechnung

  4. Aktivieren Sie die Compute Engine erforderliche API.

    Aktivieren Sie die API

Sie laden die restlichen Komponenten wie etwa die Spinnaker-Umgebung und eine Beispiel-App von GitHub herunter und stellen sie bereit.

Vor der Bereitstellung des Stapels müssen Sie sicherstellen, dass das Standarddienstkonto über die notwendigen IAM-Rollen verfügt, um die Anleitung abschließen zu können.

  1. Rufen Sie in der Google Cloud Platform Console die Cloud IAM-Seite auf.

    Cloud IAM aufrufen

  2. Ihr Google API-Dienstkonto muss die folgenden Cloud IAM-Rollen umfassen:

    • Compute-Instanzadministrator (Version 1)
    • Compute-Netzwerkadministrator
    • Compute Storage-Administrator
    • Storage-Administrator

    Informationen zur Erstellung von Dienstkonten und zur Einrichtung von Cloud IAM-Rollen finden Sie unter Neues Dienstkonto erstellen.

  3. Führen Sie schließlich alle Terminalbefehle in dieser Anleitung über die Cloud Shell aus.

    Cloud Shell öffnen

Spinnaker bereitstellen

Zuerst stellen Sie Spinnaker in Compute Engine mithilfe von Deployment Manager bereit.

  1. Starten Sie die Spinnaker-Umgebung mit dem Deployment Manager über das vorbereitete GitHub-Repository:

    git clone https://github.com/GoogleCloudPlatform/spinnaker-deploymentmanager
    cd spinnaker-deploymentmanager
    export GOOGLE_PROJECT=$(gcloud config get-value project)
    export DEPLOYMENT_NAME="${USER}-test1"
    export JENKINS_PASSWORD=$(openssl rand -base64 15)
    gcloud deployment-manager deployments create --template config.jinja ${DEPLOYMENT_NAME} --properties jenkinsPassword:${JENKINS_PASSWORD}

    Es kann einige Minuten dauern, bis die Bereitstellung abgeschlossen ist. Dann ist die Spinnaker-Instanz bereit.

  2. Speichern Sie den Instanz-URI in einer Variablen, um leicht darauf verweisen zu können:

    export SPINNAKER_VM=$(gcloud compute instances list --filter="name~${DEPLOYMENT_NAME}-spinnaker.+" --uri)
  3. Stellen Sie über SSH eine Verbindung zu der Spinnaker-Instanz her und leiten Sie die Ports für die Spinnaker-UI und die Jenkins-UI an Ihre Cloud Shell weiter:

    gcloud compute ssh ${SPINNAKER_VM} -- -L 8081:localhost:8081 -L 8082:localhost:8082

    Spinnaker wird mit einem Startskript konfiguriert. Es kann bis zu zehn Minuten dauern, bis dieses abgeschlossen ist. Sobald das Skript abgeschlossen ist und Spinnaker bereitsteht, wird eine Meldung ähnlich wie die folgende in /var/log/syslog angezeigt:

    $ tail /var/log/syslog
    ...
    INFO startup-script: Return code 0.
    INFO Finished running startup scripts.
    ...
    
  4. Klicken Sie auf die Cloud Shell-Schaltfläche Webvorschau.

  5. Klicken Sie auf Port ändern > Port 8081, um die Spinnaker-Benutzeroberfläche in Ihrem Browser zu öffnen.

    Click preview button

    Spinnaker wird in einem neuen Tab geöffnet:

    Spinnaker opens in a new tab

Anwendung zum Verankern mit Ansible konfigurieren

In dieser Anleitung stellen Sie eine Beispielanwendung (sample-app) bereit.

  1. Verzweigen Sie das Repository auf GitHub zu Ihrem eigenen Konto.
  2. Klonen Sie sample-app auf Ihrem Computer:

    git clone git@github.com:YOUR_GH_USER/sample-app.git
    

Dieses Repository enthält die Datei bake.yml,. Dabei handelt es sich um ein Ansible-Playbook, das während des Verankerungsschritts lokal von Packer ausgeführt wird. Dieses Playbook ist für das Erstellen der Anwendung und Installieren der benötigten Dienste verantwortlich. Wird eine Compute Engine-Instanz mit dem Image gestartet, werden die Dienste automatisch gestartet und sind bereit, Traffic weiterzuleiten. Im Repository befindet sich auch die Datei build.sh. Dieses Skript wird von Jenkins während der Testphase der Spinnaker-Pipeline aufgerufen und sollte die Tests für Ihre Anwendung ausführen sowie bei Bestehen der Tests einen Null-Fehlercode zurückgeben.

Die von Spinnaker aufgerufene Packer-Vorlage sieht wie folgt aus:

    "provisioners": [
        {
        "type": "shell",
        "inline": ["sudo apt-add-repository -y ppa:ansible/ansible",
                "sudo apt-get update",
                "sudo apt-get install -y ansible=2.3.0.0-1ppa~xenial
    git=1:2.7.4-0ubuntu1",
                "sudo git clone [[user 'repository']] /opt/go/src/deploy",
                "cd /opt/go/src/deploy && sudo git checkout [[user
    'repository_hash']]",
                "sudo ANSIBLE_HOST_KEY_CHECKING=false ansible-playbook -i
    'localhost,' bake.yml"]
        }
    ]

Diese Vorlage wird der Spinnaker-VM während der Bereitstellung hinzugefügt und in /opt/rosco/config/packer/gce-ansible.json geschrieben. Auf die Vorlage wird später verwiesen, wenn Sie die Pipeline konfigurieren.

Die Bereitstellung in der Packer-Vorlage führt Folgendes durch:

  • Sie installiert Ansible aus dem Personal Packages Archive (PPA).
  • Sie klont das Repository und prüft den von der Pipeline weitergeleiteten Commit-Hashwert.
  • Sie führt Ansible mit der Playbook-Datei bake.yml aus.

In diesem Beispiel führt das Ansible-Playbook Folgendes durch:

  • Es installiert und konfiguriert Nginx für den Upstream zum Anwendungs-Port.
  • Es lädt golang herunter und installiert die Datei.
  • Es kompiliert und installiert die Anwendung.
  • Es installiert systemd-Dienste für die Ausführung der Anwendung beim Start.

Sie sollten das Ansible-Playbook so auf Ihre Anwendung anpassen, dass beim Abschluss alle Laufzeitabhängigkeiten, die Konfiguration, Protokollierung und der Dienststart installiert sind und beim ersten Start einer mit dem Image erstellten Instanz ausgeführt werden. Dabei handelt es sich um ein Kernkonzept des Verankerns von Images, da sie nach ihrer Erstellung nicht mehr geändert werden.

Spinnaker-Anwendung erstellen

In diesem Abschnitt erstellen Sie eine neue Spinnaker-Anwendung und bereiten sie für die Beispielanwendungspipeline vor, indem Sie ein Lastenausgleichsmodul und eine Firewall hinzufügen. GCP-Lastenausgleichsmodule verwenden Weiterleitungsregeln. Daher müssen Sie die Firewallregeln auf die Instanzen anwenden, um Traffic zuzulassen. Der Vorgang zum Erstellen und Anwenden von Weiterleitungsregeln und Firewalls wird abstrahiert und für Sie in Spinnaker bereitgestellt.

Gehen Sie im Tab Applications (Anwendungen) in Spinnaker so vor:

  1. Klicken Sie oben rechts in der Benutzeroberfläche auf Actions (Aktionen) > Create Application (Anwendung erstellen).
  2. Setzen Sie das Feld Name auf sample.
  3. Setzen Sie das Feld Owner Email (E-Mail des Inhabers) auf Ihre E-Mail-Adresse.
  4. Setzen Sie das Feld Account(s) (Konto/Konten) auf my-google-account.
  5. Klicken Sie auf Create (Erstellen).

    Image

Lastenausgleichsmodul erstellen

Erstellen Sie als Nächstes ein Lastenausgleichsmodul mit HTTP-Systemdiagnosen:

  1. Klicken Sie oben rechts in der Benutzeroberfläche auf Load Balancers (Lastenausgleichsmodule).
  2. Klicken Sie auf die Schaltfläche Create Load Balancer (Lastenausgleichsmodul erstellen).
  3. Als Typ wählen Sie für das Lastenausgleichsmodul Network (Netzwerk) aus.
  4. Klicken Sie auf Create network load balancer (Netzwerklastenausgleichsmodul erstellen).
  5. Setzen Sie TCP Port Range (TCP-Port-Bereich) auf 80.
  6. Aktivieren Sie das Kästchen Enable health check? (Systemdiagnose aktivieren?) .
  7. Klicken Sie auf Create (Erstellen).

    Image

Spinnaker führt die notwendigen Aufgaben in Ihrem GCP-Konto aus, um das Lastenausgleichsmodul und die Weiterleitungsregeln zu erstellen.

Firewall erstellen

Erstellen Sie als Nächstes eine Firewall für die Anwendung:

  1. Klicken Sie rechts oben auf Firewalls.
  2. Klicken Sie auf Create Firewall (Firewall erstellen) und treffen Sie die folgenden Auswahlen:

    • Legen Sie unter Location (Position) im Feld Detail (Details) die Option http fest und geben Sie im Feld Description (Beschreibung) allow-http ein.
    • Klicken Sie unter Targets (Ziele) auf das Drop-down-Menü Targets (Ziele). Klicken Sie dann auf Specify target tags (Zieltags angeben) und auf Add New Target Tag (Neues Zieltag hinzufügen). Geben Sie "allow-http" ein.
    • Klicken Sie unter Source Filters (Quellfilter) und Source CIDRs (Quell-CIDRs) auf Add New Source CIDR (Neues Quell-CIDR hinzufügen), 0.0.0.0/0.
    • Klicken Sie unter Ingress auf Add New Protocol and Port Range (Neuen Protokoll- und Portbereich hinzufügen) und setzen Sie Protocol (Protokoll) auf TCP. Stellen Sie Start Port (Startport) und End Port (Endport) auf 80 ein.
  3. Klicken Sie auf Create (Erstellen).

    Image

Spinnaker führt die notwendigen Aufgaben in Ihrem GCP-Konto aus, um die Firewallregeln zu erstellen.

Spinnaker-Pipeline erstellen

In diesem Abschnitt definieren Sie die Pipeline der Phasen zum Testen, Verankern und Bereitstellen Ihrer Anwendung. Die Phasen werden über GitHub-Webhooks ausgelöst.

Image

Erstellen Sie in der Beispielanwendung die Pipeline wie folgt:

  1. Klicken Sie auf Pipelines und dann auf Create Pipeline or Strategy (Pipeline oder Strategie erstellen).

    Image

  2. Setzen Sie Type (Typ) auf Pipeline.

  3. Setzen Sie Pipeline Name (Name der Pipeline) auf sample-app.

  4. Klicken Sie auf Create Pipeline (Pipeline erstellen).

Trigger konfigurieren und Parameter hinzufügen

Erstellen Sie einen Trigger, der ausgelöst wird, damit bei einem Commit ins sample-app-Repository die Pipeline die neue Version erstellt und bereitstellt. Parameter durchlaufen die Pipelinephasen und werden in der Vorlage gce-ansible.json referenziert. Parameter sorgen auch für eine mehr generische Gestaltung Ihrer Pipeline, damit sie als Vorlage für andere Anwendungen verwendet werden kann.

  1. Konfigurieren Sie GitHub-Webhooks mit einem Signatur-Secret, damit Sie Commit-Benachrichtigungen für das Repository erhalten.
  2. Generieren Sie von Ihrem lokalen Terminal aus ein Secret für die gemeinsame Nutzung mit der Spinnaker-Pipelinekonfiguration:

    export GH_WEBHOOK_SECRET=$(openssl rand -base64 15)
    echo $GH_WEBHOOK_SECRET
  3. Klicken Sie in der Spinnaker-UI unter Automatische Trigger auf Trigger hinzufügen und füllen Sie die Felder so aus:

    • Wählen Sie als Type (Typ) Git aus.
    • Wählen Sie als Repo Type (Repository-Typ) github aus.
    • Setzen Sie Organization or User (Organisation oder Nutzer) auf den Inhaber des Repositorys.
    • Setzen Sie Project (Projekt) auf den Repository-Namen sample-app.
    • Setzen Sie Branch (Verzweigung) auf master.
    • Setzen Sie Secret auf den Wert des zuvor generierten GH_WEBHOOK_SECRET.
  4. Klicken Sie auf Save Changes (Änderungen speichern).

    Image

Pipeline-Parameter hinzufügen

Fügen Sie einen Pipeline-Parameter hinzu, um die Repository-URL anzugeben. Dieser Parameter wird später verwendet.

  1. Klicken Sie unter Parameter auf Add Parameter (Parameter hinzufügen).
  2. Setzen Sie Name auf repository.
  3. Setzen Sie Default Value (Standardwert) auf die HTTPS-Klon-URL des GitHub-Repositorys. Ersetzen Sie [YOUR_GH_USER] durch Ihren GitHub-Nutzernamen.

    https://github.com/[YOUR_GH_USER]/sample-app.git
    
  4. Klicken Sie auf Save Changes (Änderungen speichern).

    Image

Testphase erstellen

Die Testphase startet einen Jenkins-Job zum Testen Ihrer Anwendung vor der Bereitstellung. Der Job ruft das Skript build.sh im Stammverzeichnis des Repositorys auf.

  1. Klicken Sie oben auf der Seite Pipeline configuration (Pipeline-Konfiguration) auf Add stage (Phase hinzufügen).
  2. Wählen Sie als Type (Typ) Jenkins aus.
  3. Geben Sie als Name "Test" ein und nehmen Sie dann die folgende Auswahl vor:

    • Wählen Sie unter Jenkins Configuration (Jenkins-Konfiguration) für Master die Option Jenkins aus.
    • Wählen Sie für Job die Option runSpinnakerScript aus.
  4. Nehmen Sie unter Job Parameters (Jobparameter) die folgende Auswahl vor:

    • Setzen Sie COMMAND auf bash build.sh.
    • Setzen Sie REPO_URL auf ${parameters.repository}.
  5. Klicken Sie auf Save Changes (Änderungen speichern).

    Image

Verankerungsphase erstellen

Die Phase zum Verankern mit Ansible wird nach der Testphase ausgeführt. Sie verwenden Ihre benutzerdefinierte gce-ansible.json-Vorlage, um die Ansible-Bereitstellung auszuführen und ein neues unveränderliches Image für die Bereitstellung zu generieren.

  1. Klicken Sie auf Add Stage (Phase hinzufügen).
  2. Wählen Sie als Type (Typ) Bake (Verankern) aus.
  3. Geben Sie als Name der Phase "Bake with Ansible" ein und prüfen Sie, ob Abhängig von auf Test eingestellt ist.
  4. Nehmen Sie unter Bake Configuration (Verankerungskonfiguration) die folgende Auswahl vor:

    • Setzen Sie Package (Paket) auf None (Keines).
    • Klicken Sie für Base OS (Basis-Betriebssystem) auf xenial (v16.04).
    • Klicken Sie für Base Label (Basis-Label) auf Release.
    • Wählen Sie für Rebake (Neu verankern) das Kästchen Rebake image without regard to the status (Image neu verankern, ohne Status einer vorhandenen Verankerung zu berücksichtigen) aus.
  5. Klicken Sie auf Show Advanced Options (Erweiterte Optionen anzeigen).

  6. Setzen Sie Template File Name (Name der Vorlagendatei) auf gce-ansible.json.

  7. Klicken Sie auf Add Extended Attribute (Erweitertes Attribut hinzufügen).

    • Setzen Sie Key (Schlüssel) auf repository und Value (Wert) auf ${parameters.repository}. Klicken Sie danach auf Add (Hinzufügen).
    • Klicken Sie noch einmal auf Add Extended Attribute (Erweitertes Attribut hinzufügen), setzen Sie Key (Schlüssel) auf repository_hash und Value (Wert) auf ${trigger.hash ?: 'master'}. Klicken Sie danach auf Add (Hinzufügen).
    • Setzen Sie Base Image (Basis-Image) auf ubuntu-1604-xenial-v20170328.
  8. Klicken Sie auf Save Changes (Änderungen speichern).

    Image

Bereitstellungsphase erstellen

Die Bereitstellungsphase wird nach der Phase des Verankerns mit Ansible ausgeführt und führt die gesamte Automatisierung zur Erstellung neuer Servergruppen mit vom verankerten Image aus gestarteten VMs durch. Dabei werden diese dem Lastenausgleichsmodul hinzugefügt und die alte Servergruppe wird mithilfe einer Rot-Schwarz-(Blau-Grün)-Strategie ersetzt, damit ein Rollback der Änderungen möglich ist.

  1. Klicken Sie auf die Schaltfläche Add stage (Phase hinzufügen).
  2. Wählen Sie als Type (Typ) Deploy (Bereitstellen) aus.
  3. Setzen Sie Stage Name (Name der Phase) auf Deploy (Bereitstellen) und prüfen Sie, ob Depends On (Abhängig von) auf Bake with Ansible (Mit Ansible verankern) gesetzt ist.
  4. Klicken Sie unter Deploy Configuration (Bereitstellungskonfiguration) auf die Schaltfläche Add server group (Servergruppe hinzufügen).
  5. Wählen Sie Copy configuration from: None (Konfiguration kopieren von: Keine) aus.
  6. Klicken Sie auf Continue without a template (Ohne Vorlage fortfahren) und nehmen Sie dann die folgende Auswahl vor:

    • Setzen Sie Stack (Stapel) auf nginx.
    • Wählen Sie Strategy: Red/Black (Strategie: Rot-Schwarz) aus.
    • Setzen Sie Maximum number of server groups to leave (Maximale Anzahl der zu belassenden Servergruppen) auf 2.
    • Wählen Sie unter Load Balancer den zuvor erstellten Load Balancer sample aus.
    • Wählen Sie unter Firewalls die zuvor erstellte Firewall sample-http aus.

    Image

Deployment-Clusterkonfiguration fortsetzen

  1. Wählen Sie unter Instance Type (Instanztyp) die Option General Purpose (Allgemein) und für die Größe Small (Klein) aus.
  2. Aktivieren Sie unter AutoHealing Policy (Richtlinie für automatische Reparatur) die Option Enable AutoHealing (Automatische Reparatur aktivieren).
  3. Setzen Sie HTTP Health Check (HTTP-Systemdiagnose) auf die bei Erstellung des Load Balancers automatisch erstellte Systemdiagnose sample-hc-.
  4. Wählen Sie Metric: percent (Messwert: Prozent) aus und setzen Sie Max Unavailable (Max. nicht verfügbar) auf 10 %.
  5. Prüfen Sie, ob unter Advanced Settings (Erweiterte Einstellungen) im Feld Tags das Tag sample-http- hinzugefügt wurde.
  6. Klicken Sie auf Add (Hinzufügen) und anschließend auf Save Changes (Änderungen speichern).

Pipeline manuell ausführen

Sie haben alle drei Phasen der Pipeline erstellt. Jetzt können Sie eine manuelle Ausführung starten, um zu bestätigen, ob die Phasen korrekt ausgeführt und bereitgestellt werden, bevor Sie den Commit-Trigger aktivieren:

  1. Klicken Sie auf die Liste Pipelines oben in der Ansicht Sample application (Beispielanwendung).
  2. Klicken Sie für die Pipeline sample-app auf die Schaltfläche Start Manual Execution (Manuelle Ausführung starten) und dann auf Run (Ausführen), um die Pipeline zum ersten Mal auszuführen.

Die Phasen zum Testen, Verankern mit Ansible und Bereitstellen werden ausgeführt, um den Master-Branch des Repositorys sample-app bereitzustellen.

Sie können jede Phase der Pipeline überwachen, indem Sie darauf klicken, um die Details anzeigen. Klicken Sie während der Verankerungsphase auf den Link View Bakery Details (Verankerungsdetails anzeigen), um einen neuen Tab zu öffnen, auf dem Sie die Ausgabe der Packer-Ausführung sehen.

Image

Alle Phasen sollten den Test bestehen und innerhalb weniger Minuten sollte die App unter der IP-Adresse des Lastenausgleichsmoduls verfügbar sein.

So finden Sie die IP-Adresse des Lastenausgleichsmoduls in der Spinnaker-Benutzeroberfläche:

  1. Klicken Sie auf die Schaltfläche Load Balancers (Lastenausgleichsmodule).
  2. Klicken Sie unter dem Lastenausgleichsmodul sample auf die Region US-WEST1.
  3. Suchen Sie die IP-Adresse unter dem Feld DNS Name (DNS-Name).

Build über GitHub-Webhook auslösen

Als Nächstes konfigurieren Sie Ihr GitHub-Repository für das Senden von Benachrichtigungen an die Spinnaker-API, um einen neuen Build auszulösen. Webhooks sind in der Regel statt Abfragen die bevorzugte Methode zur Erfassung von Änderungen in einem Quell-Repository. Durch die Verwendung von Webhooks können die Gesamtlast des Repository-Hosts verringert und die Extrahierung detaillierter Commit-Änderungen vereinfacht werden.

Da Sie in dieser Lösung die Deployment Manager-Vorlage verwendet haben, wurde der Spinnaker-Webhook-API-Endpunkt /gate/webhooks/git/github automatisch verfügbar gemacht. GitHub sendet Benachrichtigungen an diesen Endpunkt. Aus Sicherheitsgründen ist dies der einzige Spinnaker-API-Endpunkt, der vom Lastenausgleichsmodul angezeigt wird.

GitHub-Webhooks konfigurieren

  1. Suchen Sie die IP-Adresse der allgemeinen Weiterleitungsregel, die auf die mit der Cloud Deployment Manager-Vorlage erstellte Spinnaker-API verweist.

    gcloud compute forwarding-rules list --regexp="${DEPLOYMENT_NAME}-spinnaker-api-lb"
    
  2. Geben Sie für den Webhook die folgende URL an:

    http://HTTP_LB_IP/gate/webhooks/git/github
    

    In der vorstehenden URL ist HTTP_LB_IP die IP-Adresse der Weiterleitungsregel.

  3. Öffnen Sie anschließend die GitHub-Repository-Einstellungen:

    https://github.com/[YOUR_GH_USER]/sample-app/settings/hooks
    

    In der vorstehenden URL ist [YOUR_GH_USER] der Nutzer oder die Organisation, zu dem bzw. der das Beispiel-App-Repository abgezweigt wurde.

  4. Klicken Sie auf die Schaltfläche Add Webhook (Webhook hinzufügen).

  5. Setzen Sie Payload URL (Nutzlast-URL) auf Ihre Webhook-URL.

  6. Setzen Sie Content type (Inhaltstyp) auf application/json.

  7. Setzen Sie Secret auf den zuvor erstellten Wert GH_WEBHOOK_SECRET.

  8. Klicken Sie auf Add webhook (Webhook hinzufügen).

    Image

Nachdem Sie auf Add webhook (Webhook hinzufügen) geklickt haben, wird eine Testnutzlast an Spinnaker gesendet. Ist dieser Vorgang erfolgreich, wird neben dem Webhook auf der GitHub-Seite ein grünes Häkchen angezeigt.

Image

Sie können den Empfang des Webhooks auch in den Logs des Echo-Dienstes auf der Spinnaker-VM einsehen:

grep Webhook /var/log/spinnaker/echo/echo.log

Spinnaker-Pipeline durch Zusammenführen einer Pull-Anfrage auslösen

Das Zusammenführen einer Pull-Anfrage unter GitHub entspricht dem Commit einer neuen Änderung aus einem Branch im Git-Repository. Pull-Anfragen werden als Best Practice für die gemeinsame Prüfung und ein sichereres Zusammenführen von Open-Source-Software unter GitHub betrachtet.

  1. Bearbeiten Sie die Datei html.go im GitHub-Codebrowser.
  2. Ändern Sie Color (Farbe) von Green (Grün) in Blue (Blau) und wählen Sie Create a new branch for this commit and start a pull request (Neuen Branch für diesen Commit erstellen und Pull-Anfrage starten) aus.
  3. Klicken Sie auf die Schaltfläche Commit changes (Commit für Änderungen ausführen).

Nachdem Sie die Pull-Anfrage zusammengeführt haben, wird die Spinnaker-Pipeline ausgelöst und die Ausführung der Pipeline-Phasen gestartet.

Image

Beachten Sie, dass die Ausführungsquelle diesmal GIT ist.

Image

Nach abgeschlossener Bereitstellung befinden sich unter Clusters zwei Servergruppen: V000 und V001. Die Servergruppe V000 ist deaktiviert.

Cluster auf vorherige Version zurücksetzen

Sie haben die Bereitstellungsphase der Pipeline mit der Rot-Schwarz-Strategie konfiguriert. Dabei bleiben die älteren Versionen der Servergruppen bestehen, werden aber deaktiviert, damit sie nicht Teil des Lastenausgleichs sind. Falls Sie eine Änderung rückgängig machen müssen, ist die alte Servergruppe weiterhin verfügbar und muss nicht neu erstellt werden.

So setzen Sie die sample-app auf die vorherige Version zurück:

  1. Klicken Sie oben in der Ansicht der Beispielanwendung auf Clusters.
  2. Klicken Sie auf die Servergruppe V001.
  3. Klicken Sie in der UI rechts oben auf die Schaltfläche Server Group Actions (Aktionen für Servergruppe) und wählen Sie Rollback aus.
  4. Wählen Sie Restore to: sample-nginx-v000 (Zurücksetzen auf: sample-nginx-v000) aus.
  5. Geben Sie den Namen Ihres Kontos in das Feld unten im Dialogfeld ein.
  6. Klicken Sie auf Submit (Senden).

    Image

Dadurch werden mehrere Aufgaben ausgeführt, um die Servergruppe V000 wieder zu aktivieren und dem Lastenausgleichsmodul hinzuzufügen.

Nach einigen Minuten sollte der Traffic zum Lastenausgleichsmodul den Status der sample-app vor dem Commit der Pull-Anfrage wiedergeben.

Führen Sie jetzt einen Commit-Vorgang für eine weitere Änderung in der Datei html.go aus. Verwenden Sie dabei eine Pull-Anfrage und lösen Sie die Pipeline aus, um V002 bereitzustellen.

Bereinigen

So vermeiden Sie, dass Ihr Google Cloud Platform-Konto für die in dieser Anleitung genutzten Ressourcen unnötig mit Gebühren belastet wird:

Spinnaker speichert seine Pipeline-Konfigurationen in Ihrem Cloud Storage-Bucket, sodass sie auch nach Neustarts des Spinnaker-Servers bestehen bleiben. Sie müssen diesen Cloud Storage-Bucket löschen, bevor Sie die Bereitstellung löschen, mit der Ihr Spinnaker-Stapel erstellt wurde.

Gehen Sie wie folgt vor, um alle im Rahmen dieser Anleitung erstellten Ressourcen zu bereinigen und zu entfernen, damit keine zusätzlichen Kosten entstehen.

Ressourcen mit Spinnaker löschen

Gehen Sie in der Spinnaker-UI so vor:

  1. Löschen Sie die Pipeline. Wählen Sie dazu unter Pipelines, Konfigurieren die Pipeline sample-app aus. Klicken Sie dann auf Pipeline Actions (Pipeline-Aktionen) und Delete (Löschen).
  2. Löschen Sie unter Clusters alle Servergruppen.
  3. Löschen Sie unter Load Balancers (Lastenausgleichsmodule) das Lastenausgleichsmodul.
  4. Löschen Sie unter Firewalls die Firewall.
  5. Klicken Sie auf der Hauptanwendungsseite auf Config. (Konfigurieren) und dann auf Delete application (Anwendung löschen).

Ressourcen mithilfe Ihres lokalen Terminals löschen

Führen Sie von Ihrem lokalen Terminal den folgenden Code aus, um front50 zu stoppen und anschließend das Objekt, den Bucket und daraufhin die Bereitstellung zu löschen.

gcloud compute ssh ${SPINNAKER_VM} -- sudo service front50 stop
gsutil rm -r gs://spinnaker-${GOOGLE_PROJECT}-${DEPLOYMENT_NAME}/front50
gsutil rb gs://spinnaker-${GOOGLE_PROJECT}-${DEPLOYMENT_NAME}

Löschen Sie von Ihrem lokalen Terminal aus jedes der von Packer erstellten Images:

gcloud compute images list --filter="name~'none-all-[0-9]{13}.+-xenial'"

Löschen Sie von Ihrem lokalen Terminal aus die Bereitstellung:

gcloud deployment-manager deployments delete ${DEPLOYMENT_NAME}

Nächste Schritte

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

Feedback geben zu...