They're both declarative manifests describing how to run one or more images on your system.

You use .container for a single container, .kube for all-in-one pods, .network for networks, and .volume for volumes. It has all the stuff it's just broken down in a more (imho) sysadmin friendly way where all the pieces are independent and can be independently deployed.

How's that better? How many files do you need to replace a complex compose project, 10? And you still have to deal with SystemD?

Yeah, I see Docker Compose as a development environment setup aid. This seems like a way to set up a system.

But if it's a stepping stone to emulating Docker Swarm, that'd be something.

I actually use Podman and write Kube config yaml instead of docker compose yaml. I do like it better. It's a bit more polished.

I actually had the opposite reaction to it, but I do think it's nice there are tools for every use case and preference.

For anything other than a hello world type project a compose file will fall over kinda quick. I would much prefer to (ahem) compose smaller things together and systemd is great for that.

Lolol have been running compose in dev & prod for 7 years - still the best tool around.

That might work for whatever you are doing, but the truth is that root-ful containers are not appropriate for a lot of applications, and docker as a layer to your container runtime is rough sometimes. I don't think docker wants to continue to develop this anyway - they have had enough problems trying to be profitable so instead it is time to focus on docker desktop and charging for docker hub image hosting.

I feel like we are kind of in this weird limbo where I know I need to move to a podman focused stack, but the tooling just isn't there yet. I guess that is what makes Quadlets interesting, but idk if a single tool will really emerge. There is also podman-compose floating around. I still feel like I should hold of on some stuff until a winner emerges. So at home I'm still on docker with compose files. Although I will be moving to kubernetes for... reasons.

Docker already supports rootless, the issue is networking, which podman also suffers from.

There's already a clear winner, docker compose. Podman is barely used in prod and podman compose is barely used in dev. Docker also has buildkit and rootless configs so I'm not sure they are just letting it decay.

It will depend on the complexity of the stack, the number of environments you are deploying into, the number of devs on the team etc. It can work, and if it is working for you in this manner don't change what isn't broken, but in my experience for sophisticated systems with many services, envs, and developers it becomes unmanageable pretty quickly.

In what way? Docker-compose files are composable. I can specify several compose files that layer functionality or have different behavior and tie it together with make. You can also set defaults and override with environment variables using bash syntax.

> "hello world"

This is at best hyperbole and at worst nonsense. Come on, at least put some effort into drawing the line of complexity a little clearer.

For my home server, I have a flat 2507 line docker-compose file that automatically configures and boots all of my 85 containers. I still have some complexity: .env files in /opt/<container>/, a systemd process that automatically runs

  docker-compose -f /<dir>/docker-compose.yaml -d

on boot, and it's only a little irritating to have use absolute paths for everything instead of relative. But, after having to update all of my services manually for 3 years, I will never be able to go back.

> 2507 line docker-compose file

mother_of_god.gif

Yeah, she's a big girl, but having one flat file and one systemd process is infinitely better than juggling 85 of each. I have the systemd process start after docker.service, and most of my containers have a "depends_on" argument so they don't all try to boot at once. All of the containers also push logging to a Splunk instance, which adds 9 lines per container, which increases the file by 765 lines.

I’ve got a similar probably-too-large docker-compose on my home server.

If those 9 lines are identical you can probably simplify quite a bit with extension fields and yaml anchors. [0]

You would put

    logging: *default-logging

As a single line under each container, and then define it elsewhere. The example on the docs page is for logging, but you can also simplify other fields too, like “depends on”.

[0] https://docs.docker.com/compose/compose-file/compose-file-v3...

Oh my god, why didn't I look into that, that's so much better. Thank you!

you had me until you said splunk and now I am horrified to know the true topology of your homelab

Heh, Splunk is way overkill for what I need, but they have a free 10GB Dev license that you have to renew every 6 months, and building a custom COVID dashboard during the first few months of 2020 kept me sane. Here's my home/lab "prod":

Homeserver: Ryzen 3950x, 64GB RAM, Ubuntu 22.04 DNS: 1 RPi 3B+ and 1 RPi 400 running pihole and Unbound Edge router/firewall: Palo Alto PA-440 Switch: Cisco 2960 24-port w/PoE AP: Aruba AP-345 in Instant mode

Have you used splunk's free tier? It's easy to setup, 500mb/day ingest free, and it's pretty easy to use (easier than grafana imho.) If they're using it professionally then why not at home?

What do you need 85 containers for in a home lab

For fun, pretty much. 20 of them are Matrix related (synapse/dendrite, bridges, and bots), 16 for media services (Plex, audiobookshelf, etc), stuff for management/monitoring, stuff for Fediverse, etc.

I've been kinda partial to helm charts (on a k8s cluster). Standing up services is not awful. Have you used helm or similar? What do you think of these kind of tools?

I don't manage one large compose file, but helm charts are where my home stuff is headed. Mostly for ingress controller functionality - it's the reverse proxy configuration that will get you.

Curious: What's the use case for helm if you have kustomize now built into kubectl?