Live data from Hacker News

I ditched Docker for Podman

codesmash.dev

551–560 of 670 posts

Re: I ditched Docker for Podman

#551
post #41

i'm the only one that wished docker swarm became the standard instead of k8s?

Swarm syntax is much better than the YAML sprawl of k8s. That said the underlying engine was pretty buggy and lack of customization for lower level components was a pain. Their whole plugin system was a great idea, but actual plugins developed by vendors ended up being very brittle. That said, yeah I'd prefer that timeline

I’m still using Swarm personally and agree 100%.

I’ve dealt with a fair bit of Swarm internals for https://lunni.dev/, and I’m ready to switch to k8s any moment. Don’t wanna lose Compose Spec support though, so I’ve started an IaC thingy that can map it to both k8s and Swarm resources. (Now I need to find some time for it!)

Re: I ditched Docker for Podman

#552
What do you guys use to profile whole ci/cd pipelines that involve building software , building (many) containers, running tests, running e2e tests etc. Ci/cd can be a huge drag on the lead time of delivery teams, containerisation helped with one thing but prolonged another. Is there a way out of this performance drag?

Re: I ditched Docker for Podman

#553
post #356

I don't know how podman compares to docker in terms of performance, and I do know that rootless containers can be a real pain. But Docker is simply a non-starter. It's based on a highly privileged daemon with an enormous, hyper-complicated attack surface. It's a fundamentally bad architecture, and as far as I've been able to tell, it also comes from a project that's always shown an "Aw, shucks" attitude toward securi…

I generally find rootless pretty easy, it's just annoying that it's an additional few steps. Feels like an afterthought when it should be the default.

It's easy in theory. I'd say about 30% of my containers require root and just wouldn't work on Podman.

Re: I ditched Docker for Podman

#554

What do you guys use to profile whole ci/cd pipelines that involve building software , building (many) containers, running tests, running e2e tests etc. Ci/cd can be a huge drag on the lead time of delivery teams, containerisation helped with one thing but prolonged another. Is there a way out of this performance drag?

By drag I mean 3-4 hrs until all e2e passed on an ephemeral k8s stack on a vm.

Re: I ditched Docker for Podman

#555
post #253

Earlier quoted context omitted.

Some tools talk to docker not using the docker CLI but directly through its REST API. Podman also exposes a similar REST API[1]. Is Podman with its API server switched on substantially different from the docker daemon? [1]. https://docs.podman.io/en/latest/markdown/podman-system-serv...

Docker daemon runs as root, and runs continuously. If you're running rootless Podman containers then the Podman API is only running with user privileges. And, because Podman uses socket activation, it only runs when something is actively talking to it.

Sometimes it's possible to not use the Podman API at all. Convert the compose file to quadlet files with the command-line tool podlet and start the container with "systemctl --user start myapp.service". Due to the fork/exec architecture of podman, the container can then be started without using the Podman API.

Re: I ditched Docker for Podman

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

Forget docker for a second.

Suddenly you're in a team with 2-3 people and one of them likes to git push broken code and walk-off.

Okay, lets make this less about working with a jack-ass, same setup, but each 5 minutes of downtime cost you millions of dollars. One of your pushes work locally but don't work on the server.

The point of a more structed / complex CI/CD process is to eliminate failures. As the stakes become higher, and the stack becomes more complex, the need for the automation grows.

Docker is just a single part of that automation that makes other things / possible / lowers specific class of failures.

Re: I ditched Docker for Podman

#557
I do not know: the lack of proper docker compose support it is a problem for me. About security: gVistor adoption failure in Google is a proof that containerization cannot be enforced easily and container will always be less secure than a VM.

If you want proper security go to firecracker [^1]. Podman is the "RedHat/IBM docker-way" but I see very little benefit overall; never less if it works for you great and go with it!

[^1]: https://firecracker-microvm.github.io

Re: I ditched Docker for Podman

#558

Earlier quoted context omitted.

Docker daemon runs as root, and runs continuously. If you're running rootless Podman containers then the Podman API is only running with user privileges. And, because Podman uses socket activation, it only runs when something is actively talking to it.

Sometimes it's possible to not use the Podman API at all. Convert the compose file to quadlet files with the command-line tool podlet and start the container with "systemctl --user start myapp.service". Due to the fork/exec architecture of podman, the container can then be started without using the Podman API.

Yes, either quadlet or handwritten podman CLI in .service files is the way to go. I don't like using generate-systemd because it hides the actual configuration of the container, I see no point in being stateful...

Re: I ditched Docker for Podman

#559

I do not know: the lack of proper docker compose support it is a problem for me. About security: gVistor adoption failure in Google is a proof that containerization cannot be enforced easily and container will always be less secure than a VM. If you want proper security go to firecracker [^1]. Podman is the "RedHat/IBM docker-way" but I see very little benefit overall; never less if it works for you great and go with…

Podman 4.7 supports both the ordinary compose (Go implementation) and older Python podman-compose. But personally I moved to quadlets and didn't look back.

Re: I ditched Docker for Podman

#560

I do not know: the lack of proper docker compose support it is a problem for me. About security: gVistor adoption failure in Google is a proof that containerization cannot be enforced easily and container will always be less secure than a VM. If you want proper security go to firecracker [^1]. Podman is the "RedHat/IBM docker-way" but I see very little benefit overall; never less if it works for you great and go with…

There is a podman-compose which works almost as drop-in replacement.

Almost because most common commands work, but I have not check all.

And almost, because for some docker-compose.yaml which you downloaded/LLM generated you may need to prepend `docker.io/` to the image name

Post reply on HN