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.

This post accompanies my article on the Docker plugin for Heat. In order for WaitCondition resources to operate correctly in Heat, you will need to make sure that that you have: Created the necessary Heat domain and administrative user in Keystone, Configured appropriate values in heat.conf for stack_user_domain, stack_domain_admin, and stack_domain_admin_password. Configured an appropriate value in heat.conf for heat_waitcondition_server_url. On a single-system install this will often be pointed by default at 127.

Heat is a template-based orchestration mechanism for use with OpenStack. With Heat, you can deploy collections of resources – networks, servers, storage, and more – all from a single, parameterized template. In this article I will introduce Heat templates and the heat command line client. Writing templates Because Heat began life as an analog of AWS CloudFormation, it supports the template formats used by the CloudFormation (CFN) tools. It also supports its own native template format, called HOT (“Heat Orchestration Templates”).