Von 0 auf Kubernetes - Aufbau einer Kubernetes-CI/CD-Infrastruktur per GitLab-Pipeline - Teil 10 - Erstellung der Pipeline

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 zehnten Teil dieser Serie erstellen wir uns eine GitLab CI/CD Pipeline, die alle bisher besprochen Schritte selbstständig durchführen kann. Die Installation der Infrastruktur gelingt damit per Knopfdruck!

Rückblick

Im neunten Teil haben wir ein weiteres Ansible-Playbook zur Installation eines GitLab-Runners innerhalb unseres Rancher-Clusters erstellt. Gleichzeitig wird der Runner automatisch im GitLab registriert und kann damit CI/CD-Jobs bearbeiten.

Unser Ziel für diesen Teil

In diesem Teil wollen wir alle bisher beschriebenen Schritte in einer einzigen GitLab CI/CD-Pipeline bündeln. Dafür werde ich nacheinander die einzelnen Jobs beschreiben und auf die entsprechenden Teile dieser Anleitung verweisen. Am Ende haben wir eine Pipeline, die unsere Infrastruktur per Knopfdruck installieren kann.

Der SSH-Schlüssel

In den bisherigen Tests habt Ihr beim Starten der Ansible-Playbooks entweder das SSH-Passwort der verwendeten VMs eingeben müssen oder hattet den SSH-Schlüssel lokal abgespeichert. Damit Ansible in unserer Pipeline funktionieren kann, benötigt es natürlich diesen SSH-Schlüssel. Daher solltet ihr in eurem Projekt innerhalb eures GitLabs den SSH-Schlüssel als geschützte CI/CD-Variable namens ssh_key definieren. Beachtet, dass ich hier und im Folgenden das GitLab anspreche, in dem Ihr die Ansible-Playbooks und Terraform-Skripte verwaltet und in dem später die Pipeline zum Installieren der Infrastruktur ausgeführt wird. Dieses habe ich in der Übersicht der Infrastruktur in Orange dargestellt. Es ist damit nicht das auf der VM1 (rot) neu erstellte GitLab gemeint.

Beginn der Pipeline

Wir beginnen mit der Erstellung einer .gitlab-ci.yml im Hauptverzeichnis unseres Projekts. Zu Beginn definieren wir unsere Sprache und die verschiedenen Stages der Pipeline:

---
before_script:
  - export LANG="de_DE.UTF-8"

stages:
  - Setup
  - Rancher Configuration
  - GitLab Configuration
  - Setup GitLab Runner
 

Die Struktur der Stages sollte euch an die Struktur dieser Anleitung erinnern. Alle folgenden Code-Schnipsel sind Teil dieser .gitlab-ci.yml.

GitLab, Traefik und die Docker-Registry

Im ersten Job der Stage Setup nutzen wir unser Ansible-Playbook zum Installieren von GitLab, Traefik und der Docker-Registry aus den Teilen 2, 3 und 4. Um eine funktionierende Ansible-Installation zur Verfügung zu haben, nutzen wir das Docker-Image cytopia/ansible mit dem Tag 2.8-tools. Nun geben wir den Tag des in unserem GitLab verwendbaren GitLab-Runners an. In meinem Fall lautet dieser docker. Im script müssen wir nun zwei Vorbereitungen für Ansible treffen. Zum einen wird uns SSH bei der ersten Verbindung mit einem neuen System über eine interaktive Abfrage auffordern, den öffentlichen Schlüssel des Systems zu bestätigen. Da wir innerhalb einer CI/CD-Pipeline keine interaktiven Abfragen erlauben können, schalten wir diesen Check über StrictHostKeyChecking no innerhalb der SSH-Konfigurationsdatei ~/.ssh/config ab. Nun kopieren wir den Inhalt der Umgebungsvariable ssh_key, welche nach obigem Schritt unseren SSH-Schlüssel enthält, in die Datei ~/.ssh/id_rsa. Dies ist die von SSH im Standard verwendete Schlüsseldatei, wodurch wir uns eine zusätzliche Pfadangabe sparen. Für das Verzeichnis ~/.ssh/ und die Datei ~/.ssh/id_rsa hat SSH strenge Anforderungen an die Dateirechte, weshalb wir diese per chmod auf 700 bzw. 600 setzen. Anschließend können wir in das Verzeichnis der Ansible-Playbooks wechseln und das erste Playbook ausführen:

 Das Rancher-Cluster

Der Job zur Installation des Rancher-Clusters hat nur zwei nennenswerte Unterschiede zum gerade beschriebenen Job. Zum einen wird statt des Playbooks gitlab.yml das Playbook rancher.yml gestartet, welches wir in den Teilen 5 und 6 erstellt haben. Zum anderen müssen wir an dieser Stelle die von RKE generierte Kube-Config als Artefakt angeben, da wir diese bei der Installation des GitLab-Runners benötigen. Die Datei wird somit in allen Jobs der folgenden Stages zur Verfügung stehen.

Install Rancher Cluster:
  stage: Setup
  image: cytopia/ansible:2.8-tools
  tags:
    - docker
  script:
    - 'mkdir -p ~/.ssh'
    - 'chmod 700 ~/.ssh'
    - 'echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
    - 'cp $ssh_key ~/.ssh/id_rsa'
    - 'chmod 600 ~/.ssh/id_rsa'
    - 'cd ansible-setup'
    - 'ansible-playbook -i inventory.yml rancher.yml'
  artifacts:
    paths:
      - ansible-setup/roles/rke_setup/kube_config_rancher-cluster.yml
 

Konfiguration des Rancher-Clusters

In diesem Job verwenden wir unser Terraform-Skript aus dem siebten Teil. Wir ordnen ihn in die Stage Rancher Configuration ein. Als Image des Jobs können wir das von Hashicorp selbst zur Verfügung gestellte Image hashicorp/terraform:light verwenden, wobei wir hier zur besseren Übersicht unseres Skripts den Entrypoint des Images überschreiben. Im script wechseln wir in das Verzeichnis des Terraform-Skripts für Rancher und führen dann die aus den Tests bekannten Befehle terraform init und terraform apply -auto-approve aus.

Configure Rancher Cluster:
  stage: Rancher Configuration
  image:
    name: hashicorp/terraform:light
    entrypoint: ["/bin/sh", "-c"]
  tags:
    - docker
  script:
    - 'cd terraform-setup-rancher'
    - 'terraform init'
    - 'terraform apply -auto-approve'
 

Konfiguration von GitLab

In diesem Abschnitt kommt das Terraform-Skript zum Konfigurieren von GitLab aus dem achten Teil zum Einsatz. Dieser Job ähnelt wieder dem vorherigen Job zur Konfiguration von Rancher und unterscheidet sich nur in der Stage GitLab Configuration, dem genutzten Verzeichnis terraform-setup-gitlab und der zusätzlichen Option -parallelism=1 beim Aufruf von terraform apply. Letzteres ist die Lösung für ein bekanntes Problem des Terraform-GitLab-Providers und könnte zum Zeitpunkt der Veröffentlichung dieses Artikels bereits gelöst sein.

Configure GitLab:
  stage: GitLab Configuration
  image:
    name: hashicorp/terraform:light
    entrypoint: ["/bin/sh", "-c"]
  tags:
    - docker
  script:
    - 'cd terraform-setup-gitlab'
    - 'terraform init'
    - 'terraform apply -auto-approve -parallelism=1'
 

Installation des GitLab-Runners

Zu guter Letzt muss noch der GitLab-Runner installiert werden. Hierfür verwenden wir das entsprechende Playbook aus dem neunten Teil. Der Job selbst, nun innerhalb der Stage Setup GitLab Runner, gleicht denen zur Installation der Services und des Rancher-Clusters, wobei an dieser Stelle das Playbook gitlab-runner.yml gestartet wird.

Setup GitLab Runner:
  stage: Setup GitLab Runner
  image: cytopia/ansible:2.8-tools
  tags:
    - docker
  script:
    - 'mkdir -p ~/.ssh'
    - 'chmod 700 ~/.ssh'
    - 'echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
    - 'cp $ssh_key ~/.ssh/id_rsa'
    - 'chmod 600 ~/.ssh/id_rsa'
    - 'cd ansible-setup'
    - 'ansible-playbook gitlab-runner.yml'
 

Unsere fertige Pipeline

Unsere Pipeline, welche aus vier Stages besteht, kann nun die gesamte Infrastruktur automatisiert installieren. Nachdem Ihr Euer Projekt per Git auf euer GitLab transferiert habt, sollte die Pipeline direkt starten. Andernfalls könnt Ihr sie auch unter dem Menüpunkt CI/CD -> Pipelines manuell starten. Der Durchlauf der Pipeline könnte einige Minuten benötigen, allerdings solltet Ihr am Ende ein fertig eingerichtetes Rancher-Cluster und GitLab vorfinden können. Von Euch getätigte Änderungen an der Infrastruktur sollten nach einem erneuten Durchlauf der Pipeline vollständig zurückgesetzt sein.

Zusammenfassung

Meinen Glückwunsch! Ihr habt es durch die 10 Teile dieser Anleitung geschafft! Wir haben jetzt die GitLab CI/CD-Pipeline fertiggestellt und dabei alle bisher besprochenen Skripte verwendet. Wir können die gesamte Infrastruktur mit einem Durchlauf der Pipeline installieren oder Änderungen mit einem Durchlauf verwerfen. Eine lauffähige GitLab-CI/CD-Kubernetes-Infrastruktur - alles nur einen Klick entfernt!