I have two Docker servers on the same home network, each with a different internal IP address and its own Traefik reverse proxy. Both servers host different applications, so this is not an HA setup, and I do not want all traffic routed through one central proxy or load balancer.
I currently use a wildcard DNS record pointing to the first server. Traefik reads container labels such as the hostname and routes requests like app.example.com to the correct container. I would like the second server to automatically create or update DNS records for the hostnames declared in its Docker labels, pointing them to the second server's IP address. The records could be managed through my local AdGuard DNS server or through my domain provider.
This is for internal-only home-lab services. I want to avoid manually maintaining DNS exceptions whenever containers change, while keeping the same simple URLs such as app.example.com rather than using a separate subdomain for the second server. Is there a container-aware DNS or service-discovery tool that can do this?
4 Answers
What you are describing is service discovery. Tools such as Consul can register services and provide DNS-based discovery, although integrating it cleanly with two independent Traefik instances may take more configuration than simply using static records. Kubernetes or Docker Swarm can also provide a shared service network, but that may be excessive for a small home setup.
If you can accept an orchestrator, Docker Swarm would let both machines participate in one cluster and gives you shared networking and service placement. Traefik can then discover the services from the Swarm API. However, that usually changes the architecture rather than simply updating DNS, and it may still require a clear ingress design if you do not want traffic entering through one particular host.
A Docker-aware DNS updater or Traefik companion is probably the closest fit. It can watch container labels and create records in a DNS provider automatically. Herald is one project worth evaluating for this kind of setup, though check its current maintenance status and whether it supports your DNS backend.
Be cautious about constantly changing DNS records. Clients and DNS resolvers cache answers, so moving a hostname from one server to another may not take effect immediately. For a home network, the simplest reliable design is often to keep one wildcard record per server or maintain a small set of explicit internal records.
The services on each server are different, so this is not about failover. I mainly want Docker labels to create the explicit records automatically while keeping each server as the direct entry point for its own applications.
I would prefer not to introduce a central ingress host. The goal is for a hostname assigned to a container on server two to resolve directly to server two, while server one continues handling its own applications.