I have a bridge device set up with systemd, br0, that replaces my primary ethernet eth0. With the br0 bridge device, Incus is able to create containers/VMs that have unique MAC addresses that are then assigned IP addresses by my DHCP server. (sudo incus profile device add <profileName> eth0 nic nictype=bridged parent=br0) Additionally, the containers/VMs can directly contact the host, unlike with MACVLAN.
With Docker, I can’t see a way to get the same feature-set with their options. I have MACVLAN working, but it is even shoddier than the Incus implementation as it can’t do DHCP without a poorly-maintained plugin. And the host cannot contact the container due to the MACVLAN method (precludes running a container like a DNS server that the host server would want to rely on).
Is there a way I’ve missed with the bridge driver to specify a specific parent device? Can I make another bridge device off of br0 and bind to that one host-like? Searching really fell apart when I got to this point.
Also, if someone knows how to match Incus’ networking capability with Podman, I would love to hear that. I’m eyeing trying to move to Podman Quadlets (with Debian 13) after I’ve got myself well-versed with Docker (and its vast support infrastructure to learn from).
Hoping someone has solved this and wants to share their powers. I can always put a Docker/podman inside of an Incus container, but I’d like to avoid onioning if possible.
I dont get it - are you trying to mimic vm’s with you docker containers? docker works great using the normal way of exposing ports from the internal docker net through the host. Making technology work in ways it wasnt designed for usually gives you a hard to maintain setup
Confused at this sentiment, Docker includes a MACVLAN driver so clearly it’s intended to be used. Do you eschew any networking in Docker beyond the default bridge for some reason?
There are other solutions than docker for that use-case that I think are better fits. It probably works fine, but for me other drivers including host mode and ipvlan seems to have been introduced to solve the wrong thing. Like how it needs privilege for them to work and how it exposes the containers network interface. For me it kinda breaks parts of why i would use docker.
Its my personal opinion and how i like to work.
You could probably make your setup work but it seems too complicated for me when you introduce a bridge as the root interface. Maybe with macvlan adapters on the host instead or in addition.
I see, do you know of a way in Docker (or Podman) to bind to a specific network interface on the host? (So that a container could use a macvlan adapter on the host)
Or are you more advocating for putting the Docker/Podman containers inside of a VM/LXC that has the macvlan adapter (or fancy incus bridge adapter) attached?
No - i would advocate for not using docker if I need a network interface. But thats my opinion, and others will have a different one.
You can use macvlan networking, and if you need host<->container communication you give your host a macvlan interface instead or in addition to the root nic. Macvlan works “on top of” an existing interface, so theres no routing locally between the underlying nic and the macvlan nics.
If the host have several nic’s you can pass one through to a given container