Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating from Docker to Podman

marcusnoble.co.uk

Post reply on HN
Print view View original

91–100 of 111 posts

Re: Migrating from Docker to Podman

#91

Post by ViViDboarder »

CyanLite2 wrote: post #46
mdoms wrote: post #38

Someone correct me if I'm wrong but my understanding is that Docker is only charging for Docker Desktop, which is a GUI and management tool required to use Docker on Windows and MacOS - both of which are not supported by Podman. And Docker Desktop is not required (or even available) on Linux - the only platform Podman supports.

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.

Also, build infra doesn’t even have to change. Only development tools. I just uninstalled Docker Desktop and installed minikube (single binary) and I’m all set.

Re: Migrating from Docker to Podman

#92

Post by motiejus »

rank0 wrote: post #79
motiejus wrote: post #21

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…

I love your project! Can I still get the same networking functionality with undocker/systemd that docker provides? For example, container hostname resolution, private networks, container->localhost port forwarding?

Nope, systemd doesn't have as advanced network namespace capabilities as docker. You'd need to do this via other means.

Re: Migrating from Docker to Podman

#93

Post by motiejus »

amelius wrote: post #84
motiejus wrote: post #21

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…

Can this be installed and run as a non-root user?

Undocker reads and writes tarballs. So yes.

Running them is a different story. I've never tried systemd user services, so can't tell. Curious myself. :)

Re: Migrating from Docker to Podman

#94

Post by motiejus »

nonameiguess wrote: post #65
motiejus wrote: post #21

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…

I really like this. At least for the nspawn case, systemd as of 242 supports loading containers from OCI images directly, but still doesn't seem to support OCI hooks or have a runc-compatible CLI, which were the other two outstanding issues identified by Poettering before it could be considered a true drop-in replacement for running container bundles loaded from OCI images. As for just using systemd and not nspawn at…

ProtectHostname will generate a new hostname for the service process hierarchy.

JoinsNamespaceOf can be used to set up network namespaces (albeit in a clunky way).

It is possible, but multiplexing networked services requires significantly more effort with systemd than with others. I do not have a strong use case yet to invest in tooling for it, but it may come.

Re: Migrating from Docker to Podman

#95

Post by sjellis »

xgbi wrote: post #37

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.

I installed Podman 3.3.1 on a Mac yesterday from Homebrew and volume mounts were definitely an issue, but it otherwise worked as advertised on the command-line.

The bugs cited in the article are already fixed in the code, so I don't hold those against it.

I did have an issue that was my fault, encountered one genuine bug, and was disappointed to find that there's some work to be done before third-party tools can use it as a Docker replacement:

https://github.com/containers/podman/issues/11397

I agree that Podman is not yet a complete replacement for Docker on macOS, but the experiment was successful enough for me that I intend to try Podman instead of Docker on Linux servers.

Re: Migrating from Docker to Podman

#97

Post by hda111 »

thomasbacklund wrote: post #15

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/

On CentOS and similar distros I agree. But on Debian like distros podman has too many rough edges and the packaging isn’t something you can contribute to easily on GitHub. I find this sad since podman is really good but there isn’t much effort in improving UX on Debian distros.

Re: Migrating from Docker to Podman

#98

Post by hda111 »

kaba0 wrote: post #47
ibeckermayer wrote: post #29

Earlier quoted context omitted.

I don’t really get it — my low resolution understanding is that Nix gives you the ability to define your Unix environment itself with definition files, similar to how Docker gives you the ability to define a container abstraction with Dockerfiles. 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 multipl…

With nix, the whole dependency hell problem is solved, so you will not get conflicting dependencies anymore (other than perhaps bugs). You could install the same program twice with the exact same version of libc compiled by gcc and clang for example and it would still not get into each other’s way. Docker on the other hand doesn’t solve this problem itself - docker images can be built declaratively (eg. with nix itse…

You can get the reproducibility resolved. But when I tried nix I didn’t found a way to save the source code easily in my project. Similar to the vendor directory in Go there should be a way to backup the source since the source can go away any time.

Re: Migrating from Docker to Podman

#99

Post by kaba0 »

hda111 wrote: post #98
kaba0 wrote: post #47

Earlier quoted context omitted.

With nix, the whole dependency hell problem is solved, so you will not get conflicting dependencies anymore (other than perhaps bugs). You could install the same program twice with the exact same version of libc compiled by gcc and clang for example and it would still not get into each other’s way. Docker on the other hand doesn’t solve this problem itself - docker images can be built declaratively (eg. with nix itse…

You can get the reproducibility resolved. But when I tried nix I didn’t found a way to save the source code easily in my project. Similar to the vendor directory in Go there should be a way to backup the source since the source can go away any time.

What do you mean? Just use a git repository as a source, but you may as well create a hashed folder containing your source files, but that is not the primary function of nix.

Re: Migrating from Docker to Podman

#100

Post by hda111 »

kaba0 wrote: post #99
hda111 wrote: post #98

Earlier quoted context omitted.

You can get the reproducibility resolved. But when I tried nix I didn’t found a way to save the source code easily in my project. Similar to the vendor directory in Go there should be a way to backup the source since the source can go away any time.

What do you mean? Just use a git repository as a source, but you may as well create a hashed folder containing your source files, but that is not the primary function of nix.

I mean so I can reproduce it in 10+ years where many git repos don’t exist anymore. Go can keep checksumed copies of any code it uses to compile. I’d like to see this in Nix as well.
Post reply on HN