For 1, docker has a handy special file to make this even easier! `compose.override.yaml` loads automatically on top of the main `compose.yaml`. We keep dev configs in there so Devs only need to run `docker compose up` locally without any environment variables, but on prod (which is automated) we set the compose file to be `compose.yaml:compose.prod.yaml`.

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.

You can solve anything with enough scripts, but that in no way invalidates his point that the abstraction level seems a bit off.

I'm not sure that his solution is really an improvement, however, because then you have to bake in the semantics for a fixed set of product types, and when that list gets extended, you have to bake-in a new one.

Borgmatic works great for #2. before_backup runs docker compose stop, after_backup runs docker compose up, done.

> So the problem is…

This feels like quite a shallow reading. Being able to manage system-wide things (DNS, and a centralised Caddy, centralised database) from individual compose units in such a way that you're not going through a ton of setup each service. This much might just need Caddy to work better with other instances of itself but it isn't a solved problem.

I'll grant you that backing up volumes isn't hard.

I think 2) actually has the most merit. If you have a large number of e.g. temp files a container creates, retaining that file history may not be particularly valuable.

Some sort of "hey back this data up, it's important to my function standard would be nice, and not just for container apps.

Trying to figure out where your app hid its configuration and save files is a perennial user frustration.

For #2 I use https://kopia.io/ and upload to Backblaze b3 (S3 api)

I guess it’s simple if you already know which S3 service you want to use? For those of us who don’t, it means it’s time to go shopping for one.

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.

it's perfectly fine if everything can run on a single server instance. which is probably the majority of things.

i've run production instances with 2PB of data being scraped per month by 100+ CPUs and 256GB of RAM using docker compose. some of the machines (smaller instances) have run flawlessly with zero reboots for years on end. both on cloud and on-prem.

i'd say its 100% production ready.

I've used it for both.... but for production only in extremely constrained/limited environments. Its every bit as stable as anything else... you can version the compose you deploy so rollbacks are easy, etc etc.

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

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

Its not going to be amazingly professional and 100% best practice, but you can set up docker-composes and/or design containers to pull everything they need on first run.

That plus a decent backup system would work for a small array of servers with fail-safes. Though I would die inside if a production user-focused app under any level of proper load was set up like that.

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

How so? I run docker compose in production on 30 bare metals without any issue.

Same here, we never use compose in production.

There is already a third version of compose.

> I've always understood docker-compose to be a development or personal tool, not for production. Is that not usually the case?

Tons of sites are launched manually and have been for years in production.

Docker compose is a huge step up from that, so why wouldn't it be?

Just use Podman with plain simple .container file which is controlled entirenly by SystemD. Rock solid and easy to fix.

We run large, auto scaling clusters with compose and a small orchestration thing we have been using since the 90s (written in perl) (before compose we had our own compose-like with chroot). No issues. For decades.

I migrated several services from Kubernetes to compose and couldn't be happier. K8s was a maintenance nightmare, constantly breaking in ways that were difficult to track down and unclear how to fix once you did. Compose configs are simple and readable with all the flexibility I need and I've literally never had an issue caused by the platform itself.

That's what I thought the first day, the first month and maybe even the first half year.

Now it's 5 years+ running, all fine. No major hassle (crossing fingers!), no configuration hell. Never touched k8s, and not going to in the near future.

Maybe it just works and is sufficient for my case.

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.

Huh, why not? If you aren't building huge scaling apps, then docker (compose) does the job good enough.

I worked for a medium size company that served, and still is, ~150 clients (some Fortune 500 included) by deploying prod with docker-compose. It can be done.

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.

It's more than just a runtime for running containers, from the main landing page it looks like they're really specifically targeting self-hosting for the barely-technical [0]. In that context this article makes some degree of sense: their target audience will probably be legitimately overwhelmed by that pihole example and wouldn't know how to write a Python script to save their life.

If they can pull it off more power to them, but I'm skeptical that what the non-technical self-hoster needs is a TOML DSL that abstracts away ports, volumes, and even database implementations behind a magic text file. At some point you just have to bite the bullet and admit that your audience needs a GUI (like Sandstorm [1]).

[0] https://tealok.tech/

[1] https://sandstorm.io/

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

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.

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

… aand there is even Ansible playbook for that! Maybe overkill.

Do you have some reference that you can link to? Would be curious to see something about this

IME, people dramatically overestimate how hard it is to write any program.

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.

Is canine.sh hosted on Canine?

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.

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?

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.

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.

Not sure why comments aren't jumping on this more. Swarm is for production. compose is for development. That's always been the case.

And Swarm is barely more complicated than compose anyway. Don't know why people who are claiming they use compose in production just don't learn the few extra steps to do what Docker recommends.

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

Looks like https://dockerswarm.rocks says that the site is deprecated.

https://dockerswarm.rocks/swarm-or-kubernetes/ says "it's not sensible to build a new product using Docker Swarm Mode"

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

My first thought as well.

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

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

Is there a popular project which puts systemd and multiple processes in a container? I've seen only single process containers so far.

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.

Being able to tell a fellow developer "do docker compose up and you can work" is a lot better than navigating them through the installation of a bunch of tools, each with their own quirks.

I'm not convinced anyone below google needs kubernetes, but containers for quickly setting up and running something on my machine are a blessing.

Containers are a convenient work-around for the problem where programs have incompatible dependencies, and additionally the problem where security isn't as good as it should be.

For instance, you want to run one program that was written for Python 3.y, but also another program written for Python 3.z. You might be able to just install 3.z and have them both work, but it's not guaranteed. Worse, your OS version only comes with version 3.x and upgrading is painful. With docker containers, you can just containerize each application with its own Python version and have a consistent environment that you can run on lots of different machines (even on different OSes).

They're also a lot more convenient than having to go through the arcane and non-standard installation procedures that a lot of software applications (esp. proprietary ones) have.

Yeah, honestly it kinda sucks that we're adding this layer of inefficiency and bloat to things, but these tools were invented for a reason.

It is an abstraction.