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

Docker Compose Isn't Enough

blog.tealok.tech

Post reply on HN
Print view View original

131–140 of 208 posts

Re: Docker Compose Isn't Enough

#131

Post by qtbt »

hluska wrote: post #121
SOLAR_FIELDS wrote: post #114

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.

you're too lazy to post counterpoints and then call the place sad. you are the problem, my friend! i don't like posting this kind of comment but felt it needed to be called out. i'd prefer if neither of our comments were posted.

Re: Docker Compose Isn't Enough

#132

Post by ggregoire »

Izkata wrote: post #8

I've always understood docker-compose to be a development or personal tool, not for production. Is that not usually the case? Also aside, "docker compose" (V2) is different from "docker-compose" (V1) [0], it was rewritten and integrated into docker as a plugin. It should still be able to handle most old compose files, but there were some changes. [0] https://docs.docker.com/compose/releases/migrate/

How so? I run docker compose in production on 30 bare metals without any issue.

Re: Docker Compose Isn't Enough

#134

Post by chrisandchris »

dankle wrote: post #108

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

That's what I thought the first day, the first month and maybe even the first half year.

Now it's 5 years+ running, all fine. No major hassle (crossing fingers!), no configuration hell. Never touched k8s, and not going to in the near future.

Maybe it just works and is sufficient for my case.

Re: Docker Compose Isn't Enough

#135

Post by eliribble »

lolinder wrote: post #30
wmf wrote: post #9

Earlier quoted context omitted.

It's called content marketing. IMO this article is content marketing done right since it has useful information even if you don't read to the end.

Does it, though? It has a very brief introduction to Docker and Docker Compose, but then it mostly has a lot of FUD that's designed to scare people off of Docker Compose but is not remotely convincing to someone who's actually worked with it. The way they frame that pihole example ("Whew! That’s a lot of stuff!") is just silly. Looking at their website, I think they started out trying to make self-hosting really easy…

> The way they frame that pihole example ("Whew! That’s a lot of stuff!") is just silly.

Yeah, you're probably right. Originally that line was in there when I had a breakdown of what each line in the docker-compose was doing. My editor thought that was unnecessary - it's unlikely people reading the post would need that kind of breakdown. So I rewrote parts to assume more baseline knowledge. I should have noticed that line and taken it out.

You're right about what we're trying to do, and I agree that the post doesn't really help someone be successful today deploying things. The post is more meant to gauge whether or not I'm alone in having pain deploying a couple dozen services with docker compose on a single box.

I want more people to have the power to host their own services. I think we can do that, but we have to figure out the right thing to build to do it.

Re: Docker Compose Isn't Enough

#136

Post by eliribble »

datadeft wrote: post #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. ¯\_(ツ)_/¯

While a bit of a hot take, you're not wrong. We need something that's less scalability focused than Kubernetes/Mesos/Docker Swarm but that doesn't put too much burden on application developers. Something that focuses on being secure, reliable, and understandable, in that order. I'm not aware of anything going for that niche. That means a new tool is in order.

Re: Docker Compose Isn't Enough

#137

Post by stryan »

ChocolateGod wrote: post #122
mati365 wrote: post #118

Earlier quoted context omitted.

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.

Why not? I can't imagine you'd deploy an application without some form of service management (even if it's just throwing it in tmux) and unless you've gone out of your way to use a non systemd distro systemd is builtin and works for both user and root containers.

Most places (though not all) that I've seen using docker or docker-compose are throwing them in systemd units anyway.

Re: Docker Compose Isn't Enough

#138

Post by stonemetal12 »

ggregoire wrote: post #132
Izkata wrote: post #8

I've always understood docker-compose to be a development or personal tool, not for production. Is that not usually the case? Also aside, "docker compose" (V2) is different from "docker-compose" (V1) [0], it was rewritten and integrated into docker as a plugin. It should still be able to handle most old compose files, but there were some changes. [0] https://docs.docker.com/compose/releases/migrate/

How so? I run docker compose in production on 30 bare metals without any issue.

According to docker: "Compose has traditionally been focused on development and testing workflows, but with each release we're making progress on more production-oriented features."

https://docs.docker.com/compose/intro/features-uses/

Sounds like dev, and test tool with production aspirations that isn't actually there yet to me.

Re: Docker Compose Isn't Enough

#139

Post by raphinou »

I am particularly happy with docker swarm with traefik as described here: https://dockerswarm.rocks/traefik/

Incredibly easy to setup and manage for usual small scale deployments. I use it as one node swarms, and I have setup - backups - automatic https certificates setup and renewal - automatic upgrades to new images - easy setup of persistence of data on the server

I'm very surprised it is not more popular, with quite some people trying to replicate swarm's features with docker compose, but often in harder to maintain setups.

Re: Docker Compose Isn't Enough

#140

Post by eliribble »

mkarrmann wrote: post #54

I'm pretty confused by this article. It says docker compose is at the "wrong-level of abstraction", but I kept feeling the author was instead expecting docker compose to solve different problems that it was ever meant to solve. In fact, they seem to be expecting a highly-opinionated, high-level interface which solves problems that I don't think anyone using docker compose in prod should even be worried about. A lot o…

These are great points, and probably worth their own blog post to answer.

> First of all, why is this a concern? Idle threads have basically no impact on a system, so this generally isn't a concern

Idle threads have very low impact on CPU utilization, probably, if the application is well-behaved (and I expect most databases and caching layers to be well-behaved in this way). The application itself, however, will need memory and the way containers are built prevents the usual de-deplication of system libraries.

> but generally it won't even make the list of top-100 performance bottlenecks for most applications

True, but it makes the short list of "how much stuff can I run on a $100 computer", and it's one of the relatively few concerns an application operator has when they are not the application developer.

> Even if you wanted to enforce your applications sharing a postgres instance under the hood, why would you want that to be black-magic performed by the container orchestrator?

To make self-hosting much simpler. If the container orchestrator doesn't do it, what do you think should do it?

> Other stuff like DB backups just don't seem like issues docker compose users have. If you need to orchestrate across multiple nodes in order to meet your SLOs, then don't use docker compose.

The DB backups are meant for disaster recovery rather than supporting multiple nodes. I guess that's multiple nodes through time... But, yeah, I agree, docker-compose is not a good fit.

> Finally, it seems like the actual solution is significantly under-discussed. I both have tons of questions about how it's supposed to work, and I see lots of shortcomings with the parts that I do understand.

Yeah, agreed, I'll be writing other things to discuss what I think the correct solution should be. I'm curious to find out if other people have existing solutions to the problems I outlined. If it's a solved problem and I just don't know about it, that'd be better.

> I'd be interested to read an article which tried to articulate why such an opinionated API would improve SDLC-considerations over docker-compose, but I don't think that's the article I just read.

It is not, and you're right, it needs discussion.

Post reply on HN