compose: docker-compose up seems to get the wrong image... ?

I am doing something pretty simple. I have a docker-compose.yml file:

  tsdb:
    build:
      context: ./tsdb_prod
    ....

and in the Dockerfile in that directory I have:

FROM influxdb:0.13
COPY file_prod /etc/file_prod

and I have the file_prod file in that directory.

running docker-compose build with --no-cache to rebuild my image after changes:

0s 👍  $> docker-compose build --no-cache

[snip]

Building tsdb
Step 1 : FROM influxdb:0.13
 ---> c7a58aa7ce3b
Step 2 : COPY file_prod /etc/file_prod
 ---> ff2aa86452fd
Removing intermediate container 91c3eafd328c
Successfully built ff2aa86452fd
2s 👍  $> docker run --rm -it ff2aa86452fd /bin/bash
root@0e660d6a1784:/# ls /etc/file_prod
/etc/file_prod

But when I do my docker-compose up I see

2s 👍  $> docker-compose up
Recreating task_tsdb_1

[snip]

tsdb_1   | run: open server: open service: open "/etc/file_prod": no such file or directory

I’m pretty new to Docker. I’m sure I’m missing something stupid here. Is it building one image but starting another? I do see

2s 👍  $> docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                      PORTS               NAMES
f742363da3aa        58fcf34dd924        "/entrypoint.sh influ"   44 minutes ago      Exited (1) 34 minutes ago                       task_tsdb_1

[snip]

Not sure what’s going on with that. I would appreciate anyone’s insight.

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 32

Most upvoted comments

Weird thing is, if I run the app with docker run, it’s fine. If I run it with docker-compose up, it’s not. It’s almost as if docker-compose were picking the wrong image to spin the container from - an intermediary image, maybe?

pedrovanzella on May 25, 2016

I had this issue. For anybody getting a similar thing, I realised I was accidentally binding the local folder (using docker-compose) as a volume into the docker container like this:

  volumes:
    - ".:/home/node"

Which I must have done early-on, trying to get live-reload working or something. This was confusing the heck out of docker-compose and was showing a “container” version of the filesystem when putting RUN ls -al statements in Dockerfile and a “host” version of the filesystem when using CMD ls -al resulting in completely different outputs. Check to make sure you aren’t doing something similar.

peabnuts123 on May 10, 2019

Leaving a comment here in case it helps someone else. docker-compose stop followed by docker-compose build and docker-compose start isn’t good enough, you have to docker-compose down, docker-compose build and docker-compose up because down/up is when docker actually maps images to containers. If you don’t use down/up docker-compose will use the old pre-existing containers.

This is probably obvious to seasoned docker users, but a casual like me didn’t understand this nuance and it very well could be the trap many of the commenters on this thread are accidentally falling into.

patrick-mcdougle on Oct 6, 2020

@aanand awesome, it worked! Summary of changes:

New line in .env:

# /var/www/development-site/docker
COMPOSE_PROJECT_NAME=development-site

# /var/www/production-site/docker
COMPOSE_PROJECT_NAME=production-site

Removal of image and container_name from docker-compose.yml

Images and containers no longer conflict and I see developmentsite_web_1 and productionsite_web_1 in docker ps. Awesome!

kachkaev on Jul 25, 2016

@kachkaev This isn’t a bug, and has nothing to do with caching.

Both your directories are named the same thing (docker), so when you run docker-compose up in either directory you’re working on the same project. Each time you’re updating the configuration of the same service (web) to change both the image name and container name.

It looks like what you actually want is two separate apps, each with its own image and container. In that case, I suggest doing the following:

Either rename each directory so they’re different or use the --project-name option or COMPOSE_PROJECT_NAME environment variable to set a different project name for each app. For example, myappdev and myappprod.
Remove the container_name option from both Compose files - it’s unnecessary.

If you run docker-compose up in both directories, you should now have two containers: myappdev_web and myappprod_web.

aanand on Jul 25, 2016

I’m having the same problem here.

Further, if I docker run image, the file is there. If I docker-compose up, the file is not there.

Exact same behavior on the latest beta on OSX and on Windows.

PS C:\Users\pedro> docker-compose version
docker-compose version 1.7.1, build 0a9ab35
docker-py version: 1.8.1
CPython version: 2.7.11
OpenSSL version: OpenSSL 1.0.2d 9 Jul 2015

pedrovanzella on May 24, 2016

Can you try running docker-compose down -v --rmi then run build / up again?

shin- on May 18, 2016