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

31–40 of 111 posts

Re: Migrating from Docker to Podman

#31

Post by traceroute66 »

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…

> Goal: no more daemons to run 3rd party containers, systemd is good enough by now: resource limits, isolation, chroot, dynamic users, logging, and more.

Isn't that what Firecracker[1] does ?

(Well, ok, not really, but a bit closer to the base system than Docker/Podman)

[1] https://firecracker-microvm.github.io/

Re: Migrating from Docker to Podman

#32

Post by ithkuil »

riedel wrote: post #3

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…

https://github.com/lima-vm/lima may fit your usecase

Re: Migrating from Docker to Podman

#33

Post by riedel »

riedel wrote: post #30
pred_ wrote: post #6

Earlier quoted context omitted.

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

OK I start to get the problem with WSL2. I guess forking docker machine to support WSL2 natively would be a good way to go then.

I just noted that it seems to straight forward to extend machine via drivers and at least there is one for parallels. Also rancher seems to maintain a fork of machine itself so it seems unlikely to die as an alternative...

Re: Migrating from Docker to Podman

#34

Post by technological »

f0e4c2f7 wrote: post #23
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…

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!

One trade off I can think about is rolling out changes or updates . With docker the orchestration tool will handle that for me

Re: Migrating from Docker to Podman

#35

Post by benguillet »

ibeckermayer wrote: post #29
domenkozar wrote: post #20

Still for reproducibility, it's best to build container images with Nix: https://nix.dev/tutorials/building-and-running-docker-images

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…

One use case I see is if you're using Nix for all your local development, but Docker in production (because it's the easiest these days: package an image, give it to ECS/Fargate or equivalent and it's good to go).

You're not using Docker in development because of the sync issues on Mac between the host and the containers, but ideally you still want as much as possible the development and production environment parity (same versions of dependencies, etc). You can build your Docker images with Nix to ensure the dependencies versions you're developing with will be the same in prod.

Re: Migrating from Docker to Podman

#36

Post by junon »

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…

Been using systemd for personal project deployments for quite a while now after leaving ZEIT (Vercel) and the year or so fighting endlessly with k8s and docker's shortcomings.

I love it. It does everything I need it to, it's fast, decently documented, supports everything Docker does (just not 1:1 in terms of DX) and is present wherever I need it.

Re: Migrating from Docker to Podman

#37

Post by xgbi »

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.

Re: Migrating from Docker to Podman

#38

Post by mdoms »

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.

Re: Migrating from Docker to Podman

#39

Post by GordonS »

moxzyros wrote: post #24
cpuguy83 wrote: post #8

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…

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?

Re: Migrating from Docker to Podman

#40

Post by alias_neo »

kenada wrote: post #19
alias_neo wrote: post #4

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…

Podman [supports][1] `docker-compose` now. Just set `DOCKER_HOST` to the path of your Podman socket after activating the service, and it should just work (unless you use Swarm, which is not supported). [1]: https://www.redhat.com/sysadmin/podman-docker-compose

Thanks for the heads up.

It's worth noting for others that (it appears from a quick read, I haven't actually used this yet), the compromise for gaining the "docker-compose" superpower is that you will have to run a podman service (Daemon). This comes counter to some (not all) of the benefits I mentioned above, but is a necessary compromise if one wants the power of compose style orchestration; that is, that there must be some deamon to manage it.

This is not authoritative, I may be mistaken, but this is my educated guess based on a quick read and my knowledge of Docker et al.

Post reply on HN