CI/CD Effizientes CI/CD mit GitLab und Kubernetes: Ein Leitfaden

• Einleitung
• Voraussetzungen
  • Gitlab-Agent
• Gitlab-Runner installieren und mit Projekt verbinden
• Pipeline konfigurieren

Einleitung

In der Softwareentwicklung sind Continuous Integration und Continuous Deployment (CI/CD) heute unverzichtbar. Wir stellen eine robuste Lösung vor, die diese Prozesse nahtlos integriert: GitLab CI in Kombination mit Kubernetes.

In diesem Beitrag zeigen wir, wie man ein Kubernetes-Cluster per Agent mit Gitlab verbindet, einen Gitlab Runner installiert und anschließend eine einfache CI/CD-Pipeline einrichtet.

Voraussetzungen

1. Kubernetes Cluster: Sie benötigen einen betriebsbereiten Kubernetes-Cluster. Egal ob lokal (z.B. mit Minikube) oder einer in einer Cloud-Umgebung wie AWS, Google Cloud oder Azure.
2. Helm (Version 3.0 oder höher): Helm, der Paketmanager für Kubernetes, wird benötigt, um die GitLab-Komponenten im Kubernetes-Cluster zu installieren und zu verwalten. Stellen Sie sicher, dass Sie mindestens Version 3.0 installiert haben, die signifikante Verbesserungen und Änderungen gegenüber früheren Versionen aufweist.
3. GitLab-Server: Ein GitLab-Server, entweder eine selbstgehostete Instanz oder GitLab.com, ist erforderlich, um Ihre Repositories zu verwalten und die CI/CD-Pipeline zu orchestrieren.
4. Zugangsberechtigungen: Stellen Sie sicher, dass Sie über die notwendigen Berechtigungen verfügen, um Änderungen in Ihrem Kubernetes-Cluster und auf Ihrem GitLab-Server vorzunehmen. Dies umfasst Administratorzugriff oder zumindest Berechtigungen zum Erstellen und Verwalten von CI/CD-Pipelines und Kubernetes-Ressourcen.

Gitlab-Agent

Der Gitlab-Agent baut einen permanten und sicheren Kommunikationskanal zwischen Gitlab und Kuberntes auf, über den später diverse GitOps-Funktionen ausgeführt werden können. Außerdem ermöglicht der Agent den Betrieb der GitLab Runner im Cluster, bietet sicheren Cluster-Zugriff für CI/CD-Aufträge, scannt Images auf Schwachstellen im Cluster und vieles mehr. Um den branchenüblichen Best Practices für GitOps zu folgen, wird er per Code konfiguriert, anstatt über eine UI/Benutzeroberfläche.

In unserem Beispiel gehen wir davon aus, dass noch keine Konfigurations-Datei vorhanden ist und werden im Folgenden einen neuen Gitlab-Agent "registrieren".

1. Unter Menu wählen wir das jeweilige Projekt aus. Anschließend unter Infrastructure das gewünschte Kubernetes-Cluster.
2. Dort wählen wir Register an Agent
3. Gitlab generiert für uns nun einen Access Token. Dieser Token wird nur einmal angezeigt und sollte unbedingt sicher verwahrt werden, denn wir benötigen ihn sowohl für die Installation, als auch für mögliche spätere Updates des Agents. Gitlab gibt uns auch direkt die für den nächsten Schritt benötigten Helm-Befehle aus, die wir einfach kopieren.

Beispiel:

   helm repo add gitlab https://charts.gitlab.io
   helm repo update
   helm upgrade --install gitlab-agent gitlab/gitlab-agent \
    --namespace gitlab-agent \
    --create-namespace \
    --set config.token=<access-token> \
    --set config.kasAdress=wss://<git.url>/-/kubernetes-agent/

Die Installation des Gitlab-Agent in dem gewünschten Cluster führen wir ganz einfach per Helm Chart durch. Dafür benötigen wir Helm in der Version 3.0 oder höher und müssen uns per Terminal mit unserem Cluster verbinden. Anschließend die Befehle aus Schritt 3 auszuführen und der Agent wird installiert.

Gitlab-Runner installieren und mit Projekt verbinden

Den Gitlab-Runner installieren wir anhand des von Gitlab.com zur Verfügung gestellten Helm Charts im Kubernetes-Cluster.

Das Helm Repository hinzufügen:

helm repo add gitlab https://charts.gitlab.io

Helm inititialisieren (nur bis Helm Version 2 notwendig):

helm init

Anschließend muss der Gitlab Runner noch konfiguriert werden. Die Konfiguration erfolgt über eine values.yml Datei. In der offiziellen Gitlab Dokumention werden zahlreiche Optionen und Parameter für die Konfiguration behandelt. Für unsere Zwecke relevant sind aber vor allem die Punkte gitlabUrl und runnerRegistrationToken.

Unter der Option gitlabUrl geben die die Url des Gitlab-Servers an, gegen den der Runner sprechen soll.

runnerRegistrationToken bezieht auf den Registrierungs-Token für neue Runner, den wir im vorherigen Schritt bei der Registrierung des Agents erhalten haben. Der Token kann bei Bedarf auch als Secret abgelegt werden.

Ist die values.yaml konfiguriert, wird der Runner über den folgenden Befehl installiert. gibt dabei den Pfad zur values-Datei an und wir definieren in welchem Namespace Runner laufen soll.

helm install --namespace <NAMESPACE> gitlab-runner -f <CONFIG_VALUES_FILE> gitlab/gitlab-runner

Pipeline konfigurieren

Nachdem wir vorangehend unseren Gitlab Runner installiert haben, definieren wir nun die Stages und Jobs für die CI/CD-Pipeline in einer .gitlab-ci.yaml Datei. Struktur und Reihenfolge der Aufgaben, die der Runner in Zukunft ausführen soll, sowie gegebenenfalls Ausnahmeregelungen, lassen sich hier konfigurieren.

Im gewünschten Branch erstellen wir eine neue Datei mit dem Dateinamen .gitlab-ci.yml. Die offizielle Gitlab Dokumentation erklärt die möglichen Keyword-References für die Einrichtung von Pipelines umfassend, wir erstellen für dieses Beispiel aber lediglich eine einfache Pipeline mit 3 Jobs, die wie folgt aussehen könnte:

build-job:
  stage: build
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"

test-job1:
  stage: test
  script:
    - echo "This job tests something"

test-job2:
  stage: test
  script:
    - echo "This job tests something, but takes more time than test-job1."
    - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
    - echo "which simulates a test that runs 20 seconds longer than test-job1"
    - sleep 20

deploy-prod:
  stage: deploy
  script:
    - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."

Von nun an wird die Pipeline bei jedem Commit ausgeführt.