Hacker Neue

Preferences
exceptione parent 

  > Specifically for docker it is a very common gotcha that the container runtime can and will bypass firewall rules and open ports anyway.
Like I said in another comment, drop Docker, install podman.
kh_hk
I keep reading comments by podman fans asking to drop Docker and yet every time I have tried to use podman it failed on me miserably. IMHO it would be better if podman was not designed and sold as a docker drop in replacement but its own thing.
exceptione OP
That sucks, I never had any problem running a Dockerfile in podman. I don't know what I do differently, but I would as a principle filter out any container that messes with stuff like docker in docker. Podman doesn't need these kind of shenegians.

Also the Docker Compose tool is a well-know exception to the compatibility story. (There is some unofficial podman compose tool, but that is not feature complete and quadlets are better anyway.)

I agree with approaching podman as its own thing though. Yes, you can build a Dockerfile, but buildah lets you build an efficient OCI image from scratch without needing root. For those interested, this document¹ explains how buildah compares to podman and docker.

1. https://github.com/containers/buildah/tree/main/docs/contain...

Nelkins
There's a real dearth of blog posts explaining how to use quadlets for the local dev experience, and actually most guides I've seen seem to recommend using podman/Docker compose. Do you use quadlets for local dev and testing?
kh_hk
A side-effect of running rootless and daemonless is that containers stop on user log out, and I can't believe how all this is to be expected for a newcomer to parse. Because I thought the whole point of containers in production was for them to keep running when you log out.

Of course, when you think about it, nobody expects a command to just survive logging out, but coming from docker, you still have that expectation. And I wonder, am I supposed to be running this on a tmux like the old days? No, you need to do a bunch of systemd/linger/stuff. So being that we are already in systemd land, you keep searching and end up in quadlets, which are a new-ish thing with (last I checked) bad docs, replacing whatever was used before (which has good docs). Docs, being said, that give k8s ptsd. Quadlet, podlet and pods.

It seems that when podman deviates from docker, it does in the least ergonomic way possible. Or maybe I have been lobotomized by years and years of using docker, or maybe my patience threshold is very low nowadays. But this has been my experience. I felt very stupid when I deployed something and it stopped after 5 minutes. I was ready to use podman, because it worked locally. And then it failed in production. Thanks no.

tremon
A side-effect of running rootless and daemonless is that containers stop on user log out

This is not a side effect of running rootless, it's a side effect of running systemd (or rather, systemd-logind).

exceptione OP 

  loginctl enable-linger
kh_hk
Yes, but I want it to only apply to podman, not any running task.

    systemctl --user enable podman.socket loginctl enable-linger <USER>

?
exceptione OP
You should compare it imho to ssh. If you break your connection, your session is gone. So if you only want certain parts of your session survive, which ones should? Because maybe your container depends on avahi on the host, or cups, or...?

Just a random thought, but if you can create a user on the host that just has the most minimal set of systemd services enabled your container needs, you could apply it to that user.

But still, on a server that wouldn't make much sense imho, as the default user is usually the service user having a minimal set of services enabled. On a desktop, your default user is logged in anyways. So I think this isn't a real problem tbh.

osigurdson
I just use Podman's Kubernetes yaml as a compose substitute when running everything locally. This way it is fairly similar to production. Docker compose seems very niche to me now.
dns_snek
podman is not a drop-in replacement for Docker. You can replace it with podman but expect to encounter minor inconsistencies and some major differences, especially if you use Docker Compose or you want to use podman in rootless mode. It's far from just being a matter of `alias docker=podman`.

The only non-deprecated way of having your Compose services restart automatically is with Quadlet files which are systemd unit files with extra options specific to containers. You need to manually translate your docker-compose.yml into one or more Quadlet files. Documentation for those leaves a lot to be desired too, it's just one huge itemized man page.

3np
This affects podman too.
jsheard
Not if you run it in rootless mode, which is more of a first class citizen in Podman compared to Docker.
3np
> Not if you run it in rootless mode.

Same as for docker, yes?

https://docs.docker.com/engine/security/rootless/

wasmitnetzen
Rootless exists in Docker, yes, but as OP said, it's not first-class. The setup process is clunky, things break more often. In podman it just works, and podman is leading with features like quadlets, which make docker services just services like any other.
newsoftheday
No one wants, nor asked for, quadlets.
exceptione OP
nope. You should look at https://docs.docker.com/engine/network/

Networking is just better in podman.

joshuaissac
> nope. You should look at https://docs.docker.com/engine/network/

That page does not address rootless Docker, which can be installed (not just run) without root, so it would not have the ability to clobber firewall rules.

newsoftheday
Nothing in the article talked about podman or podman vs docker. Umami with its NexJS and React CVE vulnerability was the issue. BTW, I use Docker because it works extremely well and because there is so much astroturfing from the podman gang I wouldn't use it if my life depended on it until that shit calms down.
figassis
In docker, simply clearly define the interface (ip) and port. It can be 0.0.0.0:80 for example. No bypass happens.
newsoftheday
No, I'm happy with Docker, Docker works very well.

This item has no comments currently.