Dockerize everything

Letzte Woche hatte ich die Gelegenheit beim 27. Technologieplauscherl über Docker zu sprechen. Es hat mich sehr gefreut, dass mehr als 75 Leute beim Plauscherl waren und mir super Feedback zu meinem Talk gegeben haben. Hier die Folien zu meinem Vortrag:

Zusätzlich zu den Folien haben wir in unserem Podcast Donau Tech Radio dem Thema eine ganze Episode gewidmet: Episode 53 – Docker – damit kann man zu den Folien auch noch mal den Vortrag hören.

Hier noch ein paar Fotos die mir Elisabeth Rosemann dankenswerte Weise zur Verfügung gestellt hat:

Endlich Internet!

Ich war etwas optimistisch, als ich am 19.12.2013 hier auf meinem Blog gepostet habe: Fast am Ziel. Damals hatte ich gerade die Zusage erhalten, in Weichstetten einen FTTH Anschluss zu bekommen. Erst ein paar Wochen später stellte sich heraus, dass noch einiges zu tun war um zum Ziel zu gelangen.

Ende Februar 2014 habe ich dann Markus Lauss und Johannes Schachner aus Weichstetten kennengelernt, die auch beide sehr daran interessiert waren FTTH nach Weichstetten zu bringen. Wir haben uns ein paar mal getroffen und einen Schlachtplan entwickelt.

  • Schon im Dezember hatte ich http://weichstetten.net/ registriert und eingerichtet. Dort wurden nun regelmäßig Informationen für Interessenten zur Verfügung gestellt.Screen Shot 2015-01-25 at 21.27.42
  • Ab März wurde damit begonnen Letter of Intents zu sammeln. Damit wurde begonnen die Liste der Interessenten zu erheben um der Energie AG zu zeigen wie viele potentielle Kunden es in Weichstetten gibt. Bis Mai kamen dabei 34 Unterschriften zusammen.
  • Am 8. Mai gab es die erste Infoveranstaltung im Gasthaus zur Sonne – sie war sehr gut besucht.IMG_3958
  • Immer wieder gab es Artikel über das Projekt in der Gemeindezeitung, im Pfarrblatt und der Zeitung der ÖVP St. Marien.
    1398314_10152310881532118_3003023385930261145_o  10329053_10152435862317118_8630878119474869462_n  ovp
  • Anfang Juni wurden die Folder gestaltet, welche anschließend bei für die Bewerbung des FTTH Projekts in Weichstetten verwendet wurden.falter_seite_1falter_seite_2
  • Im Juni haben Johannes, Markus und ich dann damit begonnen Hausbesuche zu machen und die Folder in fast ganz Weichstetten zu verteilen. Insgesamt waren wir 6 Abende unterwegs.
  • Der Bürgermeister Helmut Templ hat zweimal einen persönlichen Brief an alle Haushalte in Weichstetten versendet und auf den zweiten Infoabend hingewiesen, der im September stattfinden würde.
  • Am 16. September fand der zweite Infoabend, dieses Mal in der Volksschule, statt. Auch dort kamen wieder viele Interessenten und es wurde auch gleich ein paar weitere Verträge abgeschlossen.IMG_0028
  • Zwischendurch wurden alle Interessenten via Newsletter immer wieder über den aktuellen Projektstatus am Laufenden gehaltenScreen Shot 2015-01-25 at 22.50.36
  • Ich habe eine Webanwendung entwickelt, über die wir im Projektteam den Status zu den einzelnen Interessenten festgehalten haben. Dort wurden Gesprächsnotizen gespeichert und einsammelte Verträge hochgeladen, damit sie dort von der Energie AG downgeloadet werden konnten.Screen Shot 2015-01-25 at 22.52.57
  • Anfang Oktober hat sich dann abgezeichnet, dass ein Ausbau von FTTH in Weichstetten stattfinden wird, nachdem wir mehr als 60 Verträge gesammelt hatten. Am 16. Oktober bekamen wir von der Energie AG das offizielle Schreiben.Evernote-Snapshot-20141030-221811
  • Im November starteten dann die Grabungsarbeiten und man konnte im ganzen Ort sehen, dass das Projekt umgesetzt wird.

    IMG_0491

    Klicken für mehr Fotos!

  • Seit ein Anfang 2015 gibt es ein Forum unter http://forum.weichstetten.net/, auf dem alles wichtige rund um das FTTH Weichstetten Projekt diskutiert werden kann.
  • Am Freitag den 23.1.2015 ging bei mir zuhause das Lämpchen “Fiber Link” am Router an und ich war persönlich am Ziel. Allerdings ist damit das Projekt noch lange nicht abgeschlossen, der Ausbau weiterer Zonen liegt mir noch sehr am Herzen.

Für mich persönlich kann ich jetzt schon sagen, dass die mehr als 100 Stunden, die ich bisher in das Projekt investiert habe, es wert waren. Endlich muss ich mich nicht mehr täglich über die langsame Verbindung bei mir zuhause ärgern.

Vorher:4075768870Nachher:4082501822

Auf jeden Fall ist es für Weichstetten eine gewaltige Möglichkeit FTTH zu haben. Ich hoffe, dass noch möglichst viele Haushalte angeschlossen werden können, damit möglichst viele von unserem Projekt etwas haben.

 

Mehr sprechen, weniger schreiben

Mit fällt auf, dass ich in letzter Zeit sehr wenig auf meinem Blog schreibe. Das liegt hauptsächlich daran, dass ich vor eineinhalb Jahren begonnen habe, zusammen mit meinem Freund und Kollegen Andre Steingreß, regelmässig einen Podcast aufzunehmen: Das Donau Tech Radio

dtr-logo-big1

Den möchte ich an dieser Stelle allen empfehlen, die gerne mehr davon hören wollen, was mich gerade so beschäftigt.

Update to my previous post on Countly

Shortly after I published my post on Countly in a Docker container my pull request was approved, adding the Dockerfile directly to the Countly github repository.

So now it is possible to build the Countly Docker image simply by running:

Countly even created an official Docker hub repository under https://registry.hub.docker.com/u/countly/countly-server/ which means you do not have to build the image yourself, just run it via

The image will be pulled from the repository and launched on your host – the simplest way to try out Countly.

Countly in a Docker container

We are using Countly to track and analyse usage of our various mobile apps at troii. Since we are hosting Countly ourself, and I am in the process of moving all our hosted services and apps into Docker containers, Countly was next.

Dockerfile

Of course the first thing to do when starting with creating a Docker container for a specific application is to look for already existing ones. I found two, but but none of them worked out of the box. The one from dz0ny looked best so I forked the repository and based my efforts on it.

The resulting Dockerfile for Countly looks like:

Most of the changes I made were combining multiple RUN statements into a single line to minimize the number of intermediate images created. See Best practices for writing Dockerfiles why this is should be done.

The Docker images uses supervisor to run nginx, mongodb and counlty inside one container. This contradicts the rule “Run only one process per container” from Best practices for writing Dockerfiles but because I do not have any mongodb Docker image running currently I did not change that.

Data volumes

As one comment on my last post on Docker pointed out, I glossed over the part on how to create a data volume, so this time I will explain it in detail.

To create a data volume for my Countly Docker container I run the following command:

After running this command line, there is a stopped container named countly_data with a volume /data. We can use this container to persist the data created by the mongodb Countly is using. We do this by running the Countly Docker container with the following command line:

This starts the Countly Docker container named “countly” using the volume from the data container countly_data. The parameter --restart="always" automatically restarts the container if the docker daemon is restarted.

You can find the full Countly Docker repository at https://github.com/troii/docker-countly. I would be very happy about your feedback!

Jenkins in a Docker container

After having our Sonatype Nexus repository running in a Docker container (see my previous post), the next part of our infrastructure I wanted to move into a Docker container was our Jenkins build server.

The most difficult part of this, was to get the Android SDK installed inside the Docker image. After downloading the compressed SDK you have to run the android installer from the tools folder. This installer downloads the requested Android versions and asks for accepting the different license agreements – which is a problem because the building the docker images is non interactive. After a lot of trial and error, I found the Android SDK Installer project on github which provides the necessary scripts.

Here is my resulting Dockerfile using the Android SDK Installer:

The steps in this Dockerfile are

  • installing required libs for the Android SDK via apt
  • downloading the latest Jenkins WAR file
  • using the Android SDK Installer to install the required parts for building our Android apps
  • defining the ANDROID_HOME environment variable
  • defining an entrypoint using the war file for starting Jenkins
  • exposing port 8080 for accessing Jenkins
  • defining a volume for persisting the Jenkins work directory

With the image generated by this Dockerfile it is now possible to start up a Jenkins build wherever I want. To make the running Jenkins docker container available via Apache on Port 80 I use the following reverse proxy config:

The jenkinsPort is defined in an apache config file as 8080.

I am using a data volume for persisting the /jenkins folder as explained in my last post under “Data volumes”.

Because Jenkins allows to install everything else that is required afterwards via the web UI (JDKs, Maven, Gradle, Plugins, …) this basic image is enough. Another great improvement in Jenkins is the ability to configure credentials, like SSH keys and username/password combinations, via the web UI. This way it is not required to stored the secret stuff inside the Docker image anymore.

Again, like for the nexus repository in my last post, it is very nice to update Jenkins to the newest version by just executing docker stop, docker build and docker run.

For our Xcode builds we use the Jenkins config that is executed via SSH access to a Mac mini server. Nothing Jenkins specific had to be installed on the Mac mini, Java, Xcode and a SSH access was enough.

Docker infrastructure

Since I saw the 5 minute long video “The future of Linux containers” last year in April, in which Solomon Hykes presented Docker the first time at PyCon, I wanted to use Docker for running my server side software.

The first thing I thought about, was using it for running our time tracking product timr. It is currently deployed on multiple hosts with multiple tomcat instances and a MySQL database. Docker would make it easy to spin up more instances and to deploy new versions.

We are also hosting server applications for our clients. Sometimes only for testing but in some cases also for production. Most of them are JVM based and it is a tedious task to set up yet another tomcat instance and apache virtual host for every new project. Docker would help here too.

Another topic docker could solve for us, was creating test environments triggered by jenkins builds. Currently we have jenkins jobs that can be run by the QA team to deploy a new version on the test server, but sometimes different testers want to have different versions deployed. I would be nice to create a new test instance from a jenkins build, accessible via an auto generated URL.

Breaking it down

After thinking too long about how to tackle all those tasks at once I thought I should start small. So I started with creating a Docker container for running our Sonatype Nexus artefact repository. Here is the resulting Dockerfile:

As you can see it is based on a docker image called troii/java7 which I will show you later. To install nexus inside the image it does the following:

  • downloads the latest sonatype nexus version into /usr/local
  • extracts the TAR file and deletes it
  • create a symbolic link /usr/local/nexus to the newly created folder
  • uses sed to adapt the nexus script to run as user root
  • changes the context path from /nexus to / in the nexus.properties file

The image exposes the port 8081 (the default port nexus uses) and adds a volume /usr/local/sonatype-work to persist the working directory of the repository. With this Dockerfile it is now possible to start up my nexus server wherever I want within seconds.

Currently it is running on an Ubuntu 14.04 root server at Hetzner. I made it available via apache reverse proxy with this config in a virtual host:

The nexusPort (in this case 8080) is defined in another apache config file where I configure all the ports for my reverse proxies.

Data volumes

If I would only run the image created by the Dockerfile before, keeping the persistent data between stopping and starting containers would not be very intuitive. Though I defined a volume for the directory sonatype-work (which makes it persistent) I would need to start the next container with the option –volumes-from to reuse the volume from the last nexus container I stopped.

Luckily there is an article called “Managing Data in Containers” that handles exactly this topic. What I did was creating a so called “data only” container that is used in the –volumes-from option every time to start the nexus container.

This leads to two images/containers being involved in my nexus docker setup, which raises the question on how to manage the startup configs for my docker containers. Those command lines with all the correct options for starting the container can get very long – should I create separate scripts just to start the containers?

Base images

As I wrote before the nexus docker image is based on the troii/java7 docker image which looks like this

It installs the Oracle JDK 7 and is based on the troii/base image which looks like this

The base image uses Ubuntu 14.04 Trusty and does the following on top of it

  • it configures a nearby ubuntu mirror
  • sets some environment variables, timezone and locale
  • installs zsh, vim, git and other stuff I like to have on the command line

First I started with one big Dockerfile but over the time I started to split them up in this way. The base image is used for every docker image I created in the last weeks.

By creating a separate image with Java installed, it is easy to update the Java version for containers base on it. Just by simply building the troii/java7 image again it downloads the latest version. When a container base on it is rebuilt the Java version is automatically updated too.

Conclusion

So far one of the biggest benefits of “dockerizing” our infrastructure was that the setup and configuration is reproducible stored in git repositories. Creating the Dockerfile really documents how the services are set up.

Another thing I noticed that is really nice about having nexus run in a docker container like this is that I just have to run three simple steps (docker stop, docker build, docker run) and I have updated nexus to the newest available version.

What is next

I want to start a series of blog posts with this one about my ongoing effort on moving more and more to a infrastructure based on Docker. There are still many questions left but some have already been answered … stay tuned!

Why Podcasts are awesome

Am Mittwoch den 16. Juli 2014 fand wieder ein Technologieplauscherl statt, dieses Mal waren wir bei Netural eingeladen. Ich durfte dort einen von vier Vorträgen halten, der Titel meines Vortrages: Why Podcasts are awesome

10446110_763889400298907_7621158855081489775_o

Foto by Klaus Fischer

2014-01-08_1389217354Wie der geneigte Leser meines Blogs (oder meiner anderen social Media Kanäle) ja schon mitbekommen haben dürfte, produziere ich seit ca. einem Jahr gemeinsam mit meinem Freund und Kollegen Andrè Steingreß das Donau Tech Radio.

Der Untertitel unseres Podcasts lautet “österreichischer Podcast rund um Software Entwicklung”. Wir reden über Themen die uns während unserer Arbeit in der Software Entwicklung unterkommen aber auch über News und Gadgets.

Den Vortrag beim Technologieplauscherl habe ich gehalten, weil ich einerseits mehr Leute von Podcasts begeistern will (mehr Hörer unseres Podcasts) und andererseits gerne Leute dazu bringen will selbst Podcasts zu produzieren (mehr Podcasts aus Österreich).

Insgesamt war das Plauscherl bei Netural wieder super – gute Location, super Verpflegung und lauter “Gleichgesinnte” anwesend 😉

Die Slides zu meinem Vortrag hab ich auf Speakerdeck gestellt und hier embedded:

Apple introduces Swift and does Bret Victor style demo of Playgrounds

When I watched the video of Bret Victor’s presentation “Inventing on Principle” I was really fascinated about how software development tools could look like – take the time, you will enjoy this presentation:

Bret Victor – Inventing on Principle from CUSEC on Vimeo.

Today Apple presented Swift and the new developer tools they are providing around it. They demonstrated a feature called Playgrounds that looks a lot like Bret showed:

This is really exciting, I am looking forward to experiment with this.