docker_container volumes host_path ignored

[mavogel]

This issue was originally opened by @schlitzered as hashicorp/terraform-provider-docker#139. It was migrated here as a result of the community provider takeover from @kreuzwerker. The original body of the issue is below.

---

Terraform Version

Terraform v0.11.13

• provider.docker v1.1.1

Affected Resource(s)

docker_container

Terraform Configuration Files

resource "docker_container" "fdsafx_dev" {
  image   = "${docker_image.fdsafx_dev.latest}"
  name    = "fdsafx_dev"
  privileged = true
  entrypoint = [
    "/usr/sbin/init"
  ]
  volumes = {
    volume_name    = "www_fdsafx_test"
    read_only      = false
    host_path = "/Users/MyUser/tmp/docker_fdsafx/terraform/blarg/"
    container_path = "/www/fdsafx_test"
  }
}

Expected Behavior

container should have /Users/MyUser/tmp/docker_fdsafx/terraform/blarg/ mounted

Actual Behavior

container has /var/lib/docker/volumes/www_fdsafx_test/_data mounted

Steps to Reproduce

1. terraform apply

Important Factoids

running on MacOS useing Docker Desktop

from docker inspect:

        "Mounts": [
            {
                "Type": "volume",
                "Name": "www_fdsafx_test",
                "Source": "/var/lib/docker/volumes/www_fdsafx_test/_data",
                "Destination": "/www/fdsafx_test",
                "Driver": "local",
                "Mode": "rw",
                "RW": true,
                "Propagation": ""
            }
        ],

[github-actions]

This issue is stale because it has been open 60 days with no activity.
Remove stale label or comment or this will be closed in 7 days.
If you don't want this issue to be closed, please set the label pinned.

[github-actions]

This issue is stale because it has been open 60 days with no activity.
Remove stale label or comment or this will be closed in 7 days.
If you don't want this issue to be closed, please set the label pinned.

[mafredri]

In case anyone runs into this issue, as a work-around, it seems that removing volume_name allows host_path to work.

This issue could be fixed by disallowing both volume_name and host_path to be set since setting both doesn't make sense (a host path can't be named).

[matifali]

In case anyone runs into this issue, as a work-around, it seems that removing volume_name allows host_path to work.

This issue could be fixed by disallowing both volume_name and host_path to be set since setting both doesn't make sense (a host path can't be named).

Following this approach solved this for me.

[Junkern]

I read the official docker docs and looked into the provider codebase and found out what the problem is.
According to https://docs.docker.com/engine/reference/run/#volume-shared-filesystems when creating a volume

The host-src can either be an absolute path or a name value. If you supply an absolute path for the host-src, Docker bind-mounts to the path you specify. If you supply a name, Docker creates a named volume by that name.

To separate this "union" type in this provider, two values got introduced: volume_name and host_path.
And @mafredri was right: having both should not be possible.

The code actually is:

volumeName := volume["volume_name"].(string)
if len(volumeName) == 0 {
  volumeName = volume["host_path"].(string)
}

which leads to the case, that as soon as the volume_name is set, the host_path does not matter. (I assume that some users think that volume_name is simply an internally used value and set both. I would do that as well, to be honest).

How to fix:

• We could introduce a mechanisms (ConflictsWith) which checks whether both values are set and, if so it errors.
• Or we simply assume that when host_path is set and prioritize its value
• We move away from the two-values system and simply use a host-src, the same way as the docker documentation describes it, and simply pass the value do the docker client

I don't like option 2, and I think option 1 & 3 migh be breaking changes which would first need a warning with a new minor version and then the change with the major version.
However, I am not sure whether option 1 would really be a breaking change..

Any opinions of the people affected by this bug?

[matifali]

I would prefer option 1 with a link to docs that describe you can not use both of them at the same time.