Not every software which is delivered via Docker containers is able to use environment variables directly in the configuration files. But these environment variables are crucial to control the software. Usually scripts are used to take these environment variable values and glue them into the configuration files. But this is not very flexible because different configuration files are using different configuration languages (jaml, json, …).

Injector now takes a Golang template file and the whole list of environment variables puts them together an prints the result on the standard output.

Project Link:

Kubernetes - The roguelike way!

Not everyone is using a cloud platform (or multiple cloud platforms) and there are different reasons why they not use them. Sometime you already have multiple data centers on premise and still want to use them, like in our case. Kubernetes and other cloud native software was born on the internet and most of the time it is not easy to take and integrate them on premise.

But if you want them or need them, you may have no other choice as to deep dive into the components and find out how the things are really working. And while doing so, you can be sure, that you will face a lot of pitfalls where you have to start over and over again. I compare this with a special kind of computer games which are commonly know as Roguelike Games. If you make a terrible mistake, you face the permadeath and have to start over - but you every time you try you gain experience and get better in understanding the game.

Project Link:


BosnD takes a configuration file as argument and based on that configuration file, it uses the given Docker Swarm connection to retrieve information from the Docker Swarm. Therefore the daemon connects to a Docker Swarm manager (leader or promoted node) via the Docker API. The needed information is collected from the docker network inspect -v and docker service inspect commands via API.

After the information is retrieved, BosnD processes the configured Golang templates and writes the resulting configuration files to the desired (configured) locations. Afterwards BosnD will reload the controlled daemon, which is also configured in the bosnd.yml config file. Alternatively and recommended, the midshipman

Project Link: