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

161–170 of 208 posts

Re: Docker Compose Isn't Enough

#161

Post by stryan »

ianburrell wrote: post #158
stryan wrote: post #137

Earlier quoted context omitted.

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.

I was more questioning why a .container file would work for system services versus application services, since basically all those same problems occur for system services too.

Either way this type of argument just comes down to "should I cluster or not" but to think out loud for a bit that's just basic HA planning: Simplest solution is keepalived/etc for stateful services, standard load balancing for stateless. Don't want load balanced services running all the time? Socket activation. Don't have a separate machine? Auto-restart the service and you can't cluster anyway. The only thing you'd really have to script is migrating application data over if you're not already using a shared storage solution, but I'm not sure there's any easier solutions in Kubernetes

Re: Docker Compose Isn't Enough

#162

Post by ffsm8 »

eliribble wrote: post #130
dizhn wrote: post #116

Earlier quoted context omitted.

(Not parent) The quickest way I could do it is if I just used my existing wireguard setup to directly access the docker container IP. In that case it's just one compose up away even without mapping/exposing ports.

Thanks, interesting. Sounds like your container has some kind of side-car that makes it directly addressable over Wireguard without needing to address the host IP. Does that mean you'd need to modify the docker-compose in some way before `docker-compose up`? How do you know which port Paperless is using for HTTP? When you want to load up Paperless in a web browser, are you typing in a service name, or the container I…

> Sounds like your container has some kind of side-car that makes it directly addressable over Wireguard

Not necessary. You can access the deployed docker container without exposing any ports or having any reverse proxy (what you've likely thought about with sidecar, which is a k8s concept, not docker) or anything else by using the ipadress of the started container and the ports the started service used. This is usually only possible from localhost, but wireguard can be configured as what's essentially a bastion host and exit node, this would let connecting clients also address containers that were started on that server, without opening any ports.

You can technically also do that without wireguard even, as long as you configure the docker host to route relevant traffic into the docker ethernet and define the docker subnet as a static route that points to the docker host, but that's another story

Re: Docker Compose Isn't Enough

#163

Post by eliribble »

bityard wrote: post #125

To save someone the click, this is a content-based marketing article. TL;DR: Author believes docker compose is too complicated, and has a grudge against YAML for some reason. Author proposes an alternative configuration syntax that hides implementation details behind named templates. So despite what the author wants us to believe, this isn't ACTUALLY a replacement for docker compose. This is yet another "easy-to-use"…

Weird editorialization. I included a TL;DR at the top, you could have just copy-pasted it.

"Docker-compose is a tool for working with Docker containers. It solves very real problems with deploying complex applications. By itself it is not enough to make self-hosting applications simple enough for the mass-market."

Re: Docker Compose Isn't Enough

#164

Post by mmcnl »

Strangely enough I'm at the complete opposite end of the author. Docker Compose imo operates exactly at the right abstraction layer and to me the author never really explains what the problems with Docker Compose actually are.

Imo Docker Compose absolutely should not handle databases and web servers. It should orchestrate containers. It's up to the user what kind of containers should be orchestrated.

Also the author somehow never got the idea to run the reverse proxy in a container? You don't need to do any port mapping then.

Re: Docker Compose Isn't Enough

#165

Post by mati365 »

ianburrell wrote: post #158
stryan wrote: post #137

Earlier quoted context omitted.

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.

Just spawn another VPS with your application and connect to load balancer. Even better - use Fedora CoreOS with Butane config and make that VPS immutable.

Re: Docker Compose Isn't Enough

#166

Post by sureglymop »

One thing I really dislike about compose is that its a CLI tool but it doesn't exist in library form with a similar API.

I wrote a backup tool for compose/swarm based setups based on restic but ended up having to reimplementing half of traefik because there was no more straightforward API and compose really is just a thin layer over docker.

Re: Docker Compose Isn't Enough

#167

Post by osigurdson »

rubinelli wrote: post #112
osigurdson wrote: post #91

Earlier quoted context omitted.

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.

I may consider using HOCON [0] if I see any traction, bust after writing a lot of YAML and even making my own YAML-driven tools, I feel its shortcomings are overstated. I got bit by corner cases maybe three or four times, and they didn't take long to debug. [0] https://github.com/lightbend/config/blob/main/HOCON.md

For the authors, I suggest a TL;DR with some basic examples. People tune out pretty quickly. You want the 10s take away to be "I like it" and "this person has really thought through it". You have achieved the second objective with what you have.

Re: Docker Compose Isn't Enough

#168

Post by raphinou »

eliribble wrote: post #144
raphinou wrote: post #139

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 qu…

Looks like https://dockerswarm.rocks says that the site is deprecated. https://dockerswarm.rocks/swarm-or-kubernetes/ says "it's not sensible to build a new product using Docker Swarm Mode"

That's indeed the opinion of the author. Note however that at this time all elements used in the setup described on dockerswarm.rocks are maintained. I started using swarm in 2022 and I documented my decision [1], and my reasoning for my kind of needs as not changed. The investment is very low, as well as the risk. Migrating away from swarm should not be very problematic for me, and in the meantime I enjoy an easy to maintain setup. I still think it's better than tweaking a maybe working solution with compose.

I'm not expecting to convince anyone but wanted to share an alternative approach(only applicable to certain setup)

1 https://www.yvesdennels.com/posts/docker-swarm-in-2022/

Re: Docker Compose Isn't Enough

#169

Post by raphinou »

therealfiona wrote: post #147
raphinou wrote: post #139

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 qu…

I love Swarm and don't see the appeal of K8s when something as simple as Swarm exists. I do however run K8s in prod for work and would never run Swarm in prod due to Docker seeming to have its days numbered. Idk where that leaves us aside from ECS. But I also have no need to run something any more robust than ECS in AWS for my workload. We are moving our EKS workload over to ECS over the next year. I expect needing t…

I agree it depends on the situation, but there still are some situations (like small apps) where I see swarm as the way to go. Yours is probably different.

Re: Docker Compose Isn't Enough

#170

Post by lolinder »

eliribble wrote: post #160
lolinder wrote: post #155

Earlier quoted context omitted.

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 ev…

I have a single GitHub repo that contains all the compose files for my main server. Each application gets a folder with the compose file and any version-controllable configuration (which gets bound to volumes in the docker containers).

I periodically run Renovate [0], which submits PRs against the infrastructure repo on my local Forgejo to update all my applications. I have a script in the repo which pulls the git changes onto the server and pulls and restarts the updated apps.

Data is all stored in volumes that are mapped to subfolders in a ~/data directory. Each application has a Borgmatic [1] config that tells Borgmatic which folder to back up for that app and tells it to stop the compose file before backup and resume it afterwards. They all go to the same BorgBase repository, but I give each app its own config (with its own retention/consistency prefix) because I don't want to have network-wide downtime during backups.

At the moment the backup command is run by me by hand, with BorgBase configured to send me emails if I forget to do it for a week. Eventually that will be a cron job, but for now it takes less time to just do it myself, and I don't change my data often enough for a week of lost work to hurt much.

All the applications bind to ports which are firewalled, with Caddy and Pihole being the only applications that run on exposed ports (53, 80, 443). Caddy has a wildcard DNS cert from LetsEncrypt for HTTPS and directs traffic from a bunch of local domain names to the correct applications. I just use Pihole to define my local DNS names (custom.list, which is where Pihole keeps the local DNS definitions, is a volume that's committed to the repo).

[0] https://github.com/renovatebot/renovate

[1] https://torsion.org/borgmatic/

Post reply on HN