Kubernetes – Einblick in die Open Source Welt

Es ist mal wieder Zeit für was Neues. Nachdem ich mich ausgiebig mit Public Cloud Providern, Docker, Continuous Integration und Continuous Deployment beschäftigt habe fehlt noch eine Kleinigkeit.

Natürlich, die Container-Orchestrierung und wie der Titel schon sagt, im speziellen mit Kubernetes. Wenn man sich mit diesen Themen beschäftigt landet man schnell bei einigen weitergehenden Themen wie zum Beispiel Terraform, Ansible, Python und GoLang. Diese findet man eigentlich überall vor.

Kubernetes selbst ist in Go geschrieben. Installationshelfer sind in Python oder Go geschrieben und einige Projekte stellen komplexe Infrastrukturen in Form von Terraform Konfigurationen und Ansible Playbooks bereit.

Die Masse dieser Programme, Konfigurationen und Helfer sind Open Source, eine ideale Welt zum lernen also. Mit Go hab ich mich schon seit etwas längerem beschäftigt und mir verschieden Programme angeschaut und natürlich auch fleissig selbst in die Tasten gehackt. Infrastructure as a Code ist mir auch geläufig, als Entwickler hat man aber meist wenig damit zu tun. All diese Tools sind aber hervorragend geeignet um einfach alles zu automatisieren. Also genau mein Geschmack.

Die letzten Tage habe ich mich hauptsächlich mit der automatisierten Installation eines Kubernetes Clusters in Public Clouds beschäftigt.
Hier kommt dann eine ordentliche Portion Gemischtes auf dem Schreibtisch.

Als erstes die Infrastruktur als Code, hier bietet Kubespray ein ordentliche Packung an Terraform Konfigurationen und Ansible Playbooks an. Mit ein paar Befehlen und Konfigurationen lässt sich so auf Amazon eine gut geplante Infrastruktur erstellen. Insgesamt dürften es 37 Ressourcen sein die bei einem Bastion – Master – Node Cluster zusammen kommen.

Dann muss Kubernetes noch auf den Master und die Nodes installiert werden. Das geht wunderbar mit Ansible und Kubespray. Man kann das ganze natürlich auch mit Kubeadm lösen und sein Cluster einrichten. Oft sind es mehrere kleine Schritte, bis alles läuft. Bei manchen Lösungen muss man aber auch einzelne Schritte öfters wiederhohlen, um zum Beispiel die Nodes einzurichten. Ander brauchen sehr viel Bootstrap bis alle Anforderungen erfüllt sind, um rund zu laufen und das leider auch auf mehreren Severn.

Es kommt aber immer etwas dazu, um das ganze noch mehr zu vereinfachen. Wenn man viel vereinfacht bleibt natürlich auch viel Wissen auf der Strecke. Um das zu vermeiden habe ich angefangen dort einzusteigen wo die Vereinfachung beginnt, denn dann muss man das ganze Wissen aufbauen um am Ende eine To Go Lösung zu erhalten die weiteren Nutzern die Arbeit abnimmt. Gerade im beruflichen Alltag fehlt einem die Zeit sich intensiv mit dem Gesamten Thema zu beschäftigen und benötigt nur eine schnelle, einfache und sichere Lösung.

Ideal wäre es, ein Konsolen Befehl einzutippen, sich eine Tasse Kaffee zu hohlen, sich kurz noch mit den Kollegen auszutauschen und beim zurück kommen an den Schreibtisch ist das Kubernetes Cluster produktiv einsetzbar. Klar man kann sogar einfach den Konsolen Befehl von automatisierten Task ausführen lassen.
Als Beispiel könnte Jenkins ein Kubernetes Cluster zum testen hochfahren, nötige Applikation als Pods starten, alle nötigen Tests durchlaufen und am ende das Cluster wieder abbauen.

Klingt nach einem tollen Gedanken. Stop, genau das hab ich doch heute schon mindestens 12 mal gemacht, nennt mich Jenkins 🙂

Tatsächlich gibt es bereits die Möglichkeiten und auch eine Auswahl, an Operation Systems, auf die ich gern mein Cluster aufbauen möchte. Ob CoreOS, CentOS oder Ubuntu ist nur eine Frage der Konfigurationsdatei ebenso welche Cloud ich nutzen möchte. Ob nun Public wie AWS, Google Cloud, Azure oder Private Clouds wie Openstack. Natürlich bleiben die Server im Rechenzentrum auch nicht unberücksichtigt und es gibt eine Bare-Metal Installation.

Schaut euch mal die verschiedenen Lösungen an und entscheidet für Euch was am besten zu euren Anforderungen passt. Ich hab mich für TK8 entschieden und bin hier fleißig dabei Code zu produzieren.

Da ich nun wieder mehr Zeit habe und intensiver mit den Themen arbeiten werde, kommen in den nächsten Wochen noch einige Inhalte rund um das Thema und auch endlich wieder YouTube Videos 🙂

Als bleibt am Ball, folgt meinem Blog oder dem YouTube Channel!

Teil 1 – CI / CD Docker Composer

Nach langer Zeit und einiges an Informationsverarbeitung, hier ein kleiner Beitrag von mir zum Thema Continuous Integration und Continuous Deployment.

Vermutlich weist du um was es sich handelt. Entwickler schreiben auf Ihren lokalen Arbeitsplätzen hervorragende Anwendungen und Features die irgendwann den Weg auf eine Testumgebung finden. Von dort aus geht es in dann meist auf eine Qualitätsumgebung bis es dann schlussendlich in der produktiven Umgebung landet. Da hier in der Vergangenheit viele manuell Schritte nötig waren, die natürlich nicht immer Fehlerfrei durchlaufen wurden, kann das ganze voll automatisch strukturiert werden. Der Vorteil liegt klar auf der Hand, automatische Prozesse machen immer das gleiche und verringern die Fehleranfälligkeit. Zudem spart man viel Zeit, im vergleich zum manuellen Deployment.

Der Workflow sieht dann im Grunde vor, dass die Entwickler wie gewohnt ihren Programmcode in einer Source Verwaltung ( Beispielsweise GIT ) aufbewahren und dort aktualisieren. Von hier aus kann der automatisch Prozess dann auch schon beginnen.

Ein so genannter Build Service, in meinem Fall Jenkins, bekommt die Information das sich in einem überwachten Branch etwas verändert hat. Nun wird der Programmcode aus dem Source Repository gezogen und „gebaut“. Bauen kann in verschiedenen Programmiersprachen natürlich unterschiedlich aussehen. Gehen wir von einer Java Applikation mit Maven aus dann wird nun ein „mvn clean package“ erzeugt. Während dessen laufen die Tests und mit ein wenig Erweiterungen wird ebenfalls die Code Qualität geprüft und die Testabdeckung berechnet. Diese Information können dann zum Beispiel in SonarQube eingesehen werden. Sollte alles passen wird das Packet weiter verarbeitet und landet in der Testumgebung. Hier können dann Integrations Test gefahren werden. Eine Lösung hierfür wäre zum Beispiel Postman. Zudem können noch Last Test gemacht werden, hier bietet sich JMeter an. All diese Tests lassen sich Problemlos automatisiert durchführen. In der Qualitätsumgebung können dann zum beispiel manuell Test gemacht werden oder noch viel besser, automatisierte Acceptance Tests durchgeführt werden. Sollte hier alles wie gewünscht laufen spricht nichts mehr dagegen die neue Version in die Produktive Umgebung zu liefern.

Wie sieht nun meine Lösung aus. Ich habe schon öfters geschrieben das ich meine Umgebung und mein Server komplett auf Docker ausgelegt habe, daher ist es auch für mich nahelegend das meine Integration dieser Schritte ebenso eine Container Lösung benötigt. Daher habe ich ein einfaches docker-compose.yml erstellt das mir die benötigten Services startet. Leider sind noch nicht alle Schritte automatisch hinterlegt aber diese werden noch im Git Repository aktualisiert und mit einer Beispielanwendung optimiert.

version: '2'
services:
jenkins:
image: jenkins/jenkins:lts-alpine
volumes:
- /var/run/docker.sock:/var/run/docker.sock
ports:
- 8088:8080
- 50000:50000
links:
- artifactory
- registry
- repository
- sonar
artifactory:
image: docker.bintray.io/jfrog/artifactory-oss
ports:
- 8081:8081
registry:
image: registry
ports:
- 5000:5000
repository:
image: gitlab/gitlab-ee
ports:
- 443:443
- 8000:80
sonar:
image: sonarqube:alpine
ports:
- 9000:9000
- 9092:9092

Hauptbaustelle ist nun die Docker Nutzung im Jenkins Container. Hier wird bereits der docker.sock gemounted aber funktioniert nicht direkt über den Jenkins User im Jenkins Container. Hierfür sind zwei weitere Schritte nötig.
Einmal muss noch die Docker CLI installiert werden:

apk --update add curl \
&& mkdir -p /tmp/download \
&& curl -L https://download.docker.com/linux/static/stable/x86_64/docker-18.06.0-ce.tgz | tar -xz -C /tmp/download \
&& mv /tmp/download/docker/docker /usr/local/bin/ \
&& rm -rf /tmp/download \
&& apk del curl \
&& rm -rf /var/cache/apk/*

zum anderen die Rechte des Users angepasst werden zum Beispiel über die Gruppe Docker:984 oder chmod docker.sock … das ist dir überlassen wie du das am liebsten löst.

Hierfür werde ich in den nächsten Tagen ein eigenes Dockerfile zur Verfügung stellen, natürlich kannst du das auch selbst realisieren und ein Dockerfile bassierend auf das jenkins/jenkins:lts-alpine oder jenkins/jenkins:lts aufbauen. Ich hab mich für die kleinere Variante mit alpine entschieden aber geht natürlich auch mit ubuntu.

Dieser Artikel dient im Ersten Schritt als eine Einführung und es werden sicher noch weitere Beiträge folgen die dieses Paket abrunden. Das Ziel ist es dieses komplette Environment auf einem Kubernetes Cluster auszurollen und in Jenkins am Ende nur noch Jobs angelegt werden müssen die Bereits mit einem Jenkinsfile im Repository liegen.

//TODO an mich: Ein Video erstellen 🙂