Despite 30 years in IT I never got overly involved in networking so I’m finding Docker/Portainer networking a bit confusing.
I’ve installed Docker on a Raspberry Pi 5/8Gb along with Portainer and both appear to run fine. I’ve also pulled and run Pi-Hole (raspberry Pi version) which also seems to be running fine by which I mean I can access it on my Raspberry Pi… while I can access Portainer, I can’t seem to access the Pi-Hole container from my Windows PC which is on my primary network (192.168.0.0/24) and to be able to see the Pi-Hole instance from my network is crucial to what I want it for. My eventual plan is to merge my current installations (Pi-Hole, NextCloud and JellyFin) onto this single Pi 5.
If I want to put the container/instance on my network (which I’d prefer), my best guess is that I have to create an ipvlan network that is effectively part of my own network and given that I already ensure that the first 64 addresses are not handed out by my router’s DHCP, I could use a pool of IPs running from.17 to.30 (192.168.1.16/28) which I know are clear i.e. there won’t be any conflicts.
So my questions are basically, can I even do this (get the containers to appear like normal machines on my network) and are the following correct?
I created the above successfully but when I join the pi-hole container to the network, it doesn’t pick up an IP and there doesn’t seem to be a way to give it a manual IP.
Ultimately, my aim is to communicate with a container OS, in this case pi-hole, on my normal network (192.168.1.0/24). I know it’s working as I can I can ping the container and access pi-hole from the Pi. I don’t greatly mind whether the connection is bridge or ipvlan (I’d prefer the latter because it feels more sensible/accessible) and just want it to act similar to the pi-hole installation I currently have running on another Pi.
A friend advised me that I should be able to access Pi-Hole by going to its IP & port however, having installed it using Portainer, I don’t know what port that is.
When you refer to ipvlan, you must refer to ipvlan_mode=l2, which is also the default.
Most people prefer macvlan as each child interface gets it’s own mac address.
WIth macvlan/ipvlan a kernel security restriction is applied, that prevents the parent interface (the one on the host) to directly communicate with its children (the ones of the containers) and the other way around. Children can communicate amongst each other, and they can communicate to every other lan device and vice-versa.
A container that is only attached to a macvlan/ipvlan network can not communicate with services on the host, or require routing through the host. Thus, it can neither reach a container only attached to a bridge or the host networking, or can be reached by it. A container can be either attached to the host networking, or to one or more bridge, ipvlan or macvlan network at the same time.
Portainer and the docker cli are just clients for the Docker API. Regardless of the client that drives the Docker API, the work is always done by the Docker Engine.
Blockquote A container that is only attached to a macvlan/ipvlan network can not communicate with services on the host, or require routing through the host. Thus, it can neither reach a container only attached to a bridge or the host networking, or can be reached by it. A container can be either attached to the host networking, or to one or more bridge, ipvlan or macvlan network at the same time.
I kinda assumed it would connect to both host and an external client so I feel that two network addresses would be needed, if that makes sense?
Blockquote Could you extend on what you mean by “it would connect to both host and an external client”?
Well, like a machine with two network cards that has access to both networks. I know docker instances are not virtual machines as such but that used to be how we did it on VMs (once upon a time).
