I hope I am posting this at the right place…
I have a fresh install of Docker/Portainer on Debian 12 (no desktop) I am still trying to find my way around but the environment is Standalone 24.0.7
I have the following containers and working well:
homeassistant, Esphome, Mosquitto setup with network mode host (because it is required by Esphome)
I need to add the following containers to a different subnet:
Unifi Controller, Wireguard VPN, Wireguard.UI, Pi-Hole.
So I added a second NIC and at the server level it is on the right subnet.
But now I have two questions;
Question #1:
How does Docker/Portainer know to connect its “host” network to the server’s first network interface or is there a way to make sure it does? if at anytime it decides to switch to the second interface, my containers will stop working.
Question #2:
Although I connect a container to the newly macvlan I created and it gets an IP on the right subnet, it is not getting its IP from my main DHCP server and I read that I need to enable promiscuous mode. Where do I need to enable this? somewhere in Docker? on the server’s second NIC? on the switch? router?
to Q1:If you mean the behavior of --network=host, there is no way. the ports inside the container will be bound to 0.0.0.0, unless you specifically bind the port to an ip inside the container. The entrypoint would need to take care of it. If you mean when a container is attached to a bridge interface, then you can use the option com.docker.network.bridge.host_binding_ipv4 ( see: https://docs.docker.com/network/drivers/bridge/) to bind the network egress ip to a specific host ip.
to Q2: docker will handle dhcp for macvlan networks, as such you must declare a range (--ip-range when creating the network) within that subnet that is not handled by the subnets dhcp server (see: https://docs.docker.com/network/drivers/macvlan/#bridge-mode).
Note: with macvlan the parent interface is not permitted to directly communicate with the macvlan child interface, and the other way around. If you need the host to access the mavlan child interface, you need to add a macvlan client interface to the host as well. Though, if a mavlan container needs to communicate with the host, it will need to use the host’s macvlan client interface’s ip. There are plenty of blog posts that discuss it.
Perhaps I am not clear in my questions, sorry about that.
In reference to Q1
The server IP for NIC#1 is 172.16.0.124 and when I installed Docker/Portainer that is the IP it took. I had to set the 3 containers to host network so yes they are at 0.0.0.0 but on my network
to access Portainer I go to 172.16.0.124:9443
to access homeassistant I go to 172.16.0.124:8123
to access ESPHome I go to 172.16.124:6052
All the same IP because it is bound to the host which resides on 172.16.0.124
Now that I added a second Interface which is 172.16.2.35, what is preventing Docker from using that second NIC?
In reference to Q2
My DHCP server have a pool of 172.16.0.10 to 172.16.0.100
When I setup macvlan I indicated the network as 172.16.0.0/24
in the ip range how do I force to give 172.16.0.2-9 or 172.16.0.101-250 ?
I tried 172.16.0.101/24 but the first ip given is 172.16.0.2.
When it gets to 10 it will start conflicting with other clients.
I am getting confused.
My network is already created outside of Docker, I just need to have the containers show up on that network bind to the second NIC on my server. maybe macvlan is not the solution? do I have other solutions?
With macvlan, Docker needs you to tell it how your outside network looks like, which range it can use and which interface is the parent interface. So the only thing you missed while adding the network was --ip-range. The beauty of Docker is that you can easily test things out, then throw them away configure them differently and test them again.
Usually people that try to re-create their experience with vm’s tend to think they need macvlan, as it allows to use ip’s from you lan network like most vm solutions do. Though, most of them experiment a while, figure that the experience with macvlan causes more headaches than what they are used from bridges in vm solutions.
Personally I would use a reverse proxy like Traefik, use a dns resolver like unbound, adguard or pihole that allows to add domain overrides, configure different domain names that point to the docker host, use reverse proxy rules to the specific target container based on the domain names.