Live data from Hacker News

Transitioning from Docker to Podman

developers.redhat.com

111–120 of 278 posts

Re: Transitioning from Docker to Podman

#111

After reading this thread, I realize that the 4 GB (average) of my vagrant box images wasn't that bad in retrospect, and that loaded a fully baked OS with packages from apt and just required VirtualBox and its extension pack. (this was not an optimized setup, I was such a noob at the time, just trying to wrangle our developer tools) The only reason I moved to docker years ago was I wanted a tighter reproducible workf…

Ditto. I for one would love to have Vagrantfiles-like Ruby scripts in Docker. Or even Typescript.

So many setups would be achievable with simple ifs.

Re: Transitioning from Docker to Podman

#112

Earlier quoted context omitted.

Here you go: https://www.freedesktop.org/software/systemd/man/systemd-not...

From the link: "systemd-notify may be called by daemon scripts to notify the init system about status changes. It can be used to send arbitrary information, encoded in an environment-block-like list of strings. Most importantly, it can be used for start-up completion notification." Perfect. Thank you!

You're welcome :)

Re: Transitioning from Docker to Podman

#113
post #67

Earlier quoted context omitted.

Completely agree. One thing I want to point out though for anybody not familiar with the differences between podman and docker, for the most part alias docker=podman will "just work" except for these situations: 1. docker-compose. podman-compose attempts to cover this but I've heard it's not quite there yet 2. Mounting the docker socket into the container. Podman is daemonless which means that won't work. There is wo…

It’s now possible to mount a docker compatible socket inside the container using podman.

Can you provide more information on this? A blog post or some instructions? I'd like to read more.

Re: Transitioning from Docker to Podman

#114

I find the podman integrates with systemd well claims a bit dubious. Last time I checked both podman and CRI-O double fork and have reimplemented process supervision from scratch (through conmon) whilst they could get all those features for free if they didn't daemonize themselves and let systemd handle running things in the background and do the process supervision. I found this very surprising. I still don't unders…

Looks like you may have double posted. Not complaining, just letting you know in case it was unintentional: https://news.ycombinator.com/item?id=25166141

Re: Transitioning from Docker to Podman

#115
post #29

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…

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…

I think the ideal is using Nix to manage development dependencies and to handle building minimal docker images for deployment.

Re: Transitioning from Docker to Podman

#116
post #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 d…

How does podman improve on container ecosystem security?

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

Re: Transitioning from Docker to Podman

#117

I find the podman integrates with systemd well claims a bit dubious. Last time I checked both podman and CRI-O double fork and have reimplemented process supervision from scratch (through conmon) whilst they could get all those features for free if they didn't daemonize themselves and let systemd handle running things in the background. I found this very surprising. I still don't understand why they made that choice.…

Perhaps that choice comes from wanting their target platform to be linux, rather than systemd?

Re: Transitioning from Docker to Podman

#118

Earlier quoted context omitted.

What kinds of tasks require two levels of containers?

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

As mentioned elsewhere in the thread, this does not require DinD. You can connect to the host’s Docker daemon. (Other interfaces such as K8S are also much safer.)

Re: Transitioning from Docker to Podman

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

I think the ideal is using Nix to manage development dependencies and to handle building minimal docker images for deployment.

Why not just use nix at that point? You can at least retain the advantage of having truly immutable and reproducible builds.

I use docker for most of my clients' work but for in house stuff I just use nix.

Re: Transitioning from Docker to Podman

#120
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.

History is full of technologies that are superior to existing options on one metric or another and yet failed to take over due to switching costs. Attacking someone as “optimizing for stagnation” is a really bizarre way to view their reaction to a product offering a smooth on boarding process.
Post reply on HN