[TekMol]

To me, this big problem with Docker is that it does a ton of changes to my system, even when I don't use it.

It runs a daemon, it uses a bunch of IPs, it mounts a ton of stuff ...

Is there a reason for all that noise and complexity?

There can't be a reason until I run a container, right? And even then, it seems way too much.

Is it different when using Quadlets?

[jeppester]

One of podman's selling points is that it doesn't need a daemon, and it runs without root privileges.

I'm not familiar enough with the lower level details to know how it works, but it certainly feels less like you are making "a ton of changes to the system" compared to docker

[viraptor]

This. Run podman without a daemon and with host networking and the only "weird" configuration you'll see is the overlay fs. Everything else is quite often an unnecessary overhead.

[v3ss0n]

What worse is , it screws up the firewall rules. Podman avoid that so , quadlets should be fine? Podman supposed to be drop-in replacement for docker but - last try (4 months ago) of podman to run our development docker containers fails to build so i think Podman is still far away from docker replacement.

[prmoustache]

> Podman supposed to be drop-in replacement for docker but - last try (4 months ago) of podman to run our development docker containers fails to build so i think Podman is still far away from docker replacement.

I'd be curious what failed to build under podman. I have been using podman as a replacement for docker for the last 3 years and haven't found any blocker. Sometimes you can't reuse a docker-compose file shared by a third party project straight away without adaptation but if you know the difference between docker and podman you can build and run anything that also run on docker.

[magicalhippo]

> Sometimes you can't reuse a docker-compose file shared by a third party project straight away without adaptation

So not a drop-in replacement then...

[prmoustache]

4 points:

1. Most of the issues I had that forced me to adapt a docker-compose was because I was using podman rootless and most people build docker-compose file with docker running as root in mind. mostly to have access to privileged ports. I guess running podman under root would have solved this but one of the reason I switched to podman in the beginning was for the rootless capability. In a way this wasn't much different than modifying a deployment to work with docker in rootless mode.

2. part of the appeal of using podman is its compatibility with kubernetes yaml file so you tend to quickly switch away from docker-compose anyway. Also for self hosting, the systemd approach was more elegant, even before the quadlets support.

3. One would argue that docker-compose != docker/moby engine.

4. docker-compose has introduced breaking changes in its history which meant adapting your compose file or add flags at runtime such as `docker-compose disable-v2`

EDIT: adding points

[kubanczyk]

> 4. docker-compose has introduced breaking changes in its history

...until the point when they resigned any notion of versioning. You can't have a breaking change if you don't promise a stable behavior, see? /s

Not many people noticed that the top-level

    version "3.9"

has no effect anymore. "It is only informative", the current spec says. Your old docker-compose.yaml files spew errors as soon as they go out-of-sync with the master branch (classy!) of the spec repo.

[magicalhippo]

Overall fair points, though I disagree with 3 since it's been integrated sufficiently (not a separate install and not a separate executable).

[viraptor]

Tbh, with the changes in the last few versions, you can't reuse some compose files even between different versions of docker, so... they're actually pretty comparable there.

[yrro]

Hmm, podman also creates rules in the nat table if that's what you're talking about--_if_ you tell it to publish ports.

Of course, if you run rootless then there's no possibility to do so. :)

[aorth]

> What worse is , it screws up the firewall rules.

Yes! And it has a hard dependency on iptables, which I have removed from all my servers long ago in favor of nftables. Grrrrrr.

[5e92cb50239222b]

In recent versions of Ubuntu, Debian, and Arch /usr/bin/iptables is an iptables-compatible interface to nftables. That's what docker is using on those systems, and it works fine. You can manage those rules with /usr/bin/nft.

[dbrgn]

That's not the case (anymore). I run a NixOS based router with nftables (no iptables installed at all), and podman works just fine. It simply adds its NAT rules to nftables (unless you tell it not to).

As far as I know, this was introduced with the new networking stack (netavark).

[deadbunny]

Do you have a link to your NixOS router config? Been thinking of doing this for a while but never got round to it.

[dbrgn]

Here's a redacted version: https://gist.github.com/dbrgn/137da9e9ad342d536d1e452fba3e9d... Maybe it's useful as reference. It includes multiple network interfaces, a firewall, VLANs, DNS and ad blocking (plus two network services). (This version of the config does not yet make use of podman, I'm still in the process of setting everything up.)

I'm also using nix flakes, to keep the setup reproducible.

If you want to get started, I can recommend the following:

1. Install nixos. That will only take a few minutes, and you end up with a system in which you have a "/etc/nixos/configuration.nix" file. Now you can edit the config file, run "nix-rebuild switch", and the changes have been applied. Every change results in a new entry in the bootloader menu, so you can always rollback.

2. Check out this great blog series: https://www.jjpdev.com/posts/home-router-nixos/ It helped me a lot.

3. Use https://search.nixos.org/options to search config options (the stuff in your config file).

Note: The blogpost still uses the classic way of managing network devices. I use Systemd, which I think is nicer and more flexible.

[deadbunny]

That's awesome, thanks for the links.

[Grimburger]

Docker's firewall modifications are incredibly obnoxious and at the top of the list of gripes for me.

[jve]

Yeah, I also tried ~months ago. To be fair, I'v only tested out dev containers with docker, so I'm too weak to debug things what went wrong.

Any article out there on how to have windows + wsl2 + podman + vscode devcontainers working?

[worksonmine]

I suggest you start by just getting plain podman running the docker.io/hello-world container to reduce the complexity and simplify debugging if anything goes wrong. It's been about a decade since I last touched windows but if wsl2 is 1:1 with Linux the official podman guide should be straight forward.

It's always easier to start with the bare minimum and build from there, and you will get a better understanding of the tools you're using.

[prmoustache]

I don't know what `vscode devcontainers` is but to run podman on wsl2 I simply installed a fedora wsl2 image (by importing the fedora container image if my memory is correct).

[sofixa]

> Is there a reason for all that noise and complexity?

To make it simple at the point of use. If developers had to configure firewalls and bind mounts for Docker to work, it never would have taken off as much as it did.

[rglover]

A safe heuristic is that whenever you introduce an abstraction to any tech stack, you can assume that it makes shortcuts that you wouldn't have to if you implemented the underlying parts yourself (w/ zero guarantee that it makes those shortcuts well). The latter meaning: short-term harder, long-term easier. Invert for any abstraction.

Related to Docker, I finally bit down and tried to do a simple deployment stack myself using systemd and OS-level dependencies instead of containers. I'll never go back. The simplicity of the implementation (and maintenance of it) made Docker irrelevant—and something I look at as a liability—for me. There's something remarkably zen about being able to SSH into a box, patch any dependency issues, and whistle on down the road.

[otabdeveloper4]

> Is there a reason for all that noise and complexity?

No. It's just Docker being shit.

[soupdiver]

This is about Podman, not Docker