Hacker News Reader

Comment by znpy | Hacker News Reader

Pro-tip: nowadays podman can pretend to be a kubernetes cluster and launch pod And deployment definitions (in yaml, of course).

That of course is way close to the "production" in "production ready".

View on HN

Without podman-compose too! I didn't know this was the case now: https://www.redhat.com/sysadmin/compose-kubernetes-podman

That sounds really cool. Do you happen to have a good link for this?

Not GP, but Perhaps https://www.redhat.com/sysadmin/compose-kubernetes-podman?

Also daemonless and rootless

docker has rootless now. Tried to set it up the other day on bog standard Debian. That's a deep ass rabbit hole with a whole lot of gotchas and I'm not entirely convinced the whole thing won't topple over at the slightest breeze. It took me an embarrassingly long time to figure out how to install the correct version of slirp4netns, which is not in the stable repo. Reassuring.

Similar experience. I used Docker rootless for a while 1-2 years ago. There were hiccups and upgrading was a pain, so I stopped using it. It's possible it has improved, though.

It works out of the box on rhel 8.3, and I've used succession Ubuntu 20.04 installed by the PPA repos.

This is one of the coolest features!

Different users run different containers, and no user can see other user's containers.

Podman is great! I was surprised to learn that the latest version is compatible with docker-compose (minus the Docker Swarm part). I have been playing around with it on my workstation (Arch/Podman/docker-compose) and it works really well, rootless and without any daemon.

....but then when you run it in production, your app fails, because it was designed against assumptions around the fake cluster and pod, or a different config file. I'm not saying there's a solution to this, but we should remind people that "we can pretend X is Y" is a reproducibility red flag.

There are step between development laptop and production you know, smarty pants?

Like, a staging cluster? A pre-prod cluster?

Which then creates its own special snowflake environment which isn't either dev or prod, and duplicates resources, and can only test one change at a time (unless you have real ephemeral environments, and most people don't). It's better to have blue/green, or something like blue green, and use that as staging, than have an actual dedicated "staging cluster".

But like I say, dev still is far from close to that. So you end up doing a lot of development in dev, and then fixing a ton of things in staging because you weren't developing against staging. And your tests aren't fantastic, so some bugs make it through both staging and prod, and it turns out they're because your design was making assumptions based on dev. Hence, make dev and prod as close as possible, and then you don't need to have "staging", because you have confidence that what worked in dev will also work in prod.

Reply on news.ycombinator.com