Closed dave-mills closed 3 years ago
Thanks for sharing your experience, @dave-mills! docker-compose down
is a nuclear option -- it removes containers and networks as described in the docs. As we recently added to the install docs, we don't expect people to use down
unless they really do want to throw everything away. Could you please tell us more about why you are using down
?
If you don't want to throw everything away, using stop
should be sufficient. In fact, I can't even think of a case where a stop
is necessary. If you do a docker-compose up
, changes will be picked up:
If there are existing containers for a service, and the service’s configuration or image was changed after the container’s creation, docker-compose up picks up the changes by stopping and recreating the containers (preserving mounted volumes).
https://docs.docker.com/compose/reference/up/
That change you've made to your docker-compose
file changes the postgres storage from an anonymous volume to a bind mount. There is likely no problem with doing this for your specific install, you'll just need to make sure to carry this change through any updates to the base compose file. We can't use a bind mount in our core compose file because we don't know anything about the host's directory structure. Relative references are not supported on Windows. We could have used a named volume and if we were starting today that's likely what we would do. However, there isn't a safe way to migrate from an anonymous to a named volume so it's not a change we can make now with so many servers running off the stock docker-compose file.
@lognaturel Thanks! This is really useful, and helps me understand more about what's actually happening when I run docker-compose commands. I'd missed the distinction between down
and stop
in my docker learning.
Could you please tell us more about why you are using down?
The installation in question is on a university server, and the IT department said they would need to pause the server to take snapshots for backup purposes, so wanted to know how they could stop and restart ODK Central.
But I think the real answer is I didn't realise stop
was the better option! (I'd missed the added warning to the install docs)
That change you've made to your docker-compose file changes the postgres storage from an anonymous volume to a bind mount.
That makes sense, so that volume is now bound to ./files/postgres
. I guess that's why it persists when I burn it all down with docker-compose down
. The IT Services team were also happy that the database was now inside the main install folder, so they have an easier backup + restore process.
However, there isn't a safe way to migrate from an anonymous to a named volume so it's not a change we can make now with so many servers running off the stock docker-compose file.
I though the change probably wouldn't be a sensible thing for the main repo. Good to know why, and to learn more about different types of docker volume in the process :)
It sounds like a way forward for me is to fork this repo for the installation, so I can carry the change over across updates as you suggest.
Thanks again for the insightful reply!
(edit: formatting)
Great, I'm glad that was helpful!
In general, we invite you to start conversations on the forum because it has more reach. We can do triage there and file any issue(s) that come out of the conversation. Then there's a nice record for other users who might have similar questions. We'd also love to learn more about the types of projects you're involved in if you have a moment to introduce yourself.
I have installed ODK central on a few servers, and I always encounter the issue described here, where every
docker-compose down && docker-compose up
results in a new database volume being created.I tested a fix on 2 of our servers: in docker-compose.yml, update the postgres block's volumes path:
This fixes the issue on our servers. I'm afraid I don't quite know why (I'm not a docker expert), but I thought I should add this here in case someone knows why this fix might work and whether it's something that is generally applicable or not!