Von 0 auf Kubernetes - Aufbau einer Kubernetes-CI/CD-Infrastruktur per GitLab-Pipeline - Teil 9 - Installation des GitLab-Runners

Ansible, Terraform, GitLab und etwas Magie: Wie ich eine ganze Infrastruktur auf Knopfdruck erstelle.

In dieser Serie möchte ich Euch zeigen, wie Ihr automatisiert ein Kubernetes-Cluster aufbaut, ein GitLab mit GitLab-Runner installiert und eine eigene Docker-Registry zur Verfügung stellt. Das Ziel wird es sein, dass Ihr Eure Anwendungen direkt aus dem GitLab heraus in eurem Cluster bauen und starten könnt.

Im neunten Teil dieser Serie erstellen wir innerhalb unseres Rancher-Clusters einen GitLab-Runner und registrieren diesen als "shared Runner" innerhalb unseres GitLabs.

Rückblick

Im achten Teil haben wir das zweite Terraform-Skript erstellt, welches uns einen neuen User, eine Gruppe und ein neues Projekt im GitLab erstellt. Innerhalb der Definition des Projekts haben wir die Nutzung von "shared Runnern" erlaubt und haben unserem User entsprechende Rechte auf der Gruppe gegeben.

Unser Ziel für diesen Teil

In diesem Teil wollen wir einen GitLab-Runner innerhalb des Rancher-Clusters erstellen. Diesen werden wir anhand des von GitLab.io zur Verfügung gestellten Helm-Charts installieren. Zur Registrierung innerhalb unseres GitLabs werden wir das initial_shared_runners_registration_token verwenden, welches wir bereits im zweiten Teil innerhalb der docker-compose.yml festgelegt hatten. Hier der zugehörige Ausschnitt der docker-compose.yml:

gitlab_rails['initial_shared_runners_registration_token'] = "safe_runner_reg_token" 

Unsere letzte Ansible-Rolle

Wir erstellen nun unsere letzte benötigte Ansible-Rolle. In dieser Rolle werden wir zuerst wieder Helm auf dem aktuellen System installieren. Die verwendeten Tasks sind also bereits aus dem sechsten Teil bekannt. Anschließend fügen wir das Helm-Repository von GitLab.io zu Helm hinzu und installieren dann den GitLab-Runner über das Helm-Chart gitlab/gitlab-runner in dem im siebten Teil erstellten Namespace gitlab-runner-namespace. Die verwendete values.yml enthält alle Konfigurationen des GitLab-Runners und wird weiter unten besprochen, wobei die Kube-Config bei der Installation des Clusters durch RKE erstellt wurde. Die main.yml der neuen Rolle gitlab_runner sieht dann wie folgt aus:

---
- name: Download helm
  get_url:
    url: https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
    dest: /usr/local/bin/get_helm.sh
    mode: '0777'

- name: Install helm
  command: /usr/local/bin/get_helm.sh
  environment:
    VERIFY_CHECKSUM: false

- name: Add the gitlab runner helm repository
  command: helm repo add gitlab https://charts.gitlab.io

- name: Install gitlab runner
  command: >
    helm upgrade --kubeconfig ./roles/rke_setup/kube_config_rancher-cluster.yml
    --install gitlab-runner -f ./roles/gitlab_runner/values.yml gitlab/gitlab-runner
    --namespace gitlab-runner-namespace
 

...und das letzte Ansible-Playbook

Neben der neuen Rolle benötigten wir ein weiteres Playbook. In diesem muss es nur einen Schritt geben, in dem die gerade erstellte Rolle gitlab_runner verwendet wird. Analog zum sechsten Teil wird hier wieder auf dem Host localhost verwiesen. Hier unser Playbook:

---
- name: setup gitlab runner
  hosts: localhost
  become: true
  roles:
    - gitlab_runner
 

Konfiguration des GitLab-Runners

Die Konfiguration des GitLab-Runners findet in der bereits angesprochenen values.yml statt. Diese erstellen wir unter folgendem Pfad: ansible-setup/roles/gitlab_runner/values.yml.

Die values.yml bietet viele Möglichkeiten, den GitLab-Runner zu konfigurieren. Hier findet ihr eine Übersicht über alle Konfigurationsparameter und deren Bedeutung. Da alle Optionen im angegebenen Link ausreichend erklärt werden, werde ich mich hier nur auf die für uns wirklich relevanten Punkte beschränken. Zuerst geben wir unter der Option gitlabUrl unseren Link zum GitLab an. Als runnerRegistrationToken verwenden wir nun das initial_shared_runners_registration_token aus dem zweiten Teil. Nicht nötig, aber "nice-to-have": Mit concurrent: 10 erlauben wir die parallele Ausführung von maximal zehn CI/CD-Jobs gleichzeitig. Unter runners legen wir nun den Tag unseres Runners mit tags: rancher fest. Der Runner kann damit in GitLab CI/CD-Pipelines über diesen Tag angesprochen und verwendet werden. Per namespace geben wir nochmals den verwendeten Namespace im Kubernetes-Cluster an. Damit werden alle CI/CD-Jobs im Namespace des GitLab-Runners gestartet. Mit privileged: true erlauben wir die Verwendung von Docker-in-Docker, was uns später das Erstellen von Docker-Images innerhalb einer Pipeline ermöglicht. Unter env legen wir einige Umgebungsvariablen fest, welche in jedem vom GitLab-Runner gestarteten Container aktiviert werden. Zuerst legen wir den HTTP- und HTTPS-Proxy fest. Hierfür verwenden wir sicherheitshalber beide Schreibweisen (groß- und kleingeschrieben), da manche Programme die ein oder andere Schreibweise erwarten. Dann geben wir an, dass bei Zugriffen auf unsere eigene Docker-Registry registry.example.com und auf das Rancher-Cluster rancher.example.com kein Proxy verwendet werden soll. Die meisten Programme, welche innerhalb der CI/CD-Jobs verwendet werden, sollten mit diesen Optionen über den Proxy einen Internetzugriff ermöglicht bekommen. Für besondere Fälle können wir ebenfalls die IP und den Port des Proxy separat als einzelne Umgebungsvariablen PROXY_IP und PROXY_PORT speichern. Dies wird nützlich, wenn wir bei einem Programm die IP und den Port des Proxy getrennt angeben müssen. In diesem Fall könnte man den Proxy beispielsweise wie folgt angeben: PROGRAMM -proxy_ip $PROXY_IP -proxy_port $PROXY_PORT.

Die resultierende values.yml sieht dann wie folgt aus:

---
gitlabUrl: http://gitlab.example.com/
runnerRegistrationToken: "safe_runner_reg_token"
concurrent: 10
checkInterval: 1

rbac:
  create: true
  clusterWideAccess: true
  podSecurityPolicy:
    enabled: false
    resourceNames:
      - gitlab-runner

runners:
  image: ubuntu:18.04
  privileged: true
  tags: rancher
  namespace: gitlab-runner-namespace
  env:
    https_proxy: http://proxy-ip:proxy-port
    http_proxy: http://proxy-ip:proxy-port
    HTTPS_PROXY: http://proxy-ip:proxy-port
    HTTP_PROXY: http://proxy-ip:proxy-port
    PROXY_IP: ->proxy-ip<-
    PROXY_PORT: ->proxy-port<-
    NO_PROXY: registry.example.com,rancher.example.com
    DOCKER_TLS_CERTDIR: ""
  builds:
    cpuRequests: 100m
    memoryRequests: 128Mi
  services:
    cpuRequests: 100m
    memoryRequests: 128Mi
  helpers:
    cpuRequests: 100m
    memoryRequests: 128Mi
 

Das muss doch jetzt klappen, oder?

Waren bisher alle Tests erfolgreich, könnt ihr euer neues Playbook mit ansible-playbook gitlab-runner.yml testen. Nach erfolgreichem Durchlauf solltet ihr in der Rancher-UI sehen können, dass der GitLab-Runner im Namespace gitlab-runner-namespace liegt. In GitLab solltet Ihr in der Admin-Area unter Overview -> Runners den neuen Runner mit dem Tag rancher finden.

Mit diesem Teil sollte Eure Infrastruktur nun fertiggestellt sein. Ihr könnt alle Services über die entsprechenden URLs erreichen, in Eurem GitLab steht ein User mit einem Testprojekt zur Verfügung, ein GitLab-Runner wartet innerhalb des Rancher-Clusters auf seine Aufgaben und Ihr könnt mit der Entwicklung beginnen. Lauffähige Anwendungen können dann im Rancher-Cluster deployt und unter dem Hostname api.example.com, welcher auf das Cluster leitet, zur Verfügung gestellt werden. Glückwunsch! Eure Infrastruktur ist nun einsatzbereit!

Zusammenfassung

In diesem Teil haben wir ein weiteres Ansible-Playbook mit zugehöriger Rolle erstellt, welche uns einen GitLab-Runner innerhalb des Rancher-Clusters installieren und in GitLab registrieren kann. Der Runner liegt in seinem eigenen Namespace und hat einen Tag erhalten, durch welchen er in CI/CD Pipelines angesprochen werden kann.

Im zehnten Teil dieser Anleitung werden wir alle bisher durchgeführten Schritte in einer einzigen GitLab CI/CD-Pipeline sammeln. Die Installation der gesamten Infrastruktur gelingt damit per Knopfdruck!