Von 0 auf Kubernetes - Aufbau einer Kubernetes-CI/CD-Infrastruktur per GitLab-Pipeline - Teil 7 - Konfiguration des Rancher-Clusters

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 siebten Teil dieser Serie richten wir das Rancher-Cluster initial mit einem Administratorkonto ein und erstellen einen Namespace für den GitLab-Runner.

Rückblick

Im sechsten Teil haben wir die benötigten Tasks zur Installation des Rancher-Clusters fertiggestellt und können nun mithilfe unserer zwei Playbooks alle benötigten Anwendungen exklusive des GitLab-Runners automatisiert über Ansible erstellen lassen.

Zur besseren Übersicht hier noch einmal das Schaubild unserer späteren Infrastruktur: 

Mit unseren Ansible-Playbooks können wir auf der VM1 Traefik, GitLab und eine Docker-Registry sowie das Rancher-Cluster auf den Systemen VM2, VM3 und VM4 starten. Alle verwendeten Hostnames wurden bereits in Traefik registriert und leiten uns an die gewünschten Maschinen weiter.

Unser Ziel für diesen Teil

In diesem Teil wollen wir ein Terraform-Skript erstellen, welches die initiale Einrichtung des Rancher-Clusters erledigt und damit einen Admin-User mit gewähltem Passwort erstellt. Anschließend erstellen wir einen Namespace für den im neunten Teil folgenden GitLab-Runner.

Terraform und der Rancher2-Provider

Zuerst erstellen wir ein neues Verzeichnis terraform-setup-rancher im Basisverzeichnis unseres Projekts. Es befindet sich also auf derselben Ebene wie das Verzeichnis ansible-setup, in welchem wir die letzten sechs Teile verbracht haben. Nun erstellen wir uns im Verzeichnis terraform-setup-rancher eine Datei namens versions.tf. In dieser müssen wir wie folgt den genutzten Provider auf den Rancher2-Provider festlegen:

terraform {
  required_providers {
    rancher2 = {
      source = "rancher/rancher2"
    }
  }
  required_version = ">= 0.13"
}
 

Neben der versions.tf erstellen wir die im Folgenden die beschriebene Datei namens rancher.tf. In dieser definieren wir unsere gewünschten Eigenschaften des Rancher-Clusters. Im ersten Schritt müssen wir die initiale Einrichtung von Rancher abschließen. Dafür ermöglicht der Rancher2-Provider das sogenannte "bootstrapping". Wir geben also einen Provider an, welchen wir mit der Option bootstrap = true versehen. Als api_url geben wir die URL zur Rancher-UI mit https://rancher.example.com an und über insecure = true erlauben wir selbstsignierte Zertifikate, welche uns von Traefik ausgeliefert werden.

Nun können wir Rancher die gewünschten Informationen übergeben: Ein Administratorpasswort und die Information, ob Rancher Telemetriedaten sammeln darf. Daher geben wir das Passwort über password = "super-duper-safe-rancher-password" an und schalten die Telemetrie über telemetry = false aus.

provider "rancher2" {
  alias = "bootstrap"

  api_url   = "https://rancher.example.com"
  bootstrap = true
  insecure = true
}

resource "rancher2_bootstrap" "admin" {
  provider = rancher2.bootstrap

  password = "super-duper-safe-rancher-password"
  telemetry = false
}
 

Nach diesen zwei Schritten wird Rancher erfolgreich eingerichtet sein. Gleichzeitig liefern diese Schritte uns ein Zugriffstoken des nun erstellten Admin-Kontos in Rancher. Dieses nutzen wir nun, um einen neuen Provider zu definieren, welcher nicht mit bootstrap = true versehen ist und damit keine initiale Einrichtung vornehmen möchte. Die api_url und die Option insecure = true übernehmen wir vom ersten Provider. Allerdings geben wir nun das Zugriffstoken des Admin-Kontos über token_key an und extrahieren dieses aus der Ressource rancher2_bootstrap.admin über rancher2_bootstrap.admin.token.

Über diesen neuen Provider können wir nun ein neues Projekt und innerhalb dieses Projekts einen Namespace erstellen. Als Namen des Projekts wählen wir den passenden Namen gitlab-runner und geben als Cluster-Id local an. Dies ist der Standardname für das Rancher-Cluster. Anschließend generieren wir einen neuen Namespace innerhalb des Projekts mit dem Namen gitlab-runner-namespace.

provider "rancher2" {
  alias = "admin"

  api_url = rancher2_bootstrap.admin.url
  token_key = rancher2_bootstrap.admin.token

  insecure = true
}

resource "rancher2_project" "gitlab-runner" {
  provider = rancher2.admin
  cluster_id = "local"
  name = "gitlab-runner"
}

resource "rancher2_namespace" "gitlab-runner" {
  provider = rancher2.admin
  name = "gitlab-runner-namespace"
  project_id = rancher2_project.gitlab-runner.id
} 

Ob das auch so stimmt?

Wollt Ihr Euren bisherigen Fortschritt testen, so solltet Ihr nochmals die Ansible-Playbooks ausführen. Nun benötigt Ihr eine funktionierende Installation von Terraform. Diese ist, wie Ansible, nur für die Tests nötig. Überprüft nochmals, ob Rancher unter rancher.example.com auf die Ersteinrichtung wartet. Nun navigiert Ihr mit einem Terminal in den Ordner terraform-setup-rancher und führt nacheinander terraform init und terraform apply -auto-approve aus. Nach erfolgreichem Durchlauf solltet Ihr euren Browser aktualisieren bzw. rancher.example.com erneut aufrufen. Statt der Ersteinrichtung solltet Ihr jetzt ein Login-Fenster sehen können. Hier könnt Ihr Euch nun mit dem Nutzer admin und dem von Euch im Terraform-Skript gewählten Passwort anmelden.

Zusammenfassung

In diesem Teil haben ein Terraform-Skript erstellt, welches die Ersteinrichtung von Rancher abschließen kann und einen Namespace für den im neunten Teil folgenden GitLab-Runner erstellt. Über die Rancher-UI kann man sich nun mit dem gewählten Passwort anmelden und somit auf das Rancher-Dashboard zugreifen.

Im achten Teil dieser Anleitung werden wir ein weiteres Terraform-Skript erstellen, welches uns einen User, eine Gruppe und ein Projekt innerhalb unseres neuen GitLabs generiert. Dafür werden wir das im dritten Teil erstellte API-Token für GitLab verwenden.