4 ms·

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

by znpy 5y ago

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

ecliptik 5y ago
That sounds really cool. Do you happen to have a good link for this?
- buildbot 5y ago
  Not GP, but Perhaps https://www.redhat.com/sysadmin/compose-kubernetes-podman https://www.redhat.com/sysadmin/compose-kubernetes-podman?
buildbot 5y ago
Without podman-compose too! I didn't know this was the case now: https://www.redhat.com/sysadmin/compose-kubernetes-podman https://www.redhat.com/sysadmin/compose-kubernetes-podman
2OEH8eoCRo0 5y ago
Also daemonless and rootless
- znpy 5y ago
  This is one of the coolest features! Different users run different containers, and no user can see other user's containers.
- deckard1 5y ago
  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.
  - emerongi 5y ago
    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.
  - znpy 5y ago
    It works out of the box on rhel 8.3, and I've used succession Ubuntu 20.04 installed by the PPA repos.
0xbadcafebee 5y ago
....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.
- znpy 5y ago
  There are step between development laptop and production you know, smarty pants? Like, a staging cluster? A pre-prod cluster?
  - 0xbadcafebee 5y ago
    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.
messo 5y ago
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.

by znpy 5y ago

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

ecliptik 5y ago

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

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

buildbot 5y ago

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

2OEH8eoCRo0 5y ago

Also daemonless and rootless

znpy 5y ago
This is one of the coolest features! Different users run different containers, and no user can see other user's containers.
deckard1 5y ago
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.
- emerongi 5y ago
  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.
- znpy 5y ago
  It works out of the box on rhel 8.3, and I've used succession Ubuntu 20.04 installed by the PPA repos.

0xbadcafebee 5y ago

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

znpy 5y ago
There are step between development laptop and production you know, smarty pants? Like, a staging cluster? A pre-prod cluster?
- 0xbadcafebee 5y ago
  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.

messo 5y ago

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.