[HN Gopher] Podman 4.0
___________________________________________________________________
Podman 4.0
Author : smbv
Score : 189 points
Date : 2022-02-22 20:47 UTC (2 hours ago)
(HTM) web link (podman.io)
(TXT) w3m dump (podman.io)
| crb wrote:
| If you want to learn about the history of the Podman project, you
| might enjoy my interview with Red Hat's container team lead and
| Podman's architect.
| https://kubernetespodcast.com/episode/164-podman/
| eatonphil wrote:
| I first learned about and was immediately sold on Podman in
| 2018 when Dan Walsh gave a talk at NYLUG.
|
| I think this is the same talk:
| https://www.youtube.com/watch?v=riZ5YPWufsY. Called "replacing
| docker with podman".
| warmwaffles wrote:
| Thanks, I'll check it out. I've been wanting a replacement to
| fill the `rkt` hole in my heart.
| szastamasta wrote:
| Great news. I hope it will now work with docker compose. Missing
| compose support was the only reason I had to ditch it in favor of
| Colima. But will try it out again now.
| eatonphil wrote:
| I use it with docker-compose now and I'm running podman 3.4.4.
| I think you just need to install `podman-docker` on Fedora to
| get the docker socket. See:
| https://www.redhat.com/sysadmin/podman-docker-compose.
| maxloh wrote:
| `docker-compose` is different from `docker compose` (with a
| space in between words).
|
| The former will be replaced by the latter in the long run.
|
| https://github.com/docker/compose-
| cli/issues/901#issuecommen...
| eatonphil wrote:
| Oh! I thought it was just a typo. That is very unfortunate
| naming.
| conor_f wrote:
| docker-compose was really the paradigm shift I needed when it
| came to containers and now I'm whole-heartedly on board with
| containerization. No reason something like the compose syntax
| (or similar) couldn't be a common, shared front-end to all
| container solutions, but until that point, I'm going to be
| sticking with Docker purely for certainty that docker-compose
| functions as expected.
| SahAssar wrote:
| I'm probably just missing some fundamental knowledge, but why
| does podman need it's own network stack? Doesn't linux include
| functionality for things like virtual networks, bridges, virtual
| networks and similar?
|
| EDIT: the second "virtual networks" meant to say "virtual
| interfaces"
| metadat wrote:
| Out-of-the-box Linux doesn't handle container networking in a
| default fashion, because there are many common configurations
| and techniques available to obtain different effects and
| results for the exact nature of each network being attached or
| created.
| freedomben wrote:
| When they say "network stack" they don't mean their own
| implementations of TCP and UDP like you would for an OS (like
| linux). They mean the various pieces that the container runtime
| has to implement. See CNI[1] for more information.
|
| [1]: https://www.cni.dev/
| SahAssar wrote:
| So it's the "compiler" for a CNI spec into a configuration
| for a linux network namespace?
| freedomben wrote:
| Yeah I think that's a reasonable way to think of it. When a
| container gets created (and Podman supports _Pods_ also),
| it needs a handful of network stuff setup, from assigning
| an IP address to the pod /container, to setting up NAT,
| configuring container-to-container networking, etc.
| SahAssar wrote:
| Thanks, that makes sense. I'd prefer it'd be called
| something else than a "network stack", but that's life.
| mindwok wrote:
| I kinda feel bad for Docker. The prevailing wisdom seems to be
| that you shouldn't be using Docker anymore, use Podman. Often the
| reasons for this is that Podman is daemonless, supports rootless
| containers, etc. But I feel this is misplaced:
|
| - The Docker daemon is actually really useful. It can run
| containers as other users, perform a bunch of mounting and
| networking stuff you can't do as rootless (or at least requires
| some hacky workarounds), and can monitor/maintain your
| containers. Podman can do lots of this as well, but requires the
| use of systemd. So in those cases you've just swapped one daemon
| for another.
|
| - For most of my use cases, I don't really care about rootless.
| On servers I run all my docker containers as non-root anyway, and
| if I'm on a workstation I have privileges and don't need
| rootless.
|
| - Although Podman claims compatibility with Docker, I've always
| found issues with trying to use it even up to a few months ago,
| prior to this release. Mostly when trying to use compose,
| although it does improve every release.
|
| I basically just view the Docker daemon as an init system like
| systemd. It's a privileged daemon that runs other processes. But
| for some reason it seems to have been made into a bogeyman.
| DCKing wrote:
| That usefulness of the Docker daemon has actually been
| acknowledged by the Podman project. That's the "socket" they're
| talking about in this blog.
|
| If you run `sudo systemctl start podman.socket` on your Podman
| 3.0+ & systemd system, you get a fully Docker daemon compatible
| API on your localhost. You can use all your Docker API
| compatible tools - including vanilla Docker Compose - and it
| will just use Podman underneath. Compatibility with Docker
| features may not be 100% yet, but it's getting to the point
| that most use cases for Docker's ""legacy architecture"" can be
| handled by Podman.
|
| And if you don't need an API, it's default off on Linux distros
| and you can just use Podman without that additional exposure.
| zzzeek wrote:
| from my experience I often find myself waiting for a hung
| docker daemon to give me the answer to a query. I dont know
| much about how it works but it feels monolithic and fragile the
| way a single container seems to be able to hang the whole thing
| and I can't even do a "docker ps" to see what's going on.
| Podman doesnt have any issues like that, it responds quickly at
| all times regardless of individual container status in my
| experience.
| jiehong wrote:
| One thing that is actually nicer is that podman can run
| kubernetes pods from the kubernetes yaml file description
| (mostly) directly.
|
| This avoids having to use kubernetes in production, and
| something different (like docker-compose) in local.
|
| Being able to search in multiple container registries is very
| nice, and docker doesn't allow you to do that (to the best of
| my knowledge). It's very useful if you have a company container
| registry for example.
| freedomben wrote:
| This is a great release, very exciting! When I worked for Red Hat
| as an OpenShift Consultant it was common to have developers super
| excited for using podman, but because the macOS story was poor
| they had to revert to docker. This removes a huge blocker for a
| lot of people!
| deknos wrote:
| does podman now support nftables and does not create legacy
| iptables anymore?
| topspin wrote:
| This release adds Netavark for container network configuration
| (in addition to the existing CNI stack support.) Netavark says
| "Support for iptables and firewalld at present, with support
| for nftables planned in a future release"
|
| So not yet, but planned.
| mfer wrote:
| It's worth noting that existing CNI plugins use iptables. If
| something uses those it'll end up using iptables. Getting those
| updated or replaced would be making transitions to something
| newer
|
| Disclaimer, I started Rancher Desktop
| kosikond wrote:
| I tried to migrate from Docker to Podman 3.4 recently, but just
| gave up. It just have still weird quirks, containers were exiting
| without any clear cause, fighting with SELinux... I could not
| manage portainer.io to get working... the docs are somewhat
| incomplete...Lack of support in Debian [1] means I can't easily
| migrate my SBCs either.
|
| I have Podman on my radar, will give it a shot next year, so far
| it still feels still quite bleeding edge. But kudos to red
| hatters for another major release!
|
| [1] Fully knowing there is v3.0.0 in repos for Stable, but
| switching to Testing just because podman?
| nhoughto wrote:
| Is there an eli5 or similar on the differences between podman /
| docker / rancher / others?
|
| Feels unexplained (at least for me), how do I know which to
| choose when and what are the trade offs?
|
| I recently went deeper on Rancher Desktop and it's use of
| containerd vs dockerd backends and it is totally not obvious what
| you lose if not using dockerd and how you might fill the gaps.
| Feels like because docker established the space and put a bunch
| of related components together (cli, image building, image
| storing and container running) and other projects make difference
| choices it can be quite confusing to compare them.
| spicyusername wrote:
| Podman is for running containers on a single host. It's exactly
| like docker with a few additional features (like the ability to
| run rootless containers and run containers in something like a
| Kubernetes pod). Podman was developed by Red Hat to replace
| docker, the cli, because Docker, the company, didn't play very
| nice with the open source community.
|
| Rancher is a Kubernetes implementation that can run containers
| across multiple hosts. Rancher is more comparable to something
| like Red Hat OpenShift or Hashicorp Nomad than docker.
| pkaye wrote:
| Does Kubernetes usage also require podman or docker?
| Bilal_io wrote:
| Kubernetes can support multiple solutions if I am not
| mistaken.
|
| I know rancher requires Docker and is not compatible with
| Podman as of today.
|
| And I believe Red Hat uses Podman in Openshift, their
| implementation of kubernetes.
| dariusj18 wrote:
| Kubernetes can use either
| spion wrote:
| I think OP meant Rancher Desktop, which is meant to be a
| replacement of sorts for Docker Desktop (it does include a
| Kubernetes implementation though)
| pydry wrote:
| my understanding was that it was docker that doesnt need root
| or a daemon.
|
| i always thought it seemed wrong that it needed either of those
| to start with.
|
| in most other respects i think it's a drop in replacement.
| mfer wrote:
| It depends on what you're looking for. Most people use
| containerd as their backend to Kubernetes. Docker itself uses
| it. Podman uses a different engine. That may matter to some
| folks.
|
| There are also a bunch of tools that talk directly to the
| docker socket.
|
| There are a lot of varying use cases here.
|
| Disclaimer, I started Rancher Desktop.
| nhoughto wrote:
| I think the most surprising coming from docker was that
| containerd can't build images, just run them, thus nerdctl
| and things plus other userspace ways of building images
| too.. so many options..
|
| Totally makes sense when you understand more but initial is
| surprising.
| Johnnynator wrote:
| Podman can also be optionally be run as a system daemon
| that provides a docker socket, but still has/used to have
| quite a bit of compatibility isues.
| stingraycharles wrote:
| From a security perspective, a daemon is a nightmare. It
| makes so much more sense to inherit the permissions from the
| process it's launched from, and as such I'm a big proponent
| of podman (or rkt in a distant past).
| zaphirplane wrote:
| there is more to it.
|
| If you are running kubernetes there are k8s daemons already
| possibly CRI-O containerd Otherwise the pod is started by
| systemd, which is another daemon
|
| A Started from the command line using podman, is not a
| production pattern
| rodgerd wrote:
| It also has a couple of other handy features:
|
| 1. It can form up k8s-style pods for deploying tightly-
| coupled containers. 2. It can understand k8s YAML for
| deployment (although obviously it doesn't support everything
| k8s does), which makes it easier to do deployment config that
| will work locally with podman and then in a k8s deployment.
| anthropodie wrote:
| What you said is true. Other than those podman:
|
| - does not mess with your iptables unlike docker. Because of
| this docker can bypass firewall rules set by ufw
|
| - does not creates bridged networks
| freedomben wrote:
| If you use K8s or some other production container runtime,
| those are enormous benefits.
| dang wrote:
| Related:
|
| _Podman in Linux_ -
| https://news.ycombinator.com/item?id=28687229 - Sept 2021 (89
| comments)
|
| _How to Replace Docker with Podman on a Mac_ -
| https://news.ycombinator.com/item?id=28462495 - Sept 2021 (85
| comments)
|
| _Podman, the open source Docker alternative ported to M1 (Apple
| Silicon) machines_ -
| https://news.ycombinator.com/item?id=28429650 - Sept 2021 (147
| comments)
|
| _Migrating from Docker to Podman_ -
| https://news.ycombinator.com/item?id=28413470 - Sept 2021 (107
| comments)
|
| _Podman: A tool for managing OCI containers and pods_ -
| https://news.ycombinator.com/item?id=28376686 - Sept 2021 (184
| comments)
|
| _Podman: A Daemonless Container Engine_ -
| https://news.ycombinator.com/item?id=26101608 - Feb 2021 (241
| comments)
|
| _Transitioning from Docker to Podman_ -
| https://news.ycombinator.com/item?id=25165195 - Nov 2020 (268
| comments)
|
| _Podman and Buildah for Docker Users_ -
| https://news.ycombinator.com/item?id=21556894 - Nov 2019 (73
| comments)
|
| _Dockerless, part 3: Moving development environment to
| containers with Podman_ -
| https://news.ycombinator.com/item?id=20503061 - July 2019 (40
| comments)
|
| _Podman and Buildah available in RHEL 7.6 and RHEL 8 Beta_ -
| https://news.ycombinator.com/item?id=19005426 - Jan 2019 (50
| comments)
| thecosmicfrog wrote:
| How's Podman's Apple Silicon (M1) support these days? Last time I
| checked - maybe 3 months ago - it was pretty rough.
| eatonphil wrote:
| I'm still on version 3 but Podman is easier to use than ever.
| Kinda random: it even supports `podman build` with `-v` so you
| can volume mount in during a build. I didn't even think about it
| (I have `alias docker=podman` on my machine) until I pushed
| `docker build -v $(pwd):/x` to Github Actions and Docker failed
| on it.
|
| And apparently Podman has supported this for years while Docker
| hasn't :shrugs:.
|
| https://github.com/moby/moby/issues/14080
| vbezhenar wrote:
| Wow I just struggled yesterday without that feature. Can't wait
| to switch to podman.
| maxloh wrote:
| How did you get podman instead of docker installed in the first
| place?
| eatonphil wrote:
| `dnf install podman` probably? I can't remember.
| freedomben wrote:
| On RHEL 8 docker didn't support cgroups v2 so the OOTB
| `docker` package installed podman and aliased it to docker.
| IIRC Fedora 30 and 31 did too? I don't remember exactly.
|
| You can run docker pretty easily on RHEL 8 but you have to
| downgrade cgroups in order to do so. Plenty of guides out
| there now.
| CrLf wrote:
| Current Docker supports cgroupsv2 as well.
| freedomben wrote:
| Yes current docker does, but it didn't at the time RHEL 8
| came out. The question I was responding to was "How did
| you get podman instead of docker installed in the first
| place?" and GP mentioned `dnf`, which is a RHEL/Fedora
| thing, so I think it's a pretty reasonable theory.
| qbasic_forever wrote:
| docker supports some volume mounts while building, it's part of
| the buildkit backend and is used for mounting secrets during
| builds. It is very poorly documented and hidden behind the
| buildkit buildx command. Check out the RUN --mount= section
| here:
| https://github.com/moby/buildkit/blob/master/frontend/docker...
| 2OEH8eoCRo0 wrote:
| New Rust-based network stack. Support for Windows and OSX.
| Supports WSL2 backend. Looks nice! Hats off to the Podman team!
| tunesmith wrote:
| Anyone know if this can be easily used in place of Docker Desktop
| for Mac?
| pm90 wrote:
| I've used it for the past 6months and haven't noticed any
| issue. I don't miss docker desktop at all.
| e40 wrote:
| Curious of this, too. Previous versions has issues with volume
| mapping to local filesystems.
| pacbard wrote:
| I want to say it's almost there with 4.0. It seems that they
| re-implementend most features.
|
| For me, this is still the roadblock:
|
| > More features, including support for volume mounts from the
| host, are planned for Podman v4.1, so stay tuned for more
| updates.
|
| I do not run many self-contained containers and I usually end
| up mounting a local folder in the container, so I'll have to
| wait a little bit longer to fully transition to Podman.
|
| Also, it doesn't have a native interface like docker desktop
| and it works mostly through the terminal. Last time I checked,
| there are some external tools that add a Docker Desktop app
| like on top of podman.
| taw28 wrote:
| Volume mounts are different than mounting a directory into
| the container. That has been well supported for a while.
|
| You can look up what a podman volume is to see the
| difference.
| MindTooth wrote:
| Rancher Desktop[0] is one new kid on the block.
|
| Any reason for why you want to change?
|
| https://rancherdesktop.io/
| kbd wrote:
| Personally I'd prefer to use open-source tools if possible.
|
| For Podman vs Rancher, what are pros and cons? If you only
| use Docker from the command line is there any reason to use
| Rancher?
| slig wrote:
| For anyone using on macOS, is it better than Docker for
| projects with thousands of files being watched for changes?
| maxloh wrote:
| How is it compared to nerdctl[0] (another docker compatible cli)?
|
| [0]: https://github.com/containerd/nerdctl
| peachy_no_pie wrote:
| Podman uses runc as the default container runtime. Nerdctl uses
| containerd. There are probably other differences but that's a
| substantial one imo.
| Macha wrote:
| Podman has been a longer lived project. It's supposed mostly by
| Red Hat, which may be a plus or minus in your view. nerdctl re-
| uses more of moby's (formerly Docker CE) underlying tech.
| Podman has some nice convenience features to generate kube yaml
| or systemd units.
| eriksjolund wrote:
| I like this Podman feature: Support for socket activation
|
| Podman will pass on the socket-activated socket to the container.
|
| I wrote a small example demo for setting up socket activation
| with systemd, Podman, and a MariaDB container:
|
| https://github.com/eriksjolund/mariadb-podman-socket-activat...
| mikepurvis wrote:
| Overall the integration story between podman and systemd is
| way, way better than with Docker. And that's in both
| directions, from using the host's systemd to start and manage
| containers, but also for running systemd within podman
| containers.
| freedomben wrote:
| I would definitely expect that given the history of systemd
| and docker. IIRC difficulty Red Hat team had with integrating
| systemd and docker was one of the reasons why they started
| Podman rather than continuing to push everything upstream to
| docker. The docker team didn't want docker to have to
| accommodate systemd and refused some contributions that were
| important for a good integration.*
|
| *There's still some bad blood out there about it, so I just
| wanted to make explicit that I'm not making a value judgment
| on docker's refusal. I'm not educated enough on the details
| to make a fair judgment. Sometimes you have to say "no" to
| features to protect your product.
| nunez wrote:
| One of the folks that wrote THE manual on how to get
| systemd to work with Docker works at Red Hat on podman, so
| that's not surprising at all.
___________________________________________________________________
(page generated 2022-02-22 23:00 UTC)