Sharing volumes (via docker-compose) errors.

[richburdon]

From the command line, everything works, from docker-compose, I have the following hello-world example (would be really useful if somewhere in the docs there were examples):

services:
  test_container:
    build:
      context: .
      dockerfile: Dockerfile-container
    volumes:
      - /usr/share
  test_client:
    build:
      context: .
      dockerfile: Dockerfile-client
    volumes_from:
      - service:test_container:ro

Dockerfile-container:

FROM busybox
ENV DIR=/usr/share
RUN mkdir $DIR
RUN echo $(date) > $DIR/timestamp.txt
RUN cat $DIR/timestamp.txt
VOLUME $DIR

Dockerfile-client

FROM busybox
ENV DIR=/usr/share
VOLUME $DIR

"docker-compose build" returns OK.
"docker run volume_test_container cat /usr/share/timestamp.txt" prints the timestamp as expected.
"docker-compose start" returns OK.

But:

1. "docker-compose up" throws internal errors:

Recreating 98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_volume_test_container_1

ERROR: for test_container  No such image: sha256:249cac03be97d189d297fae85bd69df87264670a65d7d164b8e77a27e530da8b
Traceback (most recent call last):
  File "/usr/local/Cellar/docker-compose/1.7.1/libexec/bin/docker-compose", line 9, in <module>
    load_entry_point('docker-compose==1.7.1', 'console_scripts', 'docker-compose')()
  File "/usr/local/Cellar/docker-compose/1.7.1/libexec/lib/python2.7/site-packages/compose/cli/main.py", line 63, in main
    log.error(e.msg)
AttributeError: 'ProjectError' object has no attribute 'msg'

2). No combination of magic will enable the "client" container to see the contents of the "container"s share.

[shin-]

I tried reproducing this issue with the excerpts you provided, but everything seems to be working just fine. One thing I see is that your up command is trying to recreate a container that has failed several times, given the very long prefix it was given:

Recreating 98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_98147d3b76d6_volume_test_container_1

Without a full account of what has happened before getting to that point, it's hard to pinpoint the issue, but at that point it seems like it would be a good idea to clean up the containers using docker-compose down. If that doesn't help, please let me know.

[richburdon]

Hi @shin-

Thanks "docker-compose" down worked; I was repeatedly trying "docker rmi -f XXX" which I thought would be a clean reset?

Now that up is working, #2: I still can't find a way to have my "client" be able to access the volume defined by the "container." Again works fine by command line (per docs), but I seem to be missing something from my docker-compose.yml. Can you suggest a way to debug?

My container's inspect has:

            "Volumes": {
                "/usr/share": {}
            },

And I can "docker run ls" and view the timestamp test file that is created by the container's Dockerfile.

But the client doesn't see this (and I'm not entirely sure from the docs if I need to do anything other than define volumes_from above).

Thanks again for the quick feedback.

[shin-]

docker rmi only removes images, the issue you had was caused by a faulty container.

As for the volume's visibility, things should work fine based on the info you provided. I added a command: cat /usr/share/timestamp.txt line to the test_client section of your sample YAML file and I can see the file's content printed in the logs.

$ docker-compose up
Starting repro3557_test_container_1
Recreating repro3557_test_client_1
Attaching to repro3557_test_container_1, repro3557_test_client_1
test_client_1     | Tue Jun 7 00:10:57 UTC 2016
repro3557_test_container_1 exited with code 0
repro3557_test_client_1 exited with code 0
$

Is your actual usecase significantly different? Can you reproduce the issue with the stripped-down version you shared here?

[richburdon]

• re "docker rmi" (agh yes, thanks).
• re usecase: this is actually my ultra stripped down example -- trying to understand the concepts.
• I added the command attribute to the YML file -- that worked. When I run the test_client image afterwards the volume isn't visible. ("docker run volumes_test_client cat /usr/share/timestamp.txt")

I think I got myself confused -- let me see if I have this straight: docker-compose both builds the images (when a build declaration is present) and runs new containers. Volumes persist after the container has exited (which is why the client can access the terminated volume container). But if I just issue "docker run" against the image (volumes_test_client) it's going to create a brand new container that isn't automatically connected to any volume, right?

So, of course (now) I have to add --volumes-from to restart a new container that references the same volume from a previous container.

docker run --volumes-from=volumes_test_container_1 volumes_test_client cat /usr/share/timestamp.txt

Makes sense now -- thanks very much.