Live data from Hacker News

Quadlets might make me finally stop using docker-compose

major.io

161–170 of 212 posts

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

#161

Earlier quoted context omitted.

Yeah … this response is devoid of substance. What’s all this nonsense about “soy”? Why not critique the approach with what is better about your approach or docker-compose or whatever it is you use and talk about the merits.

It probably seems like I wrote the above as a one-off shit post to bag on OP for the lulz. But I did have a solid engineering basis for writing it. The tools being better or worse isn't the issue I was getting at. Quadlets may well be an improvement on several fronts. But every tool / dependency / service / etc increases the cognitive burden of a project. That is one more component to have to learn for people who int…

Now that is a cogent post that makes claims without the hyperbole or charged words.

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

#162
post #91
post #68

Earlier quoted context omitted.

The next step: systemkubed.

Nah, we got that already. Quadlet can handle k8s manifests. https://man.archlinux.org/man/quadlet.5.en#Kube_units_%5BKub...

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.

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

#163

Earlier quoted context omitted.

For my home server, I have a flat 2507 line docker-compose file that automatically configures and boots all of my 85 containers. I still have some complexity: .env files in /opt/ /, a systemd process that automatically runs docker-compose -f / /docker-compose.yaml -d on boot, and it's only a little irritating to have use absolute paths for everything instead of relative. But, after having to update all of my services…

> 2507 line docker-compose file mother_of_god.gif

Yeah, she's a big girl, but having one flat file and one systemd process is infinitely better than juggling 85 of each. I have the systemd process start after docker.service, and most of my containers have a "depends_on" argument so they don't all try to boot at once. All of the containers also push logging to a Splunk instance, which adds 9 lines per container, which increases the file by 765 lines.

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

#164
post #115

Earlier quoted context omitted.

> 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 re…

docker-compose is slow and not quite parallel (because it's written in Python and uses requests internally). So your yearning for speed optimization is kind of misplaced. If you are using docker-compose, you probably don't care about speed anyways. And, the way I understand it's typically used is to create some slice of the system a developer is working on, so unless we are talking about many minutes difference, the…

> docker-compose is slow and not quite parallel (because it's written in Python and uses requests internally).

This hasn't been true for quite some time. Docker compose v2, written in Go, was released in 2020; v1 finally officially stopped receiving security updates this summer.

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

#165

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 thei…

> Basically the appeal is "one command > everything running"

But I can accomplish this with Shell script... And no need to deal with Python, its broken dependency management, poor piping / I/O in general, bugs in the docker-compose itself... What do I win by having to suffer all these problems?

> who don't spend their daily time writing shellscripts,

Do you write docker-compose scripts daily? Seriously? Why? My impression was that you write that once and edit very infrequently (like maybe once a month or less). So, in terms of time investment it doesn't seem to make much of a difference. Also, I see no value in imperative vs declarative approaches here. It's actually hard to understand what is going to happen when you use declarative style because you need to rely on and have a very deep knowledge of the imperative aspect of the system interpreting your declarations to be confident of the end result.

> Python people generally have either installed by default in their OS,

Being one of "Python people" I have Python 3.7 thru 3.12 built from respective heads of cPython project installed on my work laptop. I would hate to have to add more to support a tool with dubious (or as is my case extraneous) functionality.

Also, being one of those "Python people" who deals with infra, I had to import docker-compose code into my code and deal with it as dependency, both with its CLI and its modules. And... it's not good code. Well, like the wast majority of Python is a piece of garbage. Particular feature of docker-compose that stands out is that it was written by "Go people" with poor command of Python, so it's "Go written in Python" kind of program.

Also, people who write docker-compose don't care about how it interacts with other packages, and this shows in how they define their dependencies (very selective versions of ubiquitous libraries, eg. requests) that will almost certainly not play well with other libraries you'd use in this context (eg. boto3). I had plenty of headache trying to use this tool and had so far sworn never to use it in my own infra projects because of its dependency issues. If I ever use it (as in to deal with someone else's problems) I install it in its own environment. Which is yet another problem with its use because then you'd have to switch environments just to call it, and then you forget to switch back and things start behaving weirdly.

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

#166

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

And so does Python. But Python is unnecessary for this task. So, having to choose between two evils, I'd choose the necessary one.

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

#167

Earlier quoted context omitted.

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

And so does Python. But Python is unnecessary for this task. So, having to choose between two evils, I'd choose the necessary one.

Idk what python you're talking about with docker compose

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

#168

Earlier quoted context omitted.

> 2507 line docker-compose file mother_of_god.gif

Yeah, she's a big girl, but having one flat file and one systemd process is infinitely better than juggling 85 of each. I have the systemd process start after docker.service, and most of my containers have a "depends_on" argument so they don't all try to boot at once. All of the containers also push logging to a Splunk instance, which adds 9 lines per container , which increases the file by 765 lines.

you had me until you said splunk and now I am horrified to know the true topology of your homelab

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

#170

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…

When putting multiple containers together docker-compose will handle setting up the networking and hostname lookup so that the services can communicate with static names and ports.

Among other things.

Post reply on HN