[INTPenis]

I started using quadlets for new system designs a month ago and I feel like I'm neck deep in it now.

My conclusion is that there is absolutely no reason to stop using docker-compose if your developers are comfortable running one command, on one file, in one git root.

Quadlets are basically docker compose, in systemd. They've finally done it, systemd has it all and now it even has docker compose. ;)

That's really all it is in practice. I'm going to continue using it because I'm a RHEL kinda guy, but don't make it up to be magic.

[cyberax]

The next step: systemkubed.

[runiq]

Nah, we got that already. Quadlet can handle k8s manifests.

https://man.archlinux.org/man/quadlet.5.en#Kube_units_%5BKub...

[INTPenis]

Yes but when is someone going to add logic on top of this to make it a full blown distributed container orchestrator?

Could it be done with systemd and dbus? Can dbus be distributed among several systems like mmc on Windows? I have no idea, just some questions that popped into my head lately.

[alexlarsson]

https://github.com/containers/bluechi

[INTPenis]

Fett!

[sleepybrett]

This might be nice, I've seen a couple of teams that instead of using a local `kind` or other local cluster to test their continers they make a docker compose and then do a bunch of work turning that into kube manifests, then maintain them separately.

[broknbottle]

see bluechi aka hirte

https://www.redhat.com/en/blog/introducing-hirte-determinist...

https://github.com/containers/bluechi

[all2]

I've got a home server that runs docker compose as a service in systemd at startup.

I'm naive, whats the difference between doing that and using these "quadlets"?

[aaravchen]

I'm in a similar situation and I've been looking at quadlets a lot.

The approach is quite different from docker-compose and not really a substitute. It makes your individual containers into systemd services in an easier way than creating a unit file that calls `docker run`. But you still have to manually define networks in .network files, and configure all your dependencies in unit file syntax.

If you're very familiar with writing in systemd unit files, or really really want to use systemd to manage all container-related objects individually instead of having your container daemon do most of the work and a single compose file per group of related objects, you should consider switching. But in my experience there's little to be gained, a LOT to be lowt, and a lot of work to do the switch.

[Dx5IQ]

Why do you even need systems if you're using docker-compose? As long as your docker daemon starts up, docker compose can do the rest

[otabdeveloper4]

> finally

Systemd had dependencies between services and containers since forever.

The only difference here seems to be podman instead of systemd-nspawn.