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

101–110 of 208 posts

Re: Docker Compose Isn't Enough

#101

Post by hifromwork »

chipdart wrote: post #72
ricw wrote: post #28

Earlier quoted context omitted.

it's perfectly fine if everything can run on a single server instance. which is probably the majority of things. i've run production instances with 2PB of data being scraped per month by 100+ CPUs and 256GB of RAM using docker compose. some of the machines (smaller instances) have run flawlessly with zero reboots for years on end. both on cloud and on-prem. i'd say its 100% production ready.

> I'd say its 100% production ready. That's fine. Some people also manually launch containers individually with Docker as their production system. They'd be wasting their time and making their lives needlessly harder, though. They already have tools that do all the legwork for them. Why not do the research and opt to force a square peg into a round hole? Research Docker swarm mode, reverse proxies like Traefik, and L…

>They'd be wasting their time and making their lives needlessly harder, though.

Using Kubernetes where it's not needed is just that - wasting your time and making your life harder.

Before you say that I just need to research more: I know Docker swarm mode, I run my personal server on Kubernetes using Traefik and Let's Encrypt, I professionally work with Kubernetes (both as an admin and working on Kubernetes security, which is tough to get right), most services in my dayjob run on Kubernetes, and I was the person who introduced CI/CD pipelines there some years ago.

I still claim that there are production usecases that are better served by docker-compose.

Re: Docker Compose Isn't Enough

#102

Post by bunderbunder »

lokar wrote: post #97
zemo wrote: post #20

people dramatically overestimate how difficult it is to write a program that controls docker for you. This is one of those things where you can write like two pages of Python and ignore... all this: > Tealok is a runtime we’re building for running containers. If you have one machine and docker-compose is falling short, really, just write a Python script with the official docker Python package, you'll be fine.

IME, people dramatically overestimate how hard it is to write any program.

IME people overestimate how hard it should be to write a program, but underestimate how hard it actually is after they're done overengineering the problem to death.

Re: Docker Compose Isn't Enough

#103

Post by eliribble »

chipdart wrote: post #69
wmf wrote: post #10

Earlier quoted context omitted.

For many people self-hosting implies a personal server; it's not really "development" but it's not "production" either. In that context many people find k8s or other PaaS to be too heavyweight so Docker Compose is pretty popular. For more production-oriented self-hosting there are various newer tools like Kamal but it will take a while for them to catch up.

> 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 be a mapping between whatever load-balancer or reverse proxy you're using and the internal address of the application container. You'll likely need service discovery inside the orchestration system, so you could put TLS termination inside it as well and leverage the same mechanisms for routing traffic. 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..."

In the end we all build systems to do things to make people's lives better. I happen to think that separating out backups and managing ports as an exercise for the deployment team raises the barrier to people that could be hosting their own services.

I could be totally wrong. This may be a terrible idea. But I think it'll be interesting to try.

> If he would have done so, in the very least he would have eventually stumbled upon Traefik which in Docker solves absolutely everything he's complaining about

I'm aware of Traefik, I ran it for a little while in a home lab Kubernetes cluster, and later on a stack of Odroids using k3s. This was years ago, so it may have changed a lot since then, but it seemed at the time that I needed an advanced degree in container orchestration studies to properly configure it. It felt like Kubernetes was designed to solve problems you only get above 100 nodes, then k3s tried to bang that into a shape small enough to fit in a home lab, but couldn't reduce the cognitive load on the operator because it was using the same conceptual primitives and APIs. Traefik, reasonably, can't hide that level of complexity, and so was extremely hard to configure.

I'm impressed at both what Kubernetes and k3s have done. I think no home lab should run it unless you have an express goal to learn how to run Kubernetes. If Traefik is as it was years ago, deeply tied to that level of complexity, then I think small deployments can do better. Maybe Caddy is a superior solution, but I haven't tried to deploy it myself.

Re: Docker Compose Isn't Enough

#104

Post by vundercind »

wmf wrote: post #10
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/

For many people self-hosting implies a personal server; it's not really "development" but it's not "production" either. In that context many people find k8s or other PaaS to be too heavyweight so Docker Compose is pretty popular. For more production-oriented self-hosting there are various newer tools like Kamal but it will take a while for them to catch up.

I've managed to keep my personal server to just docker, no compose. None of the services I run (Jellyfin, a Minecraft server, prowlarr, a Samba server [this is so much easier to configure for basic use cases via Docker than the usual way], pihole) need to talk to one another, so I initialize each separately with shell scripts. Run the script for a new service once, and Docker takes care of restarts on system reboot or if the container crashes, don't even have to interact with my base OS's init system or really care about anything on it. When I want to upgrade a service, I destroy the container, edit the script to specify the newer version I want, and run the script again. Easy.

Re: Docker Compose Isn't Enough

#105

Post by eliribble »

lolinder wrote: post #34
zemo wrote: post #20

people dramatically overestimate how difficult it is to write a program that controls docker for you. This is one of those things where you can write like two pages of Python and ignore... all this: > Tealok is a runtime we’re building for running containers. If you have one machine and docker-compose is falling short, really, just write a Python script with the official docker Python package, you'll be fine.

It's more than just a runtime for running containers, from the main landing page it looks like they're really specifically targeting self-hosting for the barely-technical [0]. In that context this article makes some degree of sense: their target audience will probably be legitimately overwhelmed by that pihole example and wouldn't know how to write a Python script to save their life. If they can pull it off more powe…

I'm actually a fan of Sandstorm, and think it got a lot of things right. I'd love to be able to talk to Kenton Varda about why he thinks adoption on it was weak. Personally I think that it put a bit too much burden on application developers since it required them to develop applications specifically for sandstorm.

> I'm skeptical that what the non-technical self-hoster needs is a TOML DSL that abstracts away ports

I fully agree, the end user would not be writing TOML DSL files. The end user would get something much closer to an app store, or what Sandstorm did, with one (or a few) click installs. The TOML DSL would be written by developers familiar with the application and stored either in a separate database, or ideally in the applications source control like a Dockerfile.

Re: Docker Compose Isn't Enough

#106

Post by Loic »

eliribble wrote: post #94
Loic wrote: post #63

Earlier quoted context omitted.

I use the convention that all my containers are getting a /data/ folder where data can be stored and will get an automatic daily backup. It is easy to set the right storage behind /data/. Just a convention, nothing more, smoothly working for the past "many" years.

I assume you're saying this as a container image author, not as someone who is deploying containers. It'd be great if every other container image author standardized on something like this. We just need someone to create the standard and some tools to make the standard a well-paved path.

In this particular case, I am both creating the images and deploying them.

Re: Docker Compose Isn't Enough

#107

Post by lawn »

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/

> I've always understood docker-compose to be a development or personal tool, not for production. Is that not usually the case?

Tons of sites are launched manually and have been for years in production.

Docker compose is a huge step up from that, so why wouldn't it be?

Re: Docker Compose Isn't Enough

#109

Post by stavros »

wink wrote: post #79
czhu12 wrote: post #7

Shameless plug: I’m building https://canine.sh as a way of turning any managed kubernetes cluster into something as easy to use as Heroku. It’s been super frustrating in the past to be stuck on expensive PaaS vendors, but then rolling a deployment solution from scratch ended up with us trying to stitch together GitHub actions. Been just using canine for my own projects and I’ve been able to host 4 rails & 1 Rust app…

How would you rate the "overhead" of your tool+k8s (also wht specs does your server have?) because my main use for docker-compose so far has been "host a ton of small apps on 5EUR hetzner instances with just 2GB RAM". If I had a beefier box I'd probably tried k8s again but in my recollection of when I last used it was bad if you had e.g. 5x 2GB RAM/2 CPU vs 1x 8GB RAM on one box.

I wrote my own tool to solve this:

https://harbormaster.readthedocs.io

It's a very thin layer over Compose, basically just auto-pulls git repos and restarts containers if they have any new changes.

Re: Docker Compose Isn't Enough

#110

Post by vundercind »

code_runner wrote: post #100
imp0cat wrote: post #50

Earlier quoted context omitted.

You'll need more than a backup system. At least some sort of a load balancer to switch between different groups of running docker containers (so that upgrades, backups, etc... can happen without service being interrupted).

not every single system requires 100% uptime... some folks still use release windows for specific applications/hardware. I'd argue that most systems out there can support a release window.... and the overlap between "docker-compose works for us" and "we have release windows" is probably quite high. We needed to do inference on remote machines stationed at random points across North America.... the machines had work t…

My experience has been that the vast majority of systems could tolerate a few minutes offline per month for upgrades. Many could tolerate a couple hours per month. No or negligible actual business harm done, enormous cost savings and higher development velocity from not adding the complexity needed for ultra-high uptime and zero-downtime upgrades.

What's vital is being able to roll back a recent update, recover from backups, and deploy from scratch, all quickly. Those are usually (not always) far easier to achieve than ultra-high-uptime architecture (which also needs those things, but makes them all more complicated) and can be simple enough that they can be operated purely over ssh with a handful of ordinary shell commands documented in runbooks, but skipping them is how you cheap out in a bad way and end up with a system down for multiple days, or one that you're afraid to modify or update.

Post reply on HN