Quadlets might make me finally stop using docker-compose
Quadlets might make me finally stop using docker-compose
major.io
Quadlets might make me finally stop using docker-compose
54 comments
-
-
Oh, well that's simple...
-
Dependencies within unrelated projects (ie, sharing a single database container for a few unrelated apps) is something that would be pretty handy, and is missing from compose.
Auto-updates are cool - but also dangerous... I think there's something in running watchtower manually like I have been - when something breaks straight after, I know the cause.
-
Couldn't you just create a compose file for a database separately?
-
I don't really understand what you're suggesting. Having a seperate compose file for your database would "work", but you'd lack any of the dependency handling.
-
-
-
Honestly, this is kinda making me wanna redeploy a couple app stacks I have on a VPS. Hmm.
-
Interesting. But what If I'm not using CoreOS? Also RedHat fucked up by using YAML for configuration.
-
What is wrong with YAML for configuration? It is much more easy to read then say json.
-
There is some surprising behavior with some of the features of yaml, mostly arising from the fact that it looks nice to read. Here's a list of things that you can avoid to avoid a lot of the pitfalls: https://hitchdev.com/strictyaml/why/ . I haven't actually used strictyaml, but the arguments it presents are pretty solid and some are things I've run into in real environments
-
JSON was never meant for configuration.
YAML has a ton of footguns.
-
YAML is way too bloated of a standard and has a ton of inconsistencies between implementations, despite the widespread reputation of simplicity. It is easy to read as long as you limit yourself to a fraction of its capabilities and err on the side of caution when it comes to escaping characters (especially when number literals are involved, or booleans for that matter). As far as alternatives go, I prefer TOML for simple key=value configs, but it has its own issued and is nowhere near as featureful, for better or worse.
-
If you're just reading configs then yeah, it's superior. If you're maintaining big complex configurations, possibly for multiple machines, you need something to reduce boilerplate. Jsonnet, nickel or nix are excellent here. So the best way is to use one of those, generate yaml, and deploy. Saves you a lot of headaches but it's one more moving thing in your pipeline which can break.
-
-
what if I'm not using CoreOS?
Podman runs on any distro (or more strictly: any distro that uses systemd). It's essentially a FOSS alternative to Docker.
-
It's built into Podman 4.x, so you can easily install it on any distro (with Systemd).
-
54 comments
Any time I always read how to accomplish something in podman-land , the action takes like 5 extra steps compared to docker, is probably an experimental feature that's not supported and is always from a non-official source or some random blog.
In my limited experience, when Podman seems more complicated than Docker, it's because the Docker daemon runs as root and can by default do stuff Podman can't without explicitly giving it permission to do so.
99% of the stuff self-hosters run on regular rootful Docker can run with no issues using rootless Podman.
Rootless Docker is an option, but my understanding is most people don't bother with it. Whereas with Podman it's the default.
Docker is good, Podman is good. It's like comparing distros, different tools for roughly the same job.
Pods are a really powerful feature though.
Can't argue with that. There's some truth to this.
If this figure was even close to being remotely true, everyone would have moved to rootless containers by now.
These two share the same set of problems. People don't want to downgrade from a "working" docker to a rootless "safer" docker that comes with more usability headaches.
Not really. The two are really different underneath but on surface they may look like they are overlapping solutions to the untrained eye.
Last time I was giving podman a try, I didn't find anything really special about pods. Maybe it just didn't click for me or I was not the intended audience.
I use podman because it's more secure. I'm willing to put in the extra effort so that all my services aren't running as root. If it turns out a vulnerability is discovered in lemmy tomorrow that allows people to access my server through my lemmy container, the attacker will only have access to a dummy account that hosts my containers. Yes, they could stop all my containers, but they can't delete the volumes or any other data on my server.
Podman might have a "more secure" design but you can run the docker daemon as rootless. Podman itself is not immune to vulnerabilities and will not solve all your security problems.
If you make something with Podman yourself it is actually less work most of the time (the OP tutorial is incredibly convoluted for no reason).
But sure, if someone else did all the work for you and you just need to download the docker-compose file and run it, that is of course less work for you. But that is just a result of Docker's relative popularity compared to Podman.
Doubt.
OP's guide is simply describing how podman is designed to work. With systemd unit files for managing services.
Why re-invent the wheel?