Saturday, September 17, 2016

Managing Docker containers using Terraform on Windows 10

It started with evaluating Apcera, a container management platform, at work.  While Apcera "can" run on BareOS(ie one needs to install Ubuntu 14.04, and run some scripts), it is primarily made to run on top of an IaaS provider like OpenStack or AWS. After successfully installing Apcera on BareOS (see https://github.com/baboune/UnofficialApceraDoc/), my next goal was to set it up on OpenStack to troubleshoot some cloud-init issue that a colleague was experiencing.

When installing towards an IaaS provider, Apcera relies on Terraform. But it only supports Terraform 6.16, and not the latest version 0.7.3  and 0.7 is a major revision change with breaking compatibility changes.  Needless to say that this was not in the Apcera documentation and that a certain time was lost figuring out why the provided terraform files were failing (parsing errors, and Integer values are not supported (issue 6254)).

So, I decided to take a look at Terraform over the week end, and learn about it a little.

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. It can manage existing and popular service providers as well as custom in-house solutions. It is a infrastructure as code, execution plan, resource graph, and change automation tool.  It stops where Configuration Management tools like Puppet, Ansible and Chef starts.

One of the supported providers by Terraform is Docker. And, a priori, it looked simple enough to try and make a few terraform learnings.  It is quick and local to my Windows 10 setup. So, pressing Windows key -> Docker Quickstart Terminal launches the Docker default VM (VirtualBox provider) via docker-machine.

The next step is to create a project, and to attempt to launch a simple Ubuntu container as per the tutorial (see https://www.terraform.io/docs/providers/docker/index.html).

In this example tutorial, the terraform source looks like this:

# Configure the Docker provider
provider "docker" {
    host = "tcp://127.0.0.1:1234/"
}

# Create a container
resource "docker_container" "foo" {
    image = "${docker_image.ubuntu.latest}"
    name = "foo"
}

resource "docker_image" "ubuntu" {
    name = "ubuntu:latest"
}

the above needs to be saved in a "*.tf" file, e.g. example.tf in a local directory. Note that ".tf" is the terraform file extension and all files found within a directory with this extension are automatically included when running a terraform command.

There I faced a first problem, which IP and protocol to use in the provider section?  I knew that the IP is the Docker VirtualBox VM (192.168.99.100) but not the port, and the protocol should be http as the Remote Docker API is REST based.

Finding this information is easy. In the Quick Start console, simply type docker-machine config.

baboune MINGW64 ~
$ docker-machine config
--tlsverify
--tlscacert="C:\\Users\\baboune\\.docker\\machine\\certs\\ca.pem"
--tlscert="C:\\Users\\baboune\\.docker\\machine\\certs\\cert.pem"
--tlskey="C:\\Users\\baboune\\.docker\\machine\\certs\\key.pem"
--H=tcp://192.168.99.100:2376

Thus the host IP/protocol is tcp://192.168.99.100:2376.

But after updating the example.tf file with that information, and trying a terraform plan command, I still got a malformed HTTP response error (second problem).

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but
will not be persisted to local or remote state storage.

Error refreshing state: 1 error(s) occurred:
* Error pinging Docker server: Get http://192.168.99.100:2376/_ping: malformed HTTP response "\x15\x03\x01\x00\x02\x02"

A quick Google search indicates no matching results for my Docker setup (Docker Toolbox, recent docker version).  There are a few similar issues (here) but those are using boot2docker which has been deprecated in favor of docker-machine many releases ago. Also, a quick docker info will show that I am running release 1.12.1.

A netstat on the VM shows that port 2376 is open and associated with the docker server:

$ nestat -anp | grep 2376
tcp           0       0         :::2376        :::*        LISTEN        2662/dockerd

And a curl to the remote Docker API returns no visible results:

$ curl -XGET http://192.168.99.100:2376/_ping

$

But works.

It is at this point that I make the connection with the certificates directory listed by the docker-machine config command, and the Docker Remote API documentation.  Looking back to the terraform Docker documentation, it says:

The following arguments are supported:
  • host - (Required) This is the address to the Docker host. If this is blank, the DOCKER_HOST environment variable will also be read.
  • cert_path - (Optional) Path to a directory with certificate information for connecting to the Docker host via TLS. If this is blank, the DOCKER_CERT_PATH will also be checked.
While cert_path is indicated as optional, it seems that terraform might require this attribute to be set for on most deployments since docker-machine, as per Docker Remote API documentation, instantiates a Docker daemon that uses an encrypted TCP socket using TLS.

The working example.tf then becomes:

# Configure the Docker provider
provider "docker" {
    host = "tcp://127.0.0.1:1234/"
    cert_path = "c:\\Users\\Nicolas\\.docker\\machine\\certs"
}

# Create a container
resource "docker_container" "foo" {
    image = "${docker_image.ubuntu.latest}"
    name = "foo"
}

resource "docker_image" "ubuntu" {
    name = "ubuntu:latest"
}
HashiCorp allows users to update the documentation via GitHub, which leads me to create a pull request https://github.com/hashicorp/terraform/pull/8895 to update it with at least the default dockerd port information.

And terraform plan now works:


$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but
will not be persisted to local or remote state storage.

The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

+ docker_container.foo
    bridge:           "<computed>"
    gateway:          "<computed>"
    image:            "${docker_image.ubuntu.latest}"
    ip_address:       "<computed>"
    ip_prefix_length: "<computed>"
    log_driver:       "json-file"
    must_run:         "true"
    name:             "foo"
    restart:          "no"

+ docker_image.ubuntu
    latest: "<computed>"
    name:   "ubuntu:latest"

Plan: 2 to add, 0 to change, 0 to destroy.

2 comments: