provider/docker: Upload files into container before first start

[mkuzmin]

This is another attempt to implement a feature started by @ColinHebert in #4921.
The main difference from the original PR - Terraform operates with file content instead of filenames, this allows rendering files from templates, and detect changes on resource update.

Rationale

1. Storing secrets.
   For example, private TLS-keys: they cannot be stored inside Docker image in a registry, so have to be copied into a specific container instance on start.
   There is a practice to store such data in environment variables, but this approach still has limitations. Sometimes using plain files if preferable.
2. Working with official images from Docker Hub.
   Most of the tools require text configuration files, like nginx.conf, elasticsearch.yml, or influxdb.conf. Even if dynamic data (like hostnames) is moved into environment variables, we still need to customize these files, and overwrite defaults stored inside an official image. Current solutions are:
   • Build your own image on top of official one.
     But this approach significantly complicates a workflow.
   • Put configs into a volume, and mount it into a container.
     Better, but does not allow to control versions of the data.

Solution

docker_container resource gets a new upload block.
Configuration files are copied into a created container before it's started.

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

resource "docker_container" "nginx" {
  image = "${docker_image.nginx.latest}"

  upload {
    content = "${file("tls.conf")}"
    file = "/etc/nginx/conf.d/tls.conf"
  }
  upload {
    content = "${file("nginx.crt")}"
    file = "/etc/nginx/ssl/nginx.crt"
  }
  upload {
    content = "${file("nginx.key")}"
    file = "/etc/nginx/ssl/nginx.key"
  }
}

It works the same way as Docker client:

> docker create nginx
fa6015c4e044857
> docker cp tls.conf fa6015:/etc/nginx/conf.d/
> docker start fa6015

There was an idea of a provisioner for Docker containers, suggested in #6216 and #6827, but this is a different feature, and cannot be used for the use cases described here.

• Provision is performed after a container is started - at that moment it's too late to change configuration files.
• We need to detect changes in a content, and re-create containers.

[mkuzmin]

@stack72 Hi Paul!
The feature is completed, and ready for review. Thanks!

[stack72]

Hi @mkuzmin

This seems like a sane feature to me - I agree with you about the provisioner not being the correct solution for this use-case

The tests look good to me!

% make testacc TEST=./builtin/providers/docker
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2016/12/05 11:03:58 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/docker -v  -timeout 120m
=== RUN   TestAccDockerRegistryImage_basic
--- PASS: TestAccDockerRegistryImage_basic (6.60s)
=== RUN   TestAccDockerRegistryImage_private
--- PASS: TestAccDockerRegistryImage_private (1.84s)
=== RUN   TestProvider
--- PASS: TestProvider (0.00s)
=== RUN   TestProvider_impl
--- PASS: TestProvider_impl (0.00s)
=== RUN   TestAccDockerContainer_basic
--- PASS: TestAccDockerContainer_basic (17.60s)
=== RUN   TestAccDockerContainer_volume
--- PASS: TestAccDockerContainer_volume (17.02s)
=== RUN   TestAccDockerContainer_customized
--- PASS: TestAccDockerContainer_customized (27.66s)
=== RUN   TestAccDockerContainer_upload
--- PASS: TestAccDockerContainer_upload (20.68s)
=== RUN   TestAccDockerImage_basic
--- PASS: TestAccDockerImage_basic (5.71s)
=== RUN   TestAccDockerImage_private
--- PASS: TestAccDockerImage_private (1.95s)
=== RUN   TestAccDockerImage_destroy
--- PASS: TestAccDockerImage_destroy (0.33s)
=== RUN   TestAccDockerImage_data
--- PASS: TestAccDockerImage_data (8.32s)
=== RUN   TestAccDockerNetwork_basic
--- PASS: TestAccDockerNetwork_basic (0.37s)
=== RUN   TestAccDockerVolume_basic
--- PASS: TestAccDockerVolume_basic (0.26s)
PASS
ok  	github.com/hashicorp/terraform/builtin/providers/docker	108.366s

Thanks for all the work here

Paul

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.