3 ms·

I really feel like Docker Compose and Swarm are underrated. For running groups of related containers during development, Compose is wonderful - Compose files a

I really feel like Docker Compose and Swarm are underrated. For running groups of related containers during development, Compose is wonderful - Compose files are simple and easy to understand even if you've never seen one before. Swarm is also good for small-scale production deployments - it's just so simple to deploy and update. "secrets" and "configs" are also really useful, but of course I see the appeal of a centralised system such as Vault for complex deployments. I've never tried to use Swarm it at scale, so don't know what kind of issues you might face that k8s would solve.

bkircher 7y ago
Can’t I just do all what docker-compose does with a Makefile and a couple of docker network create docker run and so on? With much less magic involved?
- thinkmassive 7y ago
  The recommended approach for managing groups of multiple containers with podman seems to be using pods (hence the name), which can be managed by Makefiles as you describe.
- gravypod 7y ago
  The benefit is standardization. If every team you join has a `docker-compose.yml` to run a local development environment you know exactly what it is, how to add things to it, etc. If every team you join has a custom solution for an extremely lightweight development environment than you need to be brought up to speed every single time. It's a similar argument to "Why do you need Makefiles when you can just write a bunch of bash files and a meta-bash file to execute each sub script based on the stat results of a list of files?"
- nickjj 7y ago
  > Can’t I just do all what docker-compose does with a Makefile There's a lot of value in just being able to run a set of unified Docker Compose commands and have things work the same in every case with the same YAML configuration. But technically yes you could replicate that behavior, however Docker Compose does a bunch of pretty nice things, like when you run docker-compose up it will intelligently recreate containers that changed but leave the others untouched. Then there's the whole concept of override files, etc.. It would take a fair amount of scripting to emulate all of that behavior along with getting all of the signal processing and piping multiple services to 1 terminal output acting well. Even today Docker Compose has issues with that after years of development. You should run docker-compose with --verbose one day just to see what really happens under the hood. Compose is doing a lot. For example I wrote about this a while back. It also includes an example output of running a single service app with --verbose: https://nickjanetakis.com/blog/docker-tip-60-what-really-happens-when-you-run-docker-compose-up https://nickjanetakis.com/blog/docker-tip-60-what-really-hap...
- munmaek 7y ago
  This is like asking "can't I just use a cellar + ice instead of using a fridge?". Yes, through a lot of scripting, you can emulate docker-compose. But compose actually handles a lot of things, to the point that manual scripting doesn't really make any sense. I don't understand how people manage multiple related containers -without- compose. It makes things so much easier.
notduncansmith 7y ago
Among other responsibilities, I currently manage a Docker Swarm deployment that serves between 10k and 100k users. I can’t compare to k8s since I lack experience with k8s, but I can say that ops on this service take approximately 1% of my time per month. After the initial learning curve, Swarm has proven quite stable and easy to work with. 10/10 would deploy with again (in fact, I will within the next week).

bkircher 7y ago

Can’t I just do all what docker-compose does with a Makefile and a couple of docker network create docker run and so on? With much less magic involved?

thinkmassive 7y ago
The recommended approach for managing groups of multiple containers with podman seems to be using pods (hence the name), which can be managed by Makefiles as you describe.
gravypod 7y ago
The benefit is standardization. If every team you join has a `docker-compose.yml` to run a local development environment you know exactly what it is, how to add things to it, etc. If every team you join has a custom solution for an extremely lightweight development environment than you need to be brought up to speed every single time. It's a similar argument to "Why do you need Makefiles when you can just write a bunch of bash files and a meta-bash file to execute each sub script based on the stat results of a list of files?"
nickjj 7y ago
> Can’t I just do all what docker-compose does with a Makefile There's a lot of value in just being able to run a set of unified Docker Compose commands and have things work the same in every case with the same YAML configuration. But technically yes you could replicate that behavior, however Docker Compose does a bunch of pretty nice things, like when you run docker-compose up it will intelligently recreate containers that changed but leave the others untouched. Then there's the whole concept of override files, etc.. It would take a fair amount of scripting to emulate all of that behavior along with getting all of the signal processing and piping multiple services to 1 terminal output acting well. Even today Docker Compose has issues with that after years of development. You should run docker-compose with --verbose one day just to see what really happens under the hood. Compose is doing a lot. For example I wrote about this a while back. It also includes an example output of running a single service app with --verbose: https://nickjanetakis.com/blog/docker-tip-60-what-really-happens-when-you-run-docker-compose-up https://nickjanetakis.com/blog/docker-tip-60-what-really-hap...
munmaek 7y ago
This is like asking "can't I just use a cellar + ice instead of using a fridge?". Yes, through a lot of scripting, you can emulate docker-compose. But compose actually handles a lot of things, to the point that manual scripting doesn't really make any sense. I don't understand how people manage multiple related containers -without- compose. It makes things so much easier.

notduncansmith 7y ago

Among other responsibilities, I currently manage a Docker Swarm deployment that serves between 10k and 100k users. I can’t compare to k8s since I lack experience with k8s, but I can say that ops on this service take approximately 1% of my time per month. After the initial learning curve, Swarm has proven quite stable and easy to work with. 10/10 would deploy with again (in fact, I will within the next week).