21–30 of 111 posts
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.
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…
Edit: looking at the docs is that system-nspawn that's actually doing the heavy lifting. For Linux namespaces. I feel like this has great potential!
Ive been using Podman for a while for my non-Kubernetes cloud deployments (i.e. small VM based things). It's worked very well for me after a few initial hiccups a year or so ago. Now that Podman-compose[0] is in the works, it'll really be comparable in the UX space soon, and outperforms Docker in several ways when it comes to security. The key difference with Podman compared to Docker is that is does not run a deamon…
Docker has a rootless mode in the same way that podman has a rootless mode.
The fundamental architecture of docker makes rootless awkward but the company needs to compete with podman now which is architected to fix many of Dockers deficiencies while maintaining it's many strengths.
Docker has been a great tool but running as root has always bothered me. I'm glad they're evolving but it feels a little too late and the migration to rootless, as far as I'm concerned, is not simple. Currently I'm investigating migrating my homelab and development efforts to podman.
How does podman replace docker desktop? I thought it more as an alternative to the docker daemon, which is still free and open source. I start to wonder if people actually value open source if they run away from something just because some company publishes a commercial GUI. I like that with docker swarm one can without too much headache go from dev environments to a cluster. At university this seems much better than…
It is straightforward to get Podman up and running in WSL2; it is also possible to set up Docker in WSL2 as well without Docker Desktop as well but it is much more painful. So in the Windows space, Podman effectively becomes an alternative to Docker Desktop, simply because the latter makes it possible to do Docker at all (ignoring the other things it does).
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…
Wow I must be quite behind on systemd indeed. It's been a few years. Is there any isolation offered like you would get with docker or is that a tradeoff? Edit: looking at the docs is that system-nspawn that's actually doing the heavy lifting. For Linux namespaces. I feel like this has great potential!
As far as systemd vs dockerd goes, dockerd provides a bit more isolation by default, but `systemd-analyze security` can guide you so far beyond the Docker defaults. And it is always compatible with system daemons, giving consistent configuration between, say, postgresql from package manager and prometheus from docker container+undocker.
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…
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…
That's really interesting, I had no idea systemd could do that. Have you written in more detail anywhere? I'd love to see a detailed comparison between approaches.
Have a look at these in systemd.exec[1]: PrivateUsers, DynamicUser, ProtectProc, RootDirectory.
There are more, but these are the main ones.
[1]: https://www.freedesktop.org/software/systemd/man/systemd.exe...
Still for reproducibility, it's best to build container images with Nix: https://nix.dev/tutorials/building-and-running-docker-images
So if your whole machine’s environment is already specified, why do you need to add Docker as another layer of abstraction? Is it simply to deal with needing to run multiple apps on the same underlying machine (defined by Nix) with possibly conflicting dependencies (those would be managed by Docker)?
How does podman replace docker desktop? I thought it more as an alternative to the docker daemon, which is still free and open source. I start to wonder if people actually value open source if they run away from something just because some company publishes a commercial GUI. I like that with docker swarm one can without too much headache go from dev environments to a cluster. At university this seems much better than…
It is straightforward to get Podman up and running in WSL2; it is also possible to set up Docker in WSL2 as well without Docker Desktop as well but it is much more painful. So in the Windows space, Podman effectively becomes an alternative to Docker Desktop, simply because the latter makes it possible to do Docker at all (ignoring the other things it does).