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 🙂
Manuel Müller 