Zum Inhalt springen
Deutsch

DNS Seed Provider

DnsSeedProvider löst Seeds beim Start via DNS auf. Zwei Modi:

ModusLookupErgebnis
SRV-Records_actor-ts._tcp.example.comService + Port aus Records
A-Recordsactor-ts.example.comNur IPs; Port kommt aus Config

SRV ist die flexiblere Wahl (Service-Discovery-Style); A-Records funktionieren für einfachere Setups.

import { Cluster, DnsSeedProvider } from 'actor-ts';
const provider = new DnsSeedProvider({
service: '_actor-ts._tcp.example.com',
});
const seeds = await provider.lookup();
await Cluster.join(system, { host, port, seeds });
interface DnsSeedProviderSettings {
service: string; // SRV-Record (oder Hostname für A-Record)
port?: number; // erforderlich für A-Record-Modus
resolver?: DnsResolver; // Default-Node-DNS überschreiben
}
new DnsSeedProvider({ service: '_actor-ts._tcp.my-app.example.com' });

SRV-Records tragen pro Eintrag Host, Port, Weight, Priority. Der Provider gibt für jeden Eintrag, den die DNS-Abfrage zurückgegeben hat, host:port zurück.

Um die SRV-Records anzulegen:

_actor-ts._tcp.my-app.example.com. IN SRV 10 100 2552 node-1.my-app.example.com.
_actor-ts._tcp.my-app.example.com. IN SRV 10 100 2552 node-2.my-app.example.com.
_actor-ts._tcp.my-app.example.com. IN SRV 10 100 2552 node-3.my-app.example.com.

Plus passende A-Records für die Hostnames. Die meisten DNS-SD-Service-Registrierungstools (Consul, Eureka mit DNS-Plugin) publizieren SRV-Records automatisch.

new DnsSeedProvider({
service: 'actor-ts.example.com',
port: 2552,
});

Für Setups ohne SRV — DNS trägt nur IPs. Der Provider fragt A-Records ab und paart jede mit dem konfigurierten Port.

A-Records zeigen typischerweise auf einen Loadbalancer oder eine Round-Robin-DNS-Liste; mehrere A-Einträge bedeuten mehrere Seed-Kandidaten.

UmgebungVerwendung
Consul-verwaltete DeploymentsSRV-Modus — Consul schreibt sie automatisch.
Eureka mit DNS-PluginSRV-Modus.
Manuelle Deployments mit DNS-ServerBeide Modi; SRV bevorzugt.
Cloud mit DNS-basiertem Service DiscoverySRV-Modus.
K8sNimm KubernetesApiSeedProvider — K8s’ Headless Services produzieren zwar A-Records, aber der K8s-API-Provider ist zuverlässiger.
// Der Provider macht EIN Lookup beim Start. Kein späteres Refresh.

Sobald Cluster.join fertig ist, übernimmt die Gossip-Schicht des Clusters das Membership-Tracking — DNS wird nicht mehr konsultiert. Das heißt:

  • Ein Node, der nach dem Start hinzugefügt wird, ist für existierende Peers nicht via DNS sichtbar. Er joint über seinen eigenen DNS-Lookup, kontaktiert einen existierenden Seed, Gossip propagiert weiter.
  • DNS-TTLs spielen für die Cluster-Laufzeit keine Rolle — nur beim Start.