How to implement changes made to docker-compose.yml to detached running containers

If you just run docker-compose up -d again, it will notice the new container and the changed configuration and apply them.

But:

(without destroying anything)

There are a number of settings that can only be set at container startup time. If you change these, Docker Compose will delete and recreate the affected container. For example, links are a startup-only option, so re-running docker-compose up -d will delete and recreate the web container.

this destroyed the Mongo DB container... I cannot do that... again...

db:
    image: mongo
    restart: always

Add a volumes: option to this so that data is stored outside the container. You can keep it in a named volume, possibly managed by Docker Compose, which has some advantages, but a host-system directory is probably harder to accidentally destroy. You will have to delete and restart the container to change this option. But note that you will also have to delete and restart the container if, for example, there is a security update in MongoDB and you need a new image.

Your ideal state here is:

• Actual databases (like your MongoDB container) store data in named volumes or host directories
• Applications (like your Rails container) store nothing locally, and can be freely destroyed and recreated
• All code is in Docker images, which can always be rebuilt from source control
• Use volumes as necessary to inject config files and extract logs

If you lose your entire /var/lib/docker directory (which happens!) you shouldn't actually lose any state, though you will probably wind up with some application downtime.

Just docker-compose up -d will do the job.

Output should be like

> docker-compose up -d
Starting container1 ... done

> docker-compose up -d
container1 is up-to-date
Creating container2 ... done

As a side note, docker-compose is not really for production. You may want to consider docker swarm.