Continuous IntegrationDiensteDokumentationEntwicklungInfrastruktur

Installieren einer Gitlab Demo Umgebung auf Minikube

Vorraussetzungen

Minikube läuft auf unterschiedlichen Hypervisoren. Dieses Beispiel beschreibt die Installtion unter Virtualbox auf einem MacOS Host. Minikube unterstützt aber auch eine Menge anderer Hypersivor und Platformen.

Bevor wir starten können, müssen noch ein paar Abhängigkeiten installiert werden:

brew cask install minikube
brew install kubectl
brew install kubernetes-helm
brew install dnsmasq
brew cask install ngrok

Neben minikube selbst, sind die die Kubernetes Tools (kubectl,helm) und der lokale DNS-Resolver dnsmasq, sowie das Request Forwarding Tool ngrok (mehr zu ngrok hier)

Setup der Umgebung

Nun können wir minikube anweisen, eine passende VM zu erstellen. Diese hat in diesem Beispiel 4 CPU Kerne, 16G RAM und 32G HDD:

minikube start --cpus 4 --memory 16384 --disk-size 32768M 

minikube addons enable default-storageclass

minikube addons enable kube-dns

minikube addons disable ingress

Die Gitlab Dokumentation enthält eine detailierte Auflistung der benötigten Hardware Ressourcen

Das Repository https://gitlab.com/charts/charts.gitlab.io.git muss geklont werden.

$ cd ~/GIT/charts.gitlab.io

Nun muss auf den Branch add-minikube-support gewechselt werden. Danach muss man alle notwendigen Abhängigkeiten per helm installieren.

$ cd charts/gitlab-omnibus
$ helm repo add gitlab https://charts.gitlab.io
$ helm dep up
$ helm init

Cluster Setup

Wir müssen nun die IP der Minikube VM ermitteln. Dies gelingt mit:

$ minikube ip
192.168.99.101

Wir passen nun zum ersten Mal die dnsmasq Konfiguration an:

$ vi /usr/local/etc/dnsmasq.conf

Hier fügen wir folgenden Eintrag hinzu:

address=/.demo.io/192.168.99.101

Dies bewirkt, dass alle subdomains unserer Demo Domain (*.demo.io) auf die lokale minekube IP 192.168.99.101weitergeleitet werden.

Wir müssen hierzu dnsmasq aber noch einmal neu starten:

$ sudo brew services restart dnsmasq

Unter MacOS ist es ebenfalls wichtig, dass unter den Netzwerkeinstellungen, als erster DNS Server die lokale IP (127.0.0.1) eingetragen wird:

In einem anderen Terminal (oder einem anderen Tab) aktivieren wir nun den IP Forwarder ngrok für die Subdomain gitlab.demo.io:

$ ngrok http gitlab.demo.io:80
Session Status                online
Version                       2.2.8
Region                        United States (us)
Web Interface                 http://127.0.0.1:4040
Forwarding                    http://fe1a3260.ngrok.io -> gitlab.demo.io:80
Forwarding                    https://fe1a3260.ngrok.io -> gitlab.demo.io:80

Connections                   ttl     opn     rt1     rt5     p50     p90
                              0       0       0.00    0.00    0.00    0.00
                              

Dies macht nun unser lokales System unter einer dynaischen externen URL (fe1a3260.ngrok.io) erreichbar.

Die Installation von Gitlab

Im Gitlab Chart Repository muss nun

$ helm install --name gitlab --set provider=minikube,baseDomain=demo.io,baseIP=$(minikube ip),legoEmail=philipp@haussleiter.de,ngrokHostname=fe1a3260.ngrok.io charts/gitlab-omnibus

ausgeführt werden.

Der Fortschritt der Installtion lässt sich mit

kubectl get deployment -w gitlab-gitlab --namespace default

verfolgen:

NAME            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
gitlab-gitlab   1         1         1            0           13s
…
gitlab-gitlab   1         1         1         1         6m

DNS Auflösung reparieren. Hierzu muss der lokale DNS Server (hier 192.168.168.1) nachträglich hinzugefügt werden.

cat <

Überprüfen ob alle Pods auch laufen:

$ kubectl get pods --all-namespaces
NAMESPACE       NAME                                        READY     STATUS    RESTARTS   AGE
default         gitlab-gitlab-7f94658f45-47q8w              1/1       Running   0          1h
default         gitlab-gitlab-postgresql-5fff4f67bb-xcrdj   1/1       Running   0          1h
default         gitlab-gitlab-redis-6c88945d56-7zvwf        1/1       Running   0          1h
default         gitlab-gitlab-runner-7d8ff95d75-jbr9v       1/1       Running   5          1h
kube-lego       kube-lego-58d9b97b95-4wwp2                  1/1       Running   0          1h
kube-system     kube-addon-manager-minikube                 1/1       Running   0          1h
kube-system     kube-dns-54cccfbdf8-6ggg8                   3/3       Running   0          1h
kube-system     kubernetes-dashboard-77d8b98585-nmssj       1/1       Running   0          1h
kube-system     storage-provisioner                         1/1       Running   0          1h
kube-system     tiller-deploy-7594bf7b76-7h4nq              1/1       Running   0          1h
nginx-ingress   default-http-backend-69c767b879-kvnnl       1/1       Running   0          1h
nginx-ingress   nginx-8z52p                                 1/1       Running   0          1h

Wir können dies aber auch direkt auf dem Kubernetes Dashboard kontrollieren.

Ein

$ minikube dashboard

öffnet das Kubernetes Dashboard im Browser.

 

Hier sehen wir die laufenden Services unserer Gitlab Installation:

 

Abschluss der Installation

 

Wir müssen nun herausfinden unter welcher IP Adresse der Gitlab Service erreichbar ist.

Unter Kubernetes ist dies die IP Adresse des LoadBalancer NGinx (nginx-ingress):

 

$ kubectl get services --namespace nginx-ingres
NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                                   AGE
default-http-backend   ClusterIP      10.100.156.107           80/TCP                                    1h
nginx                  LoadBalancer   10.104.168.57         80:31950/TCP,443:31518/TCP,22:30787/TCP   1h

Uns interessiert hier die ClusterIP 10.104.168.57

Jetzt muss in /usr/local/etc/dnsmasq.conf ein weiterer Eintrag hinzugefügt werden.

address=/##dynamic ngrok hostname##/##cluster ip address for nginx##

also in unserem Fall

address=/fe1a3260.ngrok.io/10.104.168.57

Danach wird mit sudo brew services restart dnsmasq der dnsmasq Service neu gestartet.

Als letzten Schritt müssen wir die DNS Auflösung innerhalb der minikube VM beheben. Hierzu öffnen wir eine SSH Session

$ minikube ssh

Und ergänzen die /etc/hosts Datei:

$ sudo vi /etc/hosts
10.104.168.57  gitlab.demo.io
10.104.168.57  fe1a3260.ngrok.io

Wir verlassen die minikube VM wieder und können nun mit einem Browser die URL http://gitlab.demo.io öffnen.

Diese Anleitung basiert auf der Gitlab Dokumentation, während des Setup wurden aber noch ein paar Kleinigkeiten ergänzt.

Tags

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Back to top button
Close