Live data from Hacker News

I ditched Docker for Podman

codesmash.dev

51–60 of 670 posts

Re: I ditched Docker for Podman

#51
post #46
post #21

To provide 1 contrary opinion to all the others saying they have a problem: Podman rocks for me! I find docker hard to use and full of pitfalls and podman isn't any worse. On the plus side, any company I work for doesn't have to worry about licences. Win win!

> On the plus side, any company I work for doesn't have to worry about licences. Win win! Was this a deal breaker for any company? I ask because the Docker Desktop paid license requirement is quite reasonable. If you have less than 250 employees and make less than $10 million in annual revenue it's free. If you have a dev team of 10 people and are extremely profitable to where you need licenses you'd end up paying $9…

The problem isn’t generally the cost, it’s the complexity.

You end up having to track who has it installed. Hired 5 more people this week? How many of them will want docker desktop? Oh, we’ve maxed the licenses we bought? Time to re-open the procurement process and amend the purchase order.

Re: I ditched Docker for Podman

#52
post #14

I love podman, and, like others have said here, it does not always work with every container. I often try to run something using podman, then find strange errors, then switch back to docker. Typically this is with some large container, like gitlab, which probably relies on the entirety of the history of docker and its quirks. When I build something myself, most of the time I can get it working under podman. This situ…

Weird, we run GitLab server and runners all on podman. Honestly I wish we would switch to putting the runners in k8s. But it works well. We use Traefik.

Re: I ditched Docker for Podman

#53
post #46
post #21

To provide 1 contrary opinion to all the others saying they have a problem: Podman rocks for me! I find docker hard to use and full of pitfalls and podman isn't any worse. On the plus side, any company I work for doesn't have to worry about licences. Win win!

> On the plus side, any company I work for doesn't have to worry about licences. Win win! Was this a deal breaker for any company? I ask because the Docker Desktop paid license requirement is quite reasonable. If you have less than 250 employees and make less than $10 million in annual revenue it's free. If you have a dev team of 10 people and are extremely profitable to where you need licenses you'd end up paying $9…

It's a deal breaker because it was previously free to use, and frankly it's not worth $1 a month given there are better paid alternatives, let alone better free alternatives.

Re: I ditched Docker for Podman

#54
Yeah, no, sorry.

Too many problems with things that worked out of the box with docker.

I don't have time to waste on troubleshooting yet another issue that can be solved by simply using the thing that just works.

rootless is not an argument for me, since the hosts are dedicated docker hosts anyway.

Re: I ditched Docker for Podman

#55
post #31
post #21

To provide 1 contrary opinion to all the others saying they have a problem: Podman rocks for me! I find docker hard to use and full of pitfalls and podman isn't any worse. On the plus side, any company I work for doesn't have to worry about licences. Win win!

None of your companies need to worry about licenses. Docker ENGINE is free and open source. Docker DESKTOP is a software suite that requires you to purchase a license to use in a company. But Docker Engine, the core component which works on Linux, Mac and Windows through WSL2, that is completely and 1000% free to use.

From the official docs:

>This section describes how to install Docker Engine on Linux, also known as Docker CE. Docker Engine is also available for Windows, macOS, and Linux, through Docker Desktop.

https://docs.docker.com/engine/install/

I'm not an expert but everything I read online says that Docker runs on Linux so with Mac you need a virtual environment like Docker Desktop, Colima, or Podman to run it.

Re: I ditched Docker for Podman

#57
I have been running Podman in production for a number of years now, and have been very happy with the results.

Podman pods have been super useful, and the nature of my workload is such that we just run a full pod on every host, so it's actually removed the need for an orchestrator like Kubernetes. I manage everything via Ansible and it has been great.

Re: I ditched Docker for Podman

#59
I also ditched docker when I could. In my experience...

Podman with pods is a better experience than docker-compose. It's easy to interactively create a pod and add containers to it. The containers ports will behave as if they were on the same machine. Then `podman generate kube` and you have a yaml file that you can run with `podman kube play`.

Rootless networking is very slow unless you install `passt`. With Debian, you probably should install every optional package that podman recommends.

The documentation is lacking. Officially, it's mostly man pages, with a few blog posts announcing features, though the posts are often out of date.

Podman with its docker socket is often compatible with Docker. Even docker-compose can (usually) work with podman. I've had a few failures, though.

Gitlab-runner can use podman instead of docker, but in this case the is no network aliases. So it's useless if the runner needs to orchestrate several images (e.g. code and db).

Re: I ditched Docker for Podman

#60
One challenge I have come across is mapping multi-UID containers to a single host user.

By default, root in the container maps to the user running the podman container on the host. Over the years, applications have adopted patterns where containers run as non-root users, for example www-data aka UID 33 (Debian) or just 1000. Those no longer map to your own user on the host, but subordinate IDs. I wish there was an easy way to just say "ALL container UIDs map to single host user". The uidmap and userns options did not work for me (crun has failed executing those containers).

I don’t see the use case for mapping to subordinate IDs. It means those files are orphaned on the host and do not belong to anyone, when used via volume mapping?

Post reply on HN