Update on 31.3.2015 Updated the Java version to 1.8.0_40. Installing Java 8 on BusyBox After spending [some time]({% post_url 2014-11-06-Microservices-in-Microcontainers-with-Docker %}) with [microcontainers]({% post_url 2014-12-04-java-and-nodejs-in-microcontainers-with-docker %}) I got interested in trying to make the smallest feasible self contained container that includes a working recent Java 8 JRE. I’m fond of using BusyBox (especially progrium/busybox) as the base image as it contains most of the libraries needed to be usable while still being under 5 MB in size. ...

General The learning curve of Docker seems to go in the following order: trying to get existing applications to run in containers in any way possible while minimizing the changes to the applications trying to minimize the container size and to adhere to Docker best practices like one process per container going overboard with minimizing container sizes and heavily using volume containers for sharing common files between the containers finding the middle ground between extremes and using the smallest possible base image and minimizing the container size while still having the containers portable ...

Update 26th June 2015 A newer version with more recent versions of the components can be found [here]({% post_url 2015-06-26-elasticsearch-logstash-kibana-and-logspout-on-docker %}). The old examples may not run properly as the images have been updated with new versions of tools. Especially kibanabox needs to be built by hand as the DockerHub now builds the Kibana 4.1 image. General When I was using fat containers, I used rsyslog to pass the log messages to a centralized container which had Elasticsearch, Logstash and Kibana installed. This combination is also known as the ELK-stack. After moving towards microcontainers I wanted to separate the logging logic from the application containers. Orchestration is still an issue with using multiple simple containers, but at least the application containers shouldn’t need to know anything about the logging architecture as long as they can log to stdout and stderr so that Docker can pick the logs up. ...

This article was also published in DZone. In the [first article]({% post_url 2014-11-06-Microservices-in-Microcontainers-with-Docker %}) I presented a way to create Microcontainers which use volume containers to share runtimes and executables so that the actual application containers can be kept small. The containers are based on BusyBox (progrium/busybox) and necessary libraries are symbolically linked so that the executables work in the very light environment. In this article I take the concept forward with a Java runtime environment and service registration and discovery using Consul. ...

While getting familiar with different ways of using Docker I have bumped into a few pretty useful containers. Base for Microcontainers A good BusyBox based container is progrium/busybox. It contains a package manager (opkg) and includes most of the libraries to enable running applications on top of it. It’s decently sized at about 4.8 MB. Base for volume containers As volume containers don’t need any functionality, but you can’t build them on top of the scratch container, the next best alternative is tianon/true. ...

This article was originally published on DZone. Going towards minimalism After first using fat Docker containers to build PAAS like capabilities I have now switched my thinking towards simpler containers. The size of the core-container crept to over a gigabyte whereas microcontainers can be kept very small, in the megabytes or tens of megabytes range instead of hundreds of megabytes. Contained standalone services If a container was small enough it would enable a Microservice per Microcontainer kind of pattern. Combined with service registration and discovery with a mechanism like Consul it would provide a lot of flexibility in distributing services. If a service contains the runtime as well then getting them to run would equal to just firing up the container and having it register itself. ...