51–60 of 250 posts
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
Adduser vs useradd is older than I am and I still can't keep them straight. Just put this with the rest of the fire, I guess, heh!
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
On other occasions, they just hijack the name. Like they did with dstat.
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…
Why does that seem 'kind of crazy' to you? A container is really just a namespaced Linux process, so … you either need a running Linux kernel or a good-enough emulation thereof.
What seems kind of crazy to me is that so many folks who are deploying on Linux develop on macOS. That's not a dig against macOS, but one against the inevitable pains which arise when developing in one environment and deploying in another. Even though I much prefer a Linux environment, it would seem similarly crazy to develop on Linux and deploy on Windows or macOS. Heck, I think it is kind of crazy to develop on Ubuntu and deploy on Debian, and they are generally very very close!
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
> Runtime: We use the OCI runtime tools to generate OCI runtime configurations that can be used with any OCI-compliant runtime, like crun and runc.
It is almost 100% compatible with docker. I only had to do minimal changes in my Dockerfiles to use it.
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.
I was researching this few hours ago and according to https://github.com/containers/podman/issues/6114#issuecommen... it just works when you add another network.
Docker registry having no IPv6 is another fun story tho.
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…
That's exactly not true, considering you said Linux.
The utility of Linux containers is that they share the same OS instance, but have an embellished notion of Unix process group where, within a container i.e. embellished process group, they see their own filesystem and numbering for OS resources, AS IF they were on individual VMs, but they're not.
Sincere question: why would I want to use Podman over Docker? What does being "daemonless" actually buy me in practice?
Anyone have experience with this? I love the idea of it being daemonless.
* 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 parallel builds and Docker being faster even for single-threaded builds, Docker builds ended up an order of magnitude faster than the Podman ones.
* Buggy caching - There were a lot of caching bugs (randomly rebuilding when nothing changed, and reusing cached layers when files have changed). These issues are supposedly fixed, but I've lost trust in the Dockerfile builds.
* Various bugs when used as a drop-in replacement for Docker.
* Recurring issues on Ubuntu. It seemed all the developers were on Fedora/RHEL, and there were recurring issues with the Ubuntu builds. Things might be better now.
* non-root containers require editing /etc/subuid, which you can't do unless you have root access.
More information about the new BuildKit features in Docker:
Anyone have experience with this? I love the idea of it being daemonless.
If your environment would benefit from smaller, isolated containerization tools then my two cents would be that it's worth keeping an eye on these as they mature, and perhaps perform early evaluation (bearing in mind that you may not be able to migrate completely, yet).
The good:
- Separation of concerns; individual binaries and tools that do not all have to be deployed in production
- A straightforward migration path to build containers from existing Dockerfiles (via "buildah bud")
- Progressing-and-planned support for a range of important container technology, including rootless and multi-architecture builds