12 ms·

Docker Compose Isn't Enough

126 points by hartspear 2y ago

indulona 2y ago
or, just use your hardware without unnecessary isolation.
hartspear 2y ago
[flagged]
PittleyDunkin 2y ago
Curious! I think of docker-compose as squeezing a cluster onto a workstation—not exactly a tool you'd look to for anything other than home servers or conveniently-low workloads.
- yjftsjthsd-h 2y ago
  Speaking as someone who has deployed docker-compose apps to hundreds of servers at one company... It's fine. Depends what you're doing.
oceanparkway 2y ago
Definitely burying the lede that Tealok is building an alternative to docker compose. Interesting
- wmf 2y ago
  It's called content marketing. IMO this article is content marketing done right since it has useful information even if you don't read to the end.
  - lenova 2y ago
    Agreed. By default I'm against content marketing. But as a person that has played around a lot in the /r/selfhosted scene, I had to agree with all of the use-case issues mentioned in the article when it comes to managing your self-hosted apps in Docker Compose (and I say this as someone that legitimately enjoys working with Docker). I'm still not clear from the website what Tealok actually is in terms of a product offering, but I appreciate that the blog post was legit and not just SEO spam.
  - lolinder 2y ago
    Does it, though? It has a very brief introduction to Docker and Docker Compose, but then it mostly has a lot of FUD that's designed to scare people off of Docker Compose but is not remotely convincing to someone who's actually worked with it. The way they frame that pihole example ("Whew! That’s a lot of stuff!") is just silly. Looking at their website, I think they started out trying to make self-hosting really easy for a barely-technical user [0], which accounts for their attitude towards docker-compose, but it also means that the post was pretty devoid of useful information for someone who actually wants to self-host with the tech that's already ubiquitous today. [0] https://tealok.tech/ https://tealok.tech/
    - tommica 2y ago
      Anecdotal, but I learned stuff from this article
    - eliribble 2y ago
      > The way they frame that pihole example ("Whew! That’s a lot of stuff!") is just silly. Yeah, you're probably right. Originally that line was in there when I had a breakdown of what each line in the docker-compose was doing. My editor thought that was unnecessary - it's unlikely people reading the post would need that kind of breakdown. So I rewrote parts to assume more baseline knowledge. I should have noticed that line and taken it out. You're right about what we're trying to do, and I agree that the post doesn't really help someone be successful today deploying things. The post is more meant to gauge whether or not I'm alone in having pain deploying a couple dozen services with docker compose on a single box. I want more people to have the power to host their own services. I think we can do that, but we have to figure out the right thing to build to do it.
  - denkmoon 2y ago
    Looks like a grift. Note the copyright on the Tealok page, then have a gander; https://gleipnirinc.com/investors https://gleipnirinc.com/investors
    - eliribble 2y ago
      Blog post author here - that's the right company name, but not the right company website. Our company doesn't have a website yet. Looks like we may share a company name with some grifters. That's what we get for making our name an obscure mythological reference.
- nicce 2y ago
  More interesting is that there are tons of tools that convert docker-compose files to Kubernetes on the fly. Minikube and friends are pretty good and solves all the problems, in a more battle-tested way. So what is the real business opportunity here?
williamstein 2y ago
No mention of Kubernetes (and k3s, etc.)
- osigurdson 2y ago
  My first thought as well.
czhu12 2y ago
Shameless plug: I’m building https://canine.sh 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 pretty seamlessly with it on a $24/month digital ocean server. Would love any feedback!
- FaceValuable 2y ago
  Is canine.sh hosted on Canine?
  - czhu12 2y ago
    Yep! I should mention that on the website. The only thing that was innovative about that is doing docker-in-docker builds which is as simple as mounting /var/run/docker.sock:/var/run/docker.sock in the container. Zero downtime deploys make it sensible for it to deploy itself, and then restart. And it really breaks, I still know how to deploy from my laptop to get myself out of a pickle.
- wink 2y ago
  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.
  - czhu12 2y ago
    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
Izkata 2y ago
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/ https://docs.docker.com/compose/releases/migrate/
- wmf 2y ago
  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.
  - chipdart 2y ago
    > 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 orchestration tool and complains it doesn't backup the database they just rolled out. > In that context many people find k8s or other PaaS to be too heavyweight so Docker Compose is pretty popular. ...and proceed to put pressure to shitify it by arguing it should do database backups, something that even Kubernetes stays clear from. The blogger doesn't even seem to have done any research whatsoever on reverse proxies. 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. He would also have researchdd what it means to support TLS and how this is not a container orchestration responsibility. Quite bluntly, this blog post reads as if it was written by someone who researched nothing on the topic and decided instead to jump to
    - 2y ago
brody_hamer 2y ago
Comparing oneself to docker compose is a straw man, when docker’s production option is docker swarm.
- snapetom 2y ago
  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.
  - ethagnawl 2y ago
    I thought Swarm had been deprecated? I just took a quick look into it and (classic) Swarm was deprecated and ... replaced by Swarm (mode).
    - feisty0630 2y ago
      Wait until you find out about 'docker-compose' vs 'docker compose'!
      - nickfixit 2y ago
        Probably before llms figure it out
bilbo-b-baggins 2y ago
Docker Compose is … not for that use case. Docker Swarm is for hosting, but really only for trivial cases. Anything more complex deserves a full container orchestration platform.
ricw 2y ago
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 details see https://docs.docker.com/compose/how-tos/multiple-compose-files/merge/ https://docs.docker.com/compose/how-tos/multiple-compose-fil... 2) this is literally as simple as running a small bash script that creates a backup, tars and gzips the file and then uploads it to an S3 repository. Sure, maybe not out of the box, but generally pretty simple. Likewise i'd always have a script that does the inverse (downloads the latest backup, loads it into the db and restores the files). Not exactly rocket science...
- throwitawayfam 2y ago
  For #2 I use https://kopia.io/ https://kopia.io/ and upload to Backblaze b3 (S3 api)
- shubhamjain 2y ago
  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.
  - number6 2y ago
    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
    - eliribble 2y ago
      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?
hipadev23 2y ago
I manage production with docker compose just fine. This article is not great.
WifiAdapter 2y ago
After reading it I don't get what the author is trying to tell me. Docker compose works just fine for what it's made. I can have multiple different docker containers (deployed with compose) all with the same port and just use Traefik to route the requests, without having to change the default ports or even use ipv6. What am I missing?
- eliribble 2y ago
  Interesting, I wasn't aware that Traefik could do this without significant modification to the docker-compose configuration provided by the application developer. I also thought that Traefik required some sort of higher-level container orchestration like Docker Swarm or Kubernetes. I'll have to look in to that.
cyberax 2y ago
I'm moving into self-hosting for myself (photos, books, GPS tracks, exercise tracking) and so far Docker Compose has been perfect for me. I'm using Synology NAS which has a nice GUI manager for Docker-Compose. So I put all the data volumes on btrfs, and I snapshot them every day. Then I sync snapshots to Wasabi via duplicacy. It works amazingly well. No problems whatsoever. I guess having a nice front-end that shows the overall overview would be nice, but I can live without it.
zemo 2y ago
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.
- SomeCallMeTim 2y ago
  Ha. Just did almost exactly that, but with a Go script--I wanted my Docker Compose to auto-update when I built on my CI server. I found Watchtower, but polling just struck me as the Wrong Answer. Both too much overhead to keep pinging for the latest builds, and too slow to actually download the latest build. So I took some hints from Watchtower as to what I needed to do (mount the docker sock as a volume) and wrote a tiny Go server that, when pinged with a shared secret, would cause it to run `docker compose up -d --pull always`. Probably took me an hour. Then I added the ability to purge images before each update, because my tiny VM kept running out of disk space in the Docker partition. Oops. Scripts FTW. I was already using the suggestion in the article about having a single reverse proxy server to redirect different paths (and different domains) to different servers hosted in the Compose file. Seemed like the obvious answer. And I've configured k8s for my day job, so I could be using that. But I'm using Compose because I know how much of a pain k8s can be, especially around upgrades, where it has a habit of deprecating older versions of various interfaces. I'll put in the work for someone who's paying me to do it, but I'd rather work on my side project, not on configuring k8s.
  - morcus 2y ago
    > I found Watchtower, but polling just struck me as the Wrong Answer. Both too much overhead to keep pinging for the latest builds, and too slow to actually download the latest build. So I took some hints from Watchtower as to what I needed to do (mount the docker sock as a volume) and wrote a tiny Go server that, when pinged with a shared secret, would cause it to run `docker compose up -d --pull always`. Is the code for this public? I had the same desire when setting up the server for my personal project but as you mentioned I eventually decided it was OK to just poll every two minutes and I would rather work on the project than on configuring docker. What I would like though is cleaning up the older images that are no longer needed.
ongy 2y ago
They don't mention it in the article, but by default ports 80 and 443 require elevated privileges. There's some (namespaces) knob to avoid that, but the lack of nod to it makes me worried. OTOH containers as security boundary is iffy. But I still like them to not be root in case of compromise
deleted 2y ago
[deleted]
peterkelly 2y ago
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.
- aitchnyu 2y ago
  Is there a popular project which puts systemd and multiple processes in a container? I've seen only single process containers so far.
  - throwaway74354 2y ago
    LXD/Incus for hypervisor-for-containers use-case. Podman for "like Docker, but made by Linux people". It supports both application containers and system containers (which have systemd as PID 1).
  - msgilligan 2y ago
    systemd-nspawn might be what you are looking for: https://wiki.debian.org/nspawn https://wiki.debian.org/nspawn
paxys 2y ago
I know this is content marketing fluff for their own product, but complaining that Docker Compose isn't a full-fledged web application platform is idiotic. Use something like Dokku if you need such a solution.
forrestthewoods 2y ago
Containers were a mistake. This is all radically more complicated than it needs to be. Running a computer program is not that complicated.
- revskill 2y ago
  It is an abstraction.
  - forrestthewoods 2y ago
    Many abstractions are very bad. Stacking bad abstractions on bad abstractions is why modern software is so slow, laggy, and bloated.
    - theshrike79 2y ago
      What would be your solution to running, say, 15 different Python applications on the same machine, each requiring a unique set of library versions?
      - forrestthewoods 2y ago
        Create 15 pex files. Or possibly 15 PyInstaller executables. Then simply run them like normal programs.
        Capricorn2481 2y ago
        Ah yes let's not use bad abstractions like docker, let's use pyinstaller...
        dlainhart 2y ago
        Why would you load an entire userspace environment just to manage a Python package's Python dependencies? Seems a little heavy.
      - 2y ago
whydoineedthis 2y ago
This is a fun problem to see on here (for me) - because I solved a lot of these problems at my last company when I built them a dev enviroment that ran over 30 services, and growing. It was written as a makefile that wrapped docker compose commands, but that's just because it was the easiest to mvp. I considered it a "framework for running a large collection of containers locally". I solved the ports issue by using env vars like a switchboard, with an iPortService=<inside container port> and oPortService=<outside network port unique to network-layer> Then i used two directories, one for a data layer that ran datastores, and one for app, for apps. You controlled the layers as groups. You could operate the layers separately, initialize the dbs, and also reset their storage state definitely. Then I had to solve the "docker ps" output problem, since its unreadable. So, i just split it to 3 commands: state,ports, & running. It outputs what you expect. I should re-write it into better code and open source it. It was fun to build.
lolinder 2y ago
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/ https://tealok.tech/
- eliribble 2y ago
  Yeah, we're very early building this, the blog post is just a way for me to organize my thoughts and start fights online. It's, uh, embarrassingly useful to yell semi-coherent thoughts into the void and have experts yell back with a decade or more of experience and information about tools I haven't heard of. > 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. Yes, this is an excellent point. I did not articulate it well anywhere, but the goal is for users to have something more like Sandstorm, with a UI to install things. The TOML is for application developers, not end users. It'll either go in a separate database or, ideally, in the source code of the applications to be installed similar to a Dockerfile. I haven't started yet, but eventually we need to work with application developers to support things they want and to make it easier to treat Tealok as the "easy option" rather than docker compose.
  - lolinder 2y ago
    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 your file format is objectively better for the purpose, it's going to be hard to overcome the inertia.
deleted 2y ago
[deleted]
mnahkies 2y ago
I've cobbled together some scripts around docker compose that largely solves these problems for me (https://github.com/mnahkies/shoe-string-server 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/docs%2Fpostgres.md 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
osigurdson 2y ago
>> 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.
- wink 2y ago
  I'm using YAML despite it being garbage. (feels more common)
  - osigurdson 2y ago
    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.
    - rubinelli 2y ago
      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 https://github.com/lightbend/config/blob/main/HOCON.md
      - osigurdson 2y ago
        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.
mkarrmann 2y ago
I'm pretty confused by this article. It says docker compose is at the "wrong-level of abstraction", but I kept feeling the author was instead expecting docker compose to solve different problems that it was ever meant to solve. In fact, they seem to be expecting a highly-opinionated, high-level interface which solves problems that I don't think anyone using docker compose in prod should even be worried about. A lot of concerns seem to be around avoiding spinning up duplicate instances of reverse proxies, databases, and caches. First of all, why is this a concern? Idle threads have basically no impact on a system, so this generally isn't a concern. This is a nuanced and context-dependent issue, but generally it won't even make the list of top-100 performance bottlenecks for most applications. Yet the article takes for granted that the benefits of solving this problem outweigh the many cons of coupling them together. Even if you wanted to enforce your applications sharing a postgres instance under the hood, why would you want that to be black-magic performed by the container orchestrator? Other stuff like DB backups just don't seem like issues docker compose users have. If you need to orchestrate across multiple nodes in order to meet your SLOs, then don't use docker compose. Finally, it seems like the actual solution is significantly under-discussed. I both have tons of questions about how it's supposed to work, and I see lots of shortcomings with the parts that I do understand. Beyond the specific issues I see, the fundamental attitude seems to be "force everyone to architect their applications in a very specific way, and don't even try to support any use cases which fall outside of it". You need a damn good reason to be that opinionated about these sorts of things, and it by definition will only work well in specific contexts. I'd be interested to read an article which tried to articulate why such an opinionated API would improve SDLC-considerations over docker-compose, but I don't think that's the article I just read.
- eliribble 2y ago
  These are great points, and probably worth their own blog post to answer. > First of all, why is this a concern? Idle threads have basically no impact on a system, so this generally isn't a concern Idle threads have very low impact on CPU utilization, probably, if the application is well-behaved (and I expect most databases and caching layers to be well-behaved in this way). The application itself, however, will need memory and the way containers are built prevents the usual de-deplication of system libraries. > but generally it won't even make the list of top-100 performance bottlenecks for most applications True, but it makes the short list of "how much stuff can I run on a $100 computer", and it's one of the relatively few concerns an application operator has when they are not the application developer. > Even if you wanted to enforce your applications sharing a postgres instance under the hood, why would you want that to be black-magic performed by the container orchestrator? To make self-hosting much simpler. If the container orchestrator doesn't do it, what do you think should do it? > Other stuff like DB backups just don't seem like issues docker compose users have. If you need to orchestrate across multiple nodes in order to meet your SLOs, then don't use docker compose. The DB backups are meant for disaster recovery rather than supporting multiple nodes. I guess that's multiple nodes through time... But, yeah, I agree, docker-compose is not a good fit. > Finally, it seems like the actual solution is significantly under-discussed. I both have tons of questions about how it's supposed to work, and I see lots of shortcomings with the parts that I do understand. Yeah, agreed, I'll be writing other things to discuss what I think the correct solution should be. I'm curious to find out if other people have existing solutions to the problems I outlined. If it's a solved problem and I just don't know about it, that'd be better. > I'd be interested to read an article which tried to articulate why such an opinionated API would improve SDLC-considerations over docker-compose, but I don't think that's the article I just read. It is not, and you're right, it needs discussion.
zerof1l 2y ago
As someone who is self-hosting with a docker on my own server, I don't see the negatives mentioned in this article as being a problem at all. Quite the opposite, it gives you the freedom to do your docker setup how you want it. It took me some time initially to figure things out and I had to learn some things. But now it's a breeze. Once I had reverse proxy and automatic certificate renewal in place it has been working ever since then without me having to do anything. Adding a new service like Immisch or Jellyfin takes me an hour or less. Which can be quicker, but I adjust every docker compose to my setup and make it more secure. E.g. I create a new non-root user for each service. Basically I have the whole setup figured out; I have notes and checklists for the new services I add. I don't need to figure out things anymore and in 95% of the cases things just work. Updating existing services takes minutes: just increment the version in the compose file and rebuild. For my setup, I use macvlan as opposed to the default docker bridge network. So, the `ports: - "8000:5000"` docker compose config is being ignored. Instead, each docker container gets its own unique IP and MAC address I assign to it. It can then use any port it wants. Thanks to this, on my home network, I can access any container I want by IP. And any container can access any other container. I then add some restrictions for security purposes on the host machine using nftables. For reverse proxy, I use Nginx Proxy Manager which is a simplified GUI around Nginx. I'm slowly moving to just using Nginx. For the database, I run multiple instances of Postgres and MySQL and I don't see any issues. They take an insignificant amount of resources compared to the applications. If the application is not in use, its database instance is not being used as well.
Timber-6539 2y ago
Docker is simply a packaging format with docker compose being a wrapper for docker run. Author seems to confuse general application issues with docker's. Article wasn't convincing enough about docker compose's shortcomings. The linked github's README even less convincing. But to each his own.
notpushkin 2y ago
I’ve been building a Docker Swarm based server dashboard for a couple years now. It should help with some of problems mentioned in the post: https://lunni.dev/ https://lunni.dev/ I like the ideas mentioned though! Docker Compose is pretty good, but something more declarative would definitely be a plus. Would love to see where the project goes (and maybe will borrow some things for the future versions of mine :-)
echoangle 2y ago
I don’t get why docker doesn’t include a simple command (docker backup volumexyz mybackup.tar.gz) that creates an archive from a volume. Why do I have to do that myself by mounting the volume in a second container? Ok, there might be volumes that can’t be backed up (mounted sockets for example), but that could just give an error message.
rthnbgrredf 2y ago
If docker compose is not enough I would suggest to look into some of the lightweight k8s distributions like k3s, with low ressource consumption and able to operate on a single node.
dankle 2y ago
Just use k8s for prod. Docker compose is great for local dev, i would never dream of deploying to prod with compose.
- SOLAR_FIELDS 2y ago
  Sure. But that’s not the point of the article. The articles point is “Docker Compose is too complicated”, then proposes a half baked implementation of a solution that hand waves away of all that complexity with a scenario that will fulfill their specific use case but will completely fall apart when it diverges from the specific way they’ve decided to build the abstraction layer. The problem that the author refuses to accept is that deployment is inherently complex. It does require configuration of a lot of things because it supports every use case. So you either have a generic complex tool that everyone can use (like Docker Compose or Kube) or you have some specific tool that only works for a tiny subset of all users that is simpler that satisfies your use case. Note that I’m not saying Docker Compose is perfect. The syntax is a bit arcane it’s complex to understand etc. But removing the complexity by removing configuration options is not the solution here. Instead the author should focus on different approaches and tools to manage the same existing level of abstraction. And for what it’s worth, that’s essentially what Helm is for kube - a way to manage and hide away the complexity of kube manifests (but still use those manifests under the hood). But frankly, docker compose doesn’t need a helm. Because docker compose, as you point out, has value not as a deployment tool, but as a single file that developers can manage and spin up on their local machines in a manageable way that doesn’t have the author fighting YAML all day. I would say if the author was actually interested in solving this problem in a productive way they should first try to see if docker itself is amenable to altering their constructs to provide optional higher abstractions over common concepts via the compose interface natively. If the source tools roll out those abstractions everyone will get them and adopt them.
  - hluska 2y ago
    I could come out with some counterpoints, but you’re too abrasive to even engage with. It’s sad what this place has become.
mythz 2y ago
Docker Compose/SSH and some custom GitHub Actions to run DB Migrations is simple, straightforward and was more than enough to manage CI deployments all our Apps [1]. Although we're currently migrating to Kamal [2] to take advantage of its nicer remote setup, management and monitoring features. [1] https://docs.servicestack.net/ssh-docker-compose-deploment https://docs.servicestack.net/ssh-docker-compose-deploment [2] https://kamal-deploy.org https://kamal-deploy.org
zb3 2y ago
It is enough for me, and the title doesn't mention that this post promotes the alternative.
bityard 2y ago
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" container orchestration product where there's extra upstream development between you and the docker image. Docker compose can run anything you can stuff into a container. This cannot, without some additional development. That may be value in that, but I'm not sure blasting docker compose as old and busted right out of the starting gate is a terrific marketing strategy.
- eliribble 2y ago
  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."
datadeft 2y ago
In summary: Accidental complexity, accidental complexity, accidental complexity and when we use a tool that is designed for problem A for a problem B it is not sufficiently dealing with complexity. This is why we need a new tool. ¯\_(ツ)_/¯
- eliribble 2y ago
  While a bit of a hot take, you're not wrong. We need something that's less scalability focused than Kubernetes/Mesos/Docker Swarm but that doesn't put too much burden on application developers. Something that focuses on being secure, reliable, and understandable, in that order. I'm not aware of anything going for that niche. That means a new tool is in order.
  - datadeft 2y ago
    I think we need a composable system but I am not sure if the current frame where this problem and these tools exist is good enough. We might need to rethink how we handle access and usage patterns well. I only have wrong answers. Docker compose is amazing for local dev env, k8s is terrible for production. These are my experiences with this domain.
raphinou 2y ago
I am particularly happy with docker swarm with traefik as described here: https://dockerswarm.rocks/traefik/ 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 quite some people trying to replicate swarm's features with docker compose, but often in harder to maintain setups.
- eliribble 2y ago
  Looks like https://dockerswarm.rocks https://dockerswarm.rocks says that the site is deprecated. https://dockerswarm.rocks/swarm-or-kubernetes/ https://dockerswarm.rocks/swarm-or-kubernetes/ says "it's not sensible to build a new product using Docker Swarm Mode"
  - raphinou 2y ago
    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/ https://www.yvesdennels.com/posts/docker-swarm-in-2022/
- therealfiona 2y ago
  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 to down size my team because of it. One thing K8s is not is cheap. That shit takes a well oiled team or a couple of hot shots so do right. We probably did a lot of what makes it expensive to ourselves by not switching to managed add-ons sooner and never evolving the apps that run in the cluster. I've only been lead for about 5 months now, but I'm finally able to start making significant progress on the necessary evolution that I've been trying to make happen for 2 years before my promotion. The enterprise is a big ship. Takes time to turn. Thanks for reading what turned into a rambling vent session.
hbogert 2y ago
i've been at the edges of docker-compose. We were always conceptually recreating kubernetes. I'm so happy we've got k8s now and sparingly use some operators where needed, couldn't be happier. The obvious example was certificate management. Cert-manager alone is almost worth setting up K8s if you have many ingresses/fqdns.
mmcnl 2y ago
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.
sureglymop 2y ago
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.
nunez 2y ago
I'm having this problem now with our home automation stack. Compose is super easy to start with but scales poorly and makes things like "I want to access this service at https://foo.bar https://foo.bar instead of http://somehost:61234 http://somehost:61234, no HTTPS because the app doesn't support it natively and I don't have time to roll nginx." Kubernetes makes this so easy once you get past the YAML and abstractions, so I'll probably FINALLY move this stack over to it. Long overdue. And this is coming from someone who for the longest time recommended that developers new to containers start with compose before considering Kubernetes!
freeone3000 2y ago
scaling docker compose to multiple machines is traditionally the realm of kubernetes. I’m not seeing any suggestion here that’s better than dropping in k3s
leosarev 2y ago
I also think that both docker-compose & k8s & helm are wrong layer of abstraction. I see a lot of people building a opinionated way to run containers and way for them to communicate with another, to request a DB or a redis. I like to name some such attempts: - .NET Aspire - Avito Plato (home grown PaaS of ¨russian Amazon") - infrastructure layer of our ZIIoT (MES platform on top of k8s)

126 points by hartspear 2y ago

indulona 2y ago

or, just use your hardware without unnecessary isolation.

hartspear 2y ago

[flagged]

PittleyDunkin 2y ago

Curious! I think of docker-compose as squeezing a cluster onto a workstation—not exactly a tool you'd look to for anything other than home servers or conveniently-low workloads.

yjftsjthsd-h 2y ago
Speaking as someone who has deployed docker-compose apps to hundreds of servers at one company... It's fine. Depends what you're doing.

oceanparkway 2y ago

Definitely burying the lede that Tealok is building an alternative to docker compose. Interesting

wmf 2y ago
It's called content marketing. IMO this article is content marketing done right since it has useful information even if you don't read to the end.
- lenova 2y ago
  Agreed. By default I'm against content marketing. But as a person that has played around a lot in the /r/selfhosted scene, I had to agree with all of the use-case issues mentioned in the article when it comes to managing your self-hosted apps in Docker Compose (and I say this as someone that legitimately enjoys working with Docker). I'm still not clear from the website what Tealok actually is in terms of a product offering, but I appreciate that the blog post was legit and not just SEO spam.
- lolinder 2y ago
  Does it, though? It has a very brief introduction to Docker and Docker Compose, but then it mostly has a lot of FUD that's designed to scare people off of Docker Compose but is not remotely convincing to someone who's actually worked with it. The way they frame that pihole example ("Whew! That’s a lot of stuff!") is just silly. Looking at their website, I think they started out trying to make self-hosting really easy for a barely-technical user [0], which accounts for their attitude towards docker-compose, but it also means that the post was pretty devoid of useful information for someone who actually wants to self-host with the tech that's already ubiquitous today. [0] https://tealok.tech/ https://tealok.tech/
  - tommica 2y ago
    Anecdotal, but I learned stuff from this article
  - eliribble 2y ago
    > The way they frame that pihole example ("Whew! That’s a lot of stuff!") is just silly. Yeah, you're probably right. Originally that line was in there when I had a breakdown of what each line in the docker-compose was doing. My editor thought that was unnecessary - it's unlikely people reading the post would need that kind of breakdown. So I rewrote parts to assume more baseline knowledge. I should have noticed that line and taken it out. You're right about what we're trying to do, and I agree that the post doesn't really help someone be successful today deploying things. The post is more meant to gauge whether or not I'm alone in having pain deploying a couple dozen services with docker compose on a single box. I want more people to have the power to host their own services. I think we can do that, but we have to figure out the right thing to build to do it.
- denkmoon 2y ago
  Looks like a grift. Note the copyright on the Tealok page, then have a gander; https://gleipnirinc.com/investors https://gleipnirinc.com/investors
  - eliribble 2y ago
    Blog post author here - that's the right company name, but not the right company website. Our company doesn't have a website yet. Looks like we may share a company name with some grifters. That's what we get for making our name an obscure mythological reference.
nicce 2y ago
More interesting is that there are tons of tools that convert docker-compose files to Kubernetes on the fly. Minikube and friends are pretty good and solves all the problems, in a more battle-tested way. So what is the real business opportunity here?

williamstein 2y ago

No mention of Kubernetes (and k3s, etc.)

osigurdson 2y ago
My first thought as well.

czhu12 2y ago

Shameless plug: I’m building https://canine.sh 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 pretty seamlessly with it on a $24/month digital ocean server. Would love any feedback!

FaceValuable 2y ago
Is canine.sh hosted on Canine?
- czhu12 2y ago
  Yep! I should mention that on the website. The only thing that was innovative about that is doing docker-in-docker builds which is as simple as mounting /var/run/docker.sock:/var/run/docker.sock in the container. Zero downtime deploys make it sensible for it to deploy itself, and then restart. And it really breaks, I still know how to deploy from my laptop to get myself out of a pickle.
wink 2y ago
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.
- czhu12 2y ago
  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

Izkata 2y ago

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/ https://docs.docker.com/compose/releases/migrate/

wmf 2y ago
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.
- chipdart 2y ago
  > 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 orchestration tool and complains it doesn't backup the database they just rolled out. > In that context many people find k8s or other PaaS to be too heavyweight so Docker Compose is pretty popular. ...and proceed to put pressure to shitify it by arguing it should do database backups, something that even Kubernetes stays clear from. The blogger doesn't even seem to have done any research whatsoever on reverse proxies. 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. He would also have researchdd what it means to support TLS and how this is not a container orchestration responsibility. Quite bluntly, this blog post reads as if it was written by someone who researched nothing on the topic and decided instead to jump to
  - 2y ago

brody_hamer 2y ago

Comparing oneself to docker compose is a straw man, when docker’s production option is docker swarm.

snapetom 2y ago
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.
- ethagnawl 2y ago
  I thought Swarm had been deprecated? I just took a quick look into it and (classic) Swarm was deprecated and ... replaced by Swarm (mode).
  - feisty0630 2y ago
    Wait until you find out about 'docker-compose' vs 'docker compose'!
    - nickfixit 2y ago
      Probably before llms figure it out

bilbo-b-baggins 2y ago

Docker Compose is … not for that use case. Docker Swarm is for hosting, but really only for trivial cases. Anything more complex deserves a full container orchestration platform.

ricw 2y ago

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 details see https://docs.docker.com/compose/how-tos/multiple-compose-files/merge/ https://docs.docker.com/compose/how-tos/multiple-compose-fil... 2) this is literally as simple as running a small bash script that creates a backup, tars and gzips the file and then uploads it to an S3 repository. Sure, maybe not out of the box, but generally pretty simple. Likewise i'd always have a script that does the inverse (downloads the latest backup, loads it into the db and restores the files). Not exactly rocket science...

throwitawayfam 2y ago
For #2 I use https://kopia.io/ https://kopia.io/ and upload to Backblaze b3 (S3 api)
shubhamjain 2y ago
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.
- number6 2y ago
  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
  - eliribble 2y ago
    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?

hipadev23 2y ago

I manage production with docker compose just fine. This article is not great.

WifiAdapter 2y ago

After reading it I don't get what the author is trying to tell me. Docker compose works just fine for what it's made. I can have multiple different docker containers (deployed with compose) all with the same port and just use Traefik to route the requests, without having to change the default ports or even use ipv6. What am I missing?

eliribble 2y ago
Interesting, I wasn't aware that Traefik could do this without significant modification to the docker-compose configuration provided by the application developer. I also thought that Traefik required some sort of higher-level container orchestration like Docker Swarm or Kubernetes. I'll have to look in to that.

cyberax 2y ago

I'm moving into self-hosting for myself (photos, books, GPS tracks, exercise tracking) and so far Docker Compose has been perfect for me. I'm using Synology NAS which has a nice GUI manager for Docker-Compose. So I put all the data volumes on btrfs, and I snapshot them every day. Then I sync snapshots to Wasabi via duplicacy. It works amazingly well. No problems whatsoever. I guess having a nice front-end that shows the overall overview would be nice, but I can live without it.

zemo 2y ago

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.

SomeCallMeTim 2y ago
Ha. Just did almost exactly that, but with a Go script--I wanted my Docker Compose to auto-update when I built on my CI server. I found Watchtower, but polling just struck me as the Wrong Answer. Both too much overhead to keep pinging for the latest builds, and too slow to actually download the latest build. So I took some hints from Watchtower as to what I needed to do (mount the docker sock as a volume) and wrote a tiny Go server that, when pinged with a shared secret, would cause it to run `docker compose up -d --pull always`. Probably took me an hour. Then I added the ability to purge images before each update, because my tiny VM kept running out of disk space in the Docker partition. Oops. Scripts FTW. I was already using the suggestion in the article about having a single reverse proxy server to redirect different paths (and different domains) to different servers hosted in the Compose file. Seemed like the obvious answer. And I've configured k8s for my day job, so I could be using that. But I'm using Compose because I know how much of a pain k8s can be, especially around upgrades, where it has a habit of deprecating older versions of various interfaces. I'll put in the work for someone who's paying me to do it, but I'd rather work on my side project, not on configuring k8s.
- morcus 2y ago
  > I found Watchtower, but polling just struck me as the Wrong Answer. Both too much overhead to keep pinging for the latest builds, and too slow to actually download the latest build. So I took some hints from Watchtower as to what I needed to do (mount the docker sock as a volume) and wrote a tiny Go server that, when pinged with a shared secret, would cause it to run `docker compose up -d --pull always`. Is the code for this public? I had the same desire when setting up the server for my personal project but as you mentioned I eventually decided it was OK to just poll every two minutes and I would rather work on the project than on configuring docker. What I would like though is cleaning up the older images that are no longer needed.

ongy 2y ago

They don't mention it in the article, but by default ports 80 and 443 require elevated privileges. There's some (namespaces) knob to avoid that, but the lack of nod to it makes me worried. OTOH containers as security boundary is iffy. But I still like them to not be root in case of compromise

deleted 2y ago

[deleted]

peterkelly 2y ago

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.

aitchnyu 2y ago
Is there a popular project which puts systemd and multiple processes in a container? I've seen only single process containers so far.
- throwaway74354 2y ago
  LXD/Incus for hypervisor-for-containers use-case. Podman for "like Docker, but made by Linux people". It supports both application containers and system containers (which have systemd as PID 1).
- msgilligan 2y ago
  systemd-nspawn might be what you are looking for: https://wiki.debian.org/nspawn https://wiki.debian.org/nspawn

paxys 2y ago

I know this is content marketing fluff for their own product, but complaining that Docker Compose isn't a full-fledged web application platform is idiotic. Use something like Dokku if you need such a solution.

forrestthewoods 2y ago

Containers were a mistake. This is all radically more complicated than it needs to be. Running a computer program is not that complicated.

revskill 2y ago
It is an abstraction.
- forrestthewoods 2y ago
  Many abstractions are very bad. Stacking bad abstractions on bad abstractions is why modern software is so slow, laggy, and bloated.
  - theshrike79 2y ago
    What would be your solution to running, say, 15 different Python applications on the same machine, each requiring a unique set of library versions?
    - forrestthewoods 2y ago
      Create 15 pex files. Or possibly 15 PyInstaller executables. Then simply run them like normal programs.
      - Capricorn2481 2y ago
        Ah yes let's not use bad abstractions like docker, let's use pyinstaller...
        dlainhart 2y ago
        Why would you load an entire userspace environment just to manage a Python package's Python dependencies? Seems a little heavy.
    - 2y ago

whydoineedthis 2y ago

This is a fun problem to see on here (for me) - because I solved a lot of these problems at my last company when I built them a dev enviroment that ran over 30 services, and growing. It was written as a makefile that wrapped docker compose commands, but that's just because it was the easiest to mvp. I considered it a "framework for running a large collection of containers locally". I solved the ports issue by using env vars like a switchboard, with an iPortService=<inside container port> and oPortService=<outside network port unique to network-layer> Then i used two directories, one for a data layer that ran datastores, and one for app, for apps. You controlled the layers as groups. You could operate the layers separately, initialize the dbs, and also reset their storage state definitely. Then I had to solve the "docker ps" output problem, since its unreadable. So, i just split it to 3 commands: state,ports, & running. It outputs what you expect. I should re-write it into better code and open source it. It was fun to build.

lolinder 2y ago

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/ https://tealok.tech/

eliribble 2y ago
Yeah, we're very early building this, the blog post is just a way for me to organize my thoughts and start fights online. It's, uh, embarrassingly useful to yell semi-coherent thoughts into the void and have experts yell back with a decade or more of experience and information about tools I haven't heard of. > 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. Yes, this is an excellent point. I did not articulate it well anywhere, but the goal is for users to have something more like Sandstorm, with a UI to install things. The TOML is for application developers, not end users. It'll either go in a separate database or, ideally, in the source code of the applications to be installed similar to a Dockerfile. I haven't started yet, but eventually we need to work with application developers to support things they want and to make it easier to treat Tealok as the "easy option" rather than docker compose.
- lolinder 2y ago
  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 your file format is objectively better for the purpose, it's going to be hard to overcome the inertia.

deleted 2y ago

[deleted]

mnahkies 2y ago

I've cobbled together some scripts around docker compose that largely solves these problems for me (https://github.com/mnahkies/shoe-string-server 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/docs%2Fpostgres.md 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

osigurdson 2y ago

>> 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.

wink 2y ago
I'm using YAML despite it being garbage. (feels more common)
- osigurdson 2y ago
  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.
  - rubinelli 2y ago
    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 https://github.com/lightbend/config/blob/main/HOCON.md
    - osigurdson 2y ago
      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.

mkarrmann 2y ago

I'm pretty confused by this article. It says docker compose is at the "wrong-level of abstraction", but I kept feeling the author was instead expecting docker compose to solve different problems that it was ever meant to solve. In fact, they seem to be expecting a highly-opinionated, high-level interface which solves problems that I don't think anyone using docker compose in prod should even be worried about. A lot of concerns seem to be around avoiding spinning up duplicate instances of reverse proxies, databases, and caches. First of all, why is this a concern? Idle threads have basically no impact on a system, so this generally isn't a concern. This is a nuanced and context-dependent issue, but generally it won't even make the list of top-100 performance bottlenecks for most applications. Yet the article takes for granted that the benefits of solving this problem outweigh the many cons of coupling them together. Even if you wanted to enforce your applications sharing a postgres instance under the hood, why would you want that to be black-magic performed by the container orchestrator? Other stuff like DB backups just don't seem like issues docker compose users have. If you need to orchestrate across multiple nodes in order to meet your SLOs, then don't use docker compose. Finally, it seems like the actual solution is significantly under-discussed. I both have tons of questions about how it's supposed to work, and I see lots of shortcomings with the parts that I do understand. Beyond the specific issues I see, the fundamental attitude seems to be "force everyone to architect their applications in a very specific way, and don't even try to support any use cases which fall outside of it". You need a damn good reason to be that opinionated about these sorts of things, and it by definition will only work well in specific contexts. I'd be interested to read an article which tried to articulate why such an opinionated API would improve SDLC-considerations over docker-compose, but I don't think that's the article I just read.

eliribble 2y ago
These are great points, and probably worth their own blog post to answer. > First of all, why is this a concern? Idle threads have basically no impact on a system, so this generally isn't a concern Idle threads have very low impact on CPU utilization, probably, if the application is well-behaved (and I expect most databases and caching layers to be well-behaved in this way). The application itself, however, will need memory and the way containers are built prevents the usual de-deplication of system libraries. > but generally it won't even make the list of top-100 performance bottlenecks for most applications True, but it makes the short list of "how much stuff can I run on a $100 computer", and it's one of the relatively few concerns an application operator has when they are not the application developer. > Even if you wanted to enforce your applications sharing a postgres instance under the hood, why would you want that to be black-magic performed by the container orchestrator? To make self-hosting much simpler. If the container orchestrator doesn't do it, what do you think should do it? > Other stuff like DB backups just don't seem like issues docker compose users have. If you need to orchestrate across multiple nodes in order to meet your SLOs, then don't use docker compose. The DB backups are meant for disaster recovery rather than supporting multiple nodes. I guess that's multiple nodes through time... But, yeah, I agree, docker-compose is not a good fit. > Finally, it seems like the actual solution is significantly under-discussed. I both have tons of questions about how it's supposed to work, and I see lots of shortcomings with the parts that I do understand. Yeah, agreed, I'll be writing other things to discuss what I think the correct solution should be. I'm curious to find out if other people have existing solutions to the problems I outlined. If it's a solved problem and I just don't know about it, that'd be better. > I'd be interested to read an article which tried to articulate why such an opinionated API would improve SDLC-considerations over docker-compose, but I don't think that's the article I just read. It is not, and you're right, it needs discussion.

zerof1l 2y ago

As someone who is self-hosting with a docker on my own server, I don't see the negatives mentioned in this article as being a problem at all. Quite the opposite, it gives you the freedom to do your docker setup how you want it. It took me some time initially to figure things out and I had to learn some things. But now it's a breeze. Once I had reverse proxy and automatic certificate renewal in place it has been working ever since then without me having to do anything. Adding a new service like Immisch or Jellyfin takes me an hour or less. Which can be quicker, but I adjust every docker compose to my setup and make it more secure. E.g. I create a new non-root user for each service. Basically I have the whole setup figured out; I have notes and checklists for the new services I add. I don't need to figure out things anymore and in 95% of the cases things just work. Updating existing services takes minutes: just increment the version in the compose file and rebuild. For my setup, I use macvlan as opposed to the default docker bridge network. So, the `ports: - "8000:5000"` docker compose config is being ignored. Instead, each docker container gets its own unique IP and MAC address I assign to it. It can then use any port it wants. Thanks to this, on my home network, I can access any container I want by IP. And any container can access any other container. I then add some restrictions for security purposes on the host machine using nftables. For reverse proxy, I use Nginx Proxy Manager which is a simplified GUI around Nginx. I'm slowly moving to just using Nginx. For the database, I run multiple instances of Postgres and MySQL and I don't see any issues. They take an insignificant amount of resources compared to the applications. If the application is not in use, its database instance is not being used as well.

Timber-6539 2y ago

Docker is simply a packaging format with docker compose being a wrapper for docker run. Author seems to confuse general application issues with docker's. Article wasn't convincing enough about docker compose's shortcomings. The linked github's README even less convincing. But to each his own.

notpushkin 2y ago

I’ve been building a Docker Swarm based server dashboard for a couple years now. It should help with some of problems mentioned in the post: https://lunni.dev/ https://lunni.dev/ I like the ideas mentioned though! Docker Compose is pretty good, but something more declarative would definitely be a plus. Would love to see where the project goes (and maybe will borrow some things for the future versions of mine :-)

echoangle 2y ago

I don’t get why docker doesn’t include a simple command (docker backup volumexyz mybackup.tar.gz) that creates an archive from a volume. Why do I have to do that myself by mounting the volume in a second container? Ok, there might be volumes that can’t be backed up (mounted sockets for example), but that could just give an error message.

rthnbgrredf 2y ago

If docker compose is not enough I would suggest to look into some of the lightweight k8s distributions like k3s, with low ressource consumption and able to operate on a single node.

dankle 2y ago

Just use k8s for prod. Docker compose is great for local dev, i would never dream of deploying to prod with compose.

SOLAR_FIELDS 2y ago
Sure. But that’s not the point of the article. The articles point is “Docker Compose is too complicated”, then proposes a half baked implementation of a solution that hand waves away of all that complexity with a scenario that will fulfill their specific use case but will completely fall apart when it diverges from the specific way they’ve decided to build the abstraction layer. The problem that the author refuses to accept is that deployment is inherently complex. It does require configuration of a lot of things because it supports every use case. So you either have a generic complex tool that everyone can use (like Docker Compose or Kube) or you have some specific tool that only works for a tiny subset of all users that is simpler that satisfies your use case. Note that I’m not saying Docker Compose is perfect. The syntax is a bit arcane it’s complex to understand etc. But removing the complexity by removing configuration options is not the solution here. Instead the author should focus on different approaches and tools to manage the same existing level of abstraction. And for what it’s worth, that’s essentially what Helm is for kube - a way to manage and hide away the complexity of kube manifests (but still use those manifests under the hood). But frankly, docker compose doesn’t need a helm. Because docker compose, as you point out, has value not as a deployment tool, but as a single file that developers can manage and spin up on their local machines in a manageable way that doesn’t have the author fighting YAML all day. I would say if the author was actually interested in solving this problem in a productive way they should first try to see if docker itself is amenable to altering their constructs to provide optional higher abstractions over common concepts via the compose interface natively. If the source tools roll out those abstractions everyone will get them and adopt them.
- hluska 2y ago
  I could come out with some counterpoints, but you’re too abrasive to even engage with. It’s sad what this place has become.

mythz 2y ago

Docker Compose/SSH and some custom GitHub Actions to run DB Migrations is simple, straightforward and was more than enough to manage CI deployments all our Apps [1]. Although we're currently migrating to Kamal [2] to take advantage of its nicer remote setup, management and monitoring features. [1] https://docs.servicestack.net/ssh-docker-compose-deploment https://docs.servicestack.net/ssh-docker-compose-deploment [2] https://kamal-deploy.org https://kamal-deploy.org

zb3 2y ago

It is enough for me, and the title doesn't mention that this post promotes the alternative.

bityard 2y ago

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" container orchestration product where there's extra upstream development between you and the docker image. Docker compose can run anything you can stuff into a container. This cannot, without some additional development. That may be value in that, but I'm not sure blasting docker compose as old and busted right out of the starting gate is a terrific marketing strategy.

eliribble 2y ago
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."

datadeft 2y ago

In summary: Accidental complexity, accidental complexity, accidental complexity and when we use a tool that is designed for problem A for a problem B it is not sufficiently dealing with complexity. This is why we need a new tool. ¯\_(ツ)_/¯

eliribble 2y ago
While a bit of a hot take, you're not wrong. We need something that's less scalability focused than Kubernetes/Mesos/Docker Swarm but that doesn't put too much burden on application developers. Something that focuses on being secure, reliable, and understandable, in that order. I'm not aware of anything going for that niche. That means a new tool is in order.
- datadeft 2y ago
  I think we need a composable system but I am not sure if the current frame where this problem and these tools exist is good enough. We might need to rethink how we handle access and usage patterns well. I only have wrong answers. Docker compose is amazing for local dev env, k8s is terrible for production. These are my experiences with this domain.

raphinou 2y ago

I am particularly happy with docker swarm with traefik as described here: https://dockerswarm.rocks/traefik/ 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 quite some people trying to replicate swarm's features with docker compose, but often in harder to maintain setups.

eliribble 2y ago
Looks like https://dockerswarm.rocks https://dockerswarm.rocks says that the site is deprecated. https://dockerswarm.rocks/swarm-or-kubernetes/ https://dockerswarm.rocks/swarm-or-kubernetes/ says "it's not sensible to build a new product using Docker Swarm Mode"
- raphinou 2y ago
  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/ https://www.yvesdennels.com/posts/docker-swarm-in-2022/
therealfiona 2y ago
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 to down size my team because of it. One thing K8s is not is cheap. That shit takes a well oiled team or a couple of hot shots so do right. We probably did a lot of what makes it expensive to ourselves by not switching to managed add-ons sooner and never evolving the apps that run in the cluster. I've only been lead for about 5 months now, but I'm finally able to start making significant progress on the necessary evolution that I've been trying to make happen for 2 years before my promotion. The enterprise is a big ship. Takes time to turn. Thanks for reading what turned into a rambling vent session.

hbogert 2y ago

i've been at the edges of docker-compose. We were always conceptually recreating kubernetes. I'm so happy we've got k8s now and sparingly use some operators where needed, couldn't be happier. The obvious example was certificate management. Cert-manager alone is almost worth setting up K8s if you have many ingresses/fqdns.

mmcnl 2y ago

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.

sureglymop 2y ago

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.

nunez 2y ago

I'm having this problem now with our home automation stack. Compose is super easy to start with but scales poorly and makes things like "I want to access this service at https://foo.bar https://foo.bar instead of http://somehost:61234 http://somehost:61234, no HTTPS because the app doesn't support it natively and I don't have time to roll nginx." Kubernetes makes this so easy once you get past the YAML and abstractions, so I'll probably FINALLY move this stack over to it. Long overdue. And this is coming from someone who for the longest time recommended that developers new to containers start with compose before considering Kubernetes!

freeone3000 2y ago

scaling docker compose to multiple machines is traditionally the realm of kubernetes. I’m not seeing any suggestion here that’s better than dropping in k3s

leosarev 2y ago

I also think that both docker-compose & k8s & helm are wrong layer of abstraction. I see a lot of people building a opinionated way to run containers and way for them to communicate with another, to request a DB or a redis. I like to name some such attempts: - .NET Aspire - Avito Plato (home grown PaaS of ¨russian Amazon") - infrastructure layer of our ZIIoT (MES platform on top of k8s)