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

151–160 of 208 posts

Re: Docker Compose Isn't Enough

#151

Post by chipdart »

eliribble wrote: post #103
chipdart wrote: post #69

Earlier quoted context omitted.

> For many people self-hosting implies a personal server; it's not really "development" but it's not "production" either. There's Docker swarm mode for that. It supports clustering too. It's nuts how people look at a developer tool designed to quickly launch a preconfigured set of containers and think it's reasonable to use it to launch production services. It's even more baffling how anyone looks at a container orch…

Hey, blog post author here. I'm curious how that last sentence was going to end. Let's say I agree with you and that TLS termination is not a container orchestration responsibility. Where does the responsibility of container orchestration start and TLS termination end? Many applications need to create URLs that point to themselves so they have to have a notion of the domain they are being served under. There has to b…

> Let's say I agree with you and that TLS termination is not a container orchestration responsibility.

It isn't. It's not a problem, either. That's my point: your comments were in the "not even wrong" field.

> (...) It seems like any distinction you make is going to be arbitrary and basically boil-down to "no true container orchestration system should care about..."

No. My point is that you should invest some time into learning the basics of deploying a service, review your requirements, and them take a moment to realize that they are all solved problems, specially in containerized applications.

> I'm aware of Traefik, I ran it for a little while in a home lab Kubernetes (...)

I recommend you read up on Traefik. None of your scenarios you mentioned are relevant to the discussion.

The whole point of bringing up Traefik is that it's main selling point is that it provides support fo route configuration through container tags. It's the flagship feature of Traefik. That's the main reason why people use it.

Your non sequitur on Traefik and Kubernetes also suggests you're talking about things that haven't really clicked with you. Traefik can indeed be used as an ingress controller in Kubernetes, but once deployed you do not interact with it. You just define Kubernetes services, and that's it. You do interact directly with Traefik if you use it as an ingress controller in Docker swarm mode or even docker-compose, which makes your remark even more baffling.

> I'm impressed at both what Kubernetes and k3s have done. (...) If Traefik is as it was years ago,(...)

Kubernetes represents the interface, as well as the reference implementation. k3s is just another Kubernetes distribution. Traefik is a reverse proxy/load balancer used as an ingress controller in container orchestration systems such as Kubernetes or Docker swarm. The "level of complexity" is tagging a container.

Frankly, your comment sounds like you tried to play buzzword bingo without having a clue whether the buzzwords would fit together. If anything, you just validated my previous comment.

My advise: invest some time reading on the topic to go through the basics before you feel you need to write a blog post about it.

Re: Docker Compose Isn't Enough

#152

Post by xelamonster »

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.

I migrated several services from Kubernetes to compose and couldn't be happier. K8s was a maintenance nightmare, constantly breaking in ways that were difficult to track down and unclear how to fix once you did. Compose configs are simple and readable with all the flexibility I need and I've literally never had an issue caused by the platform itself.

Re: Docker Compose Isn't Enough

#153

Post by xelamonster »

xelamonster wrote: post #152
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.

I migrated several services from Kubernetes to compose and couldn't be happier. K8s was a maintenance nightmare, constantly breaking in ways that were difficult to track down and unclear how to fix once you did. Compose configs are simple and readable with all the flexibility I need and I've literally never had an issue caused by the platform itself.

This depends on your use case of course, compose autoscaling is maybe harder but I don't personally need that.

Re: Docker Compose Isn't Enough

#154

Post by anonzzzies »

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.

We run large, auto scaling clusters with compose and a small orchestration thing we have been using since the 90s (written in perl) (before compose we had our own compose-like with chroot). No issues. For decades.

Re: Docker Compose Isn't Enough

#155

Post by lolinder »

eliribble wrote: post #120
lolinder wrote: post #41

To those who are pointing out that compose isn't meant for production, keep in mind that this product that they're selling appears to be designed for the small time family self-hoster [0]. They're not targeting production web apps in a corporate setting, they seem to really be targeting people who wish that they could self-host something on their own network but don't have the technical background to use the docker c…

Yeah, we're very early building this, the blog post is just a way for me to organize my thoughts and start fights online. It's, uh, embarrassingly useful to yell semi-coherent thoughts into the void and have experts yell back with a decade or more of experience and information about tools I haven't heard of. > I'm quite skeptical that adding a layer of abstraction and switching to TOML instead of YAML will suddenly e…

Oh, that makes way more sense! Yeah, that actually sounds like it could work well if you can get buy in from application devs.

The trickiest thing doing it this late in the game is going to be that docker compose has truly become the standard at this point. I self-host a ton of different apps and I almost never have to write my own docker compose file because there's always one provided for me. At this point even if your file format is objectively better for the purpose, it's going to be hard to overcome the inertia.

Re: Docker Compose Isn't Enough

#156

Post by papichulo2023 »

chipdart wrote: post #148
papichulo2023 wrote: post #117

Earlier quoted context omitted.

Most people dont need rolling release, 24/7 availability, auto scaling, etc.. on their home server, so managing k8s just add way more complexity. My main reason to not use is because I would need to host a artifact service somewhere else which is PITA. Some k8s runtime support local building but is not as easy as compose in my experience.

> Most people dont need rolling release, 24/7 availability, auto scaling, etc.. That's perfectly fine. That's not the reason why you are better off running your apps in Kubernetes though. You are better off running your apps in Kubernetes because it handles everything you ever need to effortlessly run containerized apps. You don't even need to install tooling or deployment tools or anything at all. You can have a sin…

> You don't need to bother with anything else.

Hey that is not true, at least last time I tried I spent considerable time trying to integrate a bare metal load balancer from a 9 stars github repo plugin because apparently exposing the port is not recommended. Also having the master and the node in the same server can be problematic because by design it shouldnt be like.

One last point, the runtime ram and cpu overhead is far from minimal.

Re: Docker Compose Isn't Enough

#157

Post by hbogert »

i've been at the edges of docker-compose. We were always conceptually recreating kubernetes. I'm so happy we've got k8s now and sparingly use some operators where needed, couldn't be happier.

The obvious example was certificate management. Cert-manager alone is almost worth setting up K8s if you have many ingresses/fqdns.

Re: Docker Compose Isn't Enough

#158

Post by ianburrell »

stryan wrote: post #137
ChocolateGod wrote: post #122

Earlier quoted context omitted.

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.

What happens when your machine dies? You get paged, your service is down, you have to migrate the services to a new machine.

With Kubernetes, it starts new container on new machine, and you don't get paged.

You could write scripts to do failover, but that takes works and will be buggy.

Re: Docker Compose Isn't Enough

#159

Post by dusanh »

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.

I worked for a medium size company that served, and still is, ~150 clients (some Fortune 500 included) by deploying prod with docker-compose. It can be done.

Re: Docker Compose Isn't Enough

#160

Post by eliribble »

lolinder wrote: post #155
eliribble wrote: post #120

Earlier quoted context omitted.

Yeah, we're very early building this, the blog post is just a way for me to organize my thoughts and start fights online. It's, uh, embarrassingly useful to yell semi-coherent thoughts into the void and have experts yell back with a decade or more of experience and information about tools I haven't heard of. > I'm quite skeptical that adding a layer of abstraction and switching to TOML instead of YAML will suddenly e…

Oh, that makes way more sense! Yeah, that actually sounds like it could work well if you can get buy in from application devs. The trickiest thing doing it this late in the game is going to be that docker compose has truly become the standard at this point. I self-host a ton of different apps and I almost never have to write my own docker compose file because there's always one provided for me. At this point even if…

Yeah, I agree, we're going to need a really compelling use-case not just for end users that run the application, but for the application developers as well. Nobody wants to maintain 3+ extra deployment files for the various also-rans competing with docker-compose.

What do you use to manage all those compose files? Do you have off-site backups? I'm constantly reading and re-writing docker-compose and bash scripting everything to fit in with the rest of my infrastructure it'd be good to hear about someone with a better way.

Post reply on HN