So erreichen Sie mit GitLab die Parallelität mehrerer Jobs

Gitlab wird von Indie-Hackern, aber auch von großen Unternehmen mit Hunderten von Entwicklern verwendet.
Ein einzelner Entwickler, der sein Projekt hackt, kann hin und wieder Änderungen vornehmen, aber wenn sich das verzehnfacht, wird es für einen Build-Server schnell überwältigend.

In einigen Umgebungen arbeiten einfach zu viele Entwickler an so vielen Projekten, die jede Sekunde des Tages Änderungen vorantreiben!
Was ich beschreibe, scheinst du zu kennen. Sind Sie es leid, darauf zu warten, dass diese Build-Jobs abgeschlossen sind, oder?
Die Lösung ist einfach, erhöhen Sie die Parallelität … :]

Hinweis: In diesem Beitrag werden wir mehrere Projekte berücksichtigen, die von bedient werden eines Läufer mit docker als Vollstrecker. Dieser Runner führt die Build-Jobs basierend auf der von uns festgelegten Parallelität aus. Unterschiedliche Setups für unterschiedliche Fallbeispiele sind natürlich machbar.

Der Vollständigkeit halber werden wir alles von Grund auf neu einrichten.

Für diesen Leitfaden verwenden wir:

Nur eine Randnotiz…:
Ich liebe Automatisierung Also schreibe ich ein Buch darüber!
Es ist vollgepackt mit umfassenden Leitfäden zu den Konzepten von CI/CDimplementiert mit Technologien wie Kubernetes, Helm, Docker, Gitlab, Entwurf, Gerüst usw.
Möchten Sie benachrichtigt werden, sobald es verfügbar ist? Benachrichtigt werden!
Kennen Sie einen interessierten Freund/Kollegen? Teilt es!

Schritt 1: Erstellen Sie den Gitlab-Runner-Container

Hinweis: Möglicherweise müssen Sie es sein root

docker run --name runner --restart always -d -v $HOME/gitlab-runner:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:v10.6.0

Achtung: Dies ist KEIN registrierter Läufer. Es ist nur die gitlab-runner-Binärdatei, die in einem Docker-Container läuft!

Schritt 2: Registrieren Sie einen Läufer bei GitlabCI

gitlab-runner register --non-interactive --description "docker-runner" --url " -registration-token "something_weird" --executor "docker" --docker-image "docker:latest" --run-untagged --locked=false --docker-privileged=true --docker-volumes /var/run/docker.sock:/var/run/docker.sock

Beachten Sie das --locked=false argumentieren geht nicht. Der Läufer wird weiterhin als registriert specific. Ich schließe es ein, falls ein zukünftiges Upgrade es behebt.

Optional können Sie mehr als einen Läufer mit demselben anmelden [or different] Name, wenn Sie sie pro Projekt sperren möchten.

Schritt 3: Erhöhen Sie die Parallelität in der config.toml

Das concurrent Einstellung, steuert, wie viele Jobs gleichzeitig ausgeführt werden können.
Global. Das heißt, es gilt für alle Läufer unabhängig vom Ausführenden [docker, ssh, kubernetes etc]

Sie sollten die öffnen /etc/gitlab-runner/config.toml Datei mit einem Editor wie nano oder vim.

Und ändern Sie die concurrent = 1 zu etwas wie concurrent = 5 [or as many concurrent builds you like]

Prüfen hier Für mehr Information.

Schritt 4: Starten Sie gitlab-runner neu

Nur um auf Nummer sicher zu gehen und uns nicht den Kopf zu stoßen…

gitlab-runner restart

Schritt 5: Führen Sie einige Builds aus

Jetzt können Sie so viele Jobs ausführen, wie Sie die Parallelität festgelegt haben [i.e n]! Versuchen Sie, es mit zu überwältigen n+1nur um den +1-Job zu beobachten und geduldig darauf zu warten, dass ein Slot frei wird.

Hinweis: Wenn die docker Executor verwendet wird, wird jeder neue Build-Job in einem neuen Docker-Container ausgeführt, der automatisch erzeugt wird. Die gleiche Logik gilt für die kubernetes auch Vollstrecker.

Optionaler Schritt: Aufräumen

Es wird eine Menge (abhängig von Ihren Projekten) Cache-Container geben, die beendet bleiben, wenn die Build-Jobs erfolgreich sind.

Schauen Sie es sich unten an!

2ca3a04e44dd  88a04ddd0898  "gitlab-runner-cache " 10 minutes ago  Exited (0) 10 minutes ago  runner-707174de-project-38-concurrent-0-cache-3c3f0...
8beb199e0e1f  88a04ddd0898  "gitlab-runner-cache " 10 minutes ago  Exited (0) 10 minutes ago  runner-707174de-project-38-concurrent-0-cache-d6b5f...
a7f0bf9ba8b1  88a04ddd0898  "gitlab-runner-cache " 10 minutes ago  Exited (0) 10 minutes ago  runner-f2bd384a-project-46-concurrent-0-cache-3c3f0...
66bb3ef98879  88a04ddd0898  "gitlab-runner-cache " 10 minutes ago  Exited (0) 10 minutes ago  runner-f2bd384a-project-46-concurrent-0-cache-d6b5f...
3689d386af1b  88a04ddd0898  "gitlab-runner-cache " 18 minutes ago  Exited (0) 18 minutes ago  runner-8df2f9cc-project-19-concurrent-0-cache-3c3f0...
1391db607410  88a04ddd0898  "gitlab-runner-cache " 18 minutes ago  Exited (0) 18 minutes ago  runner-8df2f9cc-project-19-concurrent-0-cache-d6b5f...

Diese Container müssen nach dem Build bestehen bleiben, damit der nächste Build den Cache nutzen kann.
Das Entfernen nach einem Build würde seinen Zweck zunichte machen. Wenn Sie jedoch feststellen, dass Ihnen der Speicherplatz ausgeht und ein seltsames Verhalten auftritt … oder Sie nur eine winzige Zwangsstörung haben, führen Sie Folgendes aus:

docker run -d -e LOW_FREE_SPACE=10G -e EXPECTED_FREE_SPACE=20G -e LOW_FREE_FILES_COUNT=1048576 -e EXPECTED_FREE_FILES_COUNT=2097152 -e DEFAULT_TTL=10m -e USE_DF=1 --restart always -v /var/run/docker.sock:/var/run/docker.sock --name=gitlab-runner-docker-cleanup quay.io/gitlab/gitlab-runner-docker-cleanup

Hinweis: Weitere Informationen finden Sie unter hier

Similar Posts

Leave a Reply

Your email address will not be published.