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

91–100 of 208 posts

Re: Docker Compose Isn't Enough

#91

Post by osigurdson »

wink wrote: post #80
osigurdson wrote: post #52

>> I’m not using YAML, it’s garbage I suspect I probably felt like that at one time but it seems fine now after repeated use.

I'm using YAML despite it being garbage. (feels more common)

Maybe I am a boiled frog, but I personally like it. TOML looks fine for simple cases, but yaml is fine there as well. Also, yaml has very clean approaches for dealing with literal text. For instance, if your yaml file needs to include an xml file, a json file and a bash script, it all ends up being very readable.

Re: Docker Compose Isn't Enough

#92

Post by czhu12 »

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.

Yeah Hetzner is amazing and I think if you’re looking at a single app for costs in the $5 range, it’s probably not worth it to use k8s.

The magic with k8s is being able to easily host third party packages via helm. I often find for anything I want to run in production, I usually want something like sentry, grafana, etc, and those items can get expensive if you try to buy hosted versions. Kubernetes makes it trivial to just host it yourself.

In terms of performance, I’ve gotten reasonable performance out of a $24 kubernetes server, which is 2vCPU + 4GB memory. These days, DigitalOcean and linode don’t charge a markup on their managed kubernetes at all, above their regular VPS pricing.

Heztner is much cheaper than both those options though, and they don’t have a managed kubernetes product

Re: Docker Compose Isn't Enough

#93

Post by eliribble »

number6 wrote: post #85
shubhamjain wrote: post #18

Earlier quoted context omitted.

Yup, I was surprised how weak the arguments were. I mean, surely there are better reasons why docker compose fails to scale? I have been pretty happy with it right now, and haven't felt the need to try something like k8s or docker swarm.

Sounds more like a skill issue. I am quite glad with traeffik and docker-compose. But I don't have that high loads or interactions on my servers

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?

Re: Docker Compose Isn't Enough

#94

Post by eliribble »

Loic wrote: post #63
smaudet wrote: post #59

Earlier quoted context omitted.

I think 2) actually has the most merit. If you have a large number of e.g. temp files a container creates, retaining that file history may not be particularly valuable. Some sort of "hey back this data up, it's important to my function standard would be nice, and not just for container apps. Trying to figure out where your app hid its configuration and save files is a perennial user frustration.

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.

Re: Docker Compose Isn't Enough

#95

Post by eliribble »

smaudet wrote: post #58
adamc wrote: post #45

Earlier quoted context omitted.

You can solve anything with enough scripts, but that in no way invalidates his point that the abstraction level seems a bit off. I'm not sure that his solution is really an improvement, however, because then you have to bake in the semantics for a fixed set of product types, and when that list gets extended, you have to bake-in a new one.

Not only that he wants to re-invent messaging and daemons, essentially. There are pre-existing paradigms for service brokers, message passing, etc., they all try to solve this problem, and they all share this same fault, they become in-extensible... Which is the core programming tradeoff, flexibility vs robust constrained behavior. On the extreme end of flexibility you have AI goop you barely understand, but arguably…

This is a really good conceptual model, the tradeoff between flexibility and constrained declarative frameworks. The goals is to make self-hosting applications extremely easy and extremely reliable. With that as a goal, being highly constrained seems like the way to go.

Re: Docker Compose Isn't Enough

#96

Post by chefandy »

hamandcheese wrote: post #81
chefandy wrote: post #27

Earlier quoted context omitted.

I'm not dev-ops-familiar with Docker, so you might be more familiar with the problem space, but it seems like "You can just write a Python script to do what you want" is the sort of thing people say to justify not giving people the config infrastructure they need to solve their problems without having to write executable code. Like, sure, you often can make up for not having a zoom lens by walking towards what you're…

> to solve their problems without having to write executable code. Some people would rather write 1000 lines of yaml than 100 lines of python, and I really don't understand why.

It brings a new layer of complexity, which means more surface area for bugs and vulnerabilities.

It’s often easier for developers to write a script using standardized tooling than dig into deep configuration docs for a complex application you’re not familiar with, but that’s where the benefits stop. Configuring built-in functionality makes sense for the same reason using an existing framework/os/etc authentication system makes sense. It often seems like way more effort to learn how to use it than rolling your own simple system, but most of that complexity deals with edge cases you haven’t been bitten by yet. Your implementation doesn’t need to get very big or last very long before the tail of your pipeline logic gets unnecessarily long. Those features don’t exist merely because some people are scared of code.

Additionally, if you’re just telling the application to do something it already does, writing code using general purpose tools will almost certainly be more verbose. Even if not, 10 to 1 is fantastically hyperbolic. And unless you write code for a living— and many dev ops people do not— defining a bunch of boolean and string values to control heavily tested, built-in application functionality (that you should understand anyway before making a production deployment) requires way less mental overhead than writing secure, reliable, production-safe pipeline code that will then need to be debugged and maintained as a separate application when anything it touches gets changed. Updating configuration options is much simpler than figuring out how to deal with application updates in code, and the process is probably documented in release notes so you’re much more likely to realize you need to change something before stuff breaks.

Re: Docker Compose Isn't Enough

#97

Post by lokar »

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.

Re: Docker Compose Isn't Enough

#98

Post by code_runner »

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 used it for both.... but for production only in extremely constrained/limited environments. Its every bit as stable as anything else... you can version the compose you deploy so rollbacks are easy, etc etc.

far more useful for development IMO, but when push comes to shove and you need a few things running together on a machine in the middle of nowhere with limited/unreliable internet access.... you can't do much better... a few volume mounts for durability and you're really in decent shape.

logs, networking, system health etc etc.... just all a few docker and docker-compose commands away

Re: Docker Compose Isn't Enough

#99

Post by ajayvk »

theshrike79 wrote: post #76
forrestthewoods wrote: post #53

Earlier quoted context omitted.

Many abstractions are very bad. Stacking bad abstractions on bad abstractions is why modern software is so slow, laggy, and bloated.

What would be your solution to running, say, 15 different Python applications on the same machine, each requiring a unique set of library versions?

https://github.com/claceio/clace is a project I am building for that use case. Run multiple apps on the same machine, Clace acts as an application server which manages containers https://clace.io/blog/appserver/

Re: Docker Compose Isn't Enough

#100

Post by code_runner »

imp0cat wrote: post #50
small_scombrus wrote: post #29

Earlier quoted context omitted.

Its not going to be amazingly professional and 100% best practice , but you can set up docker-composes and/or design containers to pull everything they need on first run. That plus a decent backup system would work for a small array of servers with fail-safes. Though I would die inside if a production user-focused app under any level of proper load was set up like that.

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 to do depending on external factors that were rigidly scheduled. really easy to make upgrades, and the machines were _very_ beefy so docker-compose gave us everything we needed.... and since we shipped the data off to a central point regularly (and the data had a short shelf life of usability) we could wipe the machines and do it all again with almost no consequences.

I needed to coordinate a few small services and it did the trick beautifully

Post reply on HN