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:

  • How to disable all network connections inside Docker?
  • Push docker image to remote server
  • Docker publishing ports to multiple IPs
  • Why declare like “var _ I = T{}” and “var _ I = &T{}” continuously in golang?
  • Docker: understanding ENTRYPOINT and CMD instructions
  • Docker mesosphere/chronos container fails immediately after launch
  • 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)

  • Docker Compose shared CPUs
  • How to use docker v1 repository
  • How do I expose port from Container to host?
  • link docker containers and use wildcard subdomains
  • Port published via Docker — can't connect
  • Docker - misunderstanding about the execution and volume
  • 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.