Tanzu und GitLab CI
In meinem letzten Artikel habe ich gezeigt wie man auf Basis von vSphere Tanzu Cluster bereitstellen kann. Dort habe ich auch geschrieben das ein UseCase dafür unter anderem die GitLab CI ist.
Zunächst einmal, was kann GitLab CI mit Kubernetes? GitLab kann einen Kubernetescluster nutzen um dort seine Runner zu starten. Aber auch kann man über die CI seine Micro-Services auch direkt auf einem Kubernetescluster deployen. Ich beziehe mich nun auf den ersten Teil und zeige wie man CI Runner auf dem Tanzu Cluster bereitstellt.
In diesem Fall gehe ich davon aus das sich zwischen GitLab Server und Tanzu Cluster keine NAT-Instanzen befinden.
Aus Gründen des Leseflusses werde ich hier auch Teile aus der offiziellen GitLab-Anleitung übernehmen.
Die Basics
Hinzufügen kann man in GitLab einen Kubernetescluster an verschiedenen Stellen. Zum einen geht dies im Administrationsbereich, aber auch bei einzelnen Gruppen und auf Projektebene. Aber egal für welche Ebene man sich entscheidet man wird immer vor die Wahl gestellt ob man einen neuen Cluster erstellen möchte, oder ob man einen vorhanden verbinden möchte. Wir wählen immer die zweite Option. Die Eingabemaske die dann ausgefüllt werden muss sieht so aus:
Als Clusternamen kann man einen Friendly Name seiner Wahl eintragen und den Environment scope lasse ich in diesem Fall auf dem Standard (Sternchen). Die restlichen Daten können, bzw. müssen wir aus dem Cluster auslesen.
Zuerst habe ich einen neuen Tanzu Cluster bereitgestellt. Dieser heißt nun gitlab-001. Danach müssen wir uns wieder mit dem Cluster verbinden:
1 2 3 |
kubectl vsphere login --server=<SuperVisorAPI> \ --tanzu-kubernetes-cluster-namespace namespace001 \ --tanzu-kubernetes-cluster-name gitlab-001 |
Die API URL
Mit dem Befehl kubectl config get-contexts können wir uns die verfügbaren Kontexte anschauen lassen. Von Interesse ist hier aber lediglich der Kontext der zu unserem Tanzu Cluster gehört:
Wir sehen hier den Tanzu Cluster gitlab-001 und benötigen die Clusteradresse (192.168.138.131). Diese tragen wir in GitLab als API URL in diesem Format ein: https://<IP>:6443
Ein alternativer Befehl ist
kubectl cluster-info | grep 'Kubernetes master' | awk '/http/ {print $NF}' welcher uns die korrekte URL ausgibt:
https://192.168.138.131:6443
Das CA Certificate
Für das CA Certificate reicht ein einfacher Befehl:
1 2 |
kubectl get secret $(kubectl get secret | grep default | awk '{print $1}') \ -o jsonpath="{['data']['ca\.crt']}" | base64 --decode |
Das angezeigt Zertifikat kopieren wir und fügen es in GitLab als CA Certificate ein.
Der Service Token
Für den Service Token müssen wir zuerst einen entsprechenden ServiceAccount für GitLab erstellen. Ich nutze dazu diese Definition:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
apiVersion: v1 kind: ServiceAccount metadata: name: gitlab-admin namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: gitlab-admin roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: gitlab-admin namespace: kube-system |
Damit die Integration aber gelingt, muss noch ein weiteres RoleAssignment durchgeführt werden. Da dies ein Cluster ist der dediziert für GitLab verwendet wird, kann man es sich einfach gestalten:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: psp:privileged rules: - apiGroups: ['policy'] resources: ['podsecuritypolicies'] verbs: ['use'] resourceNames: - vmware-system-privileged --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: all:psp:privileged roleRef: kind: ClusterRole name: psp:privileged apiGroup: rbac.authorization.k8s.io subjects: - kind: Group name: system:serviceaccounts apiGroup: rbac.authorization.k8s.io |
Dann kann man den Befehl kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep gitlab | awk '{print $1}') nutzen um sich den token anzuzeigen. Dies ist der gesuchte Service Token und kann bei Gitlab an der entsprechenden Stelle hinterlegt werden.
Das fertige Formular
An dieser Stelle sollte das Formular in GitLab nun vollständig ausgefüllt sein:
Das Runner Setup
Die Einrichtung eines GitLab Runners auf diesem Cluster ist denkbar einfach. Dazu wechselt man auf den Applications-Tab und scrollt hinunter bis man den Eintrag GitLab Runner sieht. Dort drückt man auf Installieren:
Den Installationsstatus kann man in der Kubernetes CLI überwachen. Dazu nutzt man diesen Befehl: kubectl get pod -n gitlab-managed-apps Dort erscheint zu erst ein Pod mit dem Namen install-runner und nach einiger Zeit dann der richtige Runner. In meinem Fall heißt dieser runner-gitlab-runner-7f6cf97f67-pclzj. Ab dann kann der Runner in GitLab verwaltet und genutzt werden.
