I'm looking to redo my network logical topology in light of moving to proxmox and full virtualisation.
To get to the specific issue...
Dynamic Service based IP and DNS aliases for containers/vms.
So instead of the flat vanilla /24 subnet I have for the LAN now, where "Servers" get IPs and hostnames and occasionally DNS aliases or even IP aliases. I want the IPs and hostnames to go to the 'service' layer.
Use case example. If I spin up a CT/VM GitLab-CE environment, I would like it's services to function without port mapping. So that https://gitlab.lan.mydomain.com/ will resolve to which ever IP is assigned to that GitLab-CE virtual instance. (locally at least, I can map in remotes later, but off topic.)
If I later move said CT or VM or move the gitlab services themselves to different "hosts", the IP and hostname should follow it.
Hurdle / confusion / problem 1:
If a VM or CT is to run more than one service and require more than one IP then IP aliases might be important. I have no idea about how to do this with a basic "ISC_DHCP_SERVER" instance or bind. EDIT: Plausibly by creating multiple NICs/MACs for the containers. One per service.
Maybe if I lighten up the requirement on the "IP" following the service and rely on the hostname or SRV record following the IP of where the service lives, then this problem would cease to exist.
Hurdle / confusion / problem 2:
Docker. In particular docker stacks like GitLab. These can get very complicated and very nested very quickly with docker choosing, for the most part to manage it's own IPs, hostnames and even, to some degree DNS, while it will delegate forward to the host DNS having exhausted "in stack" resolution IIRC.
I need to explore this. Concerns of coupling docker containers to external DHCP/DNS with bridged networks could push a lot of churn and crap into the main DHCP server which should really stay in the docker stack.
Any pointers? Dos don'ts. Been there? Learnt the hardway? Please tell....
To get to the specific issue...
Dynamic Service based IP and DNS aliases for containers/vms.
So instead of the flat vanilla /24 subnet I have for the LAN now, where "Servers" get IPs and hostnames and occasionally DNS aliases or even IP aliases. I want the IPs and hostnames to go to the 'service' layer.
Use case example. If I spin up a CT/VM GitLab-CE environment, I would like it's services to function without port mapping. So that https://gitlab.lan.mydomain.com/ will resolve to which ever IP is assigned to that GitLab-CE virtual instance. (locally at least, I can map in remotes later, but off topic.)
If I later move said CT or VM or move the gitlab services themselves to different "hosts", the IP and hostname should follow it.
Hurdle / confusion / problem 1:
If a VM or CT is to run more than one service and require more than one IP then IP aliases might be important. I have no idea about how to do this with a basic "ISC_DHCP_SERVER" instance or bind. EDIT: Plausibly by creating multiple NICs/MACs for the containers. One per service.
Maybe if I lighten up the requirement on the "IP" following the service and rely on the hostname or SRV record following the IP of where the service lives, then this problem would cease to exist.
Hurdle / confusion / problem 2:
Docker. In particular docker stacks like GitLab. These can get very complicated and very nested very quickly with docker choosing, for the most part to manage it's own IPs, hostnames and even, to some degree DNS, while it will delegate forward to the host DNS having exhausted "in stack" resolution IIRC.
I need to explore this. Concerns of coupling docker containers to external DHCP/DNS with bridged networks could push a lot of churn and crap into the main DHCP server which should really stay in the docker stack.
Any pointers? Dos don'ts. Been there? Learnt the hardway? Please tell....
Last edited: