I tried to use Podman a few months ago, but the time spent to execute the "podman" command was considerably higher than that of the "docker" command. I am worried if this is a fundamental problem of the daemonless design. If that is the case, it would not be possible to solve the speed problem of Podman.
Podman: A Daemonless Container Engine
191–200 of 250 posts
Re: Podman: A Daemonless Container Engine
#192Earlier quoted context omitted.
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 everythin…
I'm intrigued that you must run Manjaro and kind of want work with you because of it. :)
Manjaro is great. Best Linux experience I've had so far. It's good that people recognize it.
Re: Podman: A Daemonless Container Engine
#193Earlier quoted context omitted.
Reading through the comments though it looks like I should try making a BTRFS mount for the container storage and that might help the fuse-overlayfs problems though.
It feels weird that a containerisation technology imposes requirements on the underlying storage technology to work well, tho. Now I understand that btrfs is not really a requirement. But I've been thinking about using podman to replace docker-in-docker on our fleet of gitlab runners where we build our images, and running btrfs is a deal breaker. We really don't want to add complexity to the mix. Fuse-overlay burning…
Have you tried Kaniko? That's how I got hid of DinD in my Gitlab Runners.
Re: Podman: A Daemonless Container Engine
#194I've been trying to use podman in production and it is not working very well. I'm excited for this technology but it is not ready. - podman layer caching during builds do not work. When we switched back to docker-ce, builds went from 45 minutes to 3 minutes with no changes to our Dockerfile - fuse-overlayfs sits at 100% CPU all day, every day on our production servers - podman loses track of containers. Sometimes the…
I could very well be wrong but Podman seems to have missed the time-frame of opportunity. It was always a knife fight between Red Hat and Docker with regard to tooling. Red Hat wanting to own the toolchain for containers so they didn't have to deal with, and so they could box out, competitors like (now basically defunct) Docker Enterprise. I've taken a look at podman from time to time over the years but it seems like…
Not to mention podman's historic[1] lack of compose support (or similar), which is frequently used in CI and local dev environments. I think has really held it back for a lot of folks.
[1]: Apparently initial support planned in version 3.0?
Re: Podman: A Daemonless Container Engine
#195Earlier quoted context omitted.
> Go is actually a really poor choice for the container runtime because much of the container setup cannot be done from multithreaded code[0] This was addressed in 2017/2018 [0], it's no longer a poor choice. [0]: https://github.com/golang/go/commit/2595fe7fb6f272f9204ca3ef...
While the particular issue of network namespaces and locking the os thread was fixed, there is still c code that must run before the go runtime starts to work around the issue that you cannot do some of the necessary nsenter calls once you have started additional threads. The c code to make runc work is encapsulated in libcontainer/nsenter[0] [0]: https://github.com/opencontainers/runc/tree/master/libcontai...
this seems like a pretty trivial amount of C, by comparison, and a pretty solved problem now.
Re: Podman: A Daemonless Container Engine
#196Earlier 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.
Remember that runc contains quite a few lines of C: https://github.com/opencontainers/runc/blob/4d4d19ce528ac40c... https://github.com/opencontainers/runc/blob/4d4d19ce528ac40c...
Is what appears to be less than 2,000 lines including detailed comments etc. "quite a lot"?
This seems like a manageable amount to very carefully maintain and not at all like writing something entirely in C.
Re: Podman: A Daemonless Container Engine
#197I recently passed the RHCSA exam, which as of last October added a containers/podman section to the test. I usually work with lxcs under libvirt and directly, so working with podman was new to me. The test requirements are very simplistic, but I went further and spent a decent amount of time finding annoyances and issues. I am not impressed with podman. It's buggy and slow. Documentation is very basic and the underla…
I really enjoy working with LXC. And the fact that I can switch now between container mode or VM mode makes it even better. That and best ng able to do lxc in lxc easily to test an infrastructure locally.
Re: Podman: A Daemonless Container Engine
#198Earlier quoted context omitted.
Reading through the comments though it looks like I should try making a BTRFS mount for the container storage and that might help the fuse-overlayfs problems though.
It feels weird that a containerisation technology imposes requirements on the underlying storage technology to work well, tho. Now I understand that btrfs is not really a requirement. But I've been thinking about using podman to replace docker-in-docker on our fleet of gitlab runners where we build our images, and running btrfs is a deal breaker. We really don't want to add complexity to the mix. Fuse-overlay burning…
>It feels weird that a containerisation technology imposes requirements on the underlying storage technology to work well, tho.
Why? Storage is literally the backbone of technology. From databases to webservers there are unique and real requirements. There's a reason why the enterprise storage market is still worth several billion dollars, and it's not because storage is easy.
In 2021, with billions of dollars of R&D at their disposal - neither Amazon, Google, or Microsoft have even a mediocre NAS stack in comparison to the likes of Dell/EMC (Isilon) or NetApp (ONTAP). Heck they can't even compete with startups like Qumulo or Vast.
Re: Podman: A Daemonless Container Engine
#199The ability to start containers as a normal user ("rootless mode") is quite interesting and imo the most significant feature missing from LXD, which requires you to either use sudo or be a part of the "lxc" group (equivalent to having sudo privileges).
Wouldn't the lxc group have much more focused permissions than sudo?
You can mount the root fs in a container and with uid mapping and because the daemon is running as root you can pretty much do whatever you want.
Re: Podman: A Daemonless Container Engine
#200I've been trying to use podman in production and it is not working very well. I'm excited for this technology but it is not ready. - podman layer caching during builds do not work. When we switched back to docker-ce, builds went from 45 minutes to 3 minutes with no changes to our Dockerfile - fuse-overlayfs sits at 100% CPU all day, every day on our production servers - podman loses track of containers. Sometimes the…
I could very well be wrong but Podman seems to have missed the time-frame of opportunity. It was always a knife fight between Red Hat and Docker with regard to tooling. Red Hat wanting to own the toolchain for containers so they didn't have to deal with, and so they could box out, competitors like (now basically defunct) Docker Enterprise. I've taken a look at podman from time to time over the years but it seems like…
> Red Hat wanting to own the toolchain for containers so they didn't have to deal with
This is a misrepresentation. The situation was that Docker didn't take patches, as some were very specific changes for systemd and lack of unionfs, etc but over time it applied to most patches from RH associated people.