Live data from Hacker News

Podman 4.2.0

github.com

91–100 of 104 posts

Re: Podman 4.2.0

#91
I really like the ideas behind podman but they were not able to get enough feature parity with docker fast enough for my org. We use rancher desktop now for local development with Docker underneath. It would be cool if they added podman support in Rancher Desktop.

Re: Podman 4.2.0

#92
post #32

Earlier quoted context omitted.

> obsolete 10 year old versions Talk about hyperboles. RHEL 8 is from 2018 and has had considerably more updates than Ubuntu 18.04. In fact some packages might even be newer than what is in 20.04.

Red Hat introduced modules with RHEL8, meaning they can easily make available more up-to-date versions of software if necessary. It's still not bleeding edge, but eg. PostgreSQL 13 was released on 2020-09-24 and that's available with support in RHEL 8 as a module. Similarly, you have eg. PHP 8, Ruby 3.0 and other software released after RHEL 8's initial release. Modules are much nicer to use than the previous softwar…

The trade off of modules, which it pays to be aware of, is that they have different support lifecycles to the distro they are in. They publish a list that is updates as new modules are released.[1] what this means in practice is that some appstream modules may only have a year or two of support, while other may have until distribution release EOL. For example, in RHEL 8 PHP 7.4 is supported until 2029, almost 9 years after released as a module, but earlier 7.x versions and 8.0 which are also modules have lifecycles that range from 18-24 months.

There's a lot of flexibility in this to support both those that need newer versions of things as well as older stable versions, just be aware and choose and plan accordingly.

1: https://access.redhat.com/support/policy/updates/rhel-app-st...

Re: Podman 4.2.0

#93
post #90

I like this Podman feature: Socket activation of containers Advantages: - Faster network. Rootless Podman will run with native network speed. Normally rootless Podman runs with reduced network speed due to the performance penalty that comes from using slirp4netns. - Improved security as you can disable the ability to establish outgoing connections with --network=none. The container can still communicate over the sock…

Docker can’t really support Socket Activation for containers because it is build around the docker daemon that fulfills similar tasks as systemd. They could only copy the concept to dockerd.

Yeah, Docker the company is funky.

Docker the software is also funky.

Re: Podman 4.2.0

#94

I like this Podman feature: Socket activation of containers Advantages: - Faster network. Rootless Podman will run with native network speed. Normally rootless Podman runs with reduced network speed due to the performance penalty that comes from using slirp4netns. - Improved security as you can disable the ability to establish outgoing connections with --network=none. The container can still communicate over the sock…

Does this work in systemd-less distros like the most common WSL2 ones? I tried to fake Podman to use in a devcontainer but it complained of a missing `/var/run/docker.sock`.

Re: Podman 4.2.0

#95
post #81
post #25

Earlier quoted context omitted.

Red Hat has no official affiliation with Canonical who make Ubuntu. If you want to test podman you 'll have better luck using an OS from the Fedora ecosystem where Red Hat has affiliations and is actively contributing. Since you mentioned Windows I 'd suggest trying something like this [1] or this [2] [1]: https://github.com/yosukes-dev/FedoraWSL [2]: https://github.com/WhitewaterFoundry/Fedora-Remix-for-WSL Disclaim…

If you install the podman package via Scoop, you'll get a `podman` client shim, and then if you run `podman machine init` it'll automatically set up a WSL instance running Fedora with Podman set up and relay the necessary sockets for you so that running `podman ps` or whatever on Windows Just Works™. Then if you want to can run `wsl -d podman-machine-default` to log into the distro as normal. You can also copy the di…

What the official Windows Podman installer, also official Podman Desktop that installs Podman and scoop's Podman package should really do is offer to integrate with your existing WSL2 distro like Docker Desktop does.

Re: Podman 4.2.0

#96
post #25

I was looking at this just last night and the story with Ubuntu is horrible. That's essentially going to be stuck on v3.4 for ten years because it's "a lot of work" to get into that distribution. You'd think an entity the size of RedHat trying to take the reins from Docker would understand that this is an investment they have to make to make it a first-class replacement. I also installed it on Windows to see how the…

Red Hat has no official affiliation with Canonical who make Ubuntu. If you want to test podman you 'll have better luck using an OS from the Fedora ecosystem where Red Hat has affiliations and is actively contributing. Since you mentioned Windows I 'd suggest trying something like this [1] or this [2] [1]: https://github.com/yosukes-dev/FedoraWSL [2]: https://github.com/WhitewaterFoundry/Fedora-Remix-for-WSL Disclaim…

[deleted]

Re: Podman 4.2.0

#97
post #89

Very cool to see Podman Desktop. This seems a replacement for Docker Desktop that is now organizations with more than 250 employees or more than $10 million in revenue https://www.infoq.com/news/2021/09/docker-desktop-subscripti... Also cool to see GitLab Runner support as the first feature mention.

It is, however, missing the 1-click Kubernetes feature of Docker Desktio.

Re: Podman 4.2.0

#99

Does anyone have experience “migrating” from docker to podman on a somewhat large scale? I am starting a new job soon in a DevOps role where the devs use both podman and docker and although the resulting images are the same, using two tools where one would suffice does not seem optimal. For context, it is a medium-sized (~40 devs) commodities trading company running some hundred applications in azure k8s but consider…

On-prem k8s is almost always a bad idea. Things like storage or traffic routing become uncertain/hacky at best or at worst just straight up don’t work. I’ve literally seen many on-prem k8s deployments where there was no support for persistent volume claims because of storage - whether the enterprise storage solution wasn’t supported by k8s or because there was no way to guarantee storage (HDDs being a capital expense…

1. Just pay the vendor. Diy csi is also an option

2. MetallB. Not sure how cert thing applies here…

3. vmware based vms are to manage underlying node image so that you dont have to mess with ipmi/ipxe that often. They can also make networking easier

Post reply on HN