A Docker deployment workflow

This post will explain the Docker image based deployment workflow used for this site. Everything is trigged after a push into the master branch of this site’s repository, creating a stateless usable image. Some background The site is created by hugo, a very fast static site generator. The generated files are built into a Docker image which uses nginx to serve them to the web. To make the containers from these images available to the general web browsing public, the production server is running nginx as a reverse proxy alongside docker-gen. »

Docker Swarm cluster missing nodes

While creating a Docker Swarm cluster; only one node would ever join. Looking at the logs of the Swarm manager revealed an error that each node had an ID that was already used by the node currently in the cluster. time="2015-05-05T11:39:33Z" level=error msg="ID duplicated. AGM4:Z2ZA:NQW3:ZQ9K:IX34:JQJ1:SCAO:ECQL:PY4W:JVC3:C1YB:RZT6 shared by and" When Docker starts it creates a trust key, which is then used to get an ID for the Docker daemon. You can find yours with: $ docker info | grep ID The problem occured due to a cloned VM image (with Docker and Swarm already installed) being used for each node. »

Using docker-gen with a Swarm cluster

TL;DR Using the latest version of docker-gen; connect it to the Swarm master (don’t forget SSL) and then use {{ $container.Node.Address.IP }} in your template files. docker-gen & Docker Swarm We will set up a Swarm cluster; in which nginx will be used as a reverse proxy to containers serving web content. docker-gen will monitor the swarm for relevant container starts and stops and update nginx accorrdingly. This in essense provides zero downtime for all container related maintenance. »

Centralizing Docker container logs

The state of Docker container logging is evolving; with options out there such as logging to a volume, running a log collection agent in each container or reading the raw Docker log files after some clunky configuration of program X. For me the solution lies with Docker: soon they will solve the container logging question, so we need a tool to read those logs and forward them to a central point. »

Go: reloading configuration on the fly - take two

This is a follow up, and perhaps a more in depth coverage to the previous article Go: reloading configuration on the fly. Several commentators pointed out that perhaps the example wasn’t as consise or correct as it should be, or that it was in general confusing. This was my fault as I originally meant to write a very quick article on the subject using a very similified version of an application I was writing. »