|
| ▲ | asciimov 17 hours ago | parent | next [-] |
| Isolation from the main system, other services, and other dependencies. Easy to migrate to new system. Easy to upgrade and downgrade. When a new version causes an issue just restart it with an older version. One directory to backup and restore that contains all the services and their settings. |
| |
| ▲ | bigstrat2003 16 hours ago | parent [-] | | A single binary accomplishes most of those things just fine. Only thing it doesn't get you is isolation, but you can isolate things if you want even then (for example, FreeBSD jails are dead easy to set up). | | |
| ▲ | c-hendricks 15 hours ago | parent | next [-] | | I use traefik so with docker compose/labels it's real easy to give things a reverse proxy with an auth gate and other middleware There's lots of solutions, I also find compose hits the sweet spot for integration into my homelab | |
| ▲ | eddythompson80 15 hours ago | parent | prev | next [-] | | ok, so you're just using a container with a different name? You can put the single binary in a container and call it a jail if it makes you feel better. | | |
| ▲ | solid_fuel 14 hours ago | parent [-] | | Well yes, but that's the point entirely - you can easily put a binary into a docker container, or a jail, or on a VM. But when something is shipped as 5 different docker containers it is MUCH harder to extract it into something you can run without docker or in a different configuration (like sharing a postgres instance between multiple applications). One distribution method is flexible and can be deployed however you want, the other prescribes solutions and makes any customization difficult. | | |
| ▲ | eddythompson80 14 hours ago | parent | next [-] | | I'm confused. The original post said "why docker compose? a single binary dominates any docker compose", (I assumed dominates here means wins over because it wouldn't make sense otherwise?) someone replied giving the additional benefit of containerization, then someone replied to that saying you get all those benefit from single binaries, and if you want the system isolation you can use a freebsd jail, which is like saying "if you want the benefit of containers you can use containers" Most applications do ship in a single container. whether it's a single binary inside, or a bunch of python or js files or shell scripts is a separate issue. If there is a dockerfile then you know how to build the container. a single binary is easier to build the container for yourself, assuming you also know the binary dependencies of that single binary. Like maybe ffmpeg or yt-dl cli on the path? Applications that ship as a list of containers are a completely different problem. Those applications are either a victim of their own success, or have developers that come from a particular background. | |
| ▲ | steezeburger 13 hours ago | parent | prev | next [-] | | I've never felt hindered by docker. It's pretty flexible. If I need even more flexibility I'm reaching for k8s, where I am still containerizing any single go binaries | |
| ▲ | nightski 14 hours ago | parent | prev | next [-] | | Are you saying it's hard to edit a docker compose file? Being one service or 5 doesn't really make things more complex. I often point servers at my own postgres container instead of spinning up an extra one (so just remove that from the compose for example). That's kind of the entire point of compose, it's so flexible. | |
| ▲ | steezeburger 13 hours ago | parent | prev [-] | | I mean I've seen many single go binaries spin up docker before haha |
|
| |
| ▲ | attilaolah 7 hours ago | parent | prev | next [-] | | Or bwrap on linux, which is probably good-enough for most services' isolation needs. | |
| ▲ | recroad 10 hours ago | parent | prev [-] | | Isolation is a pretty big deal to be glossed over. |
|
|
|
| ▲ | tracker1 12 hours ago | parent | prev | next [-] |
| A single config file in a directory beats all. All my home server apps are in /apps/app-name/ all have a docker config... All data and configurations are mounts under that directory or to my library. It's really straight forward. I don't have to hunt for different configuration files, each app has what it needs. I can spin down, move and get back up in a minute or two. All in a consistent way to the platform. The overhead for Docker isn't near a full vm, it's maybe 2-3% if that. |
|
| ▲ | zzyzxd 17 hours ago | parent | prev | next [-] |
| I don't use Docker but I love reading the compose file when a project has it. It is the quickest way for me to get a high level idea of this project's architecture. It's the best documentation :) |
| |
| ▲ | Lucasoato 16 hours ago | parent [-] | | This. Docker compose is so great that you don’t even need to use it, for it to be useful. It can describe so well the dependencies your system needs (alongside proper documentation). |
|
|
| ▲ | wilted-iris 17 hours ago | parent | prev | next [-] |
| It’s the unified interface for me. Updates, logs, service management, network routing, config and storage mapping are all uniform and I don’t have to wrangle many slightly different implementations of each. Isolation from installed packages is a nice bonus. |
|
| ▲ | steezeburger 13 hours ago | parent | prev | next [-] |
| I like to have consistent architecture across all my services, and I like to see and configure everything in (mostly) one place. If you're running a single go binary, sure do whatever, but if you're running a go binary, and a *arr stack, and a bookmarking service, home assistant, frigate, etc, it gets out of hand pretty quickly. You trade a bit of upfront setup (I mean barely now in the age of LLMs) for easier automation and flexibility down the road. I use docker compose to run my local dev stack and qa envs, but then can do whatever I want with the containers for prod. Google Cloud Run, Amazon, whatever. Right now I do just actually use docker compose behind nginx in prod, but I've used basically the same docker compose setup for all my projects that aren't large distributed systems in the last 10 years. And when the system gets too big, I refactor it into k8s, but k8s is overkill for like 99% of my personal projects and like 75% of my professional projects. |
|
| ▲ | dmtroyer 17 hours ago | parent | prev | next [-] |
| for long-running services, I've never taken the time to learn something reliable like systemd. with Compose, I can see everything I need to know in one yml file and the commands to go with it. I also don't have to really understand any dependencies or their own configuration and can cleanly remove everything associated with that service with a few commands. |
| |
| ▲ | JamesLeonis 14 hours ago | parent [-] | | You can use systemd and docker compose together. A systemd service is a single config file that runs the commands you give it, including `docker-compose` commands. Everything else about your service is still orchestrated via docker, and you can still run commands against the running containers just like before. A big win with very little effort is systemd starting your docker compose service on boot. You have your systemd config file set `ExecStart` to call your docker-compose command, throw the config file into your systemd folder, and tell systemd to enable it. Docker compose handles the rest. | | |
| ▲ | tracker1 12 hours ago | parent [-] | | You don't need systemd to restart your compose service... Just have the service set to restart always or unless stopped. And if you're running in Windows or Mac it's easier than the OS option usually. |
|
|
|
| ▲ | Balinares 8 hours ago | parent | prev | next [-] |
| I use Docker Compose so that I don't have to care if the daemon is a single binary or a whole stack: I can use the same setup for everything, and deploying an entire new thing in a maintainable way is quick and easy. Each app's startup/shutdown is managed using the same templated systemd unit, and Traefik handles the routing and Let's Encrypt cert creation and renewal. Basically I want things reliable and low-maintenance and this setup gives me that. |
|
| ▲ | jmbwell 16 hours ago | parent | prev | next [-] |
| I’ve been a die hard native package or static binary proponent for a long time. I still hold that there are real advantages. As podman has improved and compose stacks have improved, I’ve conceded that containers simplify deployment and updates and isolation, and at this point I find for me the benefits more than outweigh the hassles. Instead of crafting a set of ansible plays that do all the manual native installation steps, I have a relatively lightweight ansible rig that reads containers and relationships desired from a manifest in inventory, then builds or modifies compose files, then just deploys. Much less futzing. And I’m more likely to keep things up to date regularly as a result Or, increasingly, dispatch codex to handle it for me In this way I update home assistant across multiple instances now like magic. I don’t even dread it a little anymore |
|
| ▲ | turtlebits 17 hours ago | parent | prev | next [-] |
| Its a single config that lets you run multiple services (and can keep them running), upgrades are just editing an image tag. Don't have to look at cli docs to figure out how to run it. Doesn't have access to my file system, logs are easy. |
|
| ▲ | mrheosuper 12 hours ago | parent | prev | next [-] |
| Not OP, but i prefer a single binary on docker, at least i know it won't fuck up my filesystem when i do something stupid with it. Or at least i can reinstall any time i want, because i know it won't leave any trash in my filesystem and when reinstalling, it won't reuse those outdated files |
|
| ▲ | unshavedyak 17 hours ago | parent | prev | next [-] |
| Some isolation is nice. I say some because I’m told it’s security is not to be trusted, but I still like that even a non nefarious binary has ootb boundaries on what state will persist. |
| |
| ▲ | eddythompson80 15 hours ago | parent | next [-] | | docker isolation is nice just as a management boundary. It's nice to be sure applications don't accidently shit all over each other. Like an application that decides to clear /tmp because reasons, or 2 random ones that both store temp state in a /tmp/state.dat for some odd reason. My favorite is applications that conflict on ports. So you go to change the port an application is listening on, the docs say PORT env var so you set it, but it doesn't work. You look through the code (and this is before LLMs) but the config is just a labyrinth of values flowing from god knows where. So you search the repo for PORT and eventually find a PR from 2 weeks ago that changes PORT to ENDPOINT, so you set ENDPOINT, but it still doesn't work. Then you find an issue that was opened last night that the new `ENDPOINT` value doesn't load from env vars because it conflicts with another ENDPOINT_ prefix on another value, instead you need to create a config.toml and set an `endpoint =` in that, so you do that. Then you realize that creating an empty config.toml has now overridden all the previously defaulted values into nulls or empty strings, instead you need to run `foo config-defaults > config.toml` and go edit the endpoint one. Only to realize that there is a secret that the tool uses to encrypt an ephemeral session. if you don't specify one, the tool would auto generate one on startup. The only downside is restarting it logs your client out which isn't a big deal. But now that you switched to config.toml you must set some value there and it can't be empty Then you're just wondering why the hell did I want to change the port? | |
| ▲ | Gigachad 17 hours ago | parent | prev [-] | | Docker isolation is likely good enough if you keep your kernel up to date and aren't allowing 3rd parties to run code. If you are running a CI service or something you need micro VMs. But to host your nextcloud server, docker is good enough, it's unlikely someone will both exploit nextcloud and the kernel if you are keeping them up to date. | | |
|
|
| ▲ | surgical_fire 15 hours ago | parent | prev [-] |
| I too prefer the Docker compose route. If you give me a single binary, I'll go out of my way to run it inside a compose stack. I manage my home server with a script that presumes the service is running on a compose stack. So I can run stuff like `stack freshrss restart`. I don't want to touch my scripts, I just add the compose file to some expected path and the script finds it based on naming conventions. |
