And if you just want to restart one service? Well you have to run 4 commands[0] in order to properly do it...
And what the author was saying about needing to "template" the YAML files is also true. In the past, when shipping an Open Source library for others to use, we had to wrap Docker Compose in a CLI that generates the YAML file and then invokes Docker Compose for you. (See it here[1][2][3])
It sucks and this library definitely solves a real problem!
0: https://stackoverflow.com/questions/31466428/how-to-restart-...
1: The code: https://github.com/lunasec-io/lunasec/blob/master/js/sdks/pa...
2: The package it lives in: https://github.com/lunasec-io/lunasec/tree/master/js/sdks/pa...
3: The docs for the wrapped CLI: https://www.lunasec.io/docs/pages/overview/demo-app/overview
In Docker Compose v2 they had a more sophisticated "depends on" model with health checks, but they removed it in v3. The docs say something about Docker Swarm so I'm guessing they removed that in order to try to make v3 syntax work for clusters too.
The real tragedy here is that Kubernetes won, but we're still stuck with Docker Compose trying to be the same thing.
I hope your tool can help change this annoying status quo!
Care to elaborate? The SO answers seem to indicate it can be done in a single command, and my personal experience confirms that.
Are you perhaps also including pulling new images, rebuilding local Dockerfiles, etc etc as part of the “restart service” process?
Restarting one service isn't 4 commands.
I mostly like docker-compose just fine, but this is an annoyance & when I first started using docker-compose some years back I definitely lost more time than I would have liked trying to figure out why some change I'd just made didn't seem to have applied. I feel like destroying/creating containers is pretty cheap (that's one of the great things about containers!), so I'm not sure why docker-compose behaves this way. I presume it's for historical reasons and they don't feel comfortable changing it because of backwards compatibility.
What we were struggling with were "conditional services" like running Integration Tests. We only wanted to add that container to the cluster when we wanted to run the tests.
Same with the "demo" mode we added. That spins up an Nginx container with an example front-end app.
It's theoretically possible to define all of the containers in one big Docker Compose config and then turn them on/off with env variables per environment, but it's just hellish to debug. In fact, I suspect that's what the engineer that wrote those started with before getting frustrated with spaghetti.
Sometimes there is just no winning with the computers lol
Edit: Answering the "it isn't 4 commands" bit -- if you just restart a container it won't pick up changes to the Docker Compose config. You have to remove it an add it back to the cluster.
You could keep the YAML format and extend it, and still write compose files as pure Python.
I'm not sure how that would work with the whole "lifecycle hooks" you've mentioned a few times, but maybe it would be easier than trying to compete with Docker Compose yourself by simply wrapping it.
I posted in another comment here too but we wrote a bunch of code to deal with programmatic generation of Docker Compose files, and it was really sweet to use! I've honestly thought about making that code[0] a stand-alone library because of how valuable it was.
0: https://github.com/lunasec-io/lunasec/blob/master/js/sdks/pa...
While it's probably fine for most of the use cases you're predicting, if someone who isn't quite familiar with Python's gotchas decides to subclass, or modify one of the items at runtime, it will be a tricky thing to troubleshoot. Even though that is a rite of passage for Python developers, it's probably best to not have examples that could set them up for weird bugs.
edit: I was talking about mutable types at the top level of a class, and somehow left that out.
Classes in and of themselves are great, but having lists and dicts defined at the top level can cause problems.
How tied is it to the Docker daemon?
Instead of Docker, could one use podman, which doesn't need root.
It's docker-compose compatibility is tied up in essentially re-implementing/emulating that, which partially defeats the purpose.
My main need for the daemon component is https://github.com/nginx-proxy/acme-companion which listens to docker events to know when a new service is available to proxy.
I've managed to never touch a Kubernetes yaml thanks to it.
I am the author and have used it at a FAANG previously and now more recently at my startup to manage large, complex kubernetes and terraform managed infrastructure.
