This is a companion to my article on the Docker plugin for Heat.

While writing that article, I encountered a number of bugs in the Docker plugin and elsewhere. I’ve submitted patches for most of the issues I encountered:

Bugs in the Heat plugin

• https://bugs.launchpad.net/heat/+bug/1364017

  docker plugin fails to delete a container resource in CREATE_FAILED state.

• https://bugs.launchpad.net/heat/+bug/1364041

  docker plugin volumes_from parameter should be a list.

• https://bugs.launchpad.net/heat/+bug/1364039

  docker plugin volumes_from parameter results in an error

This is a companion to my article on the Docker plugin for Heat.

DockerInc::Docker::Container

Properties

• cmd : List

  Command to run after spawning the container.

  Optional property.

  Example:

    cmd: [ 'thttpd', '-C', '/etc/thttpd.conf', '-D', '-c', '*.cgi']
  

• dns : List

  Set custom DNS servers.

  Example:

    dns:
      - 8.8.8.8
      - 8.8.4.4
  

• docker_endopint : String

  Docker daemon endpoint. By default the local Docker daemon will be used.

  Example:

    docker_endpoint: tcp://192.168.1.100:2375
  

• env : String

I have been looking at both Docker and OpenStack recently. In my last post I talked a little about the Docker driver for Nova; in this post I’ll be taking an in-depth look at the Docker plugin for Heat, which has been available since the Icehouse release but is surprisingly under-documented.

The release announcement on the Docker blog includes an example Heat template, but it is unfortunately grossly inaccurate and has led many people astray. In particular:

I’ve been playing with Docker a bit recently, and decided to take a look at the nova-docker driver for OpenStack.

The nova-docker driver lets Nova, the OpenStack Compute service, spawn Docker containers instead of hypervisor-based servers. For certain workloads, this leads to better resource utilization than you would get with a hypervisor-based solution, while at the same time givin you better support for multi-tenancy and flexible networking than you get with Docker by itself.

Update (2018-03-22) Since I wrote this document back in 2014, Docker has developed the macvlan network driver. That gives you a supported mechanism for direct connectivity to a local layer 2 network. I’ve written an article about working with the macvlan driver.

This article discusses four ways to make a Docker container appear on a local network. These are not suggested as practical solutions, but are meant to illustrate some of the underlying network technology available in Linux.

After a recent upgrade of my Fedora 20 system to kernel 3.15.mumble, I started running into a problem (BZ 1121345) with my Docker containers. Operations such as su or runuser would fail with the singularly unhelpful System error message:

$ docker run -ti fedora /bin/bash
bash-4.2# su -c 'uptime'
su: System error

Hooking up something (like, say, socat unix-listen:/dev/log -) to /dev/log revealed that the system was logging:

Jul 19 14:31:18 su: PAM audit_log_acct_message() failed: Operation not permitted

Downgrading the kernel to 3.14 immediately resolved the problem, suggesting that this was at least partly a kernel issue. This seemed like a great opportunity to play with the git bisect command, which uses a binary search to find which commit introduced a particular problem.