Sure, docker-compose is great, but could we get similar functionality using just the tools that are built into CoreOS? Can we get automatic updates, too? Yes we can! 📦
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
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.
…except I can run Docker anywhere. It’s not tied to systemd. These quadlets seem like a very systemd-specific thing. Which is great if you’re building everything around systemd but it’s a niche.
Maybe in the wider world of all the operating systems installed on all the computers, but for Linux-based computing it is, like it or not, near ubiquitous these days. And in particular for server systems (and this is, after all, /m/selfhosted), good luck finding something that isn’t systemd-based unless you’re deliberately choosing a BSD or aiming for a system which has ever-decreasing amounts of support available.
This being selfhosted is exactly the reason I would’ve expected people to be aware there’s more variety out there. systemd is not as ubiquitous as you make it sound.
Secondly, tying your containerization solution into your init system is a spectacularly bad idea. You could already tie containers into systemd units, quadlets just make it easier; but the best practice advice is to not do it at all. You have a restart policy built into docker/podman for a reason. Let the init system deal with podman/docker itself, and let podman/docker manage their containers.
Third, the article title is misleading; if anything it should say quadlets made them give up podman-compose, not docker-compose. There’s no reason to reference docker in this article — unless you’re doing it for the views.
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
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.
JSON was never meant for configuration.
YAML has a ton of footguns.
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.
Podman runs on any distro (or more strictly: any distro that uses systemd). It’s essentially a FOSS alternative to Docker.
…except I can run Docker anywhere. It’s not tied to systemd. These quadlets seem like a very systemd-specific thing. Which is great if you’re building everything around systemd but it’s a niche.
Maybe in the wider world of all the operating systems installed on all the computers, but for Linux-based computing it is, like it or not, near ubiquitous these days. And in particular for server systems (and this is, after all, /m/selfhosted), good luck finding something that isn’t systemd-based unless you’re deliberately choosing a BSD or aiming for a system which has ever-decreasing amounts of support available.
This being selfhosted is exactly the reason I would’ve expected people to be aware there’s more variety out there. systemd is not as ubiquitous as you make it sound.
Secondly, tying your containerization solution into your init system is a spectacularly bad idea. You could already tie containers into systemd units, quadlets just make it easier; but the best practice advice is to not do it at all. You have a restart policy built into docker/podman for a reason. Let the init system deal with podman/docker itself, and let podman/docker manage their containers.
Third, the article title is misleading; if anything it should say quadlets made them give up podman-compose, not docker-compose. There’s no reason to reference docker in this article — unless you’re doing it for the views.
It’s built into Podman 4.x, so you can easily install it on any distro (with Systemd).