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

Podman: A Daemonless Container Engine

podman.io

Post reply on HN
Print view View original

81–90 of 250 posts

Re: Podman: A Daemonless Container Engine

#81

Post by lima »

shaicoleman wrote: post #59
zeroxfe wrote: post #2

Anyone have experience with this? I love the idea of it being daemonless.

I tried it, and went back to Docker with BuildKit. * The newer version of Docker+BulidKit supports bind-mounts/caching/secrets/memory filesystem etc. we used it to significantly speed up builds. You could probably find a way in buildah to achieve the same things, but it's not standard. * Parallel builds - Docker+BulidKit builds Dockerfile in parallel, in podman things run serially. The combination of caching and para…

Buildkit's caches are a killer feature. They go a long way towards making Docker builds usable for iterative development.

We also migrated back to Docker from Podman because of Buildkit and the general bugginess of Podman.

Re: Podman: A Daemonless Container Engine

#82

Post by archi42 »

otabdeveloper4 wrote: post #58
runeks wrote: post #44

Sincere question: why would I want to use Podman over Docker? What does being "daemonless" actually buy me in practice?

podman runs out of the box in normal user mode and doesn't require sudo.

This. SO MUCH THIS. We use docker for our CI, which is mostly okay. But we devs don't have root on our workstations, so we can't just load the docker image and test stuff in the CI env. Enter podman: I've written a small perl wrapper around it and now everyone can just call `ci-chroot` to drop to a CI-equivalent shell. They can get virtual root (default) or normal user (--user), and the script takes care of everything (binding some useful folders, fetching/updating our internal image, starting/stopping the actual container and cleaning up,...). Only change necessary to our [Manjaro] environment was adding podman to the package list and a small bash script that generates the `/etc/sub{u,g}id` from our LDAP.

Re: Podman: A Daemonless Container Engine

#83

Post by zerkten »

geerlingguy wrote: post #19

What's the status on ease of running on Mac? I know last time I seriously considered testing it out in my workflow, it was kind of crazy that I had to have a separate machine (VM or real) just to run container images... I see in the docs [1]: "Podman is a tool for running Linux containers. You can do this from a MacOS desktop as long as you have access to a linux box either running inside of a VM on the host, or avai…

It seems like they haven't gotten to this, don't understand the needs and the potential, or aren't doing this intentionally. My understanding is that Docker maintains what amounts to a wrapper VM with nice integration to enable the workflow. This doesn't exist for Podman as far as I've seen.

On Windows, the WSL2 feature gives you that easy wrapper in a different way. It's sets up and manages the underlying VM although you have to choose your distro etc. Once this is running after a simple setup you are just using Linux from that point on. It's less specialized than how Docker on macOS seems to work.

If someone knows of something that follows the WSL2 approach without VirtualBox or VMware Fusion I'd be all ears. That would be more versatile than how Docker seems to work right now. Docker's business interests probably aligned well with getting a workflow running, so unless someone is motivated to do similar for Podman, you are going to be out of luck. At least recognizing this deficiency would be a start though.

Re: Podman: A Daemonless Container Engine

#84

Post by SEJeff »

lima wrote: post #70
SEJeff wrote: post #41

Under the covers, both podman AND docker use runc. Redhat is writing a new version named "crun" which is lower overhead and faster: https://github.com/containers/crun

Great idea - let's rewrite the most security-critical piece of container tech in plain C! Red Hat literally took a memory safe Go program and rewrote it in C for performance, in 2020.

It is almost 50% faster for launching containers. That’s considerable, and at scale could be an actual cost savings. If nothing else, efficiency is good.

Also, small c projects can be written properly with discipline. This is a very talented team on a very small and well scoped project. It can be written properly.

Re: Podman: A Daemonless Container Engine

#85

Post by SEJeff »

coder543 wrote: post #72
lima wrote: post #70

Earlier quoted context omitted.

Great idea - let's rewrite the most security-critical piece of container tech in plain C! Red Hat literally took a memory safe Go program and rewrote it in C for performance, in 2020.

Yeah. I just don’t think “runc” has ever been a bottleneck in any systems I’ve worked with. It’s been years since I’ve been able to get excited about rewriting systems from a memory safe language into a memory unsafe language for “performance reasons”. As an industry, we have too much evidence that even the best humans make mistakes. Quality C codebases still consistently run into CVEs that a memory safe language wou…

“Any of the systems you’ve worked with”

I suspect it has been a bottleneck in some of the systems redhat has worked with, or they would have no benefit in writing it. As the authors of openshift I’m sure they’ve seen some pretty crazy use cases. Just because it isn’t your use case doesn’t make it invalid.

Re: Podman: A Daemonless Container Engine

#86

Post by jnwatson »

SEJeff wrote: post #84
lima wrote: post #70

Earlier quoted context omitted.

Great idea - let's rewrite the most security-critical piece of container tech in plain C! Red Hat literally took a memory safe Go program and rewrote it in C for performance, in 2020.

It is almost 50% faster for launching containers. That’s considerable, and at scale could be an actual cost savings. If nothing else, efficiency is good. Also, small c projects can be written properly with discipline. This is a very talented team on a very small and well scoped project. It can be written properly.

There's also the copious amount of static analysis and warnings built into gcc and clang these days, not to mention safer build options. Writing C today is quite a bit better than even 10 years ago.

Re: Podman: A Daemonless Container Engine

#87

Post by SEJeff »

jnwatson wrote: post #86
SEJeff wrote: post #84

Earlier quoted context omitted.

It is almost 50% faster for launching containers. That’s considerable, and at scale could be an actual cost savings. If nothing else, efficiency is good. Also, small c projects can be written properly with discipline. This is a very talented team on a very small and well scoped project. It can be written properly.

There's also the copious amount of static analysis and warnings built into gcc and clang these days, not to mention safer build options. Writing C today is quite a bit better than even 10 years ago.

Indeed. Pretending it isn’t is equally silly.

Re: Podman: A Daemonless Container Engine

#88

Post by Spivak »

perlgeek wrote: post #45
zeroxfe wrote: post #2

Anyone have experience with this? I love the idea of it being daemonless.

One huge advantage over docker is that if you mount a directory into the container, and the container writes files there, on the host system they always have the owner of the user that started the container. That makes it much more convenient for build environments, without having to hard-code user IDs both in the container and on the host.

If you're on a Linux system you can actually make this work better with sssd. So sssd's architecture is actually client-server over a unix socket.

So all you need to do is create a very simple base container layer that just installs sssd-client, and wires up /etc/nsswitch.conf to use it (your package manager will almost surely do this automatically). Then just bind mount the sssd socket into your container and boom, all your host users are in the container.

If you already log in with sssd you're done. But if you only use local users then you'll need to configure the proxy provider so that sssd reads from your passwd on your host. In this case the host system doesn't actually have to use sssd for anything.

Re: Podman: A Daemonless Container Engine

#89

Post by daenney »

SEJeff wrote: post #84
lima wrote: post #70

Earlier quoted context omitted.

Great idea - let's rewrite the most security-critical piece of container tech in plain C! Red Hat literally took a memory safe Go program and rewrote it in C for performance, in 2020.

It is almost 50% faster for launching containers. That’s considerable, and at scale could be an actual cost savings. If nothing else, efficiency is good. Also, small c projects can be written properly with discipline. This is a very talented team on a very small and well scoped project. It can be written properly.

> This is a very talented team on a very small and well scoped project. It can be written properly.

Talent does not preclude you from making mistakes

Most projects start out small and well scoped. That doesn’t mean it’s going to last.

Re: Podman: A Daemonless Container Engine

#90

Post by lima »

jnwatson wrote: post #86
SEJeff wrote: post #84

Earlier quoted context omitted.

It is almost 50% faster for launching containers. That’s considerable, and at scale could be an actual cost savings. If nothing else, efficiency is good. Also, small c projects can be written properly with discipline. This is a very talented team on a very small and well scoped project. It can be written properly.

There's also the copious amount of static analysis and warnings built into gcc and clang these days, not to mention safer build options. Writing C today is quite a bit better than even 10 years ago.

Better, yes. Safe, no. Even with ASAN and modern C++, vulnerabilities happen all the time.
Post reply on HN