I never thought of using "number of docker instances" as a metric for evaluating software before now.

That's because it's a pretty silly way to look at things in a world of docker compose.

Classic. Tools become too abstracted? Add a layer of abstraction to manage them.

Feel like there must be an xkcd comic on this, but it doesn't leap to mind yet.

Software becomes so complex that it becomes vulnerable. Add more code, i.e., more complexity, to "fix" the problems.

WAF

I mean, asking them to plop their cli docker setup into a yaml file isn't exactly a difficult task. I think it's probably more correct to consider docker-compose an integral part of docker rather than a superfluous abstraction layer.

This one comes to mind immediately: https://xkcd.com/927/

I would propose this one: https://xkcd.com/2347/

Surely it should be this one?

https://xkcd.com/1988/

Or maybe this one:

https://xkcd.com/1579/

Or possibly the last panel of this one:

https://xkcd.com/1718/

Or this one…

https://xkcd.com/1764/

…Or this one:

https://xkcd.com/2021/

Well, a couple things occurred to me when I realized it was at least 2 instances.

First, I'd have to get them talking to each other. I am not an expert at Docker, and I just do the most basic stuff with it.

And second, I think they'll need to be reachable from the web, so I'd want to host them somewhere out in the cloud, and not on my home network. NearlyFreeSpeech doesn't offer Docker hosting yet (that I know of) so that means paying more for somewhere else for it...

And at that point I decided I didn't care enough about the benefits to deal with all the downsides, and just signed up on a Lemmy instance. It was actually the second instance, because the first one had stability issues. I then realized I didn't like how that instance was being run, and signed up on third, which I've been happy with and it's been relatively stable. At least, when it had problems, so did most other big Lemmy instances.

Yeah with Lemmy it's pretty extreme. But to be fair, Lemmy is the only fediverse software I run in docker, Mastodon and PeerTube work easy enough without. But Lemmy being written in a compiled language makes it more difficult to get everything installed and set up to compile it. Once it's done it's very lightweight in comparison to especially Mastodon, which is nice.

That would also discourage me from setting it up, so I don't blame you, but just asking, was there not a docker compose somewhere for setting this up. It seems like that would make things a lot easier.

I didn't go deep into looking for one. It's possible it exists, but the little bit of research I did into it didn't reveal it, and I didn't want to figure out how things fit together.

Now that you say that, it seems obvious that it must exist, and I just missed it.

Couldn't someone make a Docker instance that, inside it, contains the 2-3 other docker instances? I hear it's docker all the way down.

Docker compose makes it relatively easy to coordinate multiple containers. But to answer your actual question, yes, that’s possible though definitely not recommended for standard hosting, it’s called DiD (docker in docker) and is fairly common for CIs.

It is common to use --privileged (or -v docker.sock) and run docker commands inside docker. But then you're not really in the container, you may as well be on the host.

I think genuinely containerizing inside an ordinary container, without --privileged, would mean taking extreme compromises like bocker or proot.

What's the state of the art here?

I cannot fix my comment anymore, but I meant to write DinD.

See https://hub.docker.com/_/docker

The Nextcloud All in One (AOI) images takes another approach, which is use the first image to launch the other needed images. So it lets you avoid docker compose at the cost of needing to pass the docker socket to the AOI container.

I tried this and I did not enjoy it. A docker container with access to docker socket is so cursed.

I kept having issues, like I tried to stop the container and it left all the extra containers it made running. They also had different network settings than the ones I set on the parent container. I don’t remember the exact issue but I had to manually adjust the network that it made- because it just made its own and ignored the one I assigned the parent container too.

It was the easiest way to get Nextcloud running but I immediately stopped it. I don’t want Nextcloud able to tamper with my other docker containers. I want it contained.

I haven’t yet had a chance to figure out how to get their containers running normally.

An “instance” here being just a walled-off process running inside its own chroot environment. IIRC Lemmy needs 4: frontend, backend, database and imagestore. It doesn’t need much resources when running, though.

How much data throughput does it use in a typical month? My home connection is heavily metered because I live in a failed state with regulatory capture.

That massively depends on how many groups you subscribe to. I'm running my local instance for slightly over 6 months now, have subscribed to around 30 groups/communities/subs and my local storage shows 2.7GB in the pictrs directory and 2.8GB in the Postgres directory.