123 lines
3.7 KiB
Markdown
123 lines
3.7 KiB
Markdown
---
|
|
title: Service Discovery
|
|
description: Concepts and practical patterns for finding services in self-hosted and homelab environments
|
|
tags:
|
|
- networking
|
|
- service-discovery
|
|
- dns
|
|
category: infrastructure
|
|
created: 2026-03-14
|
|
updated: 2026-03-14
|
|
---
|
|
|
|
# Service Discovery
|
|
|
|
## Introduction
|
|
|
|
Service discovery is the process of locating services by identity instead of hard-coded IP addresses and ports. It becomes more important as workloads move between hosts, IPs change, or multiple service instances exist behind one logical name.
|
|
|
|
## Purpose
|
|
|
|
Good service discovery helps with:
|
|
|
|
- Decoupling applications from fixed network locations
|
|
- Supporting scaling and failover
|
|
- Simplifying service-to-service communication
|
|
- Reducing manual DNS and inventory drift
|
|
|
|
## Architecture Overview
|
|
|
|
There are several discovery models commonly used in self-hosted environments:
|
|
|
|
- Static DNS: manually managed A, AAAA, CNAME, or SRV records
|
|
- DNS-based service discovery: clients query DNS or DNS-SD metadata
|
|
- mDNS: local-link multicast discovery for small LANs
|
|
- Registry-based discovery: a central catalog such as Consul tracks service registration and health
|
|
|
|
## Discovery Patterns
|
|
|
|
### Static DNS
|
|
|
|
Best for stable infrastructure services such as hypervisors, reverse proxies, storage appliances, and monitoring endpoints.
|
|
|
|
Example:
|
|
|
|
```text
|
|
proxy.internal.example A 192.168.20.10
|
|
grafana.internal.example CNAME proxy.internal.example
|
|
```
|
|
|
|
### DNS-SD and mDNS
|
|
|
|
Useful for local networks where clients need to discover services such as printers or media endpoints. This works well for small trusted LAN segments, but it does not cross routed boundaries cleanly without extra relays or reflectors.
|
|
|
|
### Registry-based discovery
|
|
|
|
A service catalog stores registrations and health checks. Clients query the catalog or use DNS interfaces exposed by the registry.
|
|
|
|
This is useful when:
|
|
|
|
- Service instances are dynamic
|
|
- Health-aware routing matters
|
|
- Multiple nodes host the same service
|
|
|
|
## Configuration Example
|
|
|
|
Consul service registration example:
|
|
|
|
```json
|
|
{
|
|
"service": {
|
|
"name": "gitea",
|
|
"port": 3000,
|
|
"checks": [
|
|
{
|
|
"http": "http://127.0.0.1:3000/api/healthz",
|
|
"interval": "10s"
|
|
}
|
|
]
|
|
}
|
|
}
|
|
```
|
|
|
|
DNS-SD example concept:
|
|
|
|
```text
|
|
_https._tcp.internal.example SRV 0 0 443 proxy.internal.example
|
|
```
|
|
|
|
## Troubleshooting Tips
|
|
|
|
### Clients resolve a name but still fail to connect
|
|
|
|
- Check whether the resolved port is correct
|
|
- Verify firewall policy and reverse proxy routing
|
|
- Confirm the service is healthy, not just registered
|
|
|
|
### Discovery works on one VLAN but not another
|
|
|
|
- Review routed DNS access
|
|
- Check whether the workload depends on multicast discovery such as mDNS
|
|
- Avoid relying on broadcast or multicast across segmented networks unless intentionally supported
|
|
|
|
### Service records become stale
|
|
|
|
- Use health checks where possible
|
|
- Remove hand-managed DNS entries that no longer match current placements
|
|
- Prefer stable canonical names in front of dynamic backends
|
|
|
|
## Best Practices
|
|
|
|
- Use DNS as the default discovery mechanism for stable infrastructure
|
|
- Add service registries only when the environment is dynamic enough to justify them
|
|
- Pair discovery with health checks when multiple instances or failover paths exist
|
|
- Keep discovery names human-readable and environment-specific
|
|
- Avoid hard-coding IP addresses in application configuration unless there is no realistic alternative
|
|
|
|
## References
|
|
|
|
- [Consul: Discover services overview](https://developer.hashicorp.com/consul/docs/discover)
|
|
- [Consul: Service discovery explained](https://developer.hashicorp.com/consul/docs/use-case/service-discovery)
|
|
- [RFC 6762: Multicast DNS](https://www.rfc-editor.org/rfc/rfc6762)
|
|
- [RFC 6763: DNS-Based Service Discovery](https://www.rfc-editor.org/rfc/rfc6763)
|