4 ms·
I use it a fair bit for development, provides a seemingly simple way to keep things organized and do 'infra-as-code' and have your ducks in a row with reproduci
by andbberger 8y ago
I use it a fair bit for development, provides a seemingly simple way to keep things organized and do 'infra-as-code' and have your ducks in a row with reproducible stack deployments, without the overwhelming overhead of k8s.
It's an absolute dumpster fire though. A serious convoluted mess. They try to indelicately cram something with incredible intrinsic complexity into a happy little (incredibly leaky) abstraction.
docker compose is really what I want, simple service management on one machine. Except, it can't do really basic shit like restart services (this isn't all that obvious at first). So soon you'll find that you need to use docker swarm on the one node, which is similarly chock full of inexplicable and unforeseeable shortcomings.
docker swarm/compose is an interim step on your journey to a better solution. in my judgement it's fine while you're developing your core apps. but once you need to do get serious and go into production, it's time to find a big boy tool
- ngrilly 8y agoI did the same thing. Docker Compose was what I wanted for a single-machine deployment, but I soon discovered it was unable to manage a rolling deploy (start new containers before stopping the old ones). So I switched to Docker Swarm on a single node, but I have to agree there is a lot of unexpected shortcomings. I'd like it to be more polished. And I'd like Docker Compose and Docker swarm mode to converge/merge at some point. I guess the "big boy tool" you adopted after that is k8s?
- andbberger 8y agoNo I never got the point of needing the big boy tool. But it would have been k8s.