Live data from Hacker News

I ditched Docker for Podman

codesmash.dev

601–610 of 670 posts

Re: I ditched Docker for Podman

#601
post #513

Earlier quoted context omitted.

Isn't this problem usually solved by building an actual image for your specific application, tagging that and pushing to some docker repo? At least that's how it's been at placec I've worked at that used docker. What am I missing?

What do you do when you then actually need to make a change to your application (e.g. a 1-liner fix)? Edit the binary image?

Build and tag internal base images on a regular cadence that individual projects then use in their FROM. You’ll have `company-debian-python:20250901` as a frozen-in-time version of all your system level dependencies, then the Dockerfile using it handles application-level dependencies with something that supports a lockfile (e.g. uv, npm). The application code itself is COPY’d into the image towards the end, such that everything before it is cached, but you’re not relying on the cache for reproducibility, since you’re starting from a frozen base image.

The base image building can be pretty easily automated, then individual projects using those base images can expect new base images on a regular basis, and test updating to the latest at their leisure without getting any surprise changes.

Re: I ditched Docker for Podman

#602
post #415

Back in 2001/2002, I was charged with building a WiFi hotspot box. I was a fan of OpenBSD and wanted to slim down our deployment, which was running on Python, to avoid having to copy a ton of unnecessary files to the destination systems. I also wanted to avoid dependency-hell. Naturally, I turned to `chroot` and the jails concept. My deployment code worked by running the software outside of the jail environment and m…

The best CI/CD pipeline I ever used was my first freelance deployment using Django. I didn't have a clue what I was doing and had to phone a friend. We set up a git post receive hook which built static files and restarted httpd on a git receive. Deployment was just 'git push live master'. While I've used Docker a lot since then, that remains the single easiest deployment I've ever had. I genuinely don't understand wh…

Docker in and of itself does not do you much good. Its strength comes from the massive amounts of generic tooling that is built around the container as the standard deployable unit.

If you want to handle all your deployments the same way, you can basically only choose between Nix and containers. Unfortunately, containers are far more popular and have more tooling.

Re: I ditched Docker for Podman

#603
post #415

Back in 2001/2002, I was charged with building a WiFi hotspot box. I was a fan of OpenBSD and wanted to slim down our deployment, which was running on Python, to avoid having to copy a ton of unnecessary files to the destination systems. I also wanted to avoid dependency-hell. Naturally, I turned to `chroot` and the jails concept. My deployment code worked by running the software outside of the jail environment and m…

The best CI/CD pipeline I ever used was my first freelance deployment using Django. I didn't have a clue what I was doing and had to phone a friend. We set up a git post receive hook which built static files and restarted httpd on a git receive. Deployment was just 'git push live master'. While I've used Docker a lot since then, that remains the single easiest deployment I've ever had. I genuinely don't understand wh…

> Is the reproducibility of docker really worth the added overhead of managing containers, docker compose, and running daemons on your devbox 24/7?

Why wouldn't it be, containers are super easy to manage, dockerd uses bugger all resources in dev (on Linux anyway) and docker compose files are the simplest setup scripts I've ever used

I like docker because it's easy and I'm lazy

Re: I ditched Docker for Podman

#604

Earlier quoted context omitted.

Additionally, there aren't even any trusted repos out there building/publishing a .deb for it. The ones that I could find when I searched last were all outdated or indicated they were not going to keep moving forward. I could get over this. But, IMO, it lends itself to asking the "why" question. Why wouldn't Podman make installing it easier? And the only thing that makes sense to me is that RedHat doesn't want their…

They publish statically-linked binaries on GitHub [0], so to install it, you just need to download and unpack a single file. But you don't get any automatic updates like you would if they provided an apt repository. [0]: https://github.com/containers/podman/releases

Aren't the statically linked binaries just the remote client? i.e. they can't run containers on their own, right?

In the past I think I wound up using https://github.com/mgoltzsche/podman-static because I could not get those podman static binaries to work

Re: I ditched Docker for Podman

#605

The main issue is podman support on Ubuntu. Ubuntu ships outdated podman versions that don't work out of the box. So I use podman v5, GitHub actions uses podman v3, and my coworkers on Ubuntu use docker. So now my script must work with old podman, recent podman and docker

Yes! I really like the idea of podman, but after 4 hours trying to make it work on 24.04, I reverted to Docker and compose.

There is some dissonance in presenting Podman as a plug-in replacement for Docker, and making it so damn hard to install on (some category's) most popular contemporary LTS Linux distro.

Re: I ditched Docker for Podman

#606
post #494

Earlier quoted context omitted.

Why would docker should create such tool in the first place? It's the job of the target/destination to provide compatibility layer. In this case, Kubernetes already does with kompose.io tool. kompose: https://kubernetes.io/docs/tasks/configure-pod-container/tra... Also, technically docker-compose was the first orchestration tool compared to Kubernetes. Expecting former to provide a translation layer for the latter is…

Why would docker? Because it's not very useful by itself for running production infra, but it's great for helping to develop it. Otherwise you're going to see more and more move to podman (and podman desktop) / OCI containers over time, as corps won't have to pay the docker tax and will get better integration with their existing k8s platform.

Docker is useful and running in production. (well, it was the only, before containerd got separated entirely and it was usable directly from K8s about when it was 1.16)

What you say is absolutely correct. If Docker keeps creating compatibility layers for it's competitors, it makes everyone to switch to a competitor. In this case, the competitor is Kubernetes as it's running in production for much larger scale (enterprise workloads) compared to Podman et. al.

Hence, it's the job of Podman, Kubernetes, et. al. to write their compatibility layer to provide a value-add for their customers.

Re: I ditched Docker for Podman

#607
post #531

I keep seeing Podman mentioned as a Docker alternative, but I'm unclear on when the juice is worth the squeeze. For someone doing typical web development (Node.js/Python services, Postgres, Redis), what specific problems would Podman solve that Docker doesn't? Is this more about security/compliance or are there developer experience benefits too?

Podman is daemonless while docker is a client/server pair. Podman also shipped with support for rootless containers, though Docker now has that capability as well.

The podman CLI is nearly a drop-in replacement for docker such that `alias docker=podman` works for many of the most common use cases.

If you don't care about the security implications of running containers as root via a client/server protocol, then by all means keep using Docker. I've switched to podman and I'm happy with my decision, but to each their own.

Re: I ditched Docker for Podman

#608
post #503

Earlier quoted context omitted.

Not podman user (but currently trying to install to give it a shot), this comment stream shows how even the documentation "randomly disappearing" on a project that claims in production-ready or stable state. (Or lack thereof) On the contrary, docker documentation *is* stable, I had bookmarks from 10-years ago on the *latest* editions, that still work today. The final link may have changed, but at least, there is a re…

The Podman reference section, which is what OP linked to, is a direct web version of the man pages. The main method of accessing it, the man pages, has not changed. It's a different style of documentation organization: if you want to link to a specific version you should link to the specific version not latest. I won't argue it's necessarily a better way of doing things than Docker, but knowing it's the same thing as…

You can tell users that "you are holding it wrong" or fix the actual problem that exists in the first place. Good luck telling millions of people to not to bookmark certain version, instead use this or that... Maybe, add just a redirect, a simple page with the link that says "Hey, this documentation has moved to there, click here".

Just put this thread into a whatever LLM. I overall see 2 major themes here. Compatibility and stability issues, all over the place. Not just documentation, but with other tools. Compose schema v2 does not match the current/latest one, missing functionality (although this one is acceptable at certain level), etc.

Also, as soon as the docs were "posted", it became obsolete/useless/deprecated. I mean, what sort of quality are we talking about here?

Re: I ditched Docker for Podman

#609
post #189

I started working at Red Hat this past year, so obviously all Podman, all day long. It's a super easy switch. I moved to using Containerfiles in my LinkedIn courses as well, if for no other reason than it having a much more "open" naming convention! Rootless works great, though there are some (many) images that will need to be tweaked out of the box. Daemonless works great as well. You can still mount podman.sock lik…

Docker compose works fine with podman via its socket.

Re: I ditched Docker for Podman

#610

OP fails to understand that in practice people use Docker Desktop on their laptop and deploy to a container platform or Kubernetes cluster that uses ContainerD. So all of these so-called issues are moot. Further, Docker Inc (and the people behind Docker CLI, Compose etc), have way better UX taste and care for DX than their competitors which matters a lot in local development.

The UI is what held me back from switching last time I tried podman. Docker Desktop is nice.

Podman Desktop also exists.
Post reply on HN