lobsters score: 1 · tags: devops, linux, systemd, virtualization
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.)
score 1 · canonical
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.
score 1 · canonical
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.
score 1 · canonical
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.
score 1 · canonical
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.
score 1 · canonical
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)
score 1 · canonical
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.
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
score 1 · canonical
The real alternative is using
run0but I am not sure if it’s globally available now.
score 1 · canonical
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?
score 1 · canonical
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.
score 1 · canonical
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.
score 1 · canonical
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).
score 1 · canonical