A collection of experiments with docker
Clone or download
brontolinux Added consul-master
Please see README.md for details
Latest commit d62ec2b Apr 11, 2017
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
cf-serverd Initial commit Mar 30, 2016
consul-master Added consul-master Apr 11, 2017
debian-systemd Initial commit Mar 30, 2016
docker-consul Added docker-consul Apr 10, 2017
poc-systemd Initial commit Mar 30, 2016
progrium-consul Added progrium-consul/start-single-master.sh Apr 9, 2017
.gitignore Initial commit Mar 30, 2016
LICENSE Initial commit Mar 30, 2016
README.md Added consul-master Apr 11, 2017

README.md

A collection of experiments with docker

I have started playing with Docker and I thought it would be a good idea to share my experiments on GitHub. If you want to know a bit more about how these experiments have started, see my blog post "A dockerized policy hub"

cf-serverd

Proof of concept of implementing a CFEngine policy hub in a docker container.

To build this image enter the cf-serverd directory and run

docker build -t bronto/cf-serverd:3.7.2 .

You must provide your own masterfiles in the container's /var/cfengine/masterfiles and a suitable configuration for cf-serverd in /var/cfengine/inputs. You can do that by either mounting a local filesystem inside the container, or building your own image with the policy files bundled inside.

You also need to keep the encryption keys so that the clients don't need to be re-bootstrapped each time you create a new image. Again, you can mount /var/cfengine/ppkeys from a local filesystem, or bundle your set of encryption keys in the container itself.

This container exposes the port 5308/TCP to make cf-serverd available outside the container. You'll want to use either the -P or the -p option to docker run

Refer to the blog post for more information.

debian-systemd

Dockerfile for a debian container running the systemd init system. Heavily borrowed from dockerimages/docker-systemd.

You can use it as a base image to build containers that need to run more than one process. As such, you probably won't run it alone as it does nothing useful but starting systemd...

To build this image you'll enter the debian-systemd directory and run:

docker build -t bronto/debian-systemd .

When you run this image or any container you build upon it, you'll need at least the following options for docker run:

--cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro

poc-systemd

The whole point of having an init system running in a container is for those cases where you have processes that expect to log through a syslog service that is running on the same node. In those cases you need to run a syslog daemon in addition to the process you want to "containerize". I was interested in seeing that it is actually possible, so I built on both the cf-serverd and the debian-systemd containers.

The result is an image whose containers run systemd which, in turn, spawns CFEngine daemons and a syslog daemon. Like in the other case it does nothing useful unless you provide masterfiles, configurations for cf-serverd, and possibly encryption keys.

To build this image you'll enter the debian-systemd directory and run:

docker build -t bronto/poc-systemd .

When you run this image or any container you build upon it, you'll need at least the following options for docker run:

--cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro

In addition you'll want to use either the -P or the -p option to docker run to expose cf-serverd outside the container.

progrium-consul

At the moment, this directory contains only one script: start-single-master.sh. I use this script to configure a single-node consul server to be used as a key-value store in experiments with overlay networks.

This script aggregates system information and then runs a docker container progrium/consul, with a consul server bootstrapped as a single master.

The container is configured as per instructions found at https://hub.docker.com/r/progrium/consul/

The variables in the following section allow you to configure some aspects of the container and of the script itself.

The IP advertised by consul is the IPv4 address set on the interface through which the default route is configured. Notice that if the interface has more than one address assigned, the script will likely break.

As for the IP of the docker bridge, we detect the IPv4 address of docker0, as indicated in the instructions at the progrium/consul web page

docker-consul

This is the same as progrium-consul, but using the official consul image from Docker and Hashicorp.

This directory contains two scripts.

start-single-master.sh will start a docker container running a consul agent in server mode. The container is started with the option --net=host, thus sharing the network stack with the host itself.

start-client.sh will start a docker container running a consul agent in client mode. The IP of the consul master is given as an argument on the command line.

For more information, see the comments in the scripts themselves.

consul-master

This directory contains only one script: start-consul-master.sh.

This script aggregates system information and then runs a consul server bootstrapped as a single master.

With the default configuration, the script assumes to run in a directory where the following directory structure is present:

  • bin, which contains the consul binary;
  • config, which may contain the configuration for consul
  • data, which is used by consul to store its data

You can modify the values of the variables in the configuration section of the script to change these and other parameters.

The IP advertised by consul is the IPv4 address set on the interface through which the default route is configured. Notice that if the interface has more than one address assigned, the script will likely break.