Docker Provider Does Not Support --restart Switch

[kurron]

I'm using v0.5.3 to control some Docker containers and I've run into an issue: the Docker provider does not provide an equivalent to --restart=yes of the docker run command. The upshot is that when the Docker host is restarted, your containers are inactive. This is unacceptable for the majority of containers I run -- databases and message brokers. I need those containers alive and kicking if the box gets rebooted.

[supernomad]

This is a major requirement for me as well, I am currently trying to roll out a Terraform controlled docker container cluster and without --restart I can not use Terraform, which is a terrible shame. Is there anything I can do to facilitate a speedy implementation of this? I have go experience but not in a production environment, so I am not sure I can help too much on the code, but I would love to test it out for you. Let me know 😃

[apparentlymart]

Some docs on this, in case others who are as Docker-clueless as me find this issue: 😁
https://docs.docker.com/reference/run/#restart-policies-restart

Looks like this is exposed as a RestartPolicy field in the Go client's HostConfig struct:
http://godoc.org/github.com/fsouza/go-dockerclient#HostConfig

Here is where Terraform builds the HostConfig struct it passes in to the client:

terraform/builtin/providers/docker/resource_docker_container_funcs.go

Line 91 in edbc578

hostConfig := &dc.HostConfig{

Here is where the valid attributes for the Docker container resource are defined:

terraform/builtin/providers/docker/resource_docker_container.go

Line 18 in b9a4376

Schema: map[string]*schema.Schema{

Looks like this should be a reasonably simple change to add: just add a restart_policy attribute to the schema map it to and from the HostConfig struct. It looks like all the attributes on this resource are ForceNew, and the value of this property can't be read back out later from the API, so we only have to worry about the Create case.

@supernomad if you're interested I think this could be a good change with which to get started with Terraform development, since it's includes the most common pattern in Terraform provider development: marshalling values from the Terraform config into a provider-specific client. No pressure, of course!

Even though in the Docker API there is a sub-structure for the name and maximum retry count, I think I'd be tempted to flatten them both as top-level properties so that it's simpler in the "no" and "always" cases, since the other value is only used in the "on-failure" case. But I'm far from a Docker expert, so I'll cede to someone who has a better sense of what's intuitive to Docker users.

[supernomad]

@apparentlymart I will give it a shot sometime this weekend and will post a PR as soon as possible. Is there any guidelines I should follow to match code quality?

[mkuzmin]

Another related PR: #3761

[stack72]

Merged in #3761

[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.