Von 0 auf Kubernetes - Aufbau einer Kubernetes-CI/CD-Infrastruktur per GitLab-Pipeline - Teil 8 - Konfiguration von GitLab

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 achten Teil dieser Serie erstellen wir ein zweites Terraform-Skript, welches uns einen neuen User, eine Gruppe und ein Projekt in unserem neuen GitLab einrichtet.

Rückblick

Im siebten Teil haben wir das erste Terraform-Skript erstellt. Dieses erledigt die Ersteinrichtung von Rancher und generiert innerhalb des Kubernetes-Clusters einen Namespace, in welchem später der GitLab-Runner liegen soll.

Unser Ziel für diesen Teil

In diesem Teil wollen wir ein zweites Terraform-Skript erstellen, welches unser neues GitLab konfiguriert. Wir wollen einen neuen User, eine neue Gruppe und darin ein neues Projekt generieren. Als kleine Demo werden wir innerhalb dieses Projekts gleichzeitig eine CI/CD-Variable festlegen.

Vom GitLab-Provider zum GitLab-Projekt

Zuerst erstellen wir wieder ein neues Verzeichnis terraform-setup-gitlab im Basisverzeichnis unseres Projekts. Analog zum letzten Teil erstellen wir hier wieder eine versions.tf, in welcher wir unseren Provider auf den GitLab-Provider festlegen. Die versions.tf sieht dann wie folgt aus:

terraform {
  required_providers {
    gitlab = {
      source = "gitlabhq/gitlab"
      version = "3.3.0"
    }
  }
  required_version = ">= 0.13"
} 

Jetzt erstellen wir neben der versions.tf eine Datei namens gitlab.tf. In dieser definieren wir wieder unsere gewünschten Ressourcen. Für den Provider legen wir die URL nicht einfach auf gitlab.example.com fest, sondern nutzen den direkten Link zu GitLabs API. Wie bei der Konfiguration von Rancher geben wir über insecure = true an, dass Terraform selbst-signierte Zertifikate akzeptieren soll. Als Token geben wir nun jenes Token an, welches wir im dritten Teil per GitLab-Rails-Konsole erstellt hatten.

Nun definieren wir über eine gitlab_user -Ressource einen User mit Benutzername, E-Mail und Passwort. Gleichzeitig geben wir einige weitere benötigte Optionen mit. Beispielsweise geben wir über is_admin unserem neuen User Administratorrechte. Anschließend definieren wir per gitlab_group unsere neue GitLab-Gruppe. Wir geben ihr einen passenden Namen mit Pfad und können sogar eine kleine Beschreibung hinzufügen. Damit unser neuer User diese Gruppe und alle darin enthaltenen Projekte auch nutzen kann, müssen wir diesen zur Gruppe hinzufügen. Daher geben wir per gitlab_group_membership unserem User entsprechende Rechte (hier die Rechte eines Maintainers) auf der Gruppe. Der User und die Gruppe können hier einfach per ID identifiziert werden. Schließlich definieren wir noch ein Projekt innerhalb der Gruppe. Neben einem passenden Namen und einer Beschreibung muss hier als namespace_id die ID der gerade erstellten Gruppe angegeben werden. Da wir im neunten Teil einen GitLab-Runner als sogenannten "shared Runner" dem gesamten GitLab zur Verfügung stellen werden, müssen wir die Nutzung von "shared Runnern" innerhalb dieses Projekts noch explizit per shared_runners_enabled erlauben. Andernfalls müsste man für jedes Projekt einen neuen GitLab-Runner erstellen. Die resultierende gitlab.tf hat nun folgende Gestalt:

provider "gitlab" {
  token = "super_save_api_token"
  base_url = "https://gitlab.example.com/api/v4/"
  insecure = true
}

resource "gitlab_user" "ordix" {
  name             = "ORDIX AG"
  username         = "ordix"
  password         = "super-sicheres-gitlab-passwort"
  email            = "ordix@example.com"
  is_admin         = true
  projects_limit   = 100000
  can_create_group = true
  is_external      = false
  reset_password   = false
}

resource "gitlab_group" "testgroup" {
  name        = "Test-Gruppe"
  path        = "testgroup"
  description = "Eine Gruppe zum Herumprobieren und Lernen"
}

resource "gitlab_group_membership" "testgroup" {
  user_id      = gitlab_user.ordix.id
  access_level = "maintainer"
  group_id     = gitlab_group.testgroup.id
}

resource "gitlab_project" "testproject" {
  name                   = "testprojekt"
  description            = "Testprojekt innerhalb unserer neuen Gruppe"
  namespace_id           = gitlab_group.testgroup.id
  shared_runners_enabled = true
}
 

CI/CD-Variablen über Terraform definieren

Als kleinen Bonus möchte ich euch noch zeigen, wie man CI/CD-Variablen innerhalb eines Projekts über Terraform definieren kann. Dies wird durch die Ressource gitlab_project_variable ermöglicht. Als project geben wir die ID unseres Projekts testproject an. Nun definieren wir über key und vaule eine CI/CD-Variable. Das könnten beispielsweise Credentials oder im Projekt verwendete Hostnames sein. Über protected können wir noch angeben, ob es sich hierbei und eine geschützte Variable handelt, also ob jeder den Inhalt der Variable lesen kann, oder nur Nutzer mit entsprechenden Rechten. Zur Erstellung der Variable erweitert Ihr die gitlab.tf mit folgenden Zeilen:

resource "gitlab_project_variable" "test_variable" {
  project   = gitlab_project.testproject.id
  key       = "password_for_something"
  value     = "super-important-and-safe-password"
  protected = true
} 

Ein kleiner Test – die Vierte!

An dieser Stelle könnt Ihr euren Fortschritt wieder testen, indem Ihr zuerst die Tests der letzten Teile ausgeführt habt. Ihr solltet also eine funktionierende Terraform-Installation besitzen und euer GitLab sollte unter gitlab.example.com erreichbar sein. Nun navigiert Ihr mit einem Terminal in den Ordner terraform-setup-gitlab und führt nacheinander terraform init und terraform apply -auto-approve aus. Anschließend solltet Ihr Euch im GitLab mit dem in der gitlab.tf definierten User anmelden können und Eure neue Gruppe und Euer neues Projekt sehen können.

Zusammenfassung

In diesem Teil haben wir ein zweites Terraform-Skript erstellt, welches innerhalb des GitLabs einen neuen User, eine Gruppe und ein Projekt erstellt. Wir vergeben dem User entsprechende Nutzerrechte auf der gesamten Gruppe und aktivieren die "shared Runner" innerhalb des Projekts. Außerdem habt ihr eine Möglichkeit kennengelernt, wie ihr CI/CD Variablen innerhalb eines Projekts per Terraform erstellen könnt.

Im neunten Teil dieser Anleitung werden wir einen GitLab-Runner innerhalb des Rancher-Clusters erstellen und diesen in unserem GitLab registrieren. Mit seiner Hilfe können dann innerhalb der Projekte des GitLabs CI/CD Pipelines gestartet werden.