61–70 of 111 posts
Shameless plug: I wrote undocker[1] to convert docker images to a rootfs tarball, so I can run them with plain systemd. Goal: no more daemons to run 3rd party containers, systemd is good enough by now: resource limits, isolation, chroot, dynamic users, logging, and more. Low-level tooling is done, I am now building ecosystem around it: easy installation, convert to deb/rpm, systemd units, etc. [1]: https://sr.ht/~mot…
+1000
I have really enjoyed using Podman and will keep using it. I have found it be to stable (running on CentOS) for our production stuff. Shameless plug: We built Simplenetes[1] around Podman (a simpler alternative to Kubernetes, but written in 100% shell script :) 1: https://simplenetes.io/
That actually looks pretty interesting. How do you handle load balancing of inbound traffic.. do you use a pod running Traefik or similar? How do the pods communicate when they are deploying, unavailable or busy and so on? I guess I could get this from your site but there's a LOT of information on the first pages there and possibly not what I am looking for.
We use haproxy pods for inbound traffic, they perform TLS termination and simply pass the traffic over to a local proxy pod.
The haproxy pod (and all other pods) communicate with each other over this local proxy service which is running on each host.
We have a very simplified and robust overall architecture, were each pod allocates a specific virtual port and the proxy will try each host for that pod (and remember status), meaning we don't need to keep track of global routing tables and update each host's ip tables (shivering) when pods come and go. We don't use iptables.
If some instance of a pod is unavailable the proxy will seamlessly try another instance of the pod.
Initially we tried to config haproxy to do all this proxying for us, but it was asking too much.
Good to know is that Simplenetes is still in beta.
I see all comments here and I’m wondering if anybody actually read TFA. This is NOT a drop-in replacement on Mac, very far from it. No volumes mount from the host, no auto port forward, complications when building images, bugs where the socket isn’t cleared etc. They will get there eventually but this is way over hyped for a sensible replacement for docker on Mac.
Earlier quoted context omitted.
you're right. And the caveat is still that Docker Desktop costs $240 a year only for companies with $10m+ in revenue or 250+ employees. Free for everyone else. I don't get the whole "Let's spend weeks rewriting our build infrastructure to save $240 a year" strategy going on here.
$240 a year * 250+ employees is 60k at the very least. My company has over 3500 engineers. That's almost a million dollars in new spend and you gain basically nothing. It's a product the entire org has already been using for a long time, now you just have to pay a million dollars a year to use it.
Shameless plug: I wrote undocker[1] to convert docker images to a rootfs tarball, so I can run them with plain systemd. Goal: no more daemons to run 3rd party containers, systemd is good enough by now: resource limits, isolation, chroot, dynamic users, logging, and more. Low-level tooling is done, I am now building ecosystem around it: easy installation, convert to deb/rpm, systemd units, etc. [1]: https://sr.ht/~mot…
As for just using systemd and not nspawn at all, that seems useful for a lot of cases, but not multiplexing of networked services since systemd can't assign UNIX domain hostnames and IP addresses to individual services. At least, I think it can't, can it?
Earlier quoted context omitted.
Docker has a rootless mode in the same way that podman has a rootless mode.
Having just fought it, Docker rootless is a pain to set up and feels like a hack; it's not the default behavior, requires a lot of additional setup to get it working, behaves differently than rootful docker, and lastly most documentation assumes you're using rootful docker because it's been the only way for years. The fundamental architecture of docker makes rootless awkward but the company needs to compete with podm…
"Podman relies on the unprivileged user namespace usage (CONFIG_USER_NS_UNPRIVILEGED) which has some serious security implications..."
A lot of hype around Podman on HN this week (two FP conversations regarding, but nothing "new" with Podman). Seems to be an intentional push to get people talking about it for not much of an apparent reason.
Earlier quoted context omitted.
Having just fought it, Docker rootless is a pain to set up and feels like a hack; it's not the default behavior, requires a lot of additional setup to get it working, behaves differently than rootful docker, and lastly most documentation assumes you're using rootful docker because it's been the only way for years. The fundamental architecture of docker makes rootless awkward but the company needs to compete with podm…
I just found out about Docker's rootless mode in an HN thread the other day. The docs make it seem simple, with few meaningful limitations. Really interested to hear some more about the additional setup you needed to do, and what behavioural differences you've encountered?
Shameless plug: I wrote undocker[1] to convert docker images to a rootfs tarball, so I can run them with plain systemd. Goal: no more daemons to run 3rd party containers, systemd is good enough by now: resource limits, isolation, chroot, dynamic users, logging, and more. Low-level tooling is done, I am now building ecosystem around it: easy installation, convert to deb/rpm, systemd units, etc. [1]: https://sr.ht/~mot…
Earlier quoted context omitted.
Having just fought it, Docker rootless is a pain to set up and feels like a hack; it's not the default behavior, requires a lot of additional setup to get it working, behaves differently than rootful docker, and lastly most documentation assumes you're using rootful docker because it's been the only way for years. The fundamental architecture of docker makes rootless awkward but the company needs to compete with podm…
I just found out about Docker's rootless mode in an HN thread the other day. The docs make it seem simple, with few meaningful limitations. Really interested to hear some more about the additional setup you needed to do, and what behavioural differences you've encountered?
They recommend using Ubuntu. And they are not joking. Just click on the other distros to see the amount of hoops you have to jump through. You can't even get overlay2, which offers the best filesystem performance. Not to mention the benchmarks I've seen have slirp4netns at about ~3% of the performance of root veth. I would consider both of those incredibly meaningful limitations. You have to use sysctl/setcap to get ping working, to bind to ports It's a tough sell when you can just install root Docker with a single package command and never have to worry about a bunch of caveats that might just break or change on the next release.
Shameless plug: I wrote undocker[1] to convert docker images to a rootfs tarball, so I can run them with plain systemd. Goal: no more daemons to run 3rd party containers, systemd is good enough by now: resource limits, isolation, chroot, dynamic users, logging, and more. Low-level tooling is done, I am now building ecosystem around it: easy installation, convert to deb/rpm, systemd units, etc. [1]: https://sr.ht/~mot…
Also, as good as systemd is (and I've defended it here a few times as better than what was before), it still feels like an organically grown accumulation of edge cases that were patched. I try to keep it's use to the subset of features that are easy to grow for not just myself but those of my team, and systemd is known (in my circles at least) as being somewhat obtuse. For me, that's a good argument for a dedicated application to handle it.