31–40 of 250 posts
Anyone have experience with this? I love the idea of it being daemonless.
Out of curiosity, why do you prefer daemonless setups?
Even less IPv6 support than docker. With docker you can at least get it to work somehow, even if it is totally different from IPv4, weirdly. Podman just has no IPv6 support to speak of.
Earlier quoted context omitted.
Out of curiosity, why do you prefer daemonless setups?
When you use a system-level daemon[0], the daemon has to have privileges to start a container as anyone (that is... root). In a daemon-less environment, you only need the privileges of the user who is starting the container. [0] I suppose you could have a user-level daemon that runs for each user that needs to run containers, but that's even more overhead.
There's some tradeoff I guess though, between rootful setup and per user, as images duplication per user could add up.
Earlier quoted context omitted.
Out of curiosity, why do you prefer daemonless setups?
It's a pain having to setup root access or a user for Docker. At a financial institution I worked at we had to waste about half a day to get this setup (and that's once we worked out who we had to speak to).
Isn't Singularity[1] also daemonless? [1] https://sylabs.io/
Anyone have experience with this? I love the idea of it being daemonless.
If you run it as non-root it is significantly slower than docker as root. Docker can us the overlay2 kernel driver, whereas podkan would use fuse-overlayfs in userspace. This has a high CPU overhead (e.g. don't try to run AFL inside podman), and a 1024 FD limit for the entire container (so a 'make -j40' usually dies). There are ways around it: raise the ulimit for your user and run new enough podman to raise limit fo…
Also, docker runs as root, so it won't have permissions problems. You can change the permissions of /dev/fuse if you want to allow podman containers to access it or update the group of the user launching podman.
Earlier quoted context omitted.
If I have 30 containers running, why should a single daemon being restarted cause all 30 to shutdown as well? Similarly, the docker security model is that there isn't a security model. If you can talk to the docker socket you have what ever privileges the daemon is running as.
So Docker supports live restore https://docs.docker.com/config/containers/live-restore/ which addresses the first point. Second point, yep if you run Docker as root and someone can access the socket file they get root. If that's a concern, you can run Docker rootless. And as we're talking file permissions on a local host to allow that access, the same applies to podman containers does it not? If there are permission…
I still miss an easy way to setup multiple containers in a single network like with docker-compose. podman-compose is not really useable.
https://www.redhat.com/sysadmin/podman-docker-compose
That says, you literally can use the same docker-compose app shipped from docker and it works using podman.
I still miss an easy way to setup multiple containers in a single network like with docker-compose. podman-compose is not really useable.
What's wrong with it?
But this can't be done rootless.
So with rootless podman all container map to the same ip address but different ports.
This is for some use cases (e.g. spinning up a DB for integration testing) not a problem at all. For others it is.
More over you can run multiple groups of docker containers in separate networks, you can't do so with rootless podman.
Through you can manage networks with rootfull podman (which still has no deamon and as such works better with e.g. capabilities and the audit sub system then docker does).
Through to get the full docker-compose experience you need to run it as a deamon (through systemd) in which case you can use docker-compose with podman but it has most of the problems docker has.
I used --squash, cleaned up the various apt-gets but boy it made me realise that for every abstraction we get leakage - sometimes serious leakage