Live data from Hacker News

Transitioning from Docker to Podman

developers.redhat.com

141–150 of 278 posts

Re: Transitioning from Docker to Podman

#141
post #15

I was just about to complain about another thing to learn. Then I saw you can do "$ alias docker=podman". Just want to acknowledge the importance of that work. Making things compatible is both boring and a pain, but it's a door opener for people like me who refuse to learn your new API because I know a decent one already.

So far, it's just a less functional docker and didn't bring much to the table. I don't feel the need for daemonless as docker has been working fine.

I've swapped back to docker on Fedora and CentOS by forcibly installing docker on those unsupported platforms because podman-compose doesn't work, containers just didn't work like expected in several situations (forgot detail) and portainer wouldn't work against it.

Either they should have sped up the podman development or shouldn't have deprecated docker at this point. Maybe RedHat just didn't like a third party taking the stewardship in the container business.

Re: Transitioning from Docker to Podman

#142

At my company, we run our CI/CD (Jenkins) using the Docker-in-Docker paradigm to facilitate easy maintainability of the CI itself and allow us to run containerized builds. When we shifted to RHEL 8, we attempted to move this over to Podman and it went miserably (this was back in November 2019). The main reason being is that podman-in-podman doesn't work and had bugs (at least back in Nov 2019). Maybe it fixed now but…

Your life will be a lot less painful if you abandon docker-in-docker. The Jenkins solution is to simply execute containers using the host's Docker daemon, or via a container orchestration system which you call out to.

The latter is the best option as it's much more scalable and doesn't require ugly proprietary hacks. Docker in Docker requires vertical scaling and more complex management for intermediate states/maintenance.

Podman probably isn't ready to replace Docker yet, but rootless containers are the easy-mode for federation of clusters. If you can supply the other features you need (and I think most can) it's probably worth it in the long run.

Re: Transitioning from Docker to Podman

#143
post #106

Earlier quoted context omitted.

How does podman improve on container ecosystem security?

Check the first link in the "resources" section at the bottom of the article page.

Right. I misread your comment to imply that podman improved on the "legacy applications depending on outdated packages" problem.

I suppose a more secure runtime doesn't hurt.

Re: Transitioning from Docker to Podman

#144
post #109
post #20

Earlier quoted context omitted.

No need to run a daemon. Security is better.

If you lock down the docker user, is it a problem?

The biggest issue lies not in the few lines in /etc/passwd or /etc/group, but rather the highly privileged process with a large attack surface that is the Docker daemon.

Re: Transitioning from Docker to Podman

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

btrfs is depreciated in redhat distribution

If you want to use btrfs on RHEL8, you still can: go to https://elrepo.org/ and install elrepo-release, then install kernel-ml from their -kernel repo and btrfs-progs from their -testing repo.

Re: Transitioning from Docker to Podman

#146
post #5

I really struggled with podman, a bunch of containers (I cant remember which ones) didn't work, and build tools choked as well. At work we dont get root access so I thought it would be perfect but sysadmins couldn't figure out how to configure either so was bust there too.

I just installed my new $WORK docker-compose using podman and podman-compose, and it worked out of the box. To be fair, I failed at it one time before at previous job... So... Coin flip?

I had a repeat of the same experience too recently. It was very satisfying having it work now.

Re: Transitioning from Docker to Podman

#147
post #27

Earlier quoted context omitted.

But systemd has all of those things. Everything in systemd can be orchestrated with dbus. In fact that’s all systemctl really is — a dbus client. And the file format is ini. And shell style environment files if you want. And systemd actually comes with two image launching systems systemd-nspawn and systemd-portable. And then with systemd-machined you can add software that needs virtualization too. The interface to jo…

> The interface to journald is more complicated than it should be but it’s also really powerful I thought the point of logging to stdout (i.e. docker logs) is that you just take that output and dump it to another server for processing and filtering. journald/journalctl seem to be a solution a few decades late to the party. For a single user machine or a single app prod environment, I would take a plaintext log any da…

Exactly this. I just want a stream of logs that I can process with ordinary unix tools without jumping through hoops. I don’t need any extra power for its own sake.

Re: Transitioning from Docker to Podman

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

btrfs is depreciated in redhat distribution

They just made it the default in fedora. It is likely not deprecated for unreleased RHEL versions

Re: Transitioning from Docker to Podman

#149

Earlier quoted context omitted.

Why do you say that docker-in-docker buys him nothing? It's not obvious at all and you go into no detail whatsoever to back up your opinion. In my experience, that is not true at all. Docker-in-docker allows me to deliver smaller images that can fit into a CI flow as language plugins instead of shipping a beastly 5G docker image with every possible language runtime I need to support for my CI tool.

It is because to build the image using docker requires the docker client to talk with a dockerd daemon, so one has to configure the client to access the dockerd which allow untrusted code to run as root in the host. Docker-in-docker is a workaround to make docker work in CI. Basically a security nightmare and bad design that podman doesn't have.

Any build script can do serious damage to the environment it runs in. Before docker, you'd have to create a new VM from time to time because the build agent had rotted away or died in an altercation with a bad build.

Docker in Docker in CI is like a lock on a door. It keeps honest people from being naughty, and is fairly efficient about it.

I don't think the question is "should I run CI in docker in docker," it's whose CI should I run in docker in docker. Me in my coworkers can share docker images. Customers or freeloaders cannot. So if that's in your problem domain, then you're right, it's a bad idea. But it isn't for most people.

Re: Transitioning from Docker to Podman

#150

Earlier quoted context omitted.

How are you using Docker that doesn't need a bespoke file format? You're building from a Dockerfile and either scripting around the docker command or running docker-compose.yml

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