Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker is dead? Podman – an alternative tool?

content.fme.de

Post reply on HN
Print view View original

91–100 of 183 posts

Re: Docker is dead? Podman – an alternative tool?

#91

Post by lapser »

bob778 wrote: post #35
encryptluks2 wrote: post #28

Earlier quoted context omitted.

In my experience it is quite the opposite really, a more featureful solution with much more options and safer defaults.

From using podman in prod, it seems to be lots of features but not necessarily stable or well-rounded

Podman isn't supposed to be used in prod servers. It's for local development. It produces OCI compatible images (through Buildah), and you're supposed to use those with a proper container orchestration tool such as K8s, Nomad, Docker Swarm, or whatever else there is.

Re: Docker is dead? Podman – an alternative tool?

#92

Post by digital_voodoo »

teekert wrote: post #76
qbasic_forever wrote: post #29

Rootless podman is my first choice for using containers now, it works fantastically well in my experience. It's so much nicer to have all my container related stuff like volumes, configs, the control socket, etc. in my home directory and standard user paths vs. scattered all over the system. Permission issues with bind mounts just totally disappear when you go rootless. It's so much easier and better than the root pr…

Are you saying that all files from your containers are owned by you as user? If so I will start investigating right now. It is so super annoying to download something with nzbget for example and then having to go through sudo to get to your downloaded files. It is indeed my major gripe with my docker compose setup atm. Or just messing with a html file in the nginx docker bind mount, ugh! If podman solves that I’m goi…

Something that can't be solved by PUID/PGID in the command or in Compose?

Re: Docker is dead? Podman – an alternative tool?

#93

Post by nickjj »

teekert wrote: post #76
qbasic_forever wrote: post #29

Rootless podman is my first choice for using containers now, it works fantastically well in my experience. It's so much nicer to have all my container related stuff like volumes, configs, the control socket, etc. in my home directory and standard user paths vs. scattered all over the system. Permission issues with bind mounts just totally disappear when you go rootless. It's so much easier and better than the root pr…

Are you saying that all files from your containers are owned by you as user? If so I will start investigating right now. It is so super annoying to download something with nzbget for example and then having to go through sudo to get to your downloaded files. It is indeed my major gripe with my docker compose setup atm. Or just messing with a html file in the nginx docker bind mount, ugh! If podman solves that I’m goi…

> Are you saying that all files from your containers are owned by you as user? If so I will start investigating right now

You can do this with Docker today without much fuss.

Here's a bunch of web app examples (Flask, Rails, Django, Node, Phoenix) that run your containers as a non-root user which ensures any volume mounted files end up being set to your Docker host's user along with running your main process as a non-root user: https://github.com/nickjj?tab=repositories&q=docker-*-exampl...

There's no hard coding of user names either. The user name created in the Docker image never directly gets mapped back to your Docker host.

This works because bind mounts happen over uid:gid 1000:1000 by default, so as long as your Docker host user's uid:gid is 1000:1000 everything works out of the box. On Windows and macOS you don't need to even think about this because Docker Desktop will fix permissions for you and on native Linux chances are your user uid:gid is 1000:1000 because it's the first non-root user on your system. For non-controllable environments like CI you'd typically disable volumes which is a good idea anyways because you're probably not using volumes in production. For single server deploys on a self managed VPS you control the environment. I covered this in a little more detail in my DockerCon talk at: https://nickjanetakis.com/blog/best-practices-around-product...

In the worst case scenario where you have no other options you can make the Dockerfile more complicated and introduce build args for the uid:gid so you can change it to satisfy the needs of a specific host but I don't like this since you'd need to rebuild a different image for a different environment, but it would technically work. I've never run into this scenario after having used Docker since 2014. I've also done contract work for dozens of companies in all sorts of different environments.

Re: Docker is dead? Podman – an alternative tool?

#94

Post by pxeger1 »

hamilyon2 wrote: post #73
pelorat wrote: post #71

I just use LXC, it's never failed me and has none of the hype.

Lxc rocks. It is linux-only, though

Containers are a Linux-only feature. Docker Desktop just runs a Linux VM on Windows and macOS.

(actually I think Windows Server has some container support now, but it's a totally different system)

Re: Docker is dead? Podman – an alternative tool?

#95

Post by RyEgswuCsn »

lapser wrote: post #83
teekert wrote: post #76

Earlier quoted context omitted.

Are you saying that all files from your containers are owned by you as user? If so I will start investigating right now. It is so super annoying to download something with nzbget for example and then having to go through sudo to get to your downloaded files. It is indeed my major gripe with my docker compose setup atm. Or just messing with a html file in the nginx docker bind mount, ugh! If podman solves that I’m goi…

Root inside the container is the same as your user.

No it’s not. File written from inside the container into a mounted volume as root will be owned by root outside the container (uid 0, to be specific; doesn’t matter what the user is named).

Edit: I might have misunderstood parent, who might be referring to Podman attempting to manage the uid mapping.

Re: Docker is dead? Podman – an alternative tool?

#96

Post by smarx007 »

How did the intro get so many things wrong?!

1. Mirantis did not acquire Docker Inc., they only bought Docker Enterprise. See https://techcrunch.com/2019/11/13/mirantis-acquires-docker-e... and https://www.docker.com/blog/docker-enterprise-edition/

2. k8s didn't remove dockershim for political reasons but because containerd was refactored out of Docker long time ago and k8s wanted to get rid of the extra layer. See https://kubernetes.io/blog/2022/01/07/kubernetes-is-moving-o...

3. Rate limits have nothing to do with the container runtime. Podman also has to get images from somewhere. And Cloudfront bills starting at $0.02/GB (assuming you pump 5PB+) have to be paid somehow. The rate limits were mostly in place to deny corporate CI users access to the Hub free of charge and force them to pay or deploy a mirror.

4. RedHat offers not only packages in RHEL but also support and it makes sense they will offer packaging and support only for podman (a RH project) going forward. This does not concern us who don't pay for RH support.

Having said that, Podman is a nice evolution of Docker. Though I am not sure how much I can trust the rest of the article given how the intro twisted so many facts.

Re: Docker is dead? Podman – an alternative tool?

#97

Post by weitzj »

RyEgswuCsn wrote: post #95
lapser wrote: post #83

Earlier quoted context omitted.

Root inside the container is the same as your user.

No it’s not. File written from inside the container into a mounted volume as root will be owned by root outside the container (uid 0, to be specific; doesn’t matter what the user is named). Edit: I might have misunderstood parent, who might be referring to Podman attempting to manage the uid mapping.

Last thing I remember you can tweak your /etc/setuid, setgid to properly map between the user inside the container and outside

Re: Docker is dead? Podman – an alternative tool?

#98

Post by gnfurlong »

RyEgswuCsn wrote: post #95
lapser wrote: post #83

Earlier quoted context omitted.

Root inside the container is the same as your user.

No it’s not. File written from inside the container into a mounted volume as root will be owned by root outside the container (uid 0, to be specific; doesn’t matter what the user is named). Edit: I might have misunderstood parent, who might be referring to Podman attempting to manage the uid mapping.

The parent comment is still talking about rootless podman (and really just user namespaces). Root in the container is absolutely mapped to the user executing podman outside the container.

If it mapped to root outside the container, you could just use podman to create setuid scripts owned by root for very trivial privelege escalation.

Re: Docker is dead? Podman – an alternative tool?

#99

Post by stingraycharles »

smarx007 wrote: post #96

How did the intro get so many things wrong?! 1. Mirantis did not acquire Docker Inc., they only bought Docker Enterprise. See https://techcrunch.com/2019/11/13/mirantis-acquires-docker-e... and https://www.docker.com/blog/docker-enterprise-edition/ 2. k8s didn't remove dockershim for political reasons but because containerd was refactored out of Docker long time ago and k8s wanted to get rid of the extra layer. See h…

> The rate limits were mostly in place to deny corporate CI users access to the Hub free of charge and force them to pay or deploy a mirror.

What I never understood is why they didn’t just properly handle this with mirrors like any package manager does; why is this a problem for docker, but not for yum / apt / etc?

I have to admit that these rate limits have accelerated my migration to alternatives like quay.io

Re: Docker is dead? Podman – an alternative tool?

#100

Post by Havoc »

krageon wrote: post #79
Havoc wrote: post #6

Think it is rapidly moving towards being more of a data carrier/format rather than being dead per se. Half the time you're jamming it into some cloud service anyway where you have no idea what GCP/fly/aws is using under the hood to actually run it. Meaning this discussion is more relevant to the self-hosted context. In which case I'd say containerization isn't really security. So in my mind that residual risk of the…

Kind of a weird take, to be honest. If containerization is not security, them not running as root should be an absolutely critical first step for managing risk.

>If containerization is not security

Call it less secure than VMs if you prefer that wording.

>not running as root should be an absolutely critical first step for managing risk.

Kinda depends on what angle you come at it from risk management. You could take something less secure (containers) and try to tweak it to meet whatever level of residual risk you deem acceptable. Or you could just jump straight to VM and benefit from the inherent higher level of separation.

The fact that all the big players with their clever engineers have specifically opted for VM tech (e.g. AWS creating firecracker for lambda) tells me the later is probably the way to go.

That said I mostly do stick to containers when in a trusted environment.

Post reply on HN