Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Transitioning from Docker to Podman

developers.redhat.com

Post reply on HN
Print view View original

91–100 of 278 posts

Re: Transitioning from Docker to Podman

#91

Post by nisa »

joncp wrote: post #32
ranadeep wrote: post #22

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…

I've found your issues with podman to be a theme for Red Hat projects in general. Have you ever tried to configure Keycloak or OpenShift, for example?

Spend too much with Keycloak lately - it's more like a framework with some basic batteries included and you'll hit into corner cases pretty fast. If you are fluent with Java, their templating engine and all the other funky stuff it's a powerful tool - but i.e. their REST-API is bad. List all users including groups? That'll be an additional HTTP call for every user.

Their tools solve complex problems and are free to use - so I'm thankful that they exist - but I can't help but think that there is some lack of elegance&design that causes lot's of complexity - there is no "unix philosophy" to abuse different tools or components to solve problems - it's more like either you'll use the high level APIs with certain non-obvious assumptions (i.e. worked for us, good luck :) or feel free to hack on it if you grok our complex low-level frameworks and libraries... went after a NetworkManager bug once and it was a tour de force between c, glib, dbus with zero documentation. systemd and Keycloak feel very similiar. Powerful if you fit their usecase - horrible if need to tinker with it. But to be honest I've got no idea how to solve these complex problems otherwise. It's probably the best we can do at the moment. Or are there any non-cloud/non-sass solutions that actually have all the features?

Re: Transitioning from Docker to Podman

#92

Post by haberman »

nhoughto wrote: post #78
quietbritishjim wrote: post #70

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.

What kinds of tasks require two levels of containers?

Re: Transitioning from Docker to Podman

#93

Post by dastx »

ranadeep wrote: post #58
joncp wrote: post #32

Earlier quoted context omitted.

I've found your issues with podman to be a theme for Red Hat projects in general. Have you ever tried to configure Keycloak or OpenShift, for example?

This might be biased on my part but experiences like this is why I tend to openly avoid most Red Hat projects in general. There are definitely some great projects like RHEL, Ansible that are nice to work with. Even professionally, I tend to steer clear of immature Red Hat projects. We evaluated Keycloak but went with a vendor solution. OpenShift I believe was also evaluated at my firm and hit a dead-end.

Openshift is a great solution for a k8s setup on prem. From my experience it doesn't bring a whole lot when you're already on the cloud. All the additional services openshift provides, are already available as part of the major cloud offerings.

Re: Transitioning from Docker to Podman

#94

Post by outworlder »

quietbritishjim wrote: post #70
ranadeep wrote: post #22

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…

> but is intended for the developers of Docker to debug Docker itself

Heh. We use DIND with docker compose to have a container which has KUBERNETES inside. And it even works.

How's that for a wild use-case?

EDIT: That's done to create a local dev environment, with K8s, localstack, infra, etc. Instead of having multiple machines or deploying everything outside containers.

Re: Transitioning from Docker to Podman

#95

Post by Spidler »

yjftsjthsd-h wrote: post #45
choeger wrote: 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…

Okay, I want to build a container image using gitlab CI, which runs builds in docker. How would you like me to build an image without using docker in docker, or buildah in docker?

Why not simply use that then?

We're using podman in containers inside gitlab ci.

We're _also_ running tests of containers inside containers in containers using gitlab-ci.

The main workaround we've applied is using crun as the runtime rather than runc.

Re: Transitioning from Docker to Podman

#96

Post by anderspitman »

I always like to chime in and recommend people check out Singularity[0] containers if they haven't before. It's more common in academia because you can run containers without privileges which is nice in HPC environments. The containers themselves are simple immutable flat files that can be easily copied around, backed up, etc. There's also no system daemon. It's nice knowing everything you need for your container system exists in the containers themselves and a single singularity executable. No volumes, remembering to append --rm to avoid dangling containers, wondering where the actual images are stored, etc. Of course there are tradeoffs but I like them for certain use cases.

[0]: https://sylabs.io/

Re: Transitioning from Docker to Podman

#97

Post by [deleted] »

capelio wrote: post #86
lopatin wrote: 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.

[deleted]

Re: Transitioning from Docker to Podman

#98

Post by dumpsterdiver »

joana035 wrote: post #88
dumpsterdiver wrote: post #71

Earlier quoted context omitted.

Systemd struggles with this as well. While a service can easily tell you if it's "up", sometimes the only way to determine if it's "available" is to check. Keep in mind that the sentinel for any given service will be different. If you think about it, how could any external monitoring service determine when a service under it's purview is available without actually checking? Maybe it already has something like this, b…

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!

Re: Transitioning from Docker to Podman

#99

Post by no_wizard »

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 workflow (ie docker-compose up) for all other developers, turns out vagrant has (at some point in the last 5 years) solved this problem too, with packer (I didn't know about this 5 years ago for whatever reason)

Makes me long for going back to that. At least once you built your base image, it was done and you could just make fast linked images from there. I bet with Alpine you could get a vagrant up in a few minutes tops, then it boots in seconds.

Never liked Ruby as a config language, but doing complex things like setting up shared networks and folders was a breeze comparatively I felt.

Never used vagrant in a production capacity though. Everywhere I ever worked always deployed to bare metal or essentially we bought our services (cloud functions, semi-managed containers etc)

Post reply on HN