docker-compose up recreates container when config is unchanged

I am not clearly understand how docker-compose realizes when to recreate container or where not.
My case is:

docker-compose -f conf.yml up // Ok
docker-compose -f conf.yml up // xxx is up-to-date

Then I do:

  • Connecting to Docker-Machine via docker-py on OSX
  • Where is /var/lib/docker on Mac/OS X
  • Node ECS Task Not Crashing
  • Docker default CPU architecture doesn't match host's
  • Java Spring Hibernate application runs on local, but not in aws's ecs docker
  • Best practice: Python development environment with docker for mac
  • docker-compose -f /copy/conf.yml up // Recreating container
    

    But copy/conf.yml is same as conf.yml
    Why docker-compose recreates container, while it’s config is unchanged? Its only loaded from other path. How docker-compose handles this stuff?
    It must says “up-to-date”, if config is same, despite of config’s path (I know about –no-recreate flag, but I want to know how things works)

  • How with Vagrant, ansible and docker to get Linux dev machine as close as possible to production
  • Docker API call returns “server gave HTTP response to HTTPS client”
  • mysql_upgrade failed - innodb tables doesn't exist?
  • Rethinkdb container: rethinkdb process takes less RAM than the whole container
  • Is there any way to display container names in docker stats?
  • Official Dockerfile uses apt-get commands
  • One Solution collect form web for “docker-compose up recreates container when config is unchanged”

    If one folder is /app/conf.yml and the other folder is /app_copy/conf.yml, then you’ll find that docker creates two different “projects”, one for “app” and the other for “appcopy” (it removes non-alphanumeric characters and makes it all lower case). The project is the first part of each container name by default, it’s named $project_$service_$instance.

    If you specify the container name inside your docker-compose.yml, then docker-compose will recreate it if you have things like volume mounts to the current folder which would be different. Otherwise, if the compose files are truly identical, the source image hasn’t changed, and there are no externalities that would be different, then I’m not able to reproduce this one.

    Here’s an example without a fixed container_name:

    $ docker-compose -f docker-compose.test.yml up -d
    Creating test_testapp_1
    
    $ docker-compose -f test/docker-compose.test.yml up -d
    test_testapp_1 is up-to-date
    

    Below is what happens if you try to specify a container name in the compose file:

    $ pwd
    ..../test
    
    $ docker-compose -f docker-compose.name.yml up -d
    Starting unique_name
    
    $ docker-compose -f subdir/docker-compose.name.yml up -d
    Creating network "subdir_default" with the default driver
    Creating unique_name
    
    ERROR: for test  Cannot create container for service test: Conflict. The container name "/unique_name" is already in use by container 80b44bc94912b755cf2430b132fa6112f960e2752f69a357c27375bbc905ff76. You have to remove (or rename) that container to be able to reuse that name.
    
    $ mv subdir test
    
    $ docker-compose -f test/docker-compose.name.yml up -d
    unique_name is up-to-date
    
    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.