I would love for this provider to support important resources (all resources really). The Docker API is well-defined, it's readily available, I wouldn't say it'd be trivial to support importing resources, but at least it should be possible.

This issue was originally opened by @rkr-kununu as hashicorp/terraform#8972. It was migrated here as part of the provider split. The original body of the issue is below.

Terraform Version

Terraform v0.7.4

Affected Resource(s)

• docker_container

Terraform Configuration Files

resource "docker_network" "network" {
  name = "demo"
}

resource "docker_image" "image" {
  name = "gliderlabs/alpine:latest"
  keep_locally = true
}

resource "docker_container" "container" {
  name = "demo-container"

  image = "${docker_image.image.name}"

  network_mode = "${docker_network.network.name}"

  command = [ "sleep", "356d" ]
}

output "ip_address" {
  value = "${docker_container.container.ip_address}"
}

Expected Behavior

I expected that 'ip_address' would be set to ip_address of the docker container.

Actual Behavior

The 'ip_address' was not set.

Important Factoids

I did some poking around the code. It appears that the problem is two-fold.

1. Running docker-inspect on the running container also shows that 'IPAddress' is also empty.
2. However, docker-inspect also shows that the "Networks" map also contains all the relevant information (ip address, gateways for each network the container is running in). It also appears that the go-dockerclient terraform's using is parsing this information (see NetworkSettings->Networks). My hope is that this "Network" map can be exposed as part of docker_container's output.

This issue was originally opened by @lvjp as hashicorp/terraform#5728. It was migrated here as part of the provider split. The original body of the issue is below.

Resource docker_volume in not in dependencies if docker_container even if it's used.

You can see my problem through this gist

Hi,

Is there support for building docker images using their Dockerfile?

If yes, can someone point me to the relevant documentation?

If not, can this support be added? What is the alternate route for getting this done? I am guessing using local-exec, right? But in my opinion that would be a hacky way.

I am willing to add support for this feature if it makes sense to others.
Let me know.

Regards

This issue was originally opened by @abansal85 as hashicorp/terraform#15269. It was migrated here as part of the provider split. The original body of the issue is below.

Hello guys,

I am using terraform to spin up docker swarm clusters. We have a requirement where any dev should be able to create their own docker cluster ( for dev environment purposes ). Is there a way in terraform where using the same root module ( we can create multiple docker clusters, keep in mind we can't use "count").
Really appreciate the help.

Hi @apparentlymart,

thanks for this awesome tool terraform. I'd like to update this provider to support the latest features of the go-dockerclient. Especially Swarm.

Terraform Version

v0.10.7

Terraform provider docker Version

v0.1.0

Questions

• Do you need a release of the go-dockerclient to perform an update?
  I opened an issue and asked. The current version supports only up to the Docker 1.9 and API Version 1.21 (see matrix)
  EDIT: there is a new release now
• Why was terraform-provider-docker-pull-19 not merged or uncommented for months? Because the build was failing? Or no comment was provided? Are there any Contribution Guidelines?

I'd really like to push this development forward 😃

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• go-dockerclient-685
• terraform-provider-docker-pull-19

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.

Affected Resource(s)

All docker resources as this is common at the provider level

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

This is an Enhancement request which allows user to send the Basic authentication (Username and Password) information when the the docker daemon API is protected with Basic Auth over HTTPS. The value should be passed through environment variables - DOCKER_USERNAME and DOCKER_PASSWORD

Actual Behavior

What actually happened?

Currently, there is no support

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• GH-1234

Check the necessary files of #17 and add them. Details are in the PR

Terraform Version

v0.10.8

Affected Resource(s)

• docker_image

Terraform Configuration Files

resource "docker_image" "jenkins" {
  name         = "jenkinsci/jenkins:lts-slim"
  keep_locally = true
}

Output

Error: Error applying plan:

1 error(s) occurred:

* module.InternalInfrastructure.docker_image.jenkins: 1 error(s) occurred:

* docker_image.jenkins: Unable to read Docker image into resource: Unable to pull image jenkinsci/jenkins:lts-slim: Error pulling image jenkinsci/jenkins:lts-slim: API error (500): {"message":"Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io: no such host"}

Expected Behavior

Terraform should use the local image stored on a machine, without triggering a docker pull on the registry

Actual Behavior

Terraform tries to pull a new image from a docker registry, even if an image is present in the local machine.

Steps to Reproduce

terraform apply

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.

Affected Resource(s)

Please list the resources as a list, for example:

• opc_instance
• opc_storage_volume

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

What should have happened?

Actual Behavior

What actually happened?

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• GH-1234

Hi there,

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.

v0.11.1

Terraform Docker Provider Version

0.1.1

Expected Behavior

Migrate to the official Moby Client to access the Docker API to be consistent and to avoid issues like for example properties like mount -> consistency are not exposed.

Actual Behavior

The unofficial go-dockerclient is used

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• GH-22

I am trying to use a sha256 hash tag to reference an image to avoid pulling a tampered image. But it seems that the docker provider does not work with this tag.

Terraform Version

$ terraform version
Terraform v0.11.7
+ provider.docker v0.1.1

Affected Resource(s)

resource docker_image

Terraform Configuration Files

resource "docker_image" "gitlab" {
  name = "gitlab/gitlab-ce@sha256:f54ce2fd5011331b42ecc0b018caae700d36c9c9b5811eef9982d4d1b21c719c"
}

Expected Behavior

The image should be pulled like the docker pull command is doing the same.

Actual Behavior

API error (400)

* docker_image.gitlab: 1 error(s) occurred:

* docker_image.gitlab: Unable to read Docker image into resource: Unable to pull image gitlab/gitlab-ce@sha256:f54ce2fd5011331b42ecc0b018caae700d36c9c9b5811eef9982d4d1b21c719c: Error pulling image gitlab/gitlab-ce@sha256:f54ce2fd5011331b42ecc0b018caae700d36c9c9b5811eef9982d4d1b21c719c: API error (400): {"message":"invalid reference format"}

Steps to Reproduce

use a docker_image resource with a sha256 tag, like gitlab/gitlab-ce@sha256:f54ce2fd5011331b42ecc0b018caae700d36c9c9b5811eef9982d4d1b21c719c

References

use the docker CLI with the tag does work

$ docker pull gitlab/gitlab-ce@sha256:f54ce2fd5011331b42ecc0b018caae700d36c9c9b5811eef9982d4d1b21c719c
sha256:f54ce2fd5011331b42ecc0b018caae700d36c9c9b5811eef9982d4d1b21c719c: Pulling from gitlab/gitlab-ce
b234f539f7a1: Pull complete
55172d420b43: Pull complete
5ba5bbeb6b91: Pull complete
43ae2841ad7a: Pull complete
f6c9c6de4190: Pull complete
60fed0f57f41: Pull complete
c9dd8de9d2b3: Pull complete
073411baabf1: Pull complete
5b4d66ff18f7: Pull complete
d140a401cbc5: Pull complete
eb4ac2293653: Pull complete
Digest: sha256:f54ce2fd5011331b42ecc0b018caae700d36c9c9b5811eef9982d4d1b21c719c
Status: Downloaded newer image for gitlab/gitlab-ce@sha256:f54ce2fd5011331b42ecc0b018caae700d36c9c9b5811eef9982d4d1b21c719c

This issue was originally opened by @cmacrae as hashicorp/terraform#14941. It was migrated here as part of the provider split. The original body of the issue is below.

Terraform Version

0.9.6

Affected Resource(s)

• docker_container

Terraform Configuration Files

// Docker images
resource "docker_image" "alpine" {
  name = "alpine:latest"
}

// Docker containers
resource "docker_container" "gogs_data" {
  image   = "${docker_image.alpine.latest}"
  name    = "gogs_data"
  volumes = {
    volume_name    = "data"
    container_path = "/data"    
  }
}

Expected Behavior

A Docker container will be provisioned exposing a volume named data, with the container path: /data, without any association of a local directory on the host system (as host_path is not specified).

Actual Behavior

When applying this configuration, part of the payload sent to the remote Docker API:

      "Volumes": {
        "/data": {}
      },
      "Entrypoint": null,
      "HostConfig": {
        "Binds": [
          "data:/data:rw"
        ],

As you can see, HostConfig is added, mapping a bind like so: data:/data:rw.

Important Factoids

When using Triton as a remote Docker endpoint, this causes an issue, as host volumes are not supported, and the following is returned from their API:

* docker_container.gogs_data: Unable to create container: API error (500): host volumes are not supported (34be7a41-8fec-4c0d-904c-2d0ebf6a4b11)

I'm able to work around this using the Docker cli to express a container with a volume exposed without any hostconfiguration binding:

$ docker run -d -v /gogs_data --name gogs_data alpine:latest true 
bfb113a6341ae345c125b144fed755965cf72583a43245e1b368d81c9faafd9b

References

• joyent/sdc-docker hashicorp/terraform#17: Containers with volumes defined in Terraform report "host volumes are not supported"

This issue was originally opened by @hmcgonig as hashicorp/terraform#12135. It was migrated here as part of the provider split. The original body of the issue is below.

Terraform Version

terraform 0.8.7

Affected Resource(s)

• docker_registry_image

Terraform Configuration Files

# Create a container
resource "docker_container" "nginx-proxy" {
  image        = "${docker_image.nginx-proxy.latest}"
  name         = "nginx-proxy"
  restart      = "always"
  must_run     = true
  network_mode = "host"
  env          = [
    "CONSUL_TLS=${var.consul_tls_enabled}",
    "CONSUL_ADDR=${var.consul_address}",
    "DCNAME=${var.dcname}",
    "CONSUL_DATACENTER=${var.consul_datacenter}",
    "ENABLE_SSO=${var.enable_sso}",
    "SECURE_CIDR_BLOCKS=${var.secure_cidr_blocks}",
    "DC_DOMAIN=${var.dc_domain}"
  ]
}

data "docker_registry_image" "nginx-proxy" {
  name = "nginx-proxy:v1"
}

resource "docker_image" "nginx-proxy" {
  keep_locally = true
  name = "${data.docker_registry_image.nginx-proxy.name}"
  pull_triggers = ["${data.docker_registry_image.nginx-proxy.sha256_digest}"]
}

Debug Output

n/a

Panic Output

n/a

Expected Behavior

The docker_registry_image resource should use the image sha not the image digest sha when determining if an image needs to be pulled.

Actual Behavior

Instead we use the image digest sha. The reason that this is a problem: the digest sha is different for every image and image tag, even if the same image is just tagged as two different things. This has pretty bad implications, it means that terraform will try to restart containers based off this image even if there is no actual image change.

Given the following local consul images tagged as four different things, notice that their image ID is identical. This field is based off the actual image sha, which is what we should be using for this resource, instead we are using the digest sha which is always different.

hmcgonig [terraform] > docker images                                                                                                                                    ±[●][master]
REPOSITORY           TAG                 IMAGE ID            CREATED             SIZE
consul              latest              ece765766861        13 days ago         920 MB
consul              v248                ece765766861        13 days ago         920 MB
consul              v253                ece765766861        13 days ago         920 MB
consul              v260                ece765766861        13 days ago         920 MB

Steps to Reproduce

1. tag a single image as two different tags(v1 and v2) on dockerhub or a private registry
2. setup a docker_registry_image resource and point it at tag v1
3. setup a docker_image resource to use a docker_registry_image resource's sha as a pull trigger
4. setup a container using the docker_image resource
5. terraform apply
6. swap the docker_registry_image to point at the v2 tag.
7. run terraform plan. it will now show that terraform thinks it needs to restart any containers based off your image even though tag v1 and tag v2 are identical.

Important Factoids

This can be fixed by using the v2 version of the docker registry manifest. By default, the docker registry has a default content-type of application/vnd.docker.distribution.manifest.v1+prettyjws which is a v1 manifest that contains the digest sha as a header called "Docker-Content-Digest". The v2 manifest has the proper image sha in this same "Docker-Content-Digest" header. The registry can be set to return the proper v2 manifest by simply setting the Accept header to application/vnd.docker.distribution.manifest.v2+json when making our registry request.

References

http://stackoverflow.com/questions/39375421/can-i-get-an-image-digest-without-downloading-the-image (check the accepted answer for where I found the proper accept header)

I'll be creating a PR for this ASAP. It should be a pretty easy fix, but I wanted to get this issue up for documentation purposes. Thanks!

I keep having to pass around the docker network IDs as:

output "traefik-network-id" {
  value = "${docker_network.traefik.id}"
}

And then use them in other places. Would prefer if there was a data source that lets me look up networks using name or other conditions. Something like the following:

data "docker_network" "one"{
  id = ""
  name = "network-1"
}

data "docker_networks" "list" {
  driver = ""
  label {
    key = "value"
  }
  // Matches partial name
  name = ""
  type = "custom|builtin"
}

The singular docker_network always returns one exact return by the name or id. The docker_networks returns a list of networks.

The exported attributes will be same as docker_network resource.

Will try to file a PR for this if this sounds like a good idea?

This issue was originally opened by @haai as hashicorp/terraform#18416. It was migrated here as a result of the provider split. The original body of the issue is below.

Terraform complains that it could not parse the docker hostname when the hostname contains a variable substitution, which worked with the old plugin.

Terraform Version

Terraform v0.11.7
+ provider.docker v1.0.0

Expected Behavior

It should work :)

Actual Behavior

$ 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: Error refreshing state: 1 error(s) occurred:

* provider.docker: Error initializing Docker client: parse tcp://${var.docker_host}:2375/: invalid character "{" in host name

Steps to Reproduce

Use docker plugin and a provider with

provider "docker" {
  host = "tcp://${var.docker_endpoint}/"
}

Notes

It seemed to work with the old plugin

Terraform v0.11.7
+ provider.docker v0.1.1

This issue was originally opened by @sasah as hashicorp/terraform#12603. It was migrated here as part of the provider split. The original body of the issue is below.

https://docs.docker.com/engine/reference/run/#ipc-settings---ipc

Need for running https://github.com/portworx/px-dev

This issue was originally opened by @rayward as hashicorp/terraform#5033. It was migrated here as part of the provider split. The original body of the issue is below.

Getting this error:

1 error(s) occurred:

• docker_container.nzbget: Unable to connect to network 'ba576708b1403c86625e83cfce77face1bbbefa061f0d3bb09a6869defa1d238': API error (500): Container e056e2e37486821352b1d010c92c85760dc42deb0a528c38c08df1d3121d585a is not running

Presumably because the StartContainer() call is after the block that connects the networks: https://github.com/hashicorp/terraform/blob/e490b44daa9297ac78828a44f0b1148af72ce4d0/builtin/providers/docker/resource_docker_container_funcs.go#L174

Terraform returns a non-existent IP address for a newly created container when the default bridge is disconnected as part of the local-exec provisioner. I have to disconnect the default bridge because of #10

Terraform Version

$ terraform -v
Terraform v0.11.1
+ provider.docker v0.1.1

Affected Resource(s)

• docker_container
• docker_network (?)

Terraform Configuration Files

provider "docker" {
  host = "unix:///var/run/docker.sock"
}

data "docker_registry_image" "openldap" {
  name = "osixia/openldap:1.1.11"
}

resource "docker_image" "openldap" {
  name = "${data.docker_registry_image.openldap.name}"
  pull_triggers = ["${data.docker_registry_image.openldap.sha256_digest}"]
}

resource "docker_network" "ldap" {
  name = "ldap-network"
  driver = "bridge"
}

resource "docker_container" "ldap" {
  count = 2
  image = "${docker_image.openldap.latest}"
  name = "ldap-${count.index}"
  networks = ["${docker_network.ldap.id}"]
  hostname = "ldap-${count.index}"
  env = [
    "LDAP_LOG_LEVEL=256",
    "LDAP_REPLICATION=false"
  ]
  provisioner "local-exec" {
    // https://github.com/terraform-providers/terraform-provider-docker/issues/10
    command = "/usr/local/bin/docker network disconnect bridge ldap-${count.index}"
  }
}

output "ips" { value = "${join(", ", docker_container.ldap.*.ip_address)}" }

Output

[...]
$ terraform apply
[...]
Apply complete! Resources: 4 added, 0 changed, 0 destroyed.

Outputs:

ips = 172.17.0.3,172.17.0.2

$ docker inspect ldap-0 |jq '.[0] | {networks: .NetworkSettings.Networks}'
{
  "networks": {
    "ldap-network": {
      "IPAMConfig": null,
      "Links": null,
      "Aliases": [
        "252595d82a3d"
      ],
      "NetworkID": "beeb7c11c2e8d75e078aa5b46503c42676ced6b9961f1dcd92d4de99275cc452",
      "EndpointID": "4299750f51a78d3b800bdc50d3013da3c0500fb48cd60ac7c733488caafbffb7",
      "Gateway": "172.18.0.1",
      "IPAddress": "172.18.0.3",
      "IPPrefixLen": 16,
      "IPv6Gateway": "",
      "GlobalIPv6Address": "",
      "GlobalIPv6PrefixLen": 0,
      "MacAddress": "02:42:ac:12:00:03",
      "DriverOpts": null
    }
  }
}

Expected Behavior

The exported output should contain the correct IP address. I guess NetworkSettings is read before the provisioners run.

Actual Behavior

Output shows the IP address of the default bridge which is disconnected by a local-exec provisioner.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. Create the HCL posted above
2. terraform init && terraform apply
3. docker inspect ldap-0 |jq '.[0] | {networks: .NetworkSettings.Networks}'
4. docker exec ldap-0 ip a

References

• #10

Hi There,

It looks like this provider performs a two-step process when you specify a network, and creates the docker container, then attaches a network to it.

Unfortunately the Triton Docker API doesn't currently support connecting networks after container creation, which means this:

resource "docker_container" "database" {
  name    = "database"
  image   = "${docker_image.percona.latest}"
  networks = ["internal-2720"]
}

Fails with:

* docker_container.database: Unable to connect to network 'internal-2720': API error (400): (NotImplemented) network connect is not implemented (5349d3cd-33 f1-45fd-8cdc-a37a06768a71)

"docker run --network=", or docker-compose both work fine, as these pass the network configuration in via the Docker create API call.

It should hopefully be a simple enough fix to pass the network config in via the create command instead.

This issue was originally opened by @maguec as hashicorp/terraform#2379. It was migrated here as part of the provider split. The original body of the issue is below.

Terraform apply works when using docker swarm, but since the name is set to node/container_name the destroy is not working.

Related to: hashicorp/terraform#1979

Run docker swarm from https://github.com/shokunin/puppet-docker-swarm

provider "docker" {
    host = "tcp://localhost:2378/"
}

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

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

$ terraform apply
docker_image.redis: Creating...
  latest: "" => "<computed>"
  name:   "" => "redis:latest"
docker_image.redis: Creation complete
docker_container.redis: Creating...
  bridge:           "" => "<computed>"
  gateway:          "" => "<computed>"
  image:            "" => "95af5842ddb9b03f7c6ec7601e65924cec516fcedd7e590ae31660057085cf67"
  ip_address:       "" => "<computed>"
  ip_prefix_length: "" => "<computed>"
  must_run:         "" => "1"
  name:             "" => "redis1"
docker_container.redis: Creation complete

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.

State path: terraform.tfstate
[chris@bonobo]: {master} ~/Vagrant/puppet-docker-swarm/terrform 2.0.0-p451@puppet-packer 
$ docker -H tcp://localhost:2378 ps
CONTAINER ID        IMAGE                                                                     COMMAND                CREATED                  STATUS                  PORTS               NAMES
fcd4ee473e70        95af5842ddb9b03f7c6ec7601e65924cec516fcedd7e590ae31660057085cf67:latest   "/entrypoint.sh redi   Less than a second ago   Up Less than a second   6379/tcp            node2/redis1        

Try destroy but the image remains running:

$ terraform destroy
Do you really want to destroy?
  Terraform will delete all your managed infrastructure.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

docker_image.redis: Refreshing state... (ID: 95af5842ddb9b03f7c6ec7601e65924cec516fcedd7e590ae31660057085cf67redis:latest)
docker_image.redis: Destroying...
docker_image.redis: Destruction complete

Apply complete! Resources: 0 added, 0 changed, 1 destroyed.
[chris@bonobo]: {master} ~/Vagrant/puppet-docker-swarm/terrform 2.0.0-p451@puppet-packer 
$ docker -H tcp://localhost:2378 ps
CONTAINER ID        IMAGE                                                                     COMMAND                CREATED                  STATUS              PORTS               NAMES
fcd4ee473e70        95af5842ddb9b03f7c6ec7601e65924cec516fcedd7e590ae31660057085cf67:latest   "/entrypoint.sh redi   Less than a second ago   Up 22 seconds       6379/tcp            node2/redis1 

This issue was originally opened by @H-A-T as hashicorp/terraform#5357. It was migrated here as part of the provider split. The original body of the issue is below.

Oh hai o/
A little issue about docker provider, as It seems that nested labels can't be properly be injected.
Let's take this sample code for example :

resource "docker_image" "gogs" {
    name = "gogs/gogs:latest"
    keep_updated = true
}
resource "docker_container" "gogs-fe" {
    image = "${docker_image.gogs.latest}"
    name = "gogs-fe"   
    must_run = true
    restart = "on-failure"
    labels {
     "traefik.backend" = "git"
     "traefik.port" = "3000"
    }
    ports {
    internal = "3000"
    }
    volumes {
    volume_name = "gogs_vol"
    container_path = "/data"
    #host_path = "/data"
    }
}

Planing with and without these nested values gives:

20:28:48 [hitch@Bahamut gogs]$ terraform version
Terraform v0.6.12

20:28:53 [hitch@Bahamut gogs]$ terraform plan
Refreshing Terraform state prior to plan...
[...]
+ docker_container.gogs-fe
    bridge:                            "" => "<computed>"
    gateway:                           "" => "<computed>"
    image:                             "" => "${docker_image.gogs.latest}"
    ip_address:                        "" => "<computed>"
    ip_prefix_length:                  "" => "<computed>"
    labels.#:                          "" => "2"
    labels.backend:                    "" => "git"
    labels.port:                       "" => "3000"
    log_driver:                        "" => "json-file"
    must_run:                          "" => "1"
    name:                              "" => "gogs-fe"
    ports.#:                           "" => "1"
    ports.4204094420.external:         "" => ""
    ports.4204094420.internal:         "" => "3000"
    ports.4204094420.ip:               "" => ""
    ports.4204094420.protocol:         "" => "tcp"
    restart:                           "" => "on-failure"
    volumes.#:                         "" => "1"
    volumes.2786597125.container_path: "" => "/data"
    volumes.2786597125.from_container: "" => ""
    volumes.2786597125.host_path:      "" => ""
    volumes.2786597125.read_only:      "" => ""
    volumes.2786597125.volume_name:    "" => "gogs_vol"

+ docker_image.gogs
    keep_updated: "" => "1"
    latest:       "" => "<computed>"
    name:         "" => "gogs/gogs:latest"


Plan: 2 to add, 0 to change, 0 to destroy.
20:28:55 [hitch@Bahamut gogs]$ terraform plan
Refreshing Terraform state prior to plan...
[...]
+ docker_container.gogs-fe
    bridge:                            "" => "<computed>"
    gateway:                           "" => "<computed>"
    image:                             "" => "${docker_image.gogs.latest}"
    ip_address:                        "" => "<computed>"
    ip_prefix_length:                  "" => "<computed>"
    labels.#:                          "" => "2"
    labels.traefik.backend:            "" => ""
    labels.traefik.port:               "" => ""
    log_driver:                        "" => "json-file"
    must_run:                          "" => "1"
    name:                              "" => "gogs-fe"
    ports.#:                           "" => "1"
    ports.4204094420.external:         "" => ""
    ports.4204094420.internal:         "" => "3000"
    ports.4204094420.ip:               "" => ""
    ports.4204094420.protocol:         "" => "tcp"
    restart:                           "" => "on-failure"
    volumes.#:                         "" => "1"
    volumes.2786597125.container_path: "" => "/data"
    volumes.2786597125.from_container: "" => ""
    volumes.2786597125.host_path:      "" => ""
    volumes.2786597125.read_only:      "" => ""
    volumes.2786597125.volume_name:    "" => "gogs_vol"

+ docker_image.gogs
    keep_updated: "" => "1"
    latest:       "" => "<computed>"
    name:         "" => "gogs/gogs:latest"


Plan: 2 to add, 0 to change, 0 to destroy.
20:29:06 [hitch@Bahamut gogs]$

Is there any way to confirm this behavior?

Cheers,

When using an AWS ECR registry it turns out that services cannot be pulled without the flag --with-registry-auth.

It would be very helpful to have this flag option in docker_service and docker_container resources.

$ terraform -v
Terraform v0.11.3
+ provider.docker v0.1.0

I would like to launch a container which I know will be short-lived, and have it be cleaned up once it exits, similar to docker run --rm.

Looking at the docs for the golang Docker SDK, the ContainerCreate function accepts a HostConfig object, which contains the relevant flag, AutoRemove.

It would be great if this flag was exposed like so:

resource "docker_container" "my_containerised_script" {
  name  = "my_script"
  image = "my_script_image"
  rm = true
}

I am using Terraform to create a couple Consul test clusters within docker containers. It relies on dockers hostname resolution with non-default bridge networks. My terraform file specifies that a docker network should be created. Applying this works great but destroying it fails every time. It successfully removes all the containers but when it gets to the step where the network is removed it fails with this error:

* docker_network.consul-acls-test: Error deleting network 03d5287cd27269f9599ce80a249172b932ff9eb6ed69f48438773f2255687291: Error response from daemon: network consul-acls-test id 03d5287cd27269f9599ce80a249172b932ff9eb6ed69f48438773f2255687291 has active endpoints

The docker daemon is reporting that error. If I run terraform destroy a second time immediately after it fails then it is successful and removes the network. Presumably the docker daemon is just taking a moment to remove the endpoints from the network after it returns success for container removal.

Maybe this is a docker bug and not a bug in this provider? Also if it matters I am using Docker for Mac:

Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:21:31 2018
 OS/Arch:           darwin/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:29:02 2018
  OS/Arch:          linux/amd64
  Experimental:     true

Terraform Version

Terraform v0.11.7
+ provider.docker v1.0.2
+ provider.template v1.0.0

Your version of Terraform is out of date! The latest version
is 0.11.8. You can update by downloading from www.terraform.io/downloads.html

Affected Resource(s)

Please list the resources as a list, for example:

• docker_network

Terraform Configuration Files

https://gist.github.com/mkeeler/8d1ce60054e531ca2231e5c3cbb34afe

Debug Output

mkeeler-corp:acl-dc mkeeler$ terraform destroy -auto-approve
docker_container.consul-secondary-srv1: Refreshing state... (ID: 947a33a92d9757f2aa69b7f47fbde3d77c384038aeb291414110f9bea58162e4)
docker_container.consul-primary-srv1: Refreshing state... (ID: f06259ed1e9c82ea586e34e57d7237df6b76c415723a4041be40c43df2f5f91f)
docker_container.consul-secondary-srv2: Refreshing state... (ID: d45b20d2007424e6651cbe4a8123702b9435e65e51dfc79510f2e5c29bce90b3)
docker_container.consul-secondary-srv3: Refreshing state... (ID: 8977a36921fb10a82bbcac1c38845defd8277828c2fcbbccf94497c79bdca2a0)
docker_container.consul-secondary-client1: Refreshing state... (ID: 6801fb2db3bda246a94699a12f5519e19b6265de3e213150d48c97a0efcd0460)
docker_network.consul-acls-test: Refreshing state... (ID: 03d5287cd27269f9599ce80a249172b932ff9eb6ed69f48438773f2255687291)
docker_container.consul-primary-srv3: Refreshing state... (ID: eb4e754c7e4358df944dde4355e78bbe6ca4ae832d8f0dae3efa48b83b51ac57)
docker_container.consul-secondary-client2: Refreshing state... (ID: 2d311f225312e9f2230943f761e9c6d6cf863c141db6d78d2c20c61b2f353f76)
docker_container.consul-primary-srv2: Refreshing state... (ID: 9834a8def44339d238b0c302e2a3c986cf993f91ac7a6992afd61161adca525d)
docker_container.consul-secondary-srv3: Destroying... (ID: 8977a36921fb10a82bbcac1c38845defd8277828c2fcbbccf94497c79bdca2a0)
docker_container.consul-primary-srv2: Destroying... (ID: 9834a8def44339d238b0c302e2a3c986cf993f91ac7a6992afd61161adca525d)
docker_container.consul-primary-srv3: Destroying... (ID: eb4e754c7e4358df944dde4355e78bbe6ca4ae832d8f0dae3efa48b83b51ac57)
docker_container.consul-secondary-client2: Destroying... (ID: 2d311f225312e9f2230943f761e9c6d6cf863c141db6d78d2c20c61b2f353f76)
docker_container.consul-secondary-srv2: Destroying... (ID: d45b20d2007424e6651cbe4a8123702b9435e65e51dfc79510f2e5c29bce90b3)
docker_network.consul-acls-test: Destroying... (ID: 03d5287cd27269f9599ce80a249172b932ff9eb6ed69f48438773f2255687291)
docker_container.consul-secondary-client1: Destroying... (ID: 6801fb2db3bda246a94699a12f5519e19b6265de3e213150d48c97a0efcd0460)
docker_container.consul-primary-srv1: Destroying... (ID: f06259ed1e9c82ea586e34e57d7237df6b76c415723a4041be40c43df2f5f91f)
docker_container.consul-secondary-srv1: Destroying... (ID: 947a33a92d9757f2aa69b7f47fbde3d77c384038aeb291414110f9bea58162e4)
docker_container.consul-secondary-client2: Destruction complete after 2s
docker_container.consul-secondary-srv1: Destruction complete after 2s
docker_container.consul-primary-srv1: Destruction complete after 2s
docker_container.consul-primary-srv2: Destruction complete after 2s
docker_container.consul-primary-srv3: Destruction complete after 2s
docker_container.consul-secondary-srv2: Destruction complete after 2s
docker_container.consul-secondary-client1: Destruction complete after 2s
docker_container.consul-secondary-srv3: Destruction complete after 3s

Error: Error applying plan:

1 error(s) occurred:

* docker_network.consul-acls-test (destroy): 1 error(s) occurred:

* docker_network.consul-acls-test: Error deleting network 03d5287cd27269f9599ce80a249172b932ff9eb6ed69f48438773f2255687291: Error response from daemon: network consul-acls-test id 03d5287cd27269f9599ce80a249172b932ff9eb6ed69f48438773f2255687291 has active endpoints

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

Expected Behavior

The docker network should be successfully removed.

Actual Behavior

I get that error about not being able to delete the network because there are still active endpoints.

Steps to Reproduce

1. terraform apply
2. terraform destroy

With Docker on the CLI, it's possible to create a docker container that is never started:

https://docs.docker.com/engine/reference/commandline/create/#extended-description

This can be quite useful in certain situations.

This issue was originally opened by @maks-us as hashicorp/terraform#15141. It was migrated here as part of the provider split. The original body of the issue is below.

Hi there,

Terraform Version

Terraform v0.9.6
Mac OS 10.12.5
Docker version 17.06.0-ce-rc1, build 7f8486a

Affected Resource(s)

resource "docker_container" "ubuntu"
resource "docker_image" "ubuntu"

It is example from this page https://www.terraform.io/docs/providers/docker/r/container.html

Debug Output

Error applying plan:
1 error(s) occurred:

• docker_container.ubuntu: 1 error(s) occurred:
• docker_container.ubuntu: Unable to start container: API error (400): {"message":"starting container with non-empty request body was deprecated since v1.10 and removed in v1.12"}

Expected Behavior

work example from the documentation website

Actual Behavior

start ubuntu container

Steps to Reproduce

1. create main.tf
2. add content:

resource "docker_container" "ubuntu" {
  name  = "foo"
  image = "${docker_image.ubuntu.latest}"
  command = ["top"]
}

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

3. run:
   terraform apply

This issue was originally opened by @tomwilkie as hashicorp/terraform#3526. It was migrated here as part of the provider split. The original body of the issue is below.

* docker_container.frontend.1: Unable to start container: API error (500): Cannot start container 556d141acc87dcc4797c4a84d82cb35b49197db0009d20f2304f64c0b5146305: Bind for 0.0.0.0:80 failed: port is already allocated

I get this error consistently. I have a 3 host swarm cluster, and want to start 3 replicas of the frontend container, one on each host. One always fails to start.

My diagnosis is that, as Terraform is passing the HostConfig on start (and not on create), Swarm is making the placement decision before it knows about the port mapping, and is putting two of my frontends on the same machine.

I guess the fix is to pass HostConfig on create, but the comment in the code (https://github.com/hashicorp/terraform/blob/master/builtin/providers/docker/resource_docker_container_funcs.go#L35) seems to indicate you tried this and it didn't work. I've tried it and it does; perhaps this is an Docker version thing? Either way, would you be open to a PR which send the host config on create and start?

This issue was originally opened by @fdebonneval as hashicorp/terraform#12095. It was migrated here as part of the provider split. The original body of the issue is below.

Hi there, I hope this issue have not already been reported, I took a look and did not find duplicate.
Anyway, thanks for telling me if it is an expected behavior or a genuine issue to fix.

Terraform Version

# terraform --version Terraform v0.8.7

Affected Resource(s)

• docker networks

Terraform Configuration Files

provider "docker" {
    host = "unix:///var/run/docker.sock"
}

resource "docker_container" "alpine" {
  name = "foo"
  image = "alpine:latest"
  command = ["ip", "a"]
  networks = ["tf-net"]
}

Debug Output

The docker logs of the container returns

[...]
44: eth0@if45: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.3/16 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe11:3/64 scope link tentative
       valid_lft forever preferred_lft forever
46: eth1@if47: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:12:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.2/16 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe12:2/64 scope link tentative
       valid_lft forever preferred_lft fore

Also Docker inspect of the created container :

[...]
"Networks": {
                "bridge": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "NetworkID": "8eac1874812a79759249b97e8aba68f20256e5f772a5bdcc033271d0120b86a4",
                    "EndpointID": "",
                    "Gateway": "",
                    "IPAddress": "",
                    "IPPrefixLen": 0,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": ""
                },
                "tf-net": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": [
                        "9c3bf9a9296d"
                    ],
                    "NetworkID": "71ce9a1e51eaa9a6098881c946f5099bccebe2728158f44ce374213ee9041cb8",
                    "EndpointID": "",
                    "Gateway": "",
                    "IPAddress": "",
                    "IPPrefixLen": 0,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": ""
                }
            }
[...]

Expected Behavior

With only one network in the list, I would expect only one 'eth0' interface inside the running container

Actual Behavior

I get the default bridge and the network from the list.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. On a docker host
2. Define a .tf file from the example above
3. The run an apply docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock -v $(pwd):/tf --workdir /tf hashicorp/terraform:light apply

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.

Affected Resource(s)

Please list the resources as a list, for example:

• opc_instance
• opc_storage_volume

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

What should have happened?

Actual Behavior

What actually happened?

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• GH-1234

Hello,

I have a big problem with initializing the provider itself.

Terraform & provider versions

Terraform v0.11.7
Docker provider v1.0.1

Affected Resource

The provider itself.

Terraform Configuration Files

provider "docker" {
  host          = "tcp://<some IP>:<some port>"
  ca_material   = "${data.blahblah_ca}"
  cert_material = "${data.blahblah_cert}"
  key_material  = "${data.blahblah_key}"
}

Expected Behavior

Use the content of data.blahblah_* as CA, cert and key material.

Actual Behavior

Use the content of data.blahblah_* as CA, cert and key files paths.

Steps to Reproduce

1. terraform apply

Important Factoids

It certainly comes from this commit:
1f563cc#diff-4a9f60e1d3ebb2215df43a2c3d83cfa8
... where:

dc.NewTLSClientFromBytes(c.Host, []byte(c.Cert), []byte(c.Key), []byte(c.Ca))

... has been replaced with:

client.NewClientWithOpts(
	client.WithHost(c.Host),
	client.WithTLSClientConfig(c.Ca, c.Cert, c.Key),
	client.WithVersion(apiVersion),
)

client.WithTLSClientConfig(c.Ca, c.Cert, c.Key) (from github.com/docker/docker/client) takes files paths as arguments, not data contents.

https://www.terraform.io/docs/providers/docker/d/registry_image.html
https://www.terraform.io/docs/providers/docker/r/image.html

According to the changelog, the latest release supports pulling from private registries. Although the provider docs explain how to add credentials for multiple registries, the docker_registry_image data source and docker_image resource pages both indicate that private registries are not supported in the initial (current?) release.

• move all flatteners and expanders into the structure_*.go files and test them (due to #29 (comment))
• replace for loops with stateFunc
• describe all properties to be consistent
• be consistent with API (service is already)
• refactor tests
• add let's encrypt certificate and remove InsecureRegistries workaround for ACC tests
• add check if auth to registry was successfull
• add check if image exists in repository
• check if tag in internalPullImageOptions is still need with offical docker client
• replace node http servers with more lightweight go ones
• add https://golangci.com/
• consider removing the state migrators (or into separate files)

The last release (v0.1.1) is quite old (November 2017).

Lots of commits to master since: v0.1.1...master

A new release will be very helpful.

Hi there,

I just tried using Terraform to provision some Docker containers for a local throwaway test infrastructure and I cannot manage to have Terraform connect to my Docker daemon.

Terraform Version

Terraform v0.11.7
+ provider.docker v0.1.1
+ provider.template v1.0.0

Affected Resource(s)

The provider's host attribute itself is affected.

Terraform Configuration Files

provider "docker" {}
resource "docker_container" "anything" { ... }

Expected Behavior

I was hoping to create a simple Docker container :-)

Actual Behavior

Terraform cannot connect to my Docker daemon. I cannot find any suitable value for the host property that will allow it to connect.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. Access a Windows 10 machine with "Docker for Windows" (the one based on Hyper-V).
2. Write a Terraform configuration that creates a single Docker container;
3. Run terraform plan

Important Factoids

When running Docker for Windows, the Docker daemon exposes a Windows named pipe rather than a TCP endpoint.

This issue was originally opened by @ghost as hashicorp/terraform#7314. It was migrated here as part of the provider split. The original body of the issue is below.

Terraform v0.7.0-rc2 (46a0709bba004d8b6e0eedad411270b3ae135a9e)

Affected Resource(s)

• docker_container

Terraform Configuration Files

resource "docker_image" "mongo" {
  name         = "mongo:2.6"
  keep_updated = true
}

resource "docker_container" "mongo" {
  image             = "${docker_image.mongo.latest}"
  name              = "mongo"
  ports {
    internal = "27017"
  }
}

Debug Output

• docker_container.mongo: cannot parse '' as int: strconv.ParseInt: parsing "": invalid syntax

Expected Behavior

Terraform should allow the Docker behaviour of only specifying the containers internal inbound port and assigning a random port for host. Even better it would be if setting the external port as empty would have the same behaviour as omitting it.

Actual Behavior

The above error

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform plan

Important Factoids

See for instance the Compose File reference
https://docs.docker.com/compose/compose-file/#ports

This issue was originally opened by @jmprusi as hashicorp/terraform#4934. It was migrated here as part of the provider split. The original body of the issue is below.

Hi!

I've been trying to pull an image from a private registry using resource "docker_image" without success..

• Running docker pull private/image:latest from the instance works
• Running DOCKER_HOST=host docker pull private/image:latest from the client works

But it fails when using the docker provider of terraform with a 403

there's way to specify the registry user/password?

thanks!

Travis supports now builds on windows: https://blog.travis-ci.com/2018-10-11-windows-early-release 🎉

• Add this to build matrix
• Remove appveyor configuration

//cc @AndreLouisCaron

I'm hitting the bug that was fixed in #27. Is it possible to release version 0.2.0? That release contains the changes that make the data source work with private registries.
I've already tested the current master locally and can confirm that the changes work.

Terraform Version

v0.11.6

Affected Resource(s)

• data source docker_registry_image

Terraform Configuration Files

provider "docker" {
  registry_auth {
    address  = "docker-registry.example.com:5000"
    username = "example"
    password = "example"
  }
}

data "docker_registry_image" "service" {
  name = "docker-registry.example.com:5000/service:latest"
}

Expected Behavior

The data source docker_registry_image exports the attribute sha256_digest.

Actual Behavior

data.docker_registry_image.service: data.docker_registry_image.service: Got error when attempting to fetch image version from registry: Got bad response from registry: 404 Not Found

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform plan

References

• GH-27

Terraform Version

I'm using latest version 0.11.7 on Amazon linux AMI latest version

Affected Resource(s)

• docker_service

Output behavior

I have configured docker_service resource with two networks attached to it, while I'm running terraform apply it runs continuously but all the resources were created successfully, works fine as expected. Need to apply ctrl+C twice to interrupt the apply to get back to terminal and still resources were created successfully works as expected. From this point the terraform refresh, destroy and plan none of them gets done, they get stuck and repeat the refreshing state lines.

my code

resource "docker_service" "abcd" {
  task_spec = {
    networks = ["${var.db}", "${docker_network.ghi.id}"]

    container_spec {
      image = "${var.docker_image}"
      ]

Thank you in advance

This issue was originally opened by @FortuneLenovo as hashicorp/terraform#18050. It was migrated here as a result of the provider split. The original body of the issue is below.

I'm working on Docker swarm cluster and looking forward to manage swarm services and stacks for terraform docker provider. It will be really appreciated if we can get these docker_service and docker_stack resources in docker provider.

Terraform Version

Terraform v0.11.4
+ provider.cloudflare v0.1.0
+ provider.digitalocean v0.1.3
+ provider.docker v0.1.1
+ provider.mysql v0.1.0
+ provider.template v1.0.0

Affected Resource(s)

Please list the resources as a list, for example:

• docker_container

Terraform Configuration Files

resource docker_container "docker-file-test" {
  name  = "docker-file-test"
  image = "${docker_image.docker-file-test.latest}"

  upload {
    content = "${file("${path.module}/files/1.txt")}"

    file = "/var/1.txt"
  }
}

Debug Output

Both outputs are after running 1 apply with the relevant file

Output with plain text file

$ cat 1.txt && sha1sum 1.txt 
894fc3f56edf2d3a4c5fb5cb71df910f958a2ed8  -
4f459664a6b39e5f2cf595b37cfdfcb7d9740c17  1.txt
$ tf11 plan  --target module.docker-file-test
..
No changes. Infrastructure is up-to-date.

Output with a 2-byte binary file

cat 1.txt && echo && sha1sum 1.txt 
ñG
143fbaf9b82ba1b4f20faad9505e685e4d3639a4  1.txt
tf11 plan  --target module.docker-file-test
Terraform will perform the following actions:

-/+ module.docker-file-test.docker_container.docker-file-test (new resource required)
      id:                        "aba876dfa85d605266cabaadda63523db11bfa600d12c61c4731040b41593903" => <computed> (forces new resource)
      bridge:                    "" => <computed>
      gateway:                   "172.17.0.1" => <computed>
      image:                     "sha256:73acd1f0cfadf6f56d30351ac633056a4fb50d455fd95b229f564ff0a7adecda" => "sha256:73acd1f0cfadf6f56d30351ac633056a4fb50d455fd95b229f564ff0a7adecda"
      ip_address:                "172.17.0.26" => <computed>
      ip_prefix_length:          "16" => <computed>
      log_driver:                "json-file" => "json-file"
      must_run:                  "true" => "true"
      name:                      "docker-file-test" => "docker-file-test"
      restart:                   "no" => "no"
      upload.#:                  "1" => "1"
      upload.2067081083.content: "�G" => "" (forces new resource)
      upload.2067081083.file:    "/var/1.txt" => "" (forces new resource)
      upload.277341835.content:  "" => "\xf1G" (forces new resource)
      upload.277341835.file:     "" => "/var/1.txt" (forces new resource)


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

------------------------------------------------------------------------

Expected Behavior

The second plan should show No Changes, since the file on disk is matching the file on the container. This is important if you are uploading binaries to the container. In my case, this happens to be image files (logos/banners etc), which do not change, but give me dirty plans.

Actual Behavior

A dirty plan is generated.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. Add the attached 1.txt file to any docker_container using the same upload syntax as above.
2. Run a apply to make sure that the file uploads
3. Run another plan

I've seen the comment on the code:

// This is intentional. The container is mutated once, and never updated later.
// New configuration forces a new deployment, even with the same binaries.

but it applies unequally to binary/text files which is quite confusing.

Terraform Version

Terraform v0.11.0
+ provider.docker v0.1.0

Affected Resource(s)

Please list the resources as a list, for example:

• docker_container

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

There is no way for me to use the --device flag with the docker_container resource.

--device=[]: Allows you to run devices inside the container without the --privileged flag.

Link to docs: https://docs.docker.com/engine/reference/run/#additional-groups

Expected Behavior

There should be no empty string while mapping from map to slice

Actual Behavior

According to #29 (comment) the mapping is not correct

The following fix is proposed:

// mapTypeMapValsToStringSlice maps a map to a slice with '=': e.g. foo = "bar" -> 'foo=bar'
 func mapTypeMapValsToStringSlice(typeMap map[string]interface{}) []string {
-       mapped := make([]string, len(typeMap))
+       mapped := make([]string, 0)
        for k, v := range typeMap {
                mapped = append(mapped, k+"="+v.(string))
        }

hi,
if we compare Kubernetes provider support (https://www.terraform.io/docs/providers/kubernetes/index.html) versus Docker support ( https://www.terraform.io/docs/providers/docker/index.html), we see that the Docker provider supports no Swarm features.

In fact, most people who work with swarm are forced to write it as "inline". Is there any chance we can get support for primitives like Swarm init, join, service create/delete/update ? This would be super awesome. If we are able to do something like https://github.com/docker/docker.github.io/blob/master/swarm/configure-tls.md using Terraform, that would be mindblowing.

There are a lot of us using Docker Swarm in production and this is one of the reasons why we are delaying adopting terraform. If these primitives get supported in Terraform, a lot of us would straight away use Terraform and give up using the docker-compose.yml files.

This issue was originally opened by @jsuchenia as hashicorp/terraform#14982. It was migrated here as part of the provider split. The original body of the issue is below.

When configuring TLS connection to docker, ca_material can be optional client source
In case we can skip server verification (but still server can verify our key) - underlying library is handling this case when ca certificate is not present

Terraform Version

Terraform v0.9.6

Affected Resource(s)

Docker provider

Terraform Configuration Files

provider "docker" {
  host = "tcp://192.168.100.1:2376/"

  # ca_material   = "${var.ca_cert}"
  cert_material = "${var.client_cert}"
  key_material  = "${var.client_key}"
}

Debug Output

Error initializing Docker client: ca_material, cert_material, and key_material must be specified

Expected Behavior

Docker provider with valid key and cert but without ca present should work correctly.

Actual Behavior

Execution failed

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. Specify docker provider without ca_material
2. terraform apply

This issue was originally opened by @reppard as hashicorp/terraform#3989. It was migrated here as part of the provider split. The original body of the issue is below.

If I run 2 consecutive applies using the docker provider and image/container resources, the apply will fail because the container already exists. I would think that terraform would treat this much the same as other resources stored in a statefile and run the apply successfully without applying any modifications. Is this expected behavior?

This issue was originally opened by @iainvm as hashicorp/terraform#18292. It was migrated here as a result of the provider split. The original body of the issue is below.

Terraform Version

Terraform v0.11.7
+ provider.docker v0.1.1

Terraform Configuration Files

provider "docker" {
  host = "tcp://localhost:2376/"
}

resource "docker_image" "centos-box" {
  name = "url/to/image/centos-box:latest"
}

resource "docker_container" "app-server" {
  name  = "app-server-${count.index + 1}"
  count = 2
  image = "${docker_image.centos-box.latest}"

  ports {
    internal = 8443
    internal = 22
  }
}

tfstate

{
    "version": 3,
    "terraform_version": "0.11.7",
    "serial": 31,
    "lineage": "e82622ef-d1bb-21c7-2a3c-1483302ad337",
    "modules": [
        {
            "path": [
                "root"
            ],
            "outputs": {},
            "resources": {
                "docker_container.app-server.0": {
                    "type": "docker_container",
                    "depends_on": [
                        "docker_image.centos-box"
                    ],
                    "primary": {
                        "id": "45dc270d478567490bf8a6321484698def832479f61d36d31965c0b110036790",
                        "attributes": {
                            "bridge": "",
                            "gateway": "172.17.0.1",
                            "id": "45dc270d478567490bf8a6321484698def832479f61d36d31965c0b110036790",
                            "image": "sha256:ce2adb4a899f6c3fed335c25dca234a8e4dc9f4ec8bf7c53df170076a0feb09f",
                            "ip_address": "172.17.0.2",
                            "ip_prefix_length": "16",
                            "log_driver": "json-file",
                            "must_run": "true",
                            "name": "app-server-1",
                            "ports.#": "1",
                            "ports.51681950.external": "0",
                            "ports.51681950.internal": "22",
                            "ports.51681950.ip": "",
                            "ports.51681950.protocol": "tcp",
                            "restart": "no"
                        },
                        "meta": {},
                        "tainted": false
                    },
                    "deposed": [],
                    "provider": "provider.docker"
                },
                "docker_container.app-server.1": {
                    "type": "docker_container",
                    "depends_on": [
                        "docker_image.centos-box"
                    ],
                    "primary": {
                        "id": "2b4d2b6edc85a034a6c7074a3ca9a2c75288222bfb1d7bc9e3c1f5d67f38a77d",
                        "attributes": {
                            "bridge": "",
                            "gateway": "172.17.0.1",
                            "id": "2b4d2b6edc85a034a6c7074a3ca9a2c75288222bfb1d7bc9e3c1f5d67f38a77d",
                            "image": "sha256:ce2adb4a899f6c3fed335c25dca234a8e4dc9f4ec8bf7c53df170076a0feb09f",
                            "ip_address": "172.17.0.3",
                            "ip_prefix_length": "16",
                            "log_driver": "json-file",
                            "must_run": "true",
                            "name": "app-server-2",
                            "ports.#": "1",
                            "ports.51681950.external": "0",
                            "ports.51681950.internal": "22",
                            "ports.51681950.ip": "",
                            "ports.51681950.protocol": "tcp",
                            "restart": "no"
                        },
                        "meta": {},
                        "tainted": false
                    },
                    "deposed": [],
                    "provider": "provider.docker"
                },
                "docker_image.centos-box": {
                    "type": "docker_image",
                    "depends_on": [],
                    "primary": {
                        "id": "sha256:ce2adb4a899f6c3fed335c25dca234a8e4dc9f4ec8bf7c53df170076a0feb09furl/to/image/centos-box:latest",
                        "attributes": {
                            "id": "sha256:ce2adb4a899f6c3fed335c25dca234a8e4dc9f4ec8bf7c53df170076a0feb09furl/to/image/centos-box:latest",
                            "latest": "sha256:ce2adb4a899f6c3fed335c25dca234a8e4dc9f4ec8bf7c53df170076a0feb09f",
                            "name": "url/to/image/centos-box:latest"
                        },
                        "meta": {},
                        "tainted": false
                    },
                    "deposed": [],
                    "provider": "provider.docker"
                }
            },
            "depends_on": []
        }
    ]
}

Expected Behavior

$docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                             NAMES
2b4d2b6edc85        ce2adb4a899f        "/startup.sh"       21 minutes ago      Up 21 minutes       8443/tcp, 0.0.0.0:32782->22/tcp   app-server-2
45dc270d4785        ce2adb4a899f        "/startup.sh"       21 minutes ago      Up 21 minutes       8443/tcp, 0.0.0.0:32781->22/tcp   app-server-1

- "ports.*.external" should be either 32782 or 32781

Actual Behavior

- "ports.*.external" : "0"

Steps to Reproduce

- make conf.tf
- terraform init
- terraform apply

Additional Infomation

$docker version
Client:
 Version:      18.05.0-ce
 API version:  1.37
 Go version:   go1.10.2
 Git commit:   f150324782
 Built:        Wed May 16 22:27:45 2018
 OS/Arch:      linux/amd64
 Experimental: false
 Orchestrator: swarm

Server:
 Engine:
  Version:      18.05.0-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.10.2
  Git commit:   f150324782
  Built:        Wed May 16 22:28:17 2018
  OS/Arch:      linux/amd64
  Experimental: false

Update to Docker 18.03.1

• the refactoring #51 should be completed first
• moby/moby#35933 is fixed and tested with 18.03.1 on Mac
• implement changes until API 1.37