CI/CD-Pipeline for a java microservice application running on Docker Swarm mode cluster on DigitalOcean with Maven/Docker/Gitlab/Terraform/Ansible

Hey friends,

I finally finished to implement a continuous delivery/deployment pipeline for my java based microservice architectured application which is hosted on Gitlab and running on a swarm mode cluster on DigitalOcean (created/deployed automatically by Terraform). In this article I want to share an overview of the way I got everything running (I won’t go too deep into details because that would make the article too long, but if you are interested in more informations about any part feel free to contact me). This is not meant to be a best practice or the best way to implement it because I don’t know if it is..quite contrary – I’m pretty sure there are smarter ways to do it and it is still work in progress. But maybe you get some inspiration by the way I did it.

My application is a search engine infrastructure (the gui for the search engine is still missing) and consists (as by now) of three microservices (crawler, index and a gui for configuring the crawler) and four jar-files which are created. I will skip the source code of the application and just tell you how the jar files / microservices relate / work together.

The crawler microservice is for scanning the net and collecting everything that was found. It uses Nutch as the crawl engine. Besides Nutch I created an api-service as a jar file, which is also running in the nutch/crawler-container and which is used by the crawler-gui-microservice for communication (configuration/control of the crawler).

The crawler gui is a vaadin 10 frontend application which uses the crawler api to display informations of the crawler and which offers screens for configuring/controlling the crawler.

The last microservice is the index. When the crawler has finished one crawling cycle (which always repeats via a cronjob) it pushes the crawled data to the index-service (based on solr) which makes the data searchable (so the index will be used by the search engine gui microservice which is about to be implemented next).

Info on persistence: I am using GlusterFS to generate one Gluster-Volume for the crawler and one Gluster-Volume for the index. Those volumes are mounted as bind-mounts on every swarm mode cluster node so that the crawled/indexed data are reachable from every cluster node – so it is not important on which node a service is running.

The application code is hosted on Gitlab and I am using the free gitlab ci runners for my CI/CD-Pipeline. The running application itself is hosted/deployed on droplets from DigitalOcean.

Gitlab CI works by defining a gitlab-ci.yml on the top level of a repository and this is what my file looks like:

image: maven:latest

  - docker:dind

    - .m2/repository

  DOCKER_HOST: tcp://docker:2375
  DOCKER_DRIVER: overlay2
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"

  - test
  - build
  - release
  - deploy-infrastructure
  - deploy-services

  stage: test
    - mvn clean test
    - master

  stage: build
    - mvn clean install
      - gotcha-crawler/gotcha-crawler-webgui/target/gotcha-crawler-webgui-0.1-SNAPSHOT.jar
      - gotcha-crawler/gotcha-crawler-api/target/gotcha-crawler-api-0.1-SNAPSHOT.jar
    - master

  stage: release
  image: docker:latest
    - docker build --tag=gotcha-index ./gotcha-index
    - docker tag gotcha-index
    - docker push
    - docker build --tag=gotcha-crawler ./gotcha-crawler
    - docker tag gotcha-crawler
    - docker push
    - docker build --tag=gotcha-crawlergui ./gotcha-crawler/gotcha-crawler-webgui
    - docker tag gotcha-crawlergui
    - docker push
    - master

  stage: deploy-infrastructure
    name: hashicorp/terraform:light
      - '/usr/bin/env'
      - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
    - apk add --no-cache python3
    - apk add --no-cache curl
    - mkdir -p ~/.ssh
    - echo "$TF_VAR_DO_PRIVKEY_PLAIN" | tr -d '\r' > ~/.ssh/id_rsa
    - chmod -R 700 ~/.ssh
    - curl -O
    - python3 --user
    - touch ~/terraform.log
    - chmod 777 ~/terraform.log
    - echo "export PATH=~/.local/bin:$PATH" >> ~/.bash_profile
    - echo "export TF_LOG_PATH=~/terraform.log" >> ~/.bash_profile
    - echo "export TF_LOG=TRACE" >> ~/.bash_profile
    - source ~/.bash_profile
    - pip install awscli --upgrade --user
    - aws configure set aws_access_key_id $TF_VAR_AWS_ACCESSKEY
    - aws configure set aws_secret_access_key $TF_VAR_AWS_SECRETKEY
    - cd .infrastructure
    - if aws s3api head-bucket --bucket "de.gotcha-app.s3" 2>/dev/null ; then echo "Skipping Backend-Creation, S3-Bucket already existing!"; else cd setup_backend && terraform init && terraform plan && terraform apply -auto-approve && cd ..; fi
    - cd live/cluster
    - terraform init -backend-config="access_key=$TF_VAR_AWS_ACCESSKEY" -backend-config="secret_key=$TF_VAR_AWS_SECRETKEY"
    - terraform plan
    - until terraform apply -auto-approve; do echo "Error while using DO-API..trying again..."; sleep 2; done
    - ls -la
    - pwd
      - ~/terraform.log
    - master

  stage: deploy-services
    - echo "deb trusty main" >> /etc/apt/sources.list
    - apt-key adv --keyserver --recv-keys 93C4A3FD7BB9C367
    - apt-get update
    - apt-get install ansible -y
    - apt-get install jq -y
    - mkdir -p /root/.ssh
    - echo "$TF_VAR_DO_PRIVKEY_PLAIN" | tr -d '\r' > ~/.ssh/id_rsa
    - chmod -R 700 ~/.ssh
    - "GOTCHA_MASTER_IP=$(curl -sX GET -H \"Authorization: Bearer $TF_VAR_DO_TOKEN\" | jq -c '.droplets[] | select(.name | contains(\"gotchamaster00\")).networks.v4[0]'.ip_address)" # extrahieren der IP-Adresse von gotchamaster00 via DO-API und jq anhand des dropletnamens
    - echo "$GOTCHA_MASTER_IP"
    - export GOTCHA_MASTER_IP
    - echo $GOTCHA_MASTER_IP > /etc/ansible/hosts
    - scp -o StrictHostKeyChecking=no docker-compose.yml root@$GOTCHA_MASTER_IP:/root/docker-compose.yml
    - ansible all --user=root -a "docker stack deploy --compose-file docker-compose.yml --with-registry-auth gotcha"
    - master

As you can see, it has 5 stages: test, build, release and deploy-infrustructure and deploy-services and they pretty much do, what their names tell:

The test-stage does a mvn clean test.

The build-stage does a mvn clean install and so generates the (spring boot) jar files which are in fact running in the docker containers containing the microservices.

The release-stage builds docker images (based on Dockerfiles) which contain and run the built jar files and pushes them to a SSL-secured docker registry which I installed on a hetzner cloud machine.

The deploy-infrastructure stage is where my server cluster for the docker swarm mode is created. This is done by creating 6 Droplets on DigitalOcean (the smallest ones for 5$ per month each). After creation some tools are installed on those machines (Docker, Docker Compose, GlusterFS Server/Client (for the volumes). When this stage is finished, I have a ready configured swarm mode cluster – but no services running on the swarm. This last step is done in the last stage.

Info on the cluster creation: The pipeline is (of course) idempotent. The server cluster during the deploy-infrastructure code is only created, if it is not already existent. To achieve this, I am using a „remote backend“ for terraform (in fact an aws S3 bucket). When terraform creates a server on e.g. DigitalOcean, a file called terraform.tfstate is created, which contains the information on which servers were created and what their state is. By using a backend for terraform, I tell terraform to save this file on a S3 bucket on aws. So the first time, the deploy-infrastructure stage is run, terraform will create the droplets and save their states in a file terraform.tfstate in the S3 bucket. Every continuing time the terraform stage is triggered, terraform will look into the file saved in the S3 bucket and will skip the creation as the file says, that they were already created.

The deploy-services stage is where my docker images are pulled from the external registry and deployed onto the (in the former stage) created droplets. For that to work, I am requesting the IP of one of the master (docker swarm) droplets via the DigitalOcean API and extracting the IP from the response, containing all created droplets. Then I am using ansible to execute the docker stack deploy command. This command pulls the needed docker images from the external registry and deploys containers on all worker nodes (as configured in the docker-compose.yml). A good thing about that command is, that it can also be used to deploy the services initially into the swarm, and also to update the services already running on the swarm. The docker-compose.yml looks like the following:

version: "3.6"
      mode: global
     - "8983:8983"
     - "index-volume:/opt/solr/server/solr/backup"
     - index-username
     - index-password
      mode: replicated
      replicas: 1
     - "crawler-volume:/root/nutch/volume"
     - index-username
     - index-password
     - crawler-api-username
     - crawler-api-password
       mode: global
     - "8082:8082"
     - crawler-api-username
     - crawler-api-password
     - crawler-gui-username
     - crawler-gui-password
    external: true
    external: true
    external: true
    external: true
    external: true
    external: true
    driver: local
      type: none
      o: bind
      device: /mnt/crawler-volume
    driver: local
      type: none
      o: bind
      device: /mnt/index-volume

(If you are wondering where the secrets come from: They are creating inside the docker swarm on the deploy-infrastructure stage (during terraform apply) and are using the contents of environment variables which are created / maintained in gitlab. The volumes are also created during the terraform steps in the deploy-infrastructure stage.)


So what is happening after I push code changes:

The CI/CD-Pipeline of Gitlab starts and one stage is executed after another. If one stage fails, the pipeline fails in general and won’t continue. If everything works well: The jar files are created –>Docker-Images are pushed to my private docker registry –> the latest docker images are pulled from the registry and the running containers on my swarm cluster are updated one after another (or for the very first push: the cluster is created/intialized – which means: The Droplets are created on DigitalOcean and everything that is needed is installed/configured on those droplets (docker / docker compose / GlusterFS-Server/-Client / …)  – all executed automatically by terraform. Then the pushed docker images are pulled and deployed automatically on the created/running cluster. The pipeline duration is about 20 minutes including the server cluster creation, and about 10 minutes if the server cluster is already running.


Right now it is already possible to access (for example) the crawler gui by calling <Public-IP-address-of-one-swarm-worker-droplet>:8082/crawlerui. The next steps will be adding a reverse proxy (probably traefik) which then redirects calls to the corresponding services and bind my domain with the swarm cluster nodes.

I like that tech stack a lot and I am looking forward to extend/improve the pipeline and the application. If you have suggestions / comments / questions feel free to leave them – I will appreciate it a lot!


Docker-Volumes im Cluster: Von Hetzner zu DigitalOcean (Erfahrungsbericht)

Wie in vorherigen Artikeln bereits erwähnt, arbeite ich derzeit privat an einer Applikation, welche aus diversen Microservices besteht. In diesem Beitrag möchte ich etwas näher darauf eingehen, wie diese Applikation (bisher) technisch aufgebaut ist und welche Infrastruktur ich hierfür nutze.

Die Applikation – im Prinzip eine Suchmaschine – besteht aus mehreren Microservices: Crawler, Index, Webgui für die Crawler-Administration. Als Crawler kommt nutch ( zum Einsatz, als Index Lucene/Solr ( und für die Webgui arbeite ich mit Vaadin 10 ( Vaadin ist übrigens ein ganz grandioses java-basiertes Webframework, welchem ich definitiv auch noch den einen oder anderen Artikel widmen werde. Ich habe schon viele Applikationen/GUIs mit Vaadin entwickelt und es macht einfach unglaublich viel Spaß. Die neue Version 10 gefällt mir wirklich sehr gut.

Zurück zur Infrastruktur:

Die bisher vorhandenen Services betreibe ich derzeit auf einem Single Host System. Hierfür habe ich mir eine Cloud-Maschine bei Hetzner ( gemietet. Diese sind wirklich sehr günstig und funktionieren auch einwandfrei. Der Support von Hetzner gefällt mir ebenfalls ausgesprochen gut.

Auf dieser Maschine starte ich meine Services (derzeit noch) via Docker Compose. Der Crawler hat ein Volume gemounted, wohin er seine Crawling-Ergebnisse schreibt. Der Index hat ein Volume gemounted, um dort beim Herunterfahren des Services einen Snapshot des Indexes zu speichern um diesen beim Hochfahren wieder einzulesen). Ansonsten kommuniziert der Crawler direkt mit dem Index. Die Administrations-GUI für den Crawler kommuniziert mit einer API, welche ebenfalls im Container-Service läuft.

Ich habe also bisher: drei Microservices, zwei Volumes, keine Datenbank-Anbindung.

Ich habe auf der Hetzner-Maschine einen apache eingerichtet welcher, je nach eingegebener (sub-)Domain eben auf die Webgui für den Crawler, die Webgui für den Index oder die (noch nicht vorhandene) Webgui für die Suchmaschine an sich weiterleitet.

Mein Plan war eigentlich, als nächstes weitere Maschinen bei Hetzner anzumieten um dort ein Kubernetes-Cluster aufzubauen, in welchem meine Services repliziert laufen. Hierzu hatte ich mir beispielsweise schonmal das Tool Kompose angesehen, mit welchem es möglich ist, den Inhalt einer Docker-Compose-Datei in entsprechende Kubernetes-Konfigurations-Files zu übersetzen. Ich hatte mir auch schon eine zweite Maschine angemietet und tatsächlich einen kleinen Cluster aufgebaut – inkl. rennendem Hello-World-Service.

Nachdem ich nun am DevOps Docker Camp teilgenommen habe und dort erstmalig die Verwendung von Docker Swarm Mode live miterlebt habe, habe ich mich nun dazu entschlossen, als Orchestrierungs-Tool doch erstmal Swarm Mode einzusetzen und meinen bisherigen Stack darauf ans laufen zu bekommen.

Eines der ersten Probleme, die ich in Angriff nehmen wollte: Volumes im Cluster.

Hierzu wollte ich zuerst meinen Crawler-Service dahingehend anpassen, dass dieser im Cluster laufen kann. Problem: Ich arbeite derzeit mit einem Bind Mount (was sowieso eine schlechte Idee ist). Nicht nur wird hierdurch das Volume gelöscht, wenn der Container gelöscht wird, der Service bindet sich auch explizit an ein Verzeichnis innerhalb des Hosts. Das ist Mist. Einem Service im Cluster sollte egal sein auf welchem Rechner er gerade läuft / angesprochen wird. Er sollte nichts über die Verzeichnisstruktur der einzelnen Hosts wissen. Ich möchte dem Service sagen: Hier ist dein Volume, schreibe die Daten da rein. Was hinter diesem Volume steckt, soll der Container gar nicht wissen. Es soll egal sein, ob der Service auf Maschine A, B oder C läuft. Er soll einfach clusterweit immer das selbe Volume zur Verfügung gestellt bekommen, damit er dort seine Daten reinschreiben kann.

Hierfür bieten sich im Docker-Cosmos named Volumes an. Diese haben den Vorteil, containerunabhängig existieren zu können (man kann sie in beliebige Container mounten). Weiterer Vorteil: Mit Hilfe von Volume Plugins kann man einem Volume nicht mehr nur ein bestimmtes Verzeichnis zuordnen, sondern beispielsweise Verzeichnisse, die gar nicht direkt auf dem Host liegen (NFS, …).

Man muss sich das klar machen: Wenn ich für einen Service ein Bindmount-Volume (mit beispielsweise dem Host-Verzeichnis /var/meinvolume und dem Containerverzeichnis /volume) verwende, sage ich dem Service: Lege deine Daten im Container im Verzeichnis /volume ab, sodass diese dann auf dem Host-Rechner (auf dem der Container läuft) im Verzeichnis /var/meinvolume abgelegt werden. Ein Container im Cluster sollte aber gar nicht wissen und es sollte ihn nicht interessieren auf welchem Rechner er gerade läuft. Selbst wenn mein Crawler zeitweise auf Rechner A, zeitweise auf Rechner B und zeitweise auf Rechner C läuft, so möchte ich doch die gecrawlten Daten nicht verteilt auf Rechner A, Rechner B und Rechner C haben. Ich möchte EINEN Ort haben, wo DIE gecrawlten Daten zu finden sind.

Nun habe ich überlegt, wie ich das am besten realisieren kann. Ich muss dazu sagen, ich habe hier keinerlei Vorerfahrung gehabt und da das Thema Docker Plugins / Volume Plugins im DevOps Docker Camp leider nicht bearbeitet wurde, musste ich mich erstmal anderweitig informieren, was ich tun kann. Ich bin hierbei durch ein ziemliches Tal der Schmerzen gegangen – so viel steht fest. Vielleicht kann ich das dem ein oder anderen ersparen indem ich meinen (Irr)-Weg hier festhalte:

Ich wollte also die Crawler-Daten nicht verteilt auf meinen Cluster-Maschinen wissen. Ich wollte eine zentrale Stelle definieren, wo die Daten abgelegt werden sollen. Und ich wollte ein Volume erstellen, welches ich dem Container zur Verfügung stelle, sodass die Daten (egal auf welchem Rechner der Service läuft) immer an der gleichen Stelle abgelegt werden.

Hierbei war meine erste Idee: Beim Anlegen der Hetzner-Maschine hatte ich ausgewählt, dass der Speicherplatz als CEPH angelegt werden soll. Ich wusste, dass es Docker Volume Plugins für CEPH gibt und wollte entsprechend diesen CEPH-Speicher nutzen. Das habe ich schnell aufgegeben, da ich mich mit CEPH gar nicht auskenne, und ich nichtmal herausgefunden habe, wie ich an die Zugangsdaten hierfür komme.

Meine nächste Idee war: Ich nehme ein Amazon S3-Bucket ( und erstelle mit Hilfe eines passenden Volume Plugins ein Volume, welches die Daten dann eben genau in diesem S3-Bucket ablegt. Ich stellte schnell fest, dass S3 nicht das richtige für mich ist. Hierbei handelt es sich meiner Meinung nach eher um Cloud-Speicher oder meinetwegen eine SNAPSHOT/Backup-Ablage.

Ich bin dann auf Amazon EBS ( gestoßen. Dies schien mir schon eher zu meinem Use Case zu passen, doch: Ich habe kein entsprechendes Volume Plugin zum laufen gebracht. Rexray konnte ich nicht erfolgreich installieren und ich wollte auch nicht mit Docker for AWS arbeiten. Denn ich wollte ja bei Hetzner bleiben und lediglich für mein Volume auf eine Amazon Komponente zugreifen (und nicht etwa mit meinem Cluster zu Amazon EC2 wechseln).

Als nächstes wurde ich auf DigitalOcean aufmerksam. Hier kann man sich sowohl virtuelle Maschinen (Droplets) anlegen, als auch Volumes, welche man (optional) Droplets zuordnen kann. Ich sah, dass es für DigitalOcean Volumes ebenfalls Docker Volume Plugins gab. Also habe ich mir testhalber einen DigitalOcean-Account angelegt und dort ein Volume erstellt (Zufällig hatte ich neulich das Humble Software Bundle gekauft, in welchem unter anderem 50$ DigitalOcean Guthaben enthalten waren :D). Um das Docker Volume Plugin zu testen, habe ich mir testhalber auch eine virtuelle Maschine bei DigitalOcean hochgezogen. Nach Anlage habe ich dort Docker installiert – samt entsprechendem Volume Plugin ( und was soll ich sagen: Es funktionierte einfach! Die Plugin-Installation war schmerzfrei und ich konnte einen Container Starten, ihm das Named Volume zuordnen und Dateien reinschreiben, welche dann im Volume waren. Das hat mich wirklich begeistert.

Ich bin dann zurück zu meiner Hetzner-Maschine, habe dort das DigitalOcean-Volume-Plugin installiert und wollte dort dann auch ein Named Volume anlegen, welches auf das DigitalOcean-Volume verweist. Das hat nicht funktioniert und ohne mich in der Tiefe damit beschäftigt zu haben, so glaube ich, dass das Plugin tatsächlich nur dazu fähig ist, auf Droplets von DigitalOcean korrekt zu funktionieren.

Ich habe mich dann erkundigt, ob es bei Hetzner auch eine Möglichkeit gibt „Volumes“ wie bei DigitalOcean anzulegen: Gibt es nicht. Jedenfalls nicht für die Cloud-Maschinen. Wer sich näher dafür interessiert wie man etwas ähnliches bei Hetzner realisieren kann, dem sei dieser Artikel ans Herz gelegt: . Ein Prima-Artikel der mir sehr geholfen hat. Der mich aber auch darin bestärkt hat, Hetzner „Lebe Wohl!“ zu sagen und stattdessen auf DigitalOcean umzusteigen.

Hier sind die Maschinen in der Tat etwas teurer als bei Hetzner (die billigsten gibt es für ~5$/Monat), aber dafür hat man hier auch mehr Optionen. Außerdem arbeitet DigitalOcean gerade an einer Kubernetes-Integration, welche ich gespannt verfolgen werde.

Ich habe heute übrigens ein Terraform-Script eingerichtet, welches mir bei DigitalOcean entsprechend viele Maschinen hochzieht und diese direkt mit Docker, Docker-Compose und dem Docker Volume Plugin für DO bestückt. Ich kann schon jetzt sagen: Ich liebe Terraform ( und bedanke mich recht herzlich bei Erkan Yanar – dem Trainer des DevOps Docker Camps – für die Inspiration!

Ich ziehe nun also von Hetzner zu DigitalOcean weiter und werde hier weiter berichten, wie meine Erfahrungen dort sind.

UPDATE: Ich habe meine Services inzwischen im Swarm Mode Cluster auf DigitalOcean ans laufen bekommen und habe auch die Volume-Problematik bereits gelöst. Allerdings bin ich nicht bei dem Docker-Volume-Plugin für DigitalOcean-Spaces geblieben (Problem war, dass ein Space jeweils nur einem einzigen Droplet zugeordnet werden konnte..ich hatte es mir eher so vorgestellt, dass wenn ich 3 Swarm Mode Nodes habe, dann allen dreien den selben Space zur Verfügung stellen kann). Stattdessen installiere ich nun auf allen Master-Nodes einen GlusterFS-Server-Verbund mit zwei Volumes (crawler und index) und auf allen Worker-Nodes installiere ich den GlusterFS-Client und mounte dort jeweils die GlusterFS-Volumes, sodass im Endeffekt auf jedem Worker beide Volumes zu jeder Zeit im selben Zustand vorhanden sind. Mehr dazu findet ihr in folgendem Blog-Post: CI/CD-Pipeline for a java microservice application running on Docker Swarm mode cluster on DigitalOcean with Maven/Docker/Gitlab/Terraform/Ansible

DevOps Docker Camp – Fazit

Ich habe vom 05.06 – 07.06 am „DevOps Docker Camp“ in München teilgenommen. Hier möchte ich nun meine Eindrücke schildern.

Es war das erste Seminar der „entwickler akademie“ (Software & Support Media GmbH) an welchem ich teilgenommen habe. Der Preis belief sich auf 1899€ (ohne MwSt.) im Early Bird – Tarif (Normalpreis 1999€ ohne MwSt.). Des Seminar wurde geleitet von Erkan Yanar (

Warum ich daran teilnehmen wollte: Ich arbeite derzeit sowohl privat als auch beruflich viel mit Docker. Ich interessiere mich sehr für Microservices, Container und entsprechender Orchestrierung. Damit zusammenhängend beschäftige ich mich derzeit auch viel mit Infrastructure as Code und dynamischen automatisierten CI/CD-Pipelines.

Inhalt des Seminars

Das detaillierte geplante Programm kann auf eingesehen werden.

Tag 1 – Grundlagen

Im Prinzip sollte laut Planung der erste Tag aus einer Einführung in den Docker-Cosmos bestehen. Was ist ein Container, was ist ein Image, was ist Docker, was ist der Unterschied zur Virtualisierung.. die grundlegenden Dinge eben. Ich finde, das alles wurde ordentlich vom Trainer erklärt. Da ich bereits einige Erfahrung mit Docker habe, konnte ich aus dem ersten Tag leider nur vereinzelt Informationen ziehen die wichtig und für mich neu waren. Um nur ein kleines Beispiel zu nennen: Mir war nicht bewusst, dass Docker für jeden Container einen Ordner auf dem Host anlegt, unter welchem man z.B. auch die Logs des Containers einsehen kann.. wirklich hilfreich.

Tag 2 – Applikationen

Der zweite Tag sollte laut Planung interessanter werden – also auch für diejenigen, welche die Grundlagen bereits beherrschen. Was mich am geplanten Programm besonders reizte waren Buzzwords wie „Stateful/Stateless Container“ (was ich als Datenbankanbindung im Container-Universum interpretierte), Orchestrierung von Microservices, Build-Pipeline. Ich arbeite derzeit selber privat an einer Applikation, welche aus einer Hand voll Microservices besteht, welche bisher aber als Single-Host-Applikation (mit Docker-Compose) läuft.. unter anderem mit diversen Volumes, aber noch ohne Datenbankanbindung. Hier erhoffte ich mir vom Seminar wertvolle neue Erkenntnisse in Bezug auf Persistenzanbindung.  Auch in Bezug auf den Bereich „Build Pipeline“ erhoffte ich mir beispielsweise so etwas wie ein Beispiel, wie man eine dynamische CD-Pipeline aufbaut. Direkt zum Anfang der Schulung hatte ich beispielsweise meinen ersten Aha!-Moment, als der Trainer durchzählte wie viele Teilnehmer wir sind und dementsprechend mittels eines Kommandos (Terraform) entsprechend viele Maschinen im DigitalOcean hochzog (inklusive installiertem Docker, docker-compose, etc…). Leider kamen wir thematisch am zweiten Tag nicht wirklich gut voran. Es gab viele Nachfragen, wodurch der Trainer nur langsam in der Agenda voran kam. Volumes wurden zwar vorgestellt – insbesondere auch der Unterschied zwischen Bind Mount und Named Volumes (und warum Bind Mounts böse sind), jeoch wurde beispielsweise gar nicht auf Docker Plugins in Bezug auf Volumes eingegangen, oder wie man Volumes in einem Cluster handelt (ich hoffte, dies würde am Tag 3 im Rahmen von Docker Swarm Mode thematisiert). Ich muss zugeben – zur Halbzeit des zweiten Tages war ich etwas enttäuscht, weil es nur so langsam voran ging und für mich nicht viel neues dabei war. Das mache ich explizit nicht dem Trainer zum Vorwurf, denn es waren nunmal einige Teilnehmer dabei, die keine Vorerfahrung hatten (welchen ich das auch nicht zum Vorwurf mache). Evtl. wäre es eine Überlegung wert, das Docker Camp aufzuteilen in zwei Versionen – für Anfänger und Fortgeschrittene.

Tag 3 – Docker im Cluster

Am Ende des zweiten Tages versuchte der Trainer dann doch das Tempo anzuziehen, da man nun merkte, dass wir deutlich im Verzug waren was die Agenda anging. Am Ende von Tag 2 waren wir dann allerdings wieder im Plan und so konnte Tag 3 direkt mit den geplanten Themen für Tag 3 beginnen. Vom dritten Tag erhoffte ich mir dann Erkenntnisse / Hilfen in Bezug darauf, wie ich meine Single Host Applikation (docker compose) mittels Docker Swarm Mode in ein Cluster überführen kann. Noch lieber wäre mir stattdessen eine Einführung in Kubernetes gewesen, aber das war eben nicht Teil der Agenda und hierfür gibt es auch ein eigenes Seminar – ebenfalls mit Erkan Yanar. Und es ist natürlich auch utopisch, an einem einzelnen Tag vermitteln zu können wie Kubernetes funktioniert und wie man damit arbeitet. Also eben erstmal Docker Swarm Mode. Was ich hierbei lernte war, dass es angenehm einfach ist diesen zu verwenden und dass es wohl für meine Belange erstmal absolut reicht, diesen zu verwenden. Auch der Trainer war der Meinung, dass man eigentlich nichts falsch macht, wenn man im kleineren Rahmen erstem Docker Swarm Mode verwendet – zum die Lernkurve extrem flach ist und man somit nicht viel Zeit reinstecken muss, um den Cluster ans laufen zu bekommen. Somit habe man auch nicht viel Zeit verloren, wenn man später zum Schluss kommt, dass Kubernetes doch besser geeignet ist. Der dritte Tag war insgesamt vollgepackt mit lehrreichen Informationen. Ich kann übrigens jedem nur empfehlen, wenn man sich in Docker-Cluster einlesen möchte mal ein wenig mit zu spielen. Es ist genial, wie einfach man hier ein paar Maschinen hochziehen und darauf einen Cluster initialisieren kann. Zum Ende des Tages musste der Trainer leider nochmals das Tempo anziehen um uns die Dinge zu zeigen, von denen er der Meinung war, dass wir das unbedingt gesehen haben sollten (ELK-Stack, Prometheus, …). Das war alles interessant, aber zum Schluss war dem Trainer kaum noch zu folgen. Hier werde ich nochmal einiges in Ruhe nacharbeiten müssen.

Und sonst so?

Leistungen die in den Seminarkosten enthalten waren (abgesehen von der Schulung selbst):

  • Tägliches Mittagessen: Drei Gänge mit Suppe, Hauptgang und Dessert (Das Essen war verdammt gut!)
  • Get Together am ersten Tag mit kostenlosen Getränken / Snacks
  • Dauerhafter Zugang (im Schulungszeitraum) zu Kaffee / Wasser / Säften und Snacks
  • Ein Jahr Gratis-Abonnement einer Software & Support-Media-Zeitschrift (Auswahl aus: Java-Magazin / Entwickler Magazin / Windows Entwickler / noch irgendwas). Was ich toll fand, war, dass obwohl ich das Java-Magazin bereits abonniert habe, ich das kostenlose Abo-Jahr quasi an mein derzeitig bezahltes Abo anhängen konnte).

Leistungen die nicht enthalten waren:

  • Unterkunft (es gab einen etwas billigeren Zimmerpreis für Seminarteilnehmer)

Das Camp fand in München statt – genauer gesagt Feldkirchen. Ich muss hier wirklich eine Lanze für den Tagungsort – Das Bauer Hotel Feldkirchen – brechen. Das Zimmer war prima und das Essen äußerst lecker. Schade war, dass der S-Bahnhof genau zum Seminarzeitraum umgebaut wurde und somit außer Betrieb war. Aber es gab eine Busverbindung direkt vom Hotel zur Messestadt Ost, von wo man dann mit der Ubahn weiter nach München Mitte kommt. Das Wetter war abgesehen von einem Gewitter am zweiten Abend ein Traum! Der Pool und die Sauna (im Preis inbegriffen) haben auch sehr gefallen. Das Frühstück war – wie sämtliches Essen dort – richtig gut.


Insgesamt hat sich das Seminar für mich gelohnt – auch wenn ich mir ehrlich gesagt ein wenig mehr davon versprochen hatte. Meinerseits hätten die Grundlagen gerne etwas zügiger abgehandelt werden können um dafür mehr Zeit für die fortgeschritteneren Themen zu haben (vielleicht war auch einfach die Teilnehmer-Anzahl von ca. 15 Leuten etwas zu hoch. Bei weniger Teilnehmern gibt es auch weniger Nachfragen). Aber das ist eben ein grundlegendes Problem, wenn man einige fortgeschrittene Teilnehmer hat und einige, die noch gar kein Vorwissen haben. Was ich auch etwas zu viel fand, waren die Pausen. Es gab über den Tag verteilt drei Pausen: Morgens nach 1,5 Stunden eine halbe Stunde. Mittags zum Essen eine Stunde und Nachmittags nochmal eine halbe Stunde. So blieben pro Tag nur maximal 6 Stunden. Was ich super fand: Der Trainer hat am Anfang gefragt, was die Teilnehmer sich von der Schulung genau erhoffen und da einige Teilnehmer auch Interesse an Kubernetes zeigten, versprach der Trainer, immer wenn es sich anbietet, auch Kubernetes einzubeziehen – natürlich nicht praktisch, aber doch zumindest im Gesamtkontext. Das tat er dann auch. Generell hat es viel Spaß gemacht dem Trainer zuzuhören. Man konnte ihm gut folgen und er hat die Dinge gut herübergebracht.

Der Preis liegt mit über 2200€ inkl. MwSt. natürlich extrem hoch. Inklusive dreitägiger Unterkunft kratzt man hier schon an den 3000€. Das muss jeder selber wissen, ob man bereit ist, diesen Preis zu zahlen.

Ich bin zur Zeit am überlegen, ob ich dieses Jahr auch nochmal am DevOps Kubernetes Camp ( teilnehme. Dies ist quasi eine Folge-Veranstaltung vom selben Veranstalter und mit dem selben Trainer (zum selben Preis). Wäre der Preis etwas niedrigerer würde ich gar nicht großartig zögern, da mich der Trainer und auch der Veranstalter wirklich überzeugt haben. Aber so werde ich erst nochmal 1-2 Nächte darüber schlafen. Eine Ermäßigung für das Kubernetes Camp für Teilnehmer des Docker Camps fände ich eine prima Sache.

So viel zu meinen Eindrücken bzgl. des Docker Camps. Vielleicht hilft das ja dem ein oder anderen Leser zu entscheiden ob das auch etwas für ihn / sie sein könnte.