[oneplane]

Docker compose is a dead end AFAIK, it's not deprecated or anything, but the community power behind it has essentially moved to other things (Kubernetes, but also wasmer, nomad, skaffold).

While Docker Desktop / Podman / Rancher Desktop combined with stuff like Skaffold aren't exactly a drop-in replacement for docker-compose, it does do a much better job at bringing up and tearing down entire compositions while re-using existing packaging and access controls.

If you are running docker-compose for non-development things, it might be a different story; it might be suitable for non-GitOps things, but as posted elsewhere, at that point you're better off using something like systemd.

When composing really small setups I either do this with a shell script (think 10 lines including trapping exits) or a systemd unit. Whenever it needs to be bigger I nearly always end up with an actual scheduler (K8S, Nomad) and GitOps because you can't really deliver something maintainable, available and durable anymore without it (well... I suppose if you have only 1 project to deliver, forever, you could manually manage it).

It does get a whole lot easier when you have a common foundation you can re-use. Spinning up an entire stack with security, monitoring, alerting, automatic rollouts/rollbacks for even the smallest project is just single-digit minutes work now.

Pulling in some other factors: how sharable/collaboratable is something these days if it is not built on similar enough technologies and modules? A solo yolo project might not care much about this, but when was the last time someone asked for software that is risky and not durable?

[theteapot]

> Docker compose is a dead end AFAIK ..

What? I'm not involved and don't follow closely but pretty sure it's about as dead as docker itself. I.e. not dead. There was commits 8hrs ago -- https://github.com/docker/compose/. Not sure who did that if not "the community".

[SOLAR_FIELDS]

It’s not a dead end at all. It serves a specific purpose - if you need to have a packaged deliverable that consists of several (3-8) containers, and you want your end users to be able to easily deploy that deliverable, there is no better solution that I am aware of over docker-compose.

I’m not sure why OP feels that way, but I’ll just give two examples of great FOSS projects that live on the bleeding edge that I work with every day that offer docker compose deliverables as their #1 way to get going in prod:

1. Supabase: https://github.com/supabase/supabase/blob/master/docker/dock...

2. Netmaker: https://github.com/gravitl/netmaker/blob/master/compose/dock...

[seiferteric]

Not sure but I think OP is conflating docker compose with docker swarm. Compose to me is just a simple way to define a set of containers and their startup parameters.

[SOLAR_FIELDS]

I will say that compose does go a slight step beyond startup parameters - it bundles networking up and says that containers can talk to other containers under certain circumstances.

So it’s not quite a simple specification. It’s capable of some quite strange, interesting and possibly esoteric things.

[vntok]

Have a look at the contributors graph, it's pretty self-explanatory: https://github.com/docker/compose/graphs/contributors

Out of the 100 people listed, I counted maybe 8 tops who committed at least a few times in 2022?

[theteapot]

That seems pretty normal for a not-dead project. And anyway lack of commits is more a proxy for stable as opposed to not actively used by a wide audience of software developers.

When the repo is archived, maybe that would serve as a basis for a "dead project" argument.

[smcleod]

I really don't think this to be the case, they're for different purposes. docker-compose is simple and useful for running things on a single machine, e.g. in a VM, a home server, local machine etc..., Kubernetes is for scheduling, deploying and scaling things on many servers, cloud platforms etc.... Both work with containers - but in different situations for different purposes.

[solarkraft]

It's polarizing to call it dead, I'd say it's very much not, but it's fairly clear that the Docker people would rather have you using their follow-up project Swarm (which I think is supposed to be something like Kubernetes lite?). A major example of this is the ability to define resource limits being removed from docker compose V3 files unless you run it in swarm mode (which is mostly compatible).

[KronisLV]

> Docker compose is a dead end AFAIK, it's not deprecated or anything, but the community power behind it has essentially moved to other things (Kubernetes, but also wasmer, nomad, skaffold).

> While Docker Desktop / Podman / Rancher Desktop combined with stuff like Skaffold aren't exactly a drop-in replacement for docker-compose, it does do a much better job at bringing up and tearing down entire compositions while re-using existing packaging and access controls.

I don't know about this: in my experience the mentioned alternatives are generally way more complex and cumbersome to initially set up, for smaller projects.

I've seen successful projects use Docker Compose locally for all of the dependencies that need to run in containers (sometimes the apps run locally, for easier debugging, other times they also run in containers for no need to setup a runtime). I've even seen Docker Compose be used in production for projects that don't need to scale that much - just one server in which these containers run not that dissimilarly from what you might get with systemd services on a single node.

And when the need to scale out finally arises, then something like Docker Swarm (which uses the Compose specification) has been enough in the majority of cases, when you don't need anything too fancy (e.g. network partitioning, a la Istio/Kiali). It's extremely simple to setup and works really well, especially with something like Portainer. In addition, its integration with Ansible is also pretty great - though I'd advise Ansible in most cases in general, when you manage the underlying servers.

And I know that many claim that Swarm is dead - though in my eyes it's also basically feature complete and still gets new releases and bug fixes alongside Docker (which others claim is also dead); a bit of caution and having migration paths (e.g. Kompose) doesn't hurt, of course. When you do need (or desire to) run something more "current", then Nomad becomes sufficient on the servers, but I haven't had the need to run it locally, ever - since your environment descriptions will still be reasonably simple, you can just use Docker Compose locally and the HCL equivalent on servers, provided that you have dev/test/staging environments before prod to test everything out on, even if this is a drawback.

If you do decide to go with Kubernetes, then in my experience k0s, K3s (developed by Rancher) or even MicroK8s are all excellent starting points, but at that point you'll probably also want Helm charts and will essentially need something like Skaffold locally. When you get to that point, however, I've found that dealing with the complexity of Helm charts and running Kubernetes locally has more overhead than just using Swarm.

> It does get a whole lot easier when you have a common foundation you can re-use. Spinning up an entire stack with security, monitoring, alerting, automatic rollouts/rollbacks for even the smallest project is just single-digit minutes work now.

This is an excellent point, however! Maybe the DevOps cultures I've seen haven't been strong enough, though, since this has never really been the case in my experience and each service had a bit of custom work to be done for these aspects.

> Pulling in some other factors: how sharable/collaboratable is something these days if it is not built on similar enough technologies and modules? A solo yolo project might not care much about this, but when was the last time someone asked for software that is risky and not durable?

Here's a counterpoint - while many out there might be in the sweet spot where they can just pay someone else to give them a managed Kubernetes cluster, what about those who can't? What about those who decide to use Kubernetes, but have to host and upgrade their own clusters? It can easily become less durable and more risky, especially if your DevOps/Ops people aren't familiar with all of the nuances of Kubernetes.

Right tool for the job and all. Sometimes it's a great choice, other times it's risky.