Live data from Hacker News

Docker Compose Isn't Enough

blog.tealok.tech

121–130 of 208 posts

Re: Docker Compose Isn't Enough

#121
post #108

Just use k8s for prod. Docker compose is great for local dev, i would never dream of deploying to prod with compose.

Sure. But that’s not the point of the article. The articles point is “Docker Compose is too complicated”, then proposes a half baked implementation of a solution that hand waves away of all that complexity with a scenario that will fulfill their specific use case but will completely fall apart when it diverges from the specific way they’ve decided to build the abstraction layer. The problem that the author refuses to…

I could come out with some counterpoints, but you’re too abrasive to even engage with. It’s sad what this place has become.

Re: Docker Compose Isn't Enough

#122
post #108

Just use k8s for prod. Docker compose is great for local dev, i would never dream of deploying to prod with compose.

Just use Podman with plain simple .container file which is controlled entirenly by SystemD. Rock solid and easy to fix.

That's great for system services, not for widely deployed applications.

Re: Docker Compose Isn't Enough

#124
post #108

Just use k8s for prod. Docker compose is great for local dev, i would never dream of deploying to prod with compose.

Sure. But that’s not the point of the article. The articles point is “Docker Compose is too complicated”, then proposes a half baked implementation of a solution that hand waves away of all that complexity with a scenario that will fulfill their specific use case but will completely fall apart when it diverges from the specific way they’ve decided to build the abstraction layer. The problem that the author refuses to…

> I would say if the author was actually interested in solving this problem in a productive way they should first try to see if docker itself is amenable to altering their constructs to provide optional higher abstractions over common concepts via the compose interface natively.

docker-compose is a lot of things to a lot of people. When it was created I doubt anyone realized it would eventually be the de facto standard for deploying to homelabs. It's an amazing tool, but it could be better for that specific use. I don't think that segment is important enough to the team that maintains it to warrant the change you're suggesting.

Re: Docker Compose Isn't Enough

#125
To save someone the click, this is a content-based marketing article.

TL;DR: Author believes docker compose is too complicated, and has a grudge against YAML for some reason. Author proposes an alternative configuration syntax that hides implementation details behind named templates.

So despite what the author wants us to believe, this isn't ACTUALLY a replacement for docker compose. This is yet another "easy-to-use" container orchestration product where there's extra upstream development between you and the docker image. Docker compose can run anything you can stuff into a container. This cannot, without some additional development. That may be value in that, but I'm not sure blasting docker compose as old and busted right out of the starting gate is a terrific marketing strategy.

Re: Docker Compose Isn't Enough

#126
post #108

Just use k8s for prod. Docker compose is great for local dev, i would never dream of deploying to prod with compose.

Sure. But that’s not the point of the article. The articles point is “Docker Compose is too complicated”, then proposes a half baked implementation of a solution that hand waves away of all that complexity with a scenario that will fulfill their specific use case but will completely fall apart when it diverges from the specific way they’ve decided to build the abstraction layer. The problem that the author refuses to…

docker compose doesn't need to be overly complex though; I think if it starts to feel that way you're likely doing it wrong(tm). K8s IS very complex, and likely overkill but exactly what you should do if you need it in production. This was a very long ad with an unconvincing argument for a product that addresses the wrong problem.

Re: Docker Compose Isn't Enough

#127
In summary:

Accidental complexity, accidental complexity, accidental complexity and when we use a tool that is designed for problem A for a problem B it is not sufficiently dealing with complexity. This is why we need a new tool.

¯\_(ツ)_/¯

Re: Docker Compose Isn't Enough

#128
post #121

Earlier quoted context omitted.

Sure. But that’s not the point of the article. The articles point is “Docker Compose is too complicated”, then proposes a half baked implementation of a solution that hand waves away of all that complexity with a scenario that will fulfill their specific use case but will completely fall apart when it diverges from the specific way they’ve decided to build the abstraction layer. The problem that the author refuses to…

I could come out with some counterpoints, but you’re too abrasive to even engage with. It’s sad what this place has become.

So you took the time to write a commentary about how the parent wasn't worthy of your counterpoints, but no actual rebuttal. That sort of low-effort / high opinion / no value / zero impact comment (and this post too) is perhaps what's really wrong with internet discourse. It's not about sharing and learning, but hearing your own voice.

Re: Docker Compose Isn't Enough

#129

You know you can run multiple processes inside a single container, right? The solution to the complexity of applications that are distributed as collections of interdependent containers is to put all of the different pieces inside a single container. This is equivalent to what people did before docker existed, and it's still perfectly viable today. There's no need to over-complicate things.

Is there a popular project which puts systemd and multiple processes in a container? I've seen only single process containers so far.

systemd-nspawn might be what you are looking for: https://wiki.debian.org/nspawn

Re: Docker Compose Isn't Enough

#130
post #116

Earlier quoted context omitted.

How many steps is it for you to add a new service to your system? Say you wanted to try out Paperless NGX, what would you need to do?

(Not parent) The quickest way I could do it is if I just used my existing wireguard setup to directly access the docker container IP. In that case it's just one compose up away even without mapping/exposing ports.

Thanks, interesting.

Sounds like your container has some kind of side-car that makes it directly addressable over Wireguard without needing to address the host IP. Does that mean you'd need to modify the docker-compose in some way before `docker-compose up`?

How do you know which port Paperless is using for HTTP? When you want to load up Paperless in a web browser, are you typing in a service name, or the container IP address? If it's a service name, how are you doing DNS? Do you have TLS?

Post reply on HN