Live data from Hacker News

Transitioning from Docker to Podman

developers.redhat.com

101–110 of 278 posts

Re: Transitioning from Docker to Podman

#101

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…

Heavy compose user here, and when I tried the podman equivalent of compose was missing some functionality that made me move back.

I had the same experience, and I'm not really sure why I can't use docker-compose with podman. If it's a drop in replacement, why can't I alias podman as docker and use docker-compose like normal?

I did try that and it doesn't work, and podman compose isn't as useable. So I switched back to docker.

Re: Transitioning from Docker to Podman

#102
post #23

Is the Docker daemon actually a huge security hole? I see people championing Podman because it's daemonless but is it actually beneficial or is it championed because it's Red Hat and a case of security check boxing?

It's a root daemon which can be made to run arbitrary commands by anyone using its interface, so yes it is a huge, huge security burden. You can't just brush that off as a superficial problem.

Re: Transitioning from Docker to Podman

#103
post #86
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.

Unless you're optimizing for stagnation, this really is a terrible approach to reaping the benefits of innovation. If your prereq to trying something better is that it needs to mirror something that's "decent already," you'll spend most of your life stuck on the same plateau.

Yeah, you're right. I should make the time to learn more stuff and never make excuses for why I don't.

On the other hand, I don't think you fully understand where I'm coming from. "Optimizing for stagnation", "stuck on the same plateau". Idk, I just want to run a container. I'm totally fine being on the same Docker plateau if something like Podman makes me re-learn what I already know how to do.

Unlike Git, which, from the start, was different and BETTER than SVN, can you really make the case that Podman would be BETTER if it didn't try to follow Docker conventions? If not, what are we talking about here?

Re: Transitioning from Docker to Podman

#104
post #23

Is the Docker daemon actually a huge security hole? I see people championing Podman because it's daemonless but is it actually beneficial or is it championed because it's Red Hat and a case of security check boxing?

> Is the Docker daemon actually a huge security hole?

Yes.

Also the containers on docker hub are a security dumpster fire.

Re: Transitioning from Docker to Podman

#105

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…

> Docker-in-Docker paradigm Apologies for the patronising comment, but do you really mean that? Docker in Docker works but is intended for the developers of Docker to debug Docker itself. Usually for running Docker from within a container, you just hook up the Docker client to the TCP port of the Docker daemon running outside the container, which isn't strictly Docker-in-Docker. I ask this in case you're trying a wil…

I do a lot of build automation work, and running containers within containers would be super useful for me.

That said docker-in-docker doesn't work without running privileged or forwarding the host port.

It's a non-starter for me, there are the obvious security problems, but also practical non-security issues. Forwarding the port causes encapsulation issues, a build job can finish leaving stuff running, can also interfere with other jobs on the system.

Using privileged containers isn't an option when using things like ECS fargate.

Re: Transitioning from Docker to Podman

#106

Earlier quoted context omitted.

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…

> 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 d…

How does podman improve on container ecosystem security?

Re: Transitioning from Docker to Podman

#107

Earlier quoted context omitted.

> Docker-in-Docker paradigm Apologies for the patronising comment, but do you really mean that? Docker in Docker works but is intended for the developers of Docker to debug Docker itself. Usually for running Docker from within a container, you just hook up the Docker client to the TCP port of the Docker daemon running outside the container, which isn't strictly Docker-in-Docker. I ask this in case you're trying a wil…

Docker in docker is a very common pattern in CI, in some cases is the only way to achieve certain tasks.

There is also Kaniko which works quite well:

https://github.com/GoogleContainerTools/kaniko

Re: Transitioning from Docker to Podman

#108

Earlier quoted context omitted.

Docker in docker is a very common pattern in CI, in some cases is the only way to achieve certain tasks.

What kinds of tasks require two levels of containers?

Your CI server running in a container that is itself executing Docker commands.

Re: Transitioning from Docker to Podman

#109
post #20

Any docker Podman corner cases that people have run into? I like the idea of rootless containers but I can do that ether easily by adding one line to my dockerfile or adding a user flag when I run a docker container. What other advantages am I getting?

No need to run a daemon. Security is better.

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

Re: Transitioning from Docker to Podman

#110
post #23

Is the Docker daemon actually a huge security hole? I see people championing Podman because it's daemonless but is it actually beneficial or is it championed because it's Red Hat and a case of security check boxing?

It's a root daemon which can be made to run arbitrary commands by anyone using its interface, so yes it is a huge, huge security burden. You can't just brush that off as a superficial problem.

Given that the most common case is running docker in server environments in VMs and the sysadmins are root, is this a real issue? Can you tell me an environment where a multi-tenant system runs docker?
Post reply on HN