Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Quadlets might make me finally stop using docker-compose

major.io

Post reply on HN
Print view View original

111–120 of 212 posts

Re: Quadlets might make me finally stop using docker-compose

#111

Post by prmoustache »

magicalhippo wrote: post #106
prmoustache wrote: post #70

Earlier quoted context omitted.

> Podman supposed to be drop-in replacement for docker but - last try (4 months ago) of podman to run our development docker containers fails to build so i think Podman is still far away from docker replacement. I'd be curious what failed to build under podman. I have been using podman as a replacement for docker for the last 3 years and haven't found any blocker. Sometimes you can't reuse a docker-compose file share…

> Sometimes you can't reuse a docker-compose file shared by a third party project straight away without adaptation So not a drop-in replacement then...

4 points:

1. Most of the issues I had that forced me to adapt a docker-compose was because I was using podman rootless and most people build docker-compose file with docker running as root in mind. mostly to have access to privileged ports. I guess running podman under root would have solved this but one of the reason I switched to podman in the beginning was for the rootless capability. In a way this wasn't much different than modifying a deployment to work with docker in rootless mode.

2. part of the appeal of using podman is its compatibility with kubernetes yaml file so you tend to quickly switch away from docker-compose anyway. Also for self hosting, the systemd approach was more elegant, even before the quadlets support.

3. One would argue that docker-compose != docker/moby engine.

4. docker-compose has introduced breaking changes in its history which meant adapting your compose file or add flags at runtime such as `docker-compose disable-v2`

EDIT: adding points

Re: Quadlets might make me finally stop using docker-compose

#112

Post by 0xC0ncord »

arisudesu wrote: post #74

The syntax and examples in the article assumes usage of SystemD as service manager. Does it work on distros without SystemD too? Docker-compose does. I also do not understand separation of services to different files. Is it supposed to be more convenient? With docker-compose, the whole application stack is described in one file, before your eyes, within single yaml hierarchy. With quadlets, it's not. Lastly, I do not…

Quadlet is specific to systemd. It's actually just a systemd generator that looks for related files in /etc/containers/systemd or the user's ~/.config/containers/systemd to generate units from that can then be started as services. When you create or edit a file here, you then do 'systemctl daemon-reload' which re-invokes all systemd generators, quadlet included.

Re: Quadlets might make me finally stop using docker-compose

#113

Post by crabbone »

I never understood the appeal of docker-compose (you can accomplish roughly the same thing by having a Shell script that calls docker client, but skipping the Python clown fiesta with dependencies, environments etc.)

Quadlets seems not exactly a replacement for the function docker-compose was supposed to perform though, or am I wrong? It seems like its target audience is administrators who are supposed to run containers as systemd services (questionable choice, but probably there are people who want that)...

What am I missing?

Re: Quadlets might make me finally stop using docker-compose

#114

Post by shortrounddev2 »

crabbone wrote: post #113

I never understood the appeal of docker-compose (you can accomplish roughly the same thing by having a Shell script that calls docker client, but skipping the Python clown fiesta with dependencies, environments etc.) Quadlets seems not exactly a replacement for the function docker-compose was supposed to perform though, or am I wrong? It seems like its target audience is administrators who are supposed to run contain…

Shell scripts suck to write and bash/zsh is a terrible language to have to deal with

Re: Quadlets might make me finally stop using docker-compose

#115

Post by d_watt »

crabbone wrote: post #113

I never understood the appeal of docker-compose (you can accomplish roughly the same thing by having a Shell script that calls docker client, but skipping the Python clown fiesta with dependencies, environments etc.) Quadlets seems not exactly a replacement for the function docker-compose was supposed to perform though, or am I wrong? It seems like its target audience is administrators who are supposed to run contain…

> I never understood the appeal of docker-compose

Using a recent HN submission to spin up a local vector stack for analyzing notes, https://github.com/memgraph/odin/blob/main/docker-compose.ym...

How would you suggest a bash script handle configuring all the different images, their ports, and ensuring services are spun up in the correct dependency graph (parallel where possible), and are exposed to each other as a reliable host name over a subnet without polluting the host network?

And then how is that bash script extendable so it's not a custom script every time?

Re: Quadlets might make me finally stop using docker-compose

#116

Post by capableweb »

crabbone wrote: post #113

I never understood the appeal of docker-compose (you can accomplish roughly the same thing by having a Shell script that calls docker client, but skipping the Python clown fiesta with dependencies, environments etc.) Quadlets seems not exactly a replacement for the function docker-compose was supposed to perform though, or am I wrong? It seems like its target audience is administrators who are supposed to run contain…

> I never understood the appeal of docker-compose (you can accomplish roughly the same thing by having a Shell script that calls docker client, but skipping the Python clown fiesta with dependencies, environments etc.)

Basically the appeal is "one command > everything running" when you have multiple services working together, which sure, you could do with imperative shellscripting, but for people who don't spend their daily time writing shellscripts, something declarative like YAML is usually easier to get started with, especially when you only revisit it sometimes.

Python people generally have either installed by default in their OS, or already using because of some other system. I wonder how many developers don't have Python at all on their systems already?

Re: Quadlets might make me finally stop using docker-compose

#118

Post by aerzen »

dboreham wrote: post #117

Feel like I've fallen out the back of the wardrobe into Narnia: the way we want to run containers on a machine is part of systemd? A thing that nobody understands, that isn't present on most machines.

It's not present on most machines? All Linux boxes I've seen used systemd. It's the most used init system.

If you want to say that there are machines that don't have systemd which therefore cannot use quadlets, that's like arguing that something made for Linux is useless because "Linux is not present on most machines".

Re: Quadlets might make me finally stop using docker-compose

#119

Post by madspindel »

Actually, I believe "podman generate kube" is even better: https://www.redhat.com/sysadmin/kubernetes-workloads-podman-...

You can run your docker-compose file, then run "podman generate kube" and you will get a Kubernates yaml file.

Then you can run:

$ escaped=$(system-escape ~/guestbook.yaml)

$ systemctl --user start podman-kube@$escaped.service

And you can enable it to start on boot. It will read the yaml file and create the pod.

Re: Quadlets might make me finally stop using docker-compose

#120

Post by yrro »

madspindel wrote: post #119

Actually, I believe "podman generate kube" is even better: https://www.redhat.com/sysadmin/kubernetes-workloads-podman-... You can run your docker-compose file, then run "podman generate kube" and you will get a Kubernates yaml file. Then you can run: $ escaped=$(system-escape ~/guestbook.yaml) $ systemctl --user start podman-kube@$escaped.service And you can enable it to start on boot. It will read the yaml file and…

FYI you'll have to enable lingering for your user on that system. Otherwise your user services won't start on _boot_ but only when you log in.
Post reply on HN