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 dockerized java microservices efficiently
  • Minecraft Docker Image: game storage persistence
  • Docker container with HBA card
  • docker-machine - Error attempting heartbeat call to plugin server: connection is shut down
  • amazon beans talk docker Failed to build Docker image aws_beanstalk/staging-app not a directory
  • how to assign a group of logical Linux interfaces to a Docker container?
  • 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)

  • What is the syntax to pass Environment variables to docker image using spotify maven plugin?
  • Docker containers exiting without identifiable cause (Django web application)
  • when doing docker compose, is it possible to keep previous docker composition
  • Docker Machine Virtual Box Driver Issue
  • Dropbox in Docker
  • How can I connect to a server using python sockets inside a Docker container?
  • 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
    $ docker-compose -f up -d
    Starting unique_name
    $ docker-compose -f subdir/ 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/ 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.