4 ms·
> In addition, I'd never recommend Docker Compose to web developers that rely on databases, as quirks with it have caused many a volume-only container to be des
by nickstinemates 11y ago
> In addition, I'd never recommend Docker Compose to web developers that rely on databases, as quirks with it have caused many a volume-only container to be destroyed and rebuilt, thus defeating the purpose.
Can you point me in the direction of a bug report or a more concrete example? I'd like to make sure we follow up.
- girvo 11y agoSome of it is insurmountable without having some way of marking a container in the docker-compose.yml as "never destroy this!". It's a UX thing more than a bug, although there was two cases where "docker-compose up" destroyed and rebuilt a volume-only container that was in the docker-compose.yml -- unfortunately it was difficult to replicate so we didn't send a bug report through. The big thing is that using it on OSX with boot2docker means the cache can get confused, and so to get it to pick up config file changes (say, changes to an nginx config that are brought into the container) or some Dockerfile changes requires a "docker-compose rm && docker-compose build --no-cache", which of course will delete the volume-only container unless you're aware enough of the need to name the container you want to rebuild; as I said, it's more a UX issue than a bug, in my opinion. In terms of fixes, ideally I'd like to see a way of marking a container as "volume-only" -- this would then mean a "docker-compose rm" would not remove it, and "docker-compose up" would never rebuild it.