If you just run
docker-compose up -d again, it will notice the new container and the changed configuration and apply them.
(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
this destroyed the Mongo DB container… I cannot do that… again…
db: image: mongo restart: always
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.