Posts

This post outlines how to set up a new OS X Yosemite with sane default dotfiles and basic applications. Dotfiles are heavily influenced by Mathias Bynes. Install brew 1 ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" Install brewdler Updated on 9.3.2015 1 brew tap Homebrew/brewdler Clone dotfiles 1 git clone https://github.com/SirIle/dotfiles.git ~/.dotfiles Run brewdler 1 2 cd .dotfiles brew brewdle Run RCM 1 2 rcup rcrc rcup -f Make GNU bash default shell 1 2 echo "/usr/local/bin/bash" | sudo tee -a /etc/shells chsh -s /usr/local/bin/bash Install NPM as non-root 1 2 echo prefix=~/.node >> ~/.npmrc curl -L https://www.npmjs.org/install.sh | sh Add a ~/.extra to contain non-github stuff 1 2 3 4 5 6 7 8 9 # Git credentials # Not in the repository, to prevent people from accidentally committing under my name GIT_AUTHOR_NAME="Ilkka Anttonen" GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME" git config --global user.name "$GIT_AUTHOR_NAME" GIT_AUTHOR_EMAIL="ilkka.anttonen@accenture.com" GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL" git config --global user.email "$GIT_AUTHOR_EMAIL" git config --global credential.helper osxkeychain

General As I was creating a [minicontainer (minibox)]({% post_url 2014-12-31-fat-containers-microcontainers-and-minicontainers %}) (container that is based on BusyBox, but still contains everything that is needed to run as standalone without the need to use volume containers) I noticed that the resulting containers were way larger than they should have been. I only started paying attention to this as I was trying to create as small a container as possible. After inspecting the resulting image with docker history I noticed that the steps that were executed while installing packages, like having the file downloaded, unpacked using gunzip and after that unpacked using tar all left a large intermediate container in the history. ...

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. ...