Live data from Hacker News

Transitioning from Docker to Podman

developers.redhat.com

231–240 of 278 posts

Re: Transitioning from Docker to Podman

#231

Earlier quoted context omitted.

We use kaniko[1] in Gitlab CI and it’s working great for us. It’s annoying the kaniko image requires us to specify the entrypoint. There’s some peculiarities with Dive [2], but otherwise it’s been a very easy migration. [1] https://github.com/GoogleContainerTools/kaniko [2] https://github.com/wagoodman/dive/issues/318

It is really working for you? Presumably you setup kaniko to build the images first that then run the second part of your pipeline. To run the images, you need to tag them with something that you use inside the gitlab-ci.yml, right? Now what happens when two people push code that make changes to the containers at the same time?

GitLab CI exposes the pipeline ID and it would work for that.

Re: Transitioning from Docker to Podman

#232
post #47

Last time I tried podman it looked very cool being rootless and daemonless, except that since it's rootless I couldn't create the necessary network interfaces... making it pretty much worthless.

Podman 2.1 supports CNI networks (`podman network create`), so it might be worthful now

Great! I'll check it out!

Re: Transitioning from Docker to Podman

#233

Earlier quoted context omitted.

> RedHat just goes with what Linux already has More like, Redhat/IBM defines what Linux has simply by paying most Linux devs, and of course they take advantage of it in userspace and sys management. cgroups/namespaces, systemd, gnome (and it's integration with systemd) plus others are two-sided swords: one one hand they create new functionality, but on the other hand the price to pay is concentrating Linux know-how i…

> and greatly diminishing portability of Linux apps vs other Unix O/Ses Thank's god for that! An OS should build on its strenghts, not be a least common demoninator for portabillity's sake. If that was ok we might just as well just use one OS

Indeed, for me the best UNIX experiences that have been created so far have been NeWS and NEXTSTEP (macOS), and I wouldn't mind if Linux would just standardize on one stack as well.

Re: Transitioning from Docker to Podman

#234

Earlier quoted context omitted.

Compose

I would argue that docker-compose.yml is every bit as bespoke as a systemd service file (so, "medium"; a custom schema embedded in yaml/INI).

Like I said, I don’t actually want docker or docker compose, but they are directionally correct. Notably YAML over INI is a nice improvement. Also, that the docker daemon has a real API and not just dbus.

Re: Transitioning from Docker to Podman

#235

Earlier quoted context omitted.

>> beastly 5G docker image > my beastly 12GB image that even includes Matlab wants a word with you Perhaps in the next 10 years we will be rediscovering packages. :P If you are in the business of charging complex prices per bits over the network, then docker seems to be quite a good investment and making it as popular as possible is a good strategy to print money. /s

> If you are in the business of charging complex prices per bits over the network, then docker seems to be quite a good investment and making it as popular as possible is a good strategy to print money. /s True, that. To be fair, at least it allows me to avoid lots of the brokenness of Python packaging.

Is always good to report packaging bugs so then people can fix them, do you have examples of python packages that can be improved?

Re: Transitioning from Docker to Podman

#236
post #29

Earlier quoted context omitted.

Maybe you are just too far into docker. I noticed that a lot of default workflows (needlessly) depended on docker running with privileges. One big reason for that seem to be Mac users that only know docker from inside a VM. However, if you think about what you're really needing for CI you will easily see that docker-in-docker gains you nothing. You can as well use plain docker (or podman). The same holds for privileg…

> One big reason for that seem to be Mac users that only know docker from inside a VM That has not been the case for a good while now... Docker has been running directly on a hypervisor on the Mac.

Honest question, what's the difference between "from inside a VM" and "directly on a hypervisor"? I always thought it meant the same thing.

Re: Transitioning from Docker to Podman

#237
post #126

It's compatible with cgroups v2 unlike the standard Docker. If you're using Fedora, you have to add a kernel parameter to Grub to use cgroups v1 instead. RedHat seems to be pushing a standard ecosystem for Linux: systemd, Wayland, SELinux, GNOME, and now maybe podman. I've been on Linux for a while; it's a welcome change from all the fragmentation I'm used to. Whereas others try to work around the kernel and implemen…

Red Hat deprecated BTRFS in its products (and does not have anything like ZFS).

Its focuses on XFS from 1993.

Its Stratis idea is just a joke comparing to what ZFS is.

They should finally admin (like Canonical) that OpenZFS is the way of future filesystem for now.

Linux world should put their religion (GPL) aside here.

Besides above filesystem 'issue' the PulseAudio, systemd and SELinux are not hated without reason ... many people just 'love' what Lenny has to offer.

Re: Transitioning from Docker to Podman

#238
post #3

I like the daemonless architecture a lot, but until there's a quick and painless way to install it on OSX and Windows developer machines, you're going to see very limited uptake.

I actually like the idea of Docker as a better systemd (or rather, the interface is better). No bespoke file format, programmable API, no need to google for the right journalctl switches, and then of course the advantages of containers and images over processes and system packages. I’m not suggesting everything should be a container nor that docker is the ideal implementation, but it certainly points in the right dir…

Well, Docker has an API and its own file format (the Dockerfile), I constantly have to look up Docker switches as it's not a tool I use every day and it's not at all intuitive, and I'm still unclear why people love this layered/stack image approach given how unbelievably slow it makes everything. Apps that would once have been a 50mb tarball are now routinely a gigabyte of downloads, perhaps because whatever random version of Ubuntu I downloaded previously is now slightly different? Who knows.

There is, frankly, a lot of appeal to me in a simple INI file that starts up something I unzipped.

Re: Transitioning from Docker to Podman

#239

Assuming that it's Red Hat's fault that there is no el8 package for Docker, I think Red Hat is really shooting themselves in the foot by not supporting Docker in RHEL8. (You can still install the el7 version of Docker on el8 by performing an enable/disable/enable/disable/... module dance, but... why isn't there just an el8 version?)

Red Hat ships podman for RHEL8, that's what the article is about.

Yes, but not Docker. (Also Podman is developed by Red Hat.) I think they have rather high hopes there, and are more likely to just shoot themselves in the foot by being one of a small number of distros that don't have Docker. In fact, rebuilders of RHEL (e.g. Oracle Linux) should maybe consider explicitly supporting Docker. "We are 100% compatible with RHEL but additionally also support Docker" definitely makes for better marketing copy than just "We are 100% compatible with RHEL".

Re: Transitioning from Docker to Podman

#240

Earlier quoted context omitted.

> One big reason for that seem to be Mac users that only know docker from inside a VM That has not been the case for a good while now... Docker has been running directly on a hypervisor on the Mac.

Honest question, what's the difference between "from inside a VM" and "directly on a hypervisor"? I always thought it meant the same thing.

Docker for Mac is still running a VM via LinuxKit/HyperKit, but there's a big difference in overhead between LinuxKit and running VMWare/VirtualBox.
Post reply on HN