There are a few simplifications that can be made to the first step:
Generally, podman also includes a systemd socket definition, so you can just skip manually enabling/starting the socket entirely, and systemd will auto-start the service once the socket is interacted with.
If you do want to enable another user's rootless podman session, you can actually just do systemctl --user --machine=USERNAME@.host [...], and it will target that user's systemd session using the same underlying mechanism as machinectl.
On my system (Arch Linux), the Podman socket (systemd's socket activation) is not started by default.
Oops I presume I turned it on at some point... I mean, arguably enabling the socket instead of the service is ideal since then podman doesn't start until you need it...but I presume in practice podman running nothing inside isn't gonna use very many resources anyway.
It doesn't seem to work when part of the wheel group, unlike machinectl.
Try the sudo group, or explicitly setting up the wheel group to have sudo access. Systemd has some sudo integrations, and I dont think "wheel" has the implicit meaning there that it once did.
(Full disclosure, I've never used the docker socket, but I main rootless podman)
Thanks for the guide. I use docker-compose extensively for my own services. In the context of docker-compose, are there any features you give up or quirks you run into by swapping out docker for podman, or does everything behave exactly the same?
(I know a lot of folks prefer quadlets for multiple containers on podman, but I don't want to give up the simplicity of deploying a whole set of services anywhere I want with just two commands: git clone followed by docker compose up -d.)
Officially speaking docker-compose does not support Podman, and you "should" use podman-compose. However, I have been running the setup described here for years and it works fine. You will find, however, that certain edge cases may not be documented; I can't recall off the top of my head, but I've bumped into a few.
The article doesn't say, and I'm curious. Was there a reason you chose to use docker-compose instead of podman-compose, since you're already using podman?
Last time I checked, podman-compose missed a lot of features and was easy to break. It probably evolved since then, but I kept using docker-compose since that time.
I moved my deployments to Podman Quadlet too. Wanted to make an article for this at first but it is a too large chunk to write.
I still use docker-compose at work (for development purposes), when I get a Linux machine. It's easier to show that I'm using the same tool as everyone (while underlying it's not really Docker).
refi64 | a day ago
There are a few simplifications that can be made to the first step:
systemctl --user --machine=USERNAME@.host [...], and it will target that user's systemd session using the same underlying mechanism as machinectl.[OP] Exagone313 | a day ago
On my system (Arch Linux), the Podman socket (systemd's socket activation) is not started by default.
Good suggestion for the other user part.
EDIT: It doesn't seem to work when part of the wheel group, unlike
machinectl. Probably requiresroot.refi64 | 20 hours ago
Oops I presume I turned it on at some point... I mean, arguably enabling the socket instead of the service is ideal since then podman doesn't start until you need it...but I presume in practice podman running nothing inside isn't gonna use very many resources anyway.
oh...what? I guess this somehow doesn't go through polkit at all, or follows some different path? There's a recent open issue too: https://github.com/systemd/systemd/issues/41071
[OP] Exagone313 | 13 hours ago
The real alternative is using
run0but I am not sure if it's globally available now.landon | 15 hours ago
Try the sudo group, or explicitly setting up the wheel group to have sudo access. Systemd has some sudo integrations, and I dont think "wheel" has the implicit meaning there that it once did.
(Full disclosure, I've never used the docker socket, but I main rootless podman)
jbe_ | a day ago
Oh, interesting, I've just used podman-compose for all my composing needs so far.
bityard | a day ago
Thanks for the guide. I use docker-compose extensively for my own services. In the context of docker-compose, are there any features you give up or quirks you run into by swapping out docker for podman, or does everything behave exactly the same?
(I know a lot of folks prefer quadlets for multiple containers on podman, but I don't want to give up the simplicity of deploying a whole set of services anywhere I want with just two commands:
git clonefollowed bydocker compose up -d.)[OP] Exagone313 | 13 hours ago
So far, apart from not being able to publish root-reserved ports, the only thing I found is that internal networks are in fact not internal.
cyberia | a day ago
Officially speaking docker-compose does not support Podman, and you "should" use podman-compose. However, I have been running the setup described here for years and it works fine. You will find, however, that certain edge cases may not be documented; I can't recall off the top of my head, but I've bumped into a few.
hoistbypetard | a day ago
The article doesn't say, and I'm curious. Was there a reason you chose to use docker-compose instead of podman-compose, since you're already using podman?
[OP] Exagone313 | a day ago
Last time I checked, podman-compose missed a lot of features and was easy to break. It probably evolved since then, but I kept using docker-compose since that time.
Adding a link to it nonetheless.
hoistbypetard | a day ago
Makes sense! It looked good to me, but I liked quadlets so much that I really drifted away from either -compose for how I was using podman.
[OP] Exagone313 | a day ago
I moved my deployments to Podman Quadlet too. Wanted to make an article for this at first but it is a too large chunk to write.
I still use
docker-composeat work (for development purposes), when I get a Linux machine. It's easier to show that I'm using the same tool as everyone (while underlying it's not really Docker).