Live data from Hacker News

Podman 4.2.0

github.com

81–90 of 104 posts

Re: Podman 4.2.0

#81
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…

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 distro, import/export/register it as usual if you want a clone unaffiliated with the podman package per se.

Re: Podman 4.2.0

#82

Not a Podman or Docker-specific question/complaint, but is anyone working on a solution around UID/GID remapping between container and host? Not the "solution" offered by user namespaces, because those can only do a 1:1 remap, but an "anything any user writes inside the container is owned by the host user". In other words, if host UID 1000 runs a container that has UID 100, 101, 102 and they all write files to a moun…

You can use ACLs for this.

Re: Podman 4.2.0

#83
post #32
post #30

Earlier quoted context omitted.

> . Ubuntu also has a terrible track record of not aligning where it makes sense with other distorts You mean not aligning with Red Hat and what they're pushing on everyone else. Ubuntu is on a shorter release cycle compared to Debian so they're usually the first non-Red Hat distro with new stuff. Systemd vs Upstart, Unity vs GNOME (3?), etc. They try to do new stuff, and there's nothing wrong with that. Not everyone…

> 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 software collection system because they actually replace the "original" package, so it's just a straight version upgrade without having to worry about fixing configuration files etc. if it's compatible.

Re: Podman 4.2.0

#84
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…

I don't think GP was suggesting any official affiliation between Red Hat and canonical. I think they were making a point that there's a lot of potential users on Ubuntu who might switch to podman if it were available. When trying to establish a project, user acquisition is a critically important part.

I agree with them. I think Red Hat should be making effort to get podman working well in Ubuntu (well, Debian but would benefit Ubuntu). Although it's very possible that Red Hat is trying and have met resistance. Canonical wants for a very different direction and it wouldn't surprise me at all if they were throwing road blocks in the way (or at least, doing nothing to remove the road blocks).

Re: Podman 4.2.0

#86
post #27

Earlier quoted context omitted.

> 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. Nah, red hat probaby cares very little about that. Red hat probably cares about delivering the best it can for its users (red hat, centos and fedora users). Podman probably has no explicit goal of replacing docker, it only has the goal of p…

I don't think Podman developers are even really strongly integrated into Red Hat OS development goals. They create something that can be packaged and works on most Linux distros. I do think that Podman does try to be a replacement for docker though, and that is why they have the podman-docker layer. They may not outright say it because of the Docker licensing fiasco, but with Podman Desktop it is clear that they are…

I can't comment on Podman specifically, but Red Hat's approach to the projects that they choose to focus on in the "Red Hat ecosystem" seems to be to just do development in upstream first and then whoever is working on the distros packages it for Fedora and/or RHEL. I don't see why they should put resources into packaging in their upstream projects; it doesn't seem to me that they're hostile to other distros packaging their software.

Packaging is a distro problem, not an upstream one, though upstreams should of course work with distro maintainers to make packaging frictionless.

Re: Podman 4.2.0

#87

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 and therefore purchased ahead of time).

Examples of friction off the top of my head:

* storage - who knows if there’s actually enough space to provision and attach a volume

* exposing a service externally

    * load balancers managed by a different team (such as networking) and their process or tech environment not setup to support k8s

    * certificates need to be requested and signed by approved enterprise certificate authority

    * network security restrictions - lengthy process for firewall change requests or similar to expose a service externally (also related to point above on certificates)
I’ve also seen silly deployments where k8s runs inside VMware virtual machines - why not just run k8s directly on hardware if on-prem? Virtual machines just add a ton of unnecessary and expensive overhead.

Personally, my preferred way of doing k8s:

1. GKE (Google Kubernetes Engine) - the easiest and cheapest managed option

2. kops

Hot take here but I personally think EKS is convoluted and complicated as hell. I’ve not used AKS but in the past I’ve seen limitations such as network configuration that became problematic - couldn’t route traffic properly because IP space overlapped with corporate IP ranges already used by VPN and/or existing vnets, though it’s been a couple years since I first saw this specific example.

Re: Podman 4.2.0

#88
post #69

Now if Gitlab.com only supported leveraging Podman in their runners.

Darren here - PM for GitLab Runner. At this time, we aren't considering adding Podman to GitLab SaaS Runners on Linux. I created this issue, so please add comments there so we can continue the discussion.

https://gitlab.com/gitlab-org/gitlab/-/issues/370522

Re: Podman 4.2.0

#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.
Post reply on HN