- cross-posted to:
- containers@lemmy.world
- hackernews@derp.foo
- cross-posted to:
- containers@lemmy.world
- hackernews@derp.foo
You must log in or # to comment.
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.
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.
Can’t argue with that. There’s some truth to this.
99% of the stuff self-hosters run on regular rootful Docker can run with no issues using rootless Podman.
If this figure was even close to being remotely true, everyone would have moved to rootless containers by now.
Rootless Docker is an option, but my understanding is most people don’t bother with it. Whereas with Podman it’s the default.
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.
Docker is good, Podman is good. It’s like comparing distros, different tools for roughly the same job.
Not really. The two are really different underneath but on surface they may look like they are overlapping solutions to the untrained eye.
Pods are a really powerful feature though.
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.
on surface they may look like they are overlapping solutions to the untrained eye.
You’ll need to elaborate on this, since AFAIK Podman is literally meant as a replacement for Docker. My untrained eye can’t see what your trained eye can see under the surface.
The two are not hot-swappable solutions (as much as podman tries to act as a drop-in replacement for docker). Trying to replace one with the other after coming from extended use of either will immediately let you know of the stark differences between them.
Perhaps I misunderstand the words “overlapping” and “hot-swappable” in this case, I’m not a native english speaker. To my knowledge they’re not the same thing.
In my opinion wanting to run an extra service as root to be able to e.g. serve a webapp on an unprivileged port is just strange. But I’ve been using Podman for quite some time. Using Docker after Podman is a real pain, I’ll give you that.
I am not a native english speaker either but it seems like you are trying to understand those two words outside of their context as used in the sentences I’ve replied. They are only meant to be understood in the context of the conversation. In this case, the two terms mean almost interchangable. Look up the meaning of both words and try to apply them as previously used.
In my opinion wanting to run an extra service as root to be able to e.g. serve a webapp on an unprivileged port is just strange.
Often times we don’t get to choose the software solutions that we will eventually use, they choose us. Colloquially speaking.
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.
Don’t let perfection be the enemy of good. Security is not all or nothing. Reducing the attack surface is still important.
Can you elaborate on running docker daemon as rootless? It’s my understanding that you can add your account to a group to access the docker daemon rootless, but the containers are still running as root, as the daemon itself raises the access to root.
but the containers are still running as root, as the daemon itself raises the access to root.
No. The daemon can run without root, as such the containers don’t have root. My docker install doesn’t have root access. None of my stacks / containers need any root access tbh. I don’t have any troubles with deplyong stuff.
Not sure relying on podman alone as a security tool might be advisable. Podman is a container technology first, security is not the main goal.
Read more about rootless docker here.
I never said I was relying on it alone. Not sure why you think that.
That’s a great link. Thank you for sharing. It’s good that docker supports this functionality now.
I never said I was relying on it alone. Not sure why you think 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.
This was your argument according to you for why you think podman is more secure (than docker I presume). Seemed to imply rootless podman will save you from an attacker. I was simply disproving the flawed notion.
I think you’re interpreting too much. Security is about layers and making it harder for attackers, and that’s exactly what using a non-root user does.
In that scenario, the attacker needs to find and exploit another vulnerability to gain root access, which takes time - time which the attacker might not be willing to spend and time which you can use to respond.
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.
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).
Doubt.
OP’s guide is simply describing how podman is designed to work. With systemd unit files for managing services.
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.
Why re-invent the wheel?
Doubt.
Cool attitude. In my experience, most docker/docker-compose setups will work transparently with podman/podman-compose. If you want to tighten security, lock down ressource access, run rootless (daemon and inside the container), integrate with SELinux, then you might need to put in extra-work, just like you would if you used docker.
Why re-invent the wheel?
They aren’t. Podman is mostly just a docker-compatible CLI wrapper around an existing OCI runtime (runc by default). It also lets you manage pods and export k8s yaml, which is arguably the more important industry standard at this point. Podman was also completely usable in rootless mode way before Docker support for that was on the table, which was the main reason I switched years ago. Podman development effort also yielded buildah, which is a godsend if you want to build container images in a containerized environment, without granting docker socket access (which is a security nightmare) or using some docker in docker scenario (which is just a nightmare in general).
Cool attitude. In my experience, most docker/docker-compose setups will work transparently with podman/podman-compose. If you want to tighten security, lock down ressource access, run rootless (daemon and inside the container), integrate with SELinux, then you might need to put in extra-work, just like you would if you used docker.
The whole point of docker/compose is you don’t have to do all those things to get started.
Why re-invent the wheel? They aren’t.
This whole conversation is about re-inventing the wheel called docker-compose with quadlet. Or whatever podman will come up with next as a “drop-in” replacement.
Quadlets were never meant as a drop-in replacement. The docker-compose tool works just fine on top of podman though. I personally use it to setup Jellyfin and Nextcloud.
That’s why I used double quotes around the word drop-in (supposed to be a play on the whole preposition of podman being touted as a drop-in replacement to docker).
Even so, what is really the use of Quadlets if docker-compose works just fine? Is it supposed to be just a backup alternative to compose just incase something catastrophic were to ever happen to docker-compose? Why create two ways to do one thing? Seems rather confusing and misplaced.
I prefer the simplicity of docker-compose on top of podman myself for my self-hosting needs, but I imagine systemd integration to be advantageous in many ways. You can have your containers activated by a socket. You can configure your containers so that they depend on certain system services being up or available, giving you more fine grained control over your start up process. That’s just off-the-top of my head as I have very limited knowledge of this aspect of podman, but I don’t think it’s meant as a backup. It just provides a more flexible solution for certain deployment scenarios, in exchange for more configuration complexity of course.
Yes, but only 10% or so of the article is about what you actually need to know to use Quadlet and the rest is some convoluted mess that I don’t know why the author bothered with sharing that.
Major typically writes these as much for his own notes / thoughts as anything. Having some insight into how he got where he is in the process can help some others learn. I’ve learned tons from the guy.
I’ve known him over 15 years, and he always has written posts for himself first. This isn’t a bad way, just maybe not the simplest for experienced folks. Laying out your own thoughts along the path can help later when you wonder why you did X instead of Y.
I think he’s referring to the fact that it’s mixed in with a bunch of CoreOS setup stuff. I also thought the same of this tutorial. I use podman myself but I have no interest in CoreOS. It was a bit difficult trying to extract just the podman related stuff out of that tutorial.
Fair enough. You are right.
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.
I don’t trust anything related to red hat
Genuine question here: why?
It’s just morally rough that they basically said they don’t get anything of benefit from contributing to open source despite really owing their start to it
Thanks for the honest answer.
Have you seen how they have behaved recentl?
I don’t have a horse in this race, but this is a really unhelpful non-answer.
You mean showing a commitment to open-source and keeping all of their software open-source (when most other “open-source” companies in similar situations switched to non-Free licenses, like Elasticsearch for example)?
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
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.
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.
…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.
systemd [is] 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).
