Comment by gucci-on-fleek | Hacker News Reader

Comment by gucci-on-fleek | Hacker News Reader

Parent Full thread

> Anyone know why this is?

In Podman, a pod is essentially just a single container; each "container" within a pod is just a separate rootfs. So from that perspective, it makes sense, since you can't really restart half of a container. (But I think that it might be possible to restart individual containers within a pod; but if any container within a pod fails, then I think that the whole pod will automatically restart)

> Why? Because I have some network resources that don’t really virtualize, so they can live in one network namespace.

You can run separate containers in the same network namespace with the "--network" option [0]. You can either start one container with its own automatic netns and then join the other containers to it with "--network=container:<name>", or you can manually create a new netns with "podman network create <name>" and then join all the containers to it with "--network=<name>".

[0]: https://docs.podman.io/en/latest/markdown/podman-run.1.html#...

> You can run separate containers in the same network namespace with the "--network" option [0].

Oh, right, thanks. I think I did notice that last time I dug into this. But:

> or you can manually create a new netns with "podman network create <name>" and then join all the containers to it with "--network=<name>".

I don’t think this has the desired effect at all. And the docs for podman network connect don’t mention pods at all, which is odd. In general, I have not been very impressed by podman.

Incidentally, apptainer seems to have a more or less first class ability to join an existing netns, and it supports CNI. Maybe I should give it a try.

> > or you can manually create a new netns with "podman network create <name>" and then join all the containers to it with "--network=<name>".

> I don’t think this has the desired effect at all.

Well I'm not entirely sure what effect you're wanting here, but I use this option for some of the containers that I run, and it makes it so that all containers in that network can reach each other, while anything outside that network can't. You can also use "--network=ns:/run/user/$UID/netns/<file-name>" to join a container to a manually created network namespace (created with "ip netns add <file-name>") if you need more control.

I think you are confusing a logical network with a network namespace. A logical network is a construct of Docker or CNI or Netavark or whatever that acts kind of like a LAN. A network namespace is a collection of processes that the kernel treats as being one logical machine for networking purposes.

When you make a docker network that is attached three containers with hostnames a, b, and c, then those hostnames logically belong to the “network” (and your container engine may put considerable effort into making it possible for them to resolve each other and communicate), but there is one network namespace each for a, b, and c, for three total.

In Podman, but apparently not Docker, you can do --network container:foo to join another container’s netns. I assume that the reason that Podman and containerd support this low-level feature is that they both support some form of pod.

I think that you're correct that I'm mistaken; thanks for the correction (and sorry for the mistake).

No worries. And your reply caused me to re-remember the --network container:id podman feature, which I might actually try using.

(I generally dislike podman because of stuff like this:

https://github.com/containers/buildah/issues/6460#issuecomme...

Podman is absolutely nicer than Docker in that it integrates better with systemd (if that’s your cup of tea) and it’s less painful to use for non-root development purposes.)

> In Podman, but apparently not Docker, you can do --network container:foo to join another container’s netns

that is precisely how you accomplish the same thing in docker

https://docs.docker.com/engine/network/#container-networks

Reply on news.ycombinator.com