Automatisierte Image-Erstellung mit Jenkins, Packer und Kubernetes

Erstellen Sie benutzerdefinierte Images zum Starten Ihrer Compute Engine-Instanzen oder Docker-Container, um Startzeiten zu verkürzen und die Zuverlässigkeit zu erhöhen. Durch die Vorinstallation von Software in ein benutzerdefiniertes Image können Sie auch Ihre Abhängigkeit von der Verfügbarkeit von Drittanbieter-Repositories reduzieren, die außerhalb Ihrer Kontrolle liegen.

Sie entscheiden, wie viel Software und Konfiguration Sie in Ihre benutzerdefinierten Images aufnehmen möchten. An einem Ende des Spektrums enthält ein minimal konfiguriertes Image, das in diesem Dokument als Fundament-Image bezeichnet wird, ein Basis-Betriebssystem-Image (wie Ubuntu 14.10). Es kann grundlegende Software und Konfigurationen enthalten. Sie können zum Beispiel Sprach-Laufzeitumgebungen wie Java oder Ruby vorinstallieren, Remote-Logging konfigurieren oder Sicherheitspatches anwenden. Ein Fundament-Image bietet ein stabiles Baseline-Image, das weiter angepasst werden kann, um einer Anwendung zu dienen.

Am anderen Ende des Spektrums enthält ein vollständig konfiguriertes Image, das in diesem Dokument als unveränderliches Image bezeichnet wird, nicht nur ein Basis-Betriebssystem- oder Fundament-Image, sondern auch alles, was zum Ausführen einer Anwendung benötigt wird. Laufzeitkonfigurationen wie Datenbankverbindungsinformationen oder sensible Daten können in das Image aufgenommen werden oder über die Umgebung, Metadaten oder Schlüsselverwaltungsdienste zum Startzeitpunkt bereitgestellt werden.

Das Erstellen von Images hat viel mit der Entwicklung von Software gemeinsam: Sie haben Code (Chef, Puppet, bash usw.) und die Personen, die ihn geschrieben haben; ein Build erfolgt, wenn Sie den Code auf ein Basis-Image anwenden; ein erfolgreicher Build-Prozess gibt ein Artefakt aus; und oftmals möchten Sie das Artefakt einigen Tests unterziehen. Viele der Best Practices, die für die Entwicklung von Software gelten, gelten auch für Images: Sie können die Versionskontrolle verwenden, um Skripte zur Konfiguration von Images zu verwalten; Builds veranlassen, wenn Änderungen an diesen Skripten vorgenommen werden; Images automatisch erstellen; und Versionen und sogar Tests der resultierenden Image-Artefakte durchführen, wenn die Builds abgeschlossen sind.

Lerninhalte

Bei dieser Lösung erfahren Sie mehr über zwei allgemeine Methoden zur Erstellung von benutzerdefinierten Images und wie Sie mit verschiedenen beliebten Open-Source-Tools – wie etwa Jenkins, Packer, Docker und Kubernetes – automatisierte Pipelines zur kontinuierlichen Erstellung von Images erzeugen können. Diese Pipeline lässt sich in die Cloud Source Repositories in der Google Cloud Platform (GCP) einbinden. Sie gibt sowohl Compute Engine-Images als auch Docker-Images aus.

Sie erfahren, wie Sie sowohl Fundament- als auch unveränderliche Images erstellen können. Außerdem lernen Sie Best Practices zum Verwalten des Zugriffs auf diese Images über mehrere Projekte in der Google Cloud Platform kennen. Mit der umfassenden Anleitung am Ende des Dokuments können Sie eine Open-Source-Referenzimplementierung der Lösung bereitstellen und nutzen.

Imagetypen

Für skalierbare und stabile Webanwendungen wird eine Ruby on Rails-Webanwendung als Referenz für das Ausführen von Webanwendungen auf der Google Cloud Platform verwendet. Der Quellcode für diese Lösung verwendet keine benutzerdefinierten Images. Beim Starten einer Google Compute Engine-Instanz wird Chef Solo durch ein Startskript installiert. Daraufhin werden automatisch alle Komponenten installiert, die zur Ausführung der Anwendung notwendig sind. Dazu gehören nginx, Ruby 2, cURL und andere Systemtools, Unicorn, die Rails-App und alle ihre Gems, imagemagick und die App-Konfiguration.

Das folgende Diagramm zeigt den Bootvorgang.

Ein Diagramm, das den Bootvorgang ohne benutzerdefiniertes Image zeigt.

Der Vorgang ist nicht schnell. Jede Instanz benötigt 10–15 Minuten zum Starten, je nach Download-Geschwindigkeit der verschiedenen Repositories, die für die Pakete erforderlich sind – vorausgesetzt, dass jedes Repository, das diese Pakete hostet, online und verfügbar ist. In den folgenden Abschnitten erfahren Sie, wie ein Fundament-Image und ein unveränderliches Image die Leistung und Zuverlässigkeit des Bootvorgangs der Instanzen verbessern können.

Fundament-Images

Beim Erstellen eines Fundament-Images entscheiden Sie, welche Software und Pakete in das Image aufgenommen werden sollen. Hier sind einige Dinge, die bei dieser Entscheidung zu beachten sind:

  • Installationsgeschwindigkeit. Große Pakete brauchen manchmal lange zum Herunterladen; Software, die aus der Source erstellt werden muss, kann zeitaufwendig sein und Pakete mit vielen Abhängigkeiten verschärfen das Problem. Erwägen Sie die Aufnahme dieser Software-Arten und Pakete in Ihr Fundament-Image.
  • Zuverlässigkeit des Remote-Repositorys. Vertrauen Sie der Verfügbarkeit des Remote-Repositorys, wenn Sie die Software nicht in Ihr Foundation-Image aufnehmen und stattdessen beim Booten herunterladen? Wird Ihre Anwendung richtig funktionieren, wenn dieses Repository während des Bootvorgangs nicht verfügbar ist? Um Ihre Abhängigkeit von Remote-Repositories zu reduzieren, die außerhalb Ihrer Kontrolle liegen könnten, sollten Sie die Einbindung von kritischen Abhängigkeiten in einem Fundament-Image in Betracht ziehen.
  • Änderungsrate. Ändert sich die Software oder das Paket sehr häufig? Wenn ja, sollten Sie diese nicht in ein Fundament-Image einbinden, sondern stattdessen an einem zuverlässigen, zugänglichen Ort wie einem Cloud Storage-Bucket aufbewahren.
  • Erforderlich oder sicherheitstechnisch vorgeschrieben. Wenn bestimmte Pakete (wie Logging, OSSEC usw.) auf jeder Instanz in Ihrer Organisation mit einer bestimmten Konfiguration ausgeführt werden sollen, installieren Sie diese Pakete in einem Fundament-Image, das von allen anderen Images erweitert wird. Ein Sicherheitsteam kann ein professionelles Tool wie Chef oder Puppet nutzen, um ein Docker-Fundament-Image zu erstellen, während Downstream-Entwickler einen Dockerfile verwenden können, um das Fundament einfach zu erweitern.

Diese Kriterien deuten darauf hin, dass ein Fundament-Image für die Ruby on Rails-Anwendung aus der Scalable and Resilient Web Applications-Lösung Chef Solo, nginx, Ruby, cURL und andere Systemtools sowie Unicorn beinhalten kann. Die anderen Abhängigkeiten würden während des Bootvorgangs installiert werden.

Das folgende Diagramm beschreibt den Bootvorgang mit einem Fundament-Image:

Ein Diagramm, das den Bootvorgang mit einem Fundament-Image zeigt.

Die Funktionsinstanz in diesem Beispiel ruft ihre Konfiguration (z. B. Datenbank-Verbindungsstring, API-Schlüssel usw.) aus dem Compute Engine-Metadatendienst ab. Sie können verschiedene Dienste wie etcd oder einen einfachen Google Cloud Storage-Bucket zur Verwaltung der Konfiguration nutzen.

Die nächsten Abschnitte konzentrieren sich auf die Tools, die verwendet werden, um die Erstellung des hier dargestellten Ruby-Fundament-Images zu automatisieren.

Unveränderliche Images

Im Gegensatz zu einem Fundament-Image ist bei einem unveränderlichen Image die ganze Software im Image enthalten. Wenn eine Instanz oder ein Container aus dem Image gestartet wird, müssen keine Pakete heruntergeladen oder Software installiert werden. Ein unveränderliches Image für die Ruby on Rails-Anwendung aus der Scalable and Resilient Web Applications-Lösung würde sämtliche Software enthalten und die Instanz könnte beim Starten den Traffic unterstützen.

Ein Diagramm, das den Bootvorgang mit einem unveränderlichen Image zeigt.

Konfiguration und unveränderliche Images

Sie können entscheiden, ob Ihre Anwendung über einen Konfigurationsdienst auf die erforderlichen Konfigurationsdaten zugreifen kann oder alle Konfigurationen in das unveränderliche Image aufnehmen. Wenn Sie sich für letzteren Ansatz entscheiden, müssen Sie die Auswirkungen auf die Sicherheit, die das Einbinden von Secrets in Ihre Images hat, berücksichtigen. Wenn Sie unveränderliche Images für öffentliche Repositorys im Docker Hub hochladen, sind diese für jeden zugänglich. Daher sollten sie keine sensiblen oder geheimen Daten enthalten.

Unveränderliche Images als Deploymenteinheit

Durch die Verwendung von unveränderlichen Images als Deploymenteinheit können keine Konfigurationen mehr geändert werden, wenn der Fall eintreten sollte, dass mindestens eine Instanz in einem anderen Zustand als erwartet ist. Das kann zum Beispiel passieren, wenn Sie einen Sicherheitspatch auf 100 laufende Container anwenden und sich einige von ihnen nicht aktualisieren. Das Image wird zu dem, was Sie bereitstellen, wenn eine Veränderung vorgenommen wird. Wenn das Betriebssystem einen Softwarepatch benötigt oder die Loggingkonfiguration aktualisiert werden soll, erstellen Sie ein neues Image, um diese Änderungen einzubeziehen und führen es aus, indem neue Instanzen oder Container gestartet und alle alten ersetzt werden. Wenn Sie die Anwendungskonfiguration in einem unveränderlichen Image bündeln, führt auch eine einfache Änderung wie das Aktualisieren eines Datenbankverbindungsstrings dazu, dass ein neues Image erstellt und freigegeben werden muss.

Architektur und Implementierung einer automatisierten Pipeline zur Image-Erstellung

Dieser Abschnitt enthält Details zur Implementierung einer automatisierten Pipeline für die Image-Erstellung, die Jenkins, Packer, Docker und Google Kubernetes Engine (GKE) verwendet, um benutzerdefinierte Images automatisch zu erstellen. Jeder Abschnitt enthält eine Einführung, ein Architekturdiagramm und eine detaillierte Analyse der Komponenten in diesem Diagramm.

Verwendete Software und Dienste

Diese Software und Dienste werden verwendet, um den automatisierten Image Builder zu erstellen:

Software Nutzung
Jenkins Jenkins ist ein beliebter Open Source Continuous Integration-Server (CI). Jenkins wird genutzt, um Git-Repositorys in anderen Projekten abzurufen, die Skripte zur Konfiguration von Images enthalten, um dann Images zu erstellen, die auf diesen Repositorys basieren.
Packer Packer ist ein Tool für die Erstellung von identischen Maschinen-Images für mehrere Plattformen aus einer einzigen Quellenkonfiguration. Dieses Tool unterstützt viele verschiedene Konfigurationsquellen wie Shell, Chef, Puppet, Ansible und Salt und kann zum Beispiel Images für Compute Engine und Docker ausgeben. Packer wird von Jenkins-Agents verwendet, um Images aus Konfigurationen in Git Repositories zu erstellen.
Docker Docker ist ein Open-Source-Tool zum Verpacken und Bereitstellen von Anwendungen als Container. Das Jenkins-Deployment (einschließlich des Leader-Knotens und der Build-Agents) erfolgt in dieser Architektur und Anleitung als Docker-Container. Die Build-Agents geben außerdem Docker-Images als eine ihrer Architekturen aus.
GKE Dank der Open-Source-Technologie von Kubernetes können Sie mit GKE Docker-Container auf den virtuellen Maschinen der GCP ausführen und verwalten.
Container Registry Container Registry bietet einen sicheren privaten Speicher für Docker-Images auf der GCP. Sie wird auf der GCP ausgeführt und über einen HTTPS-Endpunkt aufgerufen.
Compute Engine GKE verwendet Compute Engine-VMs, um Kubernetes auszuführen und die Jenkins-Leader und Build-Agent-Container zu hosten. Der Jenkins-Build-Prozess liefert neben Docker-Images auch Compute Engine VM-Images.
Cloud Storage Sie verwenden Cloud Storage zum Speichern von Sicherungen Ihrer Jenkins-Konfiguration.
Nginx Nginx bietet Reverse Proxy-Funktionen und die Weiterleitung von eingehenden Anfragen an die Jenkins-Weboberfläche. Es kann so konfiguriert werden, dass es SSL-Verbindungen beendet und eine grundlegende Authentifizierung bereitstellt.

Übersicht über Image Builder

Das folgende Diagramm zeigt die Interaktion verschiedener Komponenten zur Erstellung eines Systems, das automatisch VM- und Docker-Images erzeugt.

Ein Diagramm, das die verschiedenen Komponenten des Image-Builder-Projekts zeigt.

Sie legen für jedes Image, das Sie erstellen möchten, einen Job auf dem Jenkins-Leader fest. Dieser ruft ein Quellcode-Repository ab, in dieser Abbildung Git, das Konfigurationsskripte und eine Packer-Vorlage enthält, in der das Erstellen eines Images beschrieben wird. Wenn der Abfrage-Prozess eine Änderung erkennt, weist der Jenkins-Leader den Job einem Build-Agent zu. Der Agent verwendet Packer zum Ausführen des Builds, der ein Docker-Image an das Container Registry und ein VM-Image an Compute Engine ausgibt.

Packer- und Konfigurationsskripte

Eine Packer-Vorlage und die zugehörigen Konfigurationsskripte legen gemeinsam fest, wie ein Image erstellt wird. Sie werden wie Software behandelt und in ihrem eigenen Git-Repository gespeichert. Jedes von Ihnen erstellte Image hat ein eigenes Repository mit einer Packer-Vorlage und Konfigurationsskripten.

Dieser Abschnitt bietet einen Überblick über eine mögliche Packer-Konfiguration, die Chef verwendet, um Ubuntu 14.04 durch Hinzufügen von Ruby und rbenv anzupassen. Vollständige Informationen zu Packer finden Sie in der entsprechenden Dokumentation unter https://www.packer.io/docs.

Images benennen und Packer-Variablen

Der Image-Builder erstellt ein Image, sobald eine Änderung am Git-Repository vorgenommen wird, das die Packer-Vorlagen und Konfigurationsskripte des Images enthält. Es empfiehlt sich, Images zu benennen, mit dem Git-Branch zu markieren und eine ID festzulegen, von der sie erstellt wurden. Mit Packer-Vorlagen können Sie Variablen festlegen und entsprechende Werte zur Laufzeit zur Verfügung stellen:

{
...
  "variables": {
      "Git_commit": "",
      "Git_branch": "",
      "ruby_version_name": "212",
      "project_id": "null"
  }
...
}

Der Jenkins-Build-Agent kann den Git-Branch finden, eine ID festlegen und sie dem Packer-Befehlszeilentool als Variablen zur Verfügung stellen. Dies wird Ihnen in der Anleitung, die Sie am Ende des Dokuments finden, anhand eines praktischen Beispiels gezeigt.

Programmatische Konfiguration mit Bereitstellern

Eine Packer-Vorlage legt mindestens einen Bereitsteller fest, der beschreibt, wie man ein Tool wie Chef, Puppet oder auch Shell-Skripte verwendet, um eine Instanz zu konfigurieren. Packer unterstützt viele Bereitsteller. Eine vollständige Auflistung finden Sie im Inhaltsverzeichnis der Dokumentation. Dieses Snippet legt einen Chef-Solo-Bereitsteller mit Cookbook-Pfaden und Anleitungen fest, um ein Image zu konfigurieren:

{
  ...
  "provisioners": [
    {
      "type": "chef-solo",
      "install_command": "apt-get install -y curl && curl -L https://www.opscode.com/chef/install.sh | {{if .Sudo}}sudo{{end}} bash",
      "cookbook_paths": ["chef/site-cookbooks"],
      "run_list": [{{
        "recipe[ruby]",
        "recipe[ruby::user]",
        "recipe[ruby::ruby212]"
      ]
    }
  ],
  ...
}

Die Chef-Anleitungen werden im selben Git-Repository wie die Packer-Vorlage gespeichert.

Image-Ausgaben mit Builder festlegen

Der Abschnitt builders der Vorlage legt fest, wo die Bereitsteller ausgeführt werden, um neue Images zu erstellen. Legen Sie zwei Builder fest, um sowohl ein Compute Engine-Image als auch ein Docker-Image zu erstellen:

{
  "variables": {...},
  "provisioners": [...],
  "builders": [
    {
      "type": "googlecompute",
      "project_id": "{{user `project_id`}}",
      "source_image": "ubuntu-1410-utopic-v20150202",
      "zone": "us-central1-a",
      "image_name": "{{user `ruby_version_name`}}-{{user `Git_branch`}}-{{user `Git_commit`}}"
    },
    {
      "type": "docker",
      "image": "ubuntu:14.10",
      "commit": "true"
    }
  ],
 ...
}

Der googlecompute-Builder enthält ein project_id-Attribut, das angibt, wo das resultierende Image gespeichert wird. Das Attribut image_name, das dem resultierenden Image einen Namen zuweist, verkettet Variablen, um einen Namen mit Informationen über das Image zu erstellen: die Ruby-Version, den Git-Branch und die Git-Commit-ID, mit der das Image erstellt wurde. Hier sehen Sie einen Beispiel-URI für ein vom googlecompute-Builder erstelltes Image:

https://www.googleapis.com/compute/v1/projects/image-builder-project-name/global/images/ruby212-master-9909043

Der docker-Builder sollte ein post-processors-Attribut enthalten, um das Image mit dem Docker-Registry und dem Repository zu markieren, an das es übertragen wird:

{
  "variables": {...},
  "provisioners": [...],
  "builders": [...],
  "post-processors": [
    [
      {
        "type": "docker-tag",
        "repository": "gcr.io/{{user `project_id`}}/ruby212",
        "tag": "{{user `Git_branch`}}-{{user `Git_commit`}}",
        "only": ["docker"]
      }
    ]
  ]
}

Dieser Postprozessor taggt das Image zur Speicherung in Container Registry anhand der project_id, die beim Ausführen des Builds bereitgestellt wird. Nachdem dieses Docker-Image übertragen wurde, kann es mit folgendem Befehl abgerufen werden:

docker pull gcr.io/image-builder-project-name/ruby212:master-9909043

Jedes Image, das Sie erstellen möchten, hat eine Packer-Vorlage und Konfigurationsskripte in seinem eigenen Quell-Repository. Der Jenkins-Leader hat für jedes einen Job festgelegt, wie im folgenden Diagramm gezeigt.

Ein Diagramm, das das Image-Builder-Projekt mit benutzerdefinierten Images zeigt.

Ein Vorteil der gemeinsamen Nutzung von Jenkins und Packer besteht darin, dass Jenkins alle Updates, die Sie an Ihren Packer-Vorlagen oder Konfigurationsskripten vornehmen, erkennen und auf diese reagieren kann. Wenn Sie zum Beispiel die in Ihrem Ruby-Fundament-Image installierte Version von Ruby aktualisieren, reagiert der Jenkins-Leader, indem er einen Agent veranlasst, das Repository zu klonen, Packer auf Grundlage der Vorlage auszuführen und die Images zu erstellen.

Die Anleitung am Ende dieser Lösung beschreibt die Konfiguration eines Jenkins-Jobs zur Ausführung des Packer-Builds im Detail.

Projektisolation

Die Jenkins-Leader und Build-Agents werden gemeinsam im selben Cloud Platform-Projekt ausgeführt. Die von ihnen erstellten Images werden in diesem Projekt gespeichert. Mit Projekten können Sie Anwendungen nach Funktion isolieren. Es gibt keine Gebühren für ein Projekt; Ihnen werden nur die benötigten Ressourcen berechnet. In dieser Lösung wird die Jenkins-Infrastruktur in ihrem eigenen Projekt ausgeführt, und zwar getrennt von den Quellcode-Repositorys, die sie benutzt. Jenkins-Sicherungen, die in einem nachfolgenden Abschnitt besprochen werden, werden in einem Google Cloud Storage-Bucket im Projekt gespeichert. Dadurch kann Jenkins als "Image-Hub" fungieren und dabei Images an andere Projekte weitergeben, während andere Projekte ihre eigenen Code-Repositories mit separater Zugriffskontrolle pflegen können.

Images organisationsweit erstellen und freigeben

Diese Lösung platziert jedes in Git gespeicherte Build-Image in einem separaten Projekt zur Konfiguration von Images, um das Freigeben von Images zu erleichtern. Durch diese Trennung entsteht eine Projektisolation zwischen dem Image-Builder-Projekt und den Build-Images. Durch diese Hub-and-Spoke-Architektur, bei der das Image-Builder-Projekt der Hub ist und die Projekte zur Konfiguration von Images die Spokes sind, können separate Teams die Image-Konfigurationen leichter besitzen und verwalten.

Diese Hub-and-Spoke-Architektur ist im folgenden Diagramm dargestellt.

Ein Diagramm, das das Image-Builder-Projekt als Hub-and-Spoke-System zeigt.

Die Zugriffskontrolle (Zugriffsgewährung für das Jenkins-Cluster auf jedes Image-Projekt und Zugriffsgewährung für andere Projekte auf die von Jenkins erstellten Images) wird nachfolgend erläutert.

Ein Projekt pro Image

Jedes von Ihnen erstellte Projekt verfügt über ein dediziertes Git-basiertes Cloud Repository. Es gibt keine Begrenzung für die Anzahl der von Ihnen erstellten Projekte. Sie zahlen nur für die Ressourcen wie Compute Engine-Instanzen, die Sie in einem Projekt verwenden. Wenn Sie zum Beispiel PHP-, Ruby- und Wordpress-Images haben, wäre jedes ihrer Projekte in der Google Cloud Platform Console wie im folgenden Diagramm gezeigt sichtbar.

Ein Diagramm, das das Image-Builder-Projekt mit separaten Projekten für jedes benutzerdefinierte Image zeigt.

Auf das Cloud Repository eines Projekts kann über den Menüpunkt Quellcode zugegriffen werden. Bei neuen Projekten entscheiden Sie, wie Sie das Repository initialisieren möchten: Sie können ein vorhandenes GitHub- oder Bitbucket-Repository spiegeln, ein bestehendes lokales Git-Repository verwenden oder ein neues lokales Git-Repository aus Cloud Source Repositories erstellen (siehe Abbildung unten).

Ein Bildschirmbild, das zeigt, wie Quellcode in der GCP Console durchsucht wird.

Die folgende Abbildung zeigt das Ruby Foundation Image-Projekt, das mit einer Packer-Vorlage und Chef-Schemas initialisiert wurde, die den Build definieren.

Das Ruby Foundation Image mit Packer-Vorlage und Chef-Anleitungen

Zum Aufrufen der URL für das Repository klicken Sie auf das Symbol Settings (Einstellungen). Sie benötigen diese URL beim Erstellen eines Build-Jobs für das Repository auf dem Jenkins-Leader, wie in der folgenden Abbildung gezeigt.

Die Quell-Repository-Einstellungen für den Jenkins-Leader

Zugriffskontrolle für Cloud Repository

Der Jenkins-Image-Builder benötigt eine Leseberechtigung für jedes Cloud Repository des Imagekonfigurationsprojekts. Das folgende Diagramm zeigt eine vereinfachte Ansicht der zuvor gezeigten Hub-and-Spoke-Architektur.

Image Builder-Projekt mit notwendigen Berechtigungen

Jedes Projekt muss Zugriff auf das Jenkins-Image-Builder-Projekt gewähren, indem es die E-Mail-Adresse des Compute-Dienstkontos des Image-Builder-Projekts verwendet. Das Adressformat lautet \{PROJECT_ID\}-compute@developer.gserviceaccount.com. Sie können es in der GCP Console wie in der folgenden Abbildung dargestellt in den Abschnitt "Berechtigungen" des Projekts kopieren.

Adresse zum Kopieren aus dem Abschnitt "Berechtigungen" eines Projekts

Nachdem Sie die E-Mail-Adresse des Compute-Dienstkontos für das Projekt erhalten haben, das den Jenkins-Image-Builder ausführt, gehen Sie zum Abschnitt Permissions (Berechtigungen) des entsprechenden Projekts mit einem Cloud Repository, von dem Sie Images erstellen möchten, wählen Add Member (Mitglied hinzufügen) und gewähren wie in der folgenden Abbildung gezeigt die Option Can view (Leseberechtigung).

Einstellen einer Leseberechtigung in einem Projekt

Der Jenkins-Leader, der im Image-Builder-Projekt ausgeführt wird, kann jetzt aus dem Cloud Repository in diesen Projekten Abfragen durchführen und Informationen abrufen und bei Änderungen neue Images erstellen.

Compute Engine- und Docker-Images freigeben

Die Compute Engine- und Docker-Images, die vom Image Builder erstellt wurden, werden im gleichen Projekt wie der Image Builder gespeichert. Die Images werden von Anwendungen in anderen Projekten verwendet, um Compute Engine-Instanzen und Docker-Container zu starten. Jedes Anwendungsprojekt, das auf diese Images zugreifen möchte, muss eine Leseberechtigung für das Image-Builder-Projekt haben. Folgen Sie dem im vorherigen Abschnitt beschriebenen Prozess. Suchen Sie diesmal jedoch das Compute-Dienstkonto des jeweiligen Anwendungsprojekts und fügen Sie es wie im folgenden Diagramm gezeigt als Mitglied mit Leseberechtigung zum Image-Builder-Projekt hinzu.

Hinzufügen eines anderen Projekts mit Leseberechtigung zum Image-Builder-Projekt

Jenkins-Sicherung und -Wiederherstellung

Der Jenkins-Leader umfasst einen vordefinierten Job für die regelmäßige Sicherung der Jenkins-Konfiguration und des Jobverlaufs in Google Cloud Storage. Standardmäßig wird der Job wie in der folgenden Abbildung gezeigt regelmäßig ausgeführt (an jedem Wochentag alle zwei Stunden einmal).

Automatisierte Build-Einstellungen auf dem Jenkins-Leader

Der Build-Schritt des Jobs führt ein Shell-Skript aus, das Secrets, Nutzer, Jobs und den Verlauf in einem Tarball archiviert. Es gibt zwei Kopien des erstellten Archivs: Eine ist mit einem Datumsstempel benannt, die andere heißt LATEST, sodass Sie die neueste Sicherung einfach und automatisch wiederherstellen können. Sie können diesen Schritt anpassen, um zu sichernde Artikel, wie in der folgenden Abbildung gezeigt, hinzuzufügen oder zu entfernen.

Anpassung des Build-Skripts

Eine Post-Build-Aktion nutzt das Cloud Storage-Plug-in und die Google-Anmeldedaten, die Sie erstellt haben, um mit Google APIs zu interagieren und das Sicherungsarchiv in Cloud Storage hochzuladen. Sie lädt das Archiv mit dem Datumsstempel und das LATEST-Archiv hoch. Die folgende Abbildung zeigt die entsprechenden Schritte.

Oberfläche zur Festlegung der Post-Build-Aktionen

Die folgende Abbildung zeigt einen Bucket mit einigen Sicherungen, die sich angesammelt haben:

Liste der Sicherungen, die sich für ein Projekt angesammelt haben

Sicherung wiederherstellen

In der gleichen Weise, in der Sie Umgebungsvariablen verwenden, um SSL oder Basic-Auth auf dem Nginx-Reverse-Proxy zu aktivieren, können Sie eine Umgebungsvariable verwenden, um die Replikations-Controller-Definition des Jenkins-Leaders so zu konfigurieren, dass eine Sicherung wiederhergestellt wird, wenn der Dienst startet. Der folgende Code ist ein Snippet aus der Definition des Replikations-Controllers:

{
  "kind": "ReplicationController",
  ...
  "spec": {
    ...
    "template": {
      "spec": {
        "containers": [
            {
              "name": "jenkins",
              "env": [
                {
                  "name": "GCS_RESTORE_URL",
                  "value": "gs://your-backup-bucket/jenkins-backup/LATEST.tar.gz"
                }
              ],
             ...
           }
        ]
      }
    }
  }
}

Das Docker-Image des Jenkins-Leaders prüft beim Starten das Vorhandensein der Umgebungsvariablen GCS_RESTORE_URL. Wurden diese gefunden, wird der Wert als URL der Sicherung betrachtet (einschließlich des gs://-Schemas). Das Skript verwendet das gsutil-Befehlszeilentool, das auf dem Jenkins-Leader-Image installiert ist, um das Back-up sicher herunterzuladen und wiederherzustellen.

Der Wiederherstellungsvorgang geschieht nur, wenn ein Container gestartet wird. Um eine Sicherung wiederherzustellen, nachdem Sie einen Jenkins-Leader gestartet haben, stellen Sie den Replikations-Controller auf 0 ein, aktualisieren die Definition des Controllers, um auf die URL der Sicherung zu verweisen, und stellen dann die Größe zurück auf 1. Dies ist in der Anleitung beschrieben.

Anleitung

Die vollständige Anleitung, einschließlich Anweisungen und Quellcode, steht auf GitHub unter https://github.com/GoogleCloudPlatform/kube-jenkins-imager zur Verfügung.

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

Feedback geben zu...