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! 📦
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.
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.
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 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.
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.
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.
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).
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.
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.
deleted by creator
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.
deleted by creator
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.
deleted by creator
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.
deleted by creator
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.
deleted by creator
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.
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.
https://docs.docker.com/engine/security/rootless/
deleted by creator
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.
deleted by creator
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.
deleted by creator
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.
deleted by creator
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.
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).
deleted by creator
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.
deleted by creator
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.
deleted by creator