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

41–50 of 208 posts

Re: Docker Compose Isn't Enough

#41

Post by lolinder »

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 compose files that most self-hostable apps provide as the 'easy' option.

I'm quite skeptical that adding a layer of abstraction and switching to TOML instead of YAML will suddenly enable those scared away by compose to start self-hosting, but kubernetes and docker swarm were never in the cards.

[0] https://tealok.tech/

Re: Docker Compose Isn't Enough

#43

Post by aitchnyu »

peterkelly wrote: post #33

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.

Re: Docker Compose Isn't Enough

#44

Post by moondev »

coredog64 wrote: post #26
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/

Early this year I consulted for a company that used docker-compose as their software deployment mechanism. They created new compute, but compose gave them the sidecars you’d want from k8s without all the other overhead that came with.

To go even further, podman supports actual sidecars (one or many forming a pod) and even supports actual Kubernetes deployment manifests without needing a kube-apiserver.

Re: Docker Compose Isn't Enough

#45

Post by adamc »

ricw wrote: post #14

So the problem is 1) port mapping and 2) backing up data volumes? There are simple solutions to each 1) you simple have a separate docker-compose file for a different environment, ie docker-compose.dev.yml for your dev server. in this file you simply define the parts that differ from the primary / prod compose file. that way it's a simple command. line variable that initiates a dev vs prod vs any other type. for deta…

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.

Re: Docker Compose Isn't Enough

#48

Post by mnahkies »

I've cobbled together some scripts around docker compose that largely solves these problems for me (https://github.com/mnahkies/shoe-string-server)

It basically looks for a custom external hostname property which is used to generate the haproxy configuration and issue SSL certs.

For ports I personally prefer to just use a consistent container port as much as possible (eg: 80) - I'm sticking a reverse proxy in front of everything anyway so no need for unique ports bound to the host that I won't remember.

Data I basically just bind mount into a structure that I can easily backup from the host. I've also managed to do some major postgres upgrades without any issue (https://github.com/mnahkies/shoe-string-server/blob/master/d...)

I wouldn't call this approach production grade - I'm very much in the use managed Kubernetes/SQL camp there, but it's been working great for my personal needs

Re: Docker Compose Isn't Enough

#49

Post by feisty0630 »

ethagnawl wrote: post #35
snapetom wrote: post #23

Earlier quoted context omitted.

Not sure why comments aren't jumping on this more. Swarm is for production. compose is for development. That's always been the case. And Swarm is barely more complicated than compose anyway. Don't know why people who are claiming they use compose in production just don't learn the few extra steps to do what Docker recommends.

I thought Swarm had been deprecated? I just took a quick look into it and (classic) Swarm was deprecated and ... replaced by Swarm (mode).

Wait until you find out about 'docker-compose' vs 'docker compose'!

Re: Docker Compose Isn't Enough

#50

Post by imp0cat »

small_scombrus wrote: post #29
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/

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).
Post reply on HN