I ditched Docker for Podman

Companies aren't monoliths, they're made of teams.

Big companies are made of teams of teams.

The little teams don't really get to make purchasing decisions.

If there's a free alternative, little teams just have to suck it up and try to make it work.

---

Also consider that many of these expenses are born by the 'cost center' side of the house, that is, the people who don't make money for the company.

If you work in a cost center, the name of the game is saving money by cutting expenses.

If technology goes into the actual product, the cost for that is accounted for differently.

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.

Even large companies with thousands of developers have budgets to manage and often times when the CT/IO sees free as an option that's all that matters.

This math sounds really simple until you work for a company that is “profitable” yet constantly turning over every sofa cushion for spare change. Whuch describes most publicly traded companies.

It can be quite difficult to get this kind of money for such a nominal tool that has a lot of free competition. Docker was very critical a few years ago, but “why not use podman or containerd or…” makes it harder to stand up for.

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

It is for now, but I can't think of a player as large as Docker that hasn't pulled the rug out from under deals like this. And for good reason, that deal is probably a loss leader and if they want to continue they need to convert those free customers into paying.

> Was this a deal breaker for any company?

It is at the company I currently work for. We moved to Rancher Desktop or Podman (individual choice, both are Apache licensed) and blocked Docker Desktop on IT's device management software. Much easier than going through finance and trying to keep up with licenses.

Docker Desktop is also (imo) useless and helps be ignorant.

Most Mac users I see using it struggle to see the difference between "image" and "container". Complete lack of understanding.

All the same stuff can easily be done from cli.

> Was this a deal breaker for any company?

It's not the money, it's the bureaucracy. You can't just buy software, you need a justification, a review board meeting, marketplace survey with explanations of why this particular vendor was chosen over others with similar products, sign off from the management chain, yearly re-reviews for the support contract, etc...

And then you need to work with the vendor to do whatever licensing hoops they need to do to make the software work in an offline environment that will never see the Internet, something that more often than not blows the minds of smaller vendors these days. Half the time they only think in the cloud and situations like this seem like they come from Mars.

The actual cost of the product is almost nothing compared to the cost of justifying its purchase. It can be cheaper to hire a full time engineer to maintain the open source solutions just to avoid these headaches. But then of course you get pushback from someone in management that goes "we want a support contract and a paid vendor because that's best practices". You just can't win sometimes.

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.

If you've installed Docker on Windows you've most likely done that by using Docker Desktop, though.

Podman is inside the Ubuntu WSL image. No need for docker at all

Those companies use docker desktop on their dev's machines.

You can use the real compose (Go) with Podman now. The Python clone is not your only option.

> Why wouldn't Podman make installing it easier?

What else can they do then having a package for every distro?

https://podman.io/docs/installation#installing-on-linux

Including instructions to build from source (including for Debian and Ubuntu):

https://podman.io/docs/installation#building-from-source

I don't know about this specific case but Debian and or Ubuntu having outdated software is a common Debian/Ubuntu problem which nearly always is cause by Debian/Ubuntu itself (funnily if it's outdated in Ubuntu doesn't mean it's outdated in Debian and the other way around ;=) ).

debian trixie has podman 5 packages in official repos. Good chance thqt those work on ubuntu

LTS in general being slow to uptake new versions of software is a feature not a bug. It gives predictability at the cost of having to deal with older versions of software.

With Ubuntu at least, some upstreams publish official PPAs so that you aren't stuck on the rapidly aging versions that Canonical picks when they cut an LTS release.

Debian I found out recently has something similar now via "extrepo".

I use debian specifically for things to be kept the same. Once I got things setup, I don’t really want random updates to come and break things.

Ubuntu is committed to the Snap ecosystem and there is a lot of software that you can get from a snap if you need it to be evergreen.

One of the major use cases was multi-user HPC systems. Because they can be complicated, it’s not uncommon for bioinformatics data analysis programs to be distributed as containers. Large HPC clusters are multi-tennant by nature, so running these containers needs to be rootless.

There are existing tools that fill this gap (Singularity/Apptainer). But, there is always friction when you have to use a specialized tool versus the default. For me, this is a core usecase for rootless containers.

For the reduced feature set we need from containers in bioinformatics, rootless is pretty straightforward. You could get largely the same benefits from chroots.

Where I think the issues start is when you start to use networking, subuids, or other features that require root-level access. At this level, rootless because a tedious exercise in configuration that probably isn’t worth the effort. The problem is, the features I need will be different from the features you need. Satisfying all users in a secure was may not be worth it.

I see your point but I wouldn't let the perfect be the enemy of the good.

If I just want to run a random Docker container, I'm grateful I can get at least "some security" without paying as much in setup/debugging/performance.

Of course, ideally I wouldn't have to choose and the thing that runs the container would be able to run it perfectly securely without me having to know that. But I appreciate any movement in that direction, even if it's not perfect.

Rootless is nice because if you mount some directory in, all the files don't end up owned by root. You can get around that by custom building every image so the user has your user id, but that's a pain.

Do you do OCI/container builds inside your forgejo-runner container?

That surprises me too. Podman is spearheaded by Redhat and Fedora/RHEL was one of the earliest distros to adopt it and phase out docker. Why wouldn't they have the selinux config figured out?

Can confirm, have been doing exactly what GP says is a world of pain with no problems as soon as I learned what `:z` and `:Z` do and why they might be needed.

A good reference answer: https://unix.stackexchange.com/questions/651198/podman-volum...

TL;DR: lowercase if a file from the host is shared with a container or a volume is shared between multiple containers. Uppercase in the same scenario if you want the container to take an exclusive lock on the volumes/files (very unlikely).

This is terrific advice and I would happily upvote a blog post on this! I'll look into exactly this.

Yeah, I had it running using podman, but then had some weird container restarts. I switched back to docker and those all went away. I am sure the solution is me learning more and troubleshooting podman, but I just didn't spend the time, and things are running well in an isolated VM under docker.

That's good to know it works well for you, because I would prefer not to use docker.

Use an LLM is not a solution. It's effectively telling you to switch your brain off and hope nothing goes wrong in the future. In reality things do go wrong and any conversation should be done with a good understanding of the system involved.

You don’t need an LLM for this. Use `kubectl` to create a simple pod/service/deployment/ingress/etc, run `kubectl get -o yaml > foo.yaml` to bring it back to your machine in yaml format, then edit the `foo.yaml` file in your favorite editor, adding the things you need for your service, and removing the things you don’t, or things that are automatically generated.

As others have said, depending on an LLM for this is a disaster because you don’t engage your brain with the manifest, so you aren’t immediately or at least subconsciously aware of what is in that manifest, for good or for ill. This is how bad manifest configurations can drift into codebases and are persisted with cargo-cult coding.

[edit: edit]

This is a conflation of "Simple" and "Easy" (rather, "complex" and "hard"). 'Simple vs Complex' is more or less objective, 'Easy vs Hard' is subjective, and changes based on the person.

And of course, Easy =/= Simple, nor the other way around.

I'm a CKA and use docker compose exclusively in my homelab. It's simpler.

I have not, thanks for the suggestion though.

A second challenge with the particular setup I’m trying is peer authentication with Postgres, running bare metal on the host. I mount the Unix socket into the container, and on the host Postgres sees the Podman user and permits access to the corresponding DB.

Works really well but only if the container user is root so maps natively. I ended up patching the container image which was the path of least resistance.

Yep. It works even better on a declarative distro like NixOS because you can define and extend your systemd services (including containers) from a single config.

Taking this further (self-plug), you can automatically map your Compose config into a NixOS config that runs your Compose project on systemd!

https://github.com/aksiksi/compose2nix

It totally does! On the con side, I find systemd unit files a lot less ergonomic to work with than compose files that can easily be git-tracked and colocated.

I find the man page fairly comprehensive: https://docs.podman.io/en/latest/markdown/podman-systemd.uni...

Many docker containers are optimized to run as Alpine on other systems. You get the benefit that it runs on Alpine itself.

No, you don't run the Docker containers run in OrbStack, you can spin up an Alpine instance and run all docker instance on it.

The benefit is that, Alpine has access to all your local and network drives so you can use them. You can sandbox them as well. It's not a big learning curve, just a good VM with access to all drives but isolated to local only.

Well, yes, but rootless is basically the main selling point of podman. Once you start using daemons and privileged containers, you can just keep using docker.

Udica, plus maybe ausearch | audit2allow -C, makes it easy to generate SELinux policies for containers (works great for me on RHEL10-like distros)

https://www.redhat.com/en/blog/generate-selinux-policies-con...