So skalieren Sie GitLab Continuous Deployment mit GitLab Runner auf DigitalOcean automatisch

Einführung

GitLab ist ein Open-Source-Tool, mit dem Softwareteams ihren gesamten Entwicklungs- und Bereitstellungslebenszyklus verwalten. GitLab bietet eine breite Palette von Funktionen: Fehlerverfolgung, Git-Repositorys, kontinuierliche Integration, Container-Registrierung, Bereitstellung und Überwachung. Diese Funktionen werden von Grund auf als eine einzige Anwendung erstellt. Sie können GitLab auf Ihren eigenen Servern hosten oder https://gitlab.com [GitLab.com] verwenden, einen Cloud-Dienst, bei dem Open Source-Projekte alle wichtigen Funktionen kostenlos erhalten.

Die Continuous Integration / Continuous Delivery (CI / CD) -Funktionalität von GitLab bietet eine effektive Möglichkeit, den gesamten Code vor der Bereitstellung zu testen. GitLab CI / CD ist dank eines zusätzlichen Tools, GitLab Runner, das die Skalierung Ihrer Build-Warteschlange automatisiert, um lange Wartezeiten für Entwicklungsteams zu vermeiden, die versuchen, Code freizugeben, hochgradig skalierbar.

In diesem Handbuch wird gezeigt, wie eine hochskalierbare GitLab-Infrastruktur konfiguriert wird, die ihre eigenen Kosten verwaltet und automatisch auf das Laden reagiert, indem die verfügbare Serverkapazität erhöht und verringert wird.

Tore

Auf DigitalOcean wird ein skalierbarer CI / CD-Prozess erstellt, der automatisch auf Anforderungen reagiert, indem neue Server auf der Plattform erstellt und zerstört werden, wenn die Warteschlange leer ist.

Diese wiederverwendbaren Server werden vom GitLab Runner-Prozess erzeugt und automatisch gelöscht, wenn keine Jobs ausgeführt werden. Dies reduziert die Kosten und den Verwaltungsaufwand für Ihr Team.

Wie in diesem Lernprogramm erläutert, haben Sie die Kontrolle darüber, wie viele Maschinen zu einem bestimmten Zeitpunkt erstellt werden und wie lange sie aufbewahrt werden, bevor sie zerstört werden.

Wir werden drei separate Server verwenden, um dieses Projekt zu erstellen. Gehen wir also zuerst die Terminologie durch:

* GitLab *: Ihre gehostete GitLab-Instanz oder selbst gehostete Instanz, in der Ihre Code-Repositorys gespeichert sind.
* GitLab Bastion *: Der Bastion-Server oder das Droplet ist der Kern dessen, was wir konfigurieren werden. Es ist die Kontrollinstanz, die zur Interaktion mit der DigitalOcean-API verwendet wird, um Droplets zu erstellen und diese bei Bedarf zu zerstören. Auf diesem Server werden keine Jobs ausgeführt.
* GitLab Runners *: Ihre Runners sind temporäre Server oder Droplets, die vom Bastion-Server im Handumdrehen erstellt werden, wenn ein CI / CD-Auftrag in Ihrer Build-Warteschlange ausgeführt werden soll. Diese Server stehen zur Verfügung und sind der Ort, an dem Ihr Code ausgeführt oder getestet wird, bevor Ihr Build als bestanden oder nicht bestanden markiert wird.

image: https://assets.digitalocean.com/articles/gitlab-runner/Autoscaling-GitLab-Runners.png [GitLab Runners Diagram]

Durch die Nutzung jeder der GitLab-Komponenten können Sie mit dem CI / CD-Prozess je nach Bedarf eine reaktionsschnelle Skalierung durchführen. Unter Berücksichtigung dieser Ziele sind wir bereit, unsere kontinuierliche Bereitstellung mit GitLab und DigitalOcean einzurichten.

Voraussetzungen

In diesem Tutorial wird davon ausgegangen, dass Sie GitLab bereits auf Ihrem eigenen Server oder über den gehosteten Dienst konfiguriert haben und über ein DigitalOcean-Konto verfügen.

Um dies auf einem Ubuntu 16.04-Droplet einzurichten, können Sie das DigitalOcean-Ein-Klick-Bild verwenden oder unserem Leitfaden folgen: „https://www.digitalocean.com/community/tutorials/how-to-install-and-configure- gitlab-on-ubuntu-16-04 [So installieren und konfigurieren Sie GitLab unter Ubuntu 16.04]. ”

Für die Zwecke dieses Tutorials wird davon ausgegangen, dass Sie für dieses Droplet privates Netzwerk aktiviert haben. Dies erreichen Sie, indem Sie unserem Leitfaden unter „https://www.digitalocean.com/community/tutorials/how-to-enable-digitalocean-“ folgen. private-networking-on-existing-droplets [So aktivieren Sie DigitalOcean Private Networking für vorhandene Droplets], ist jedoch nicht obligatorisch.

In diesem Tutorial verwenden wir Nicht-Root-Benutzer mit Administratorrechten für unsere Droplets.

Schritt 1 - JavaScript-Projekt importieren

Zunächst erstellen wir ein neues Beispielprojekt in Ihrer vorhandenen GitLab-Instanz, das ein Beispiel für die Anwendung Node.js enthält.

Bild: https://assets.digitalocean.com/articles/gitlab-runner/gitlab.jpg [GitLab-Benutzeroberfläche]

Melden Sie sich bei Ihrer GitLab-Instanz an und klicken Sie auf das * Plus-Symbol *. Wählen Sie dann * Neues Projekt * aus dem Dropdown-Menü.

Wählen Sie im neuen Projektbildschirm das Tag * Projekt importieren * aus und klicken Sie dann auf * Nach URL reponieren *, um unser Beispielprojekt direkt von GitHub zu importieren.

Fügen Sie die folgende Klon-URL in die Git-Repository-URL ein:

https://github.com/do-community/hello_hapi.git

Dieses Repository ist eine grundlegende JavaScript-Anwendung zu Demonstrationszwecken, die in der Produktion nicht ausgeführt wird. Um den Import abzuschließen, klicken Sie auf die Schaltfläche * Neues Projekt *.

Ihr neues Projekt befindet sich nun in GitLab und wir können mit dem Einrichten unserer CI-Pipeline beginnen.

Schritt 2 - Infrastruktur einrichten

Unser GitLab Code Runner erfordert eine bestimmte Konfiguration, da wir programmgesteuert Droplets erstellen möchten, um die CI-Belastung zu bewältigen, wenn sie wächst und schrumpft.

In diesem Tutorial werden zwei Arten von Maschinen erstellt: eine * bastion * -Instanz, die neue Maschinen steuert und erzeugt, und unsere * runner * -Instanzen, die temporäre Server sind, die vom bastion-Droplet erzeugt werden, um bei Bedarf Code zu erstellen. Die Bastion-Instanz verwendet Docker, um Ihre Läufer zu erstellen.

Hier sind die DigitalOcean-Produkte, die wir verwenden und für die die einzelnen Komponenten verwendet werden:

* Flexible Droplets * - Wir werden speicheroptimierte Droplets für unsere GitLab-Läufer erstellen, da dies ein speicherintensiver Prozess ist, bei dem Docker für die Containerisierung verwendet wird. Sie können dieses Droplet in Zukunft nach Bedarf verkleinern oder vergrößern. Wir empfehlen jedoch die flexible Droplet-Option als Ausgangspunkt, um zu verstehen, wie sich Ihre Pipeline unter Last verhält.
* DigitalOcean Spaces (Objektspeicher) * - Wir verwenden DigitalOcean Spaces, um zwischengespeicherte Build-Komponenten auf Ihren Läufern beizubehalten, während sie erstellt und zerstört werden. Dies reduziert die Zeit, die zum Einrichten eines neuen Läufers erforderlich ist, wenn die CI-Pipeline ausgelastet ist, und ermöglicht neuen Läufern, dort fortzufahren, wo andere sofort aufgehört haben.
* Privates Netzwerk * - Wir erstellen ein privates Netzwerk für Ihre Bastion Droplet- und GitLab-Läufer, um eine sichere Codekompilierung zu gewährleisten und die erforderliche Firewall-Konfiguration zu reduzieren.

Zunächst erstellen wir das Bastion-Droplet. Erstellen Sie ein new Droplet und wählen Sie dann unter * Bild auswählen * die Registerkarte * Apps mit einem Klick *. Wählen Sie von dort aus * Docker am 16.04 * (beachten Sie, dass diese Version zum Zeitpunkt des Schreibens aktuell ist) und dann die kleinste verfügbare Tröpfchengröße, da unsere Bastion Droplet die Erstellung anderer Tröpfchen verwaltet, anstatt Tests durchzuführen.

Es wird empfohlen, dass Sie Ihren Server in einem Rechenzentrum erstellen, das DigitalOcean Spaces enthält, um die Objektspeicher-Caching-Funktionen zu verwenden zuvor erwähnt.

Wählen Sie die Optionen * Privates Netzwerk * und * Überwachung * und klicken Sie dann auf * Droplet erstellen *.

Wir müssen auch unseren Speicherplatz einrichten, der für das Caching verwendet wird. Befolgen Sie zum Erstellen die Schritte unter „https://www.digitalocean.com/community/tutorials/how-to-create-a-digitalocean-space-and-api-key[How To Create a DigitalOcean Space und API Key]“ einen neuen Space im selben oder nächsten Rechenzentrum wie Ihre gehostete GitLab-Instanz zusammen mit einem API-Schlüssel.

Notieren Sie sich diesen Schlüssel, da er später im Lernprogramm benötigt wird.

Jetzt ist es Zeit, unser CI zu starten!

Schritt 3 - Konfigurieren Sie den GitLab Runner Bastion Server

Mit dem neuen Droplet können wir jetzt GitLab Runner konfigurieren. Wir installieren Skripte aus GitLab- und GitHub-Repositorys.

Stellen Sie als bewährte Methode sicher, dass Sie Skripts überprüfen, um zu bestätigen, was Sie installieren, bevor Sie die folgenden vollständigen Befehle ausführen.

Stellen Sie über SSH eine Verbindung zum Droplet her, wechseln Sie in das Verzeichnis "+ / tmp +" und fügen Sie das Verzeichnis "https://docs.gitlab.com/runner/install/linux-repository.html[offizielles GitLab Runner-Repository]" zu Ubuntus Paketmanager hinzu:

cd /tmp
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

Nach dem Hinzufügen installieren Sie die GitLab Runner-Anwendung:

sudo apt-get install gitlab-runner

Wir müssen außerdem * https://docs.docker.com/machine/install-machine/#install-machine-directly [Docker Machine] * installieren, ein zusätzliches Docker-Tool, das die Automatisierung der Bereitstellung von Containern in der Cloud unterstützt Anbieter:

curl -L https://github.com/docker/machine/releases/download/v0.14.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine && \
sudo install /tmp/docker-machine /usr/local/bin/docker-machine

Wenn diese Installationen abgeschlossen sind, können wir unseren GitLab Runner mit unserer GitLab-Installation verbinden.

Schritt 4 - Runner Registration Token erhalten

Um GitLab Runner mit Ihrer vorhandenen GitLab-Installation zu verknüpfen, müssen wir die beiden Instanzen miteinander verbinden, indem wir ein Token erhalten, das Ihren Runner mit Ihren Code-Repositorys authentifiziert.

Melden Sie sich bei Ihrer vorhandenen GitLab-Instanz als Administrator an und klicken Sie dann auf das Schraubenschlüsselsymbol, um den Bereich mit den Administratoreinstellungen aufzurufen.

Bewegen Sie den Mauszeiger auf der linken Seite Ihres Bildschirms über "Übersicht" und wählen Sie "Läufer" aus der angezeigten Liste aus.

Kopieren Sie auf der Seite Runners im Abschnitt * So richten Sie einen freigegebenen Runner für ein neues Projekt ein * das in Schritt 3 gezeigte Token und notieren Sie es sich zusammen mit der öffentlich zugänglichen URL Ihrer GitLab-Instanz aus Schritt 2. Wenn Sie HTTPS für Gitlab verwenden, stellen Sie sicher, dass es sich nicht um ein selbstsigniertes Zertifikat handelt. Andernfalls kann GitLab Runner nicht gestartet werden.

Schritt 5 - Konfigurieren Sie GitLab auf dem Bastion Droplet

Führen Sie in Ihrer SSH-Verbindung mit Ihrem Bastion-Droplet den folgenden Befehl aus:

sudo gitlab-runner register

Dadurch wird der Verknüpfungsprozess eingeleitet, und Ihnen werden eine Reihe von Fragen gestellt.

Geben Sie im nächsten Schritt die * GitLab-Instanz-URL * aus dem vorherigen Schritt ein:

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com)

Geben Sie das Token ein, das Sie von Ihrer GitLab-Instanz erhalten haben:

Please enter the gitlab-ci token for this runner

Geben Sie eine Beschreibung ein, die Sie beim Erkennen in der GitLab-Weboberfläche unterstützt. Wir empfehlen, dieser Instanz einen eindeutigen Namen zu geben, beispielsweise "+ Runner-Bastion +", um die Übersichtlichkeit zu gewährleisten.

Please enter the gitlab-ci description for this runner

Bei Bedarf können Sie die Tags für den Code eingeben, den Sie mit Ihrem Läufer erstellen. Wir empfehlen jedoch, dieses Feld zu diesem Zeitpunkt leer zu lassen. Dies kann später einfach über die GitLab-Oberfläche geändert werden.

Please enter the gitlab-ci tags for this runner (comma separated):

Wählen Sie aus, ob Ihr Läufer Jobs ohne Tags ausführen kann. Mit dieser Einstellung können Sie auswählen, ob Ihr Runner Repositorys ohne Tags erstellen soll oder ob bestimmte Tags erforderlich sind. Wählen Sie in diesem Fall true aus, damit Ihr Läufer alle Repositorys ausführen kann.

Whether to run untagged jobs [true/false]:

Wählen Sie aus, ob dieser Runner für Ihre Projekte freigegeben oder für den aktuellen gesperrt werden soll, wodurch verhindert wird, dass Code erstellt wird, der nicht den angegebenen entspricht. Wählen Sie vorerst false, da dies später in der GitLab-Benutzeroberfläche geändert werden kann:

Whether to lock Runner to current project [true/false]:

Wählen Sie den Executor, der Ihre Maschinen baut. Da wir neue Droplets mit Docker erstellen, wählen wir hier "+ Docker + Maschine +". Weitere Informationen zu den Vorteilen der einzelnen Vorgehensweisen finden Sie unter https://docs.gitlab.com/runner/executors/. README.html # Kompatibilitätstabelle [Kompatibilitätstabelle]:

Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:

Sie werden gefragt, welches Bild für Projekte verwendet werden soll, die kein explizites definieren. Wir wählen einen einfachen, sicheren Standard:

Please enter the Docker image (e.g. ruby:2.1):

Jetzt ist die Konfiguration des Core Bastion Runner abgeschlossen! Zu diesem Zeitpunkt sollte es auf der GitLab Runner-Seite Ihrer GitLab-Administratoreinstellungen angezeigt werden, auf die wir zugegriffen haben, um das Token zu erhalten.

Wenn bei diesen Schritten Probleme auftreten, finden Sie in der GitLab Runner-Dokumentation Optionen zur Fehlerbehebung.

Schritt 6 - Docker-Caching und Docker-Computer konfigurieren

Um die Droplet-Erstellung zu beschleunigen, wenn die Erstellungswarteschlange ausgelastet ist, verwenden wir die Caching-Tools von Docker im Bastion Droplet, um die Bilder für Ihre häufig verwendeten Container in DigitalOcean Spaces zu speichern.

Aktualisieren Sie dazu Docker Machine auf Ihrer SSH-Shell mit dem folgenden Befehl:

curl -L https://github.com/docker/machine/releases/download/v0.14.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine && sudo install /tmp/docker-machine /usr/local/bin/docker-machine

Nach dem Upgrade von Docker Machine können wir unsere Zugriffstoken für GitLab Runner einrichten.

Schritt 7 - Sammeln Sie DigitalOcean-Anmeldeinformationen

Jetzt müssen wir die Anmeldeinformationen erstellen, mit denen GitLab Runner mithilfe Ihres DigitalOcean-Kontos neue Droplets erstellt.

Besuchen Sie Ihr DigitalOcean https://cloud.digitalocean.com [Dashboard] und klicken Sie auf * API *. Suchen Sie im nächsten Bildschirm nach * Persönlichen Zugriffstoken * und klicken Sie auf * Neuen Token erstellen *.

Geben Sie dem neuen Token einen Namen, den Sie kennen, wie "+ GitLab Runner Access +", und stellen Sie sicher, dass sowohl der Lese- als auch der Schreibbereich aktiviert sind, da wir das Droplet benötigen, um neue Maschinen ohne menschliches Eingreifen zu erstellen.

Kopieren Sie das Token an einen sicheren Ort, da wir es im nächsten Schritt verwenden werden. Sie können dieses Token nicht erneut abrufen, ohne es erneut zu generieren. Stellen Sie daher sicher, dass es sicher gespeichert ist.

Schritt 8 - GitLab Runner-Konfigurationsdateien bearbeiten

Um all diese Komponenten zusammenzubringen, müssen wir die Konfiguration unseres Bastion-Droplets für die Kommunikation mit Ihrem DigitalOcean-Konto abschließen.

Verwenden Sie in Ihrer SSH-Verbindung zu Ihrem Bastion Droplet Ihren bevorzugten Texteditor, z. B. nano, um die GitLab Runner-Konfigurationsdatei zum Bearbeiten zu öffnen:

nano /etc/gitlab-runner/config.toml

Diese Konfigurationsdatei ist für die Regeln verantwortlich, die Ihr CI-Setup verwendet, um bei Bedarf zu skalieren. Um die Bastion so zu konfigurieren, dass sie bei Bedarf automatisch skaliert wird, müssen Sie die folgenden Zeilen hinzufügen:

/etc/gitlab-runner/config.toml

concurrent = 50   # All registered Runners can run up to 50 concurrent builds

[[runners]]
 url = ""
 token = ""             # Note this is different from the registration token used by `gitlab-runner register`
 name = "example-runner"
 executor = "docker+machine"        # This Runner is using the 'docker+machine' executor
 limit = 10                         # This Runner can execute up to 10 builds (created machines)
 [runners.docker]
   image = "alpine:latest"               # Our secure image
 [runners.machine]
   IdleCount = 1                    # The amount of idle machines we require for CI if build queue is empty
   IdleTime = 600                   # Each machine can be idle for up to 600 seconds, then destroyed
   MachineName = "gitlab-runner-autoscale-%s"    # Each machine will have a unique name ('%s' is required and generates a random number)
   MachineDriver = "digitalocean"   # Docker Machine is using the 'digitalocean' driver
   MachineOptions = [
       "digitalocean-image=coreos-stable", # The DigitalOcean system image to use by default
       "digitalocean-ssh-user=core", # The default SSH user
       "digitalocean-access-token=", # Access token from Step 7
       "digitalocean-region=", # The data center to spawn runners in
       "digitalocean-size=", # The size (and price category) of your spawned runners
       "digitalocean-private-networking" # Enable private networking on runners
   ]
 [runners.cache]
   Type = "s3"   # The Runner is using a distributed cache with the S3-compatible Spaces service
   ServerAddress = ".spaces.digitaloceanspaces.com"
   AccessKey = ""
   SecretKey = ""
   BucketName = ""
   Insecure = true # We do not have a SSL certificate, as we are only running locally

Wenn Sie die neuen Zeilen hinzugefügt haben, passen Sie das Zugriffstoken, die Region und die Tröpfchengröße an Ihre Einrichtung an. Für die Zwecke dieses Lernprogramms haben wir die kleinste Tropfengröße von 1 GB verwendet und unsere Tropfen in NYC3 erstellt. Stellen Sie sicher, dass Sie die für Ihren Fall relevanten Informationen verwenden.

Sie müssen auch die Cache-Komponente anpassen und die Serveradresse Ihres Space aus dem Schritt zur Infrastrukturkonfiguration, den Zugriffsschlüssel, den geheimen Schlüssel und den Namen des von Ihnen erstellten Space eingeben.

Wenn Sie fertig sind, starten Sie GitLab Runner neu, um sicherzustellen, dass die Konfiguration verwendet wird:

gitlab-runner restart

Weitere Informationen zu allen verfügbaren Optionen, einschließlich Nebenzeiten, finden Sie unter GitLabs erweiterte Dokumentation.

Schritt 9 - Testen Sie Ihren GitLab Runner

Zu diesem Zeitpunkt ist unser GitLab Runner-Bastion-Droplet konfiguriert und kann nach Bedarf DigitalOcean-Droplets erstellen, wenn die CI-Warteschlange voll ist. Wir müssen es testen, um sicherzustellen, dass es funktioniert. Gehen Sie dazu zu Ihrer GitLab-Instanz und dem Projekt, das wir in Schritt 1 importiert haben.

Um einen Build auszulösen, bearbeiten Sie die Datei + readme.md, indem Sie darauf klicken, dann auf * edit * klicken und der Datei einen relevanten Testtext hinzufügen. Klicken Sie dann auf * Commit changes *.

Nun wird automatisch ein Build ausgelöst, der in der linken Navigation unter der Option * CI / CD * des Projekts zu finden ist.

Auf dieser Seite sollte ein Pipeline-Eintrag mit dem Status * running * angezeigt werden. In Ihrem DigitalOcean-Konto wird eine Reihe von Droplets angezeigt, die von GitLab Runner automatisch erstellt wurden, um diese Änderung zu erstellen.

Herzliche Glückwünsche! Ihre CI-Pipeline ist cloud-skalierbar und verwaltet jetzt ihre eigene Ressourcennutzung. Nach der angegebenen Leerlaufzeit sollten die Computer automatisch zerstört werden. Wir empfehlen jedoch, diese manuell zu überprüfen, um sicherzustellen, dass keine unerwarteten Kosten anfallen.

Fehlerbehebung

In einigen Fällen meldet GitLab möglicherweise, dass der Läufer nicht erreichbar ist, und führt daher keine Aktionen aus, einschließlich der Bereitstellung neuer Läufer. Sie können dies beheben, indem Sie GitLab Runner stoppen und im Debug-Modus erneut starten:

gitlab-runner stop
gitlab-runner --debug start

Die Ausgabe sollte einen Fehler auslösen, der hilfreich ist, um festzustellen, welche Konfiguration das Problem verursacht.

Wenn Ihre Konfiguration zu viele Computer erstellt und Sie alle gleichzeitig entfernen möchten, können Sie diesen Befehl ausführen, um alle zu zerstören:

docker-machine rm $(docker-machine ls -q)

Weitere Schritte zur Fehlerbehebung und zusätzliche Konfigurationsoptionen finden Sie in der GitLab-Dokumentation.

Fazit

Sie haben mit GitLab Runner und Docker erfolgreich eine automatisierte CI / CD-Pipeline eingerichtet. Von hier aus können Sie mit Docker Registry höhere Cachestufen konfigurieren, um die Leistung zu optimieren, oder die Verwendung von Tagging-Code-Builds für bestimmte GitLab-Codeläufer untersuchen.

Weitere Informationen zu GitLab Runner finden Sie unter die detaillierte Dokumentation. Weitere Informationen finden Sie unter GitLab’s series of blog posts, wie Sie Ihre kontinuierliche Integrations-Pipeline optimal nutzen können.

Dieser Beitrag erscheint auch auf dem GitLab Blog .

TOC