Eine Service-Referenz, die nie bricht — selbst bevor du Private Networking aktivierst
Der übliche Rat für Service-zu-Service-Aufrufe ist „nutze den internen Hostnamen, nicht den öffentlichen” — vernünftig, bis die beiden Services auf verschiedenen Hosts, verschiedenen Providern oder verschiedenen Regionen landen und der interne Hostname aufhört aufzulösen. Die meisten Plattformen lösen das, indem sie dich zwingen, von Anfang an über Topologie nachzudenken. Railyards Ansatz ist, die Referenz unabhängig von der Topologie korrekt auflösen zu lassen und darunter zu ändern, was sich ändert, wenn sich die Topologie ändert.
Drei Fälle, eine Referenz
Jede App bekommt <name>.railyard.internal, und worauf dieser Name tatsächlich auflöst, hängt komplett davon ab, wo die andere App relativ dazu läuft, nicht von irgendetwas, das die aufrufende App wissen muss:
- Gleicher Server: Es ist ein Docker-Netzwerk-Alias — löst direkt zum Container auf dessen eigenem Port auf. Kein Setup, kein Netzwerk zu konfigurieren.
- Anderer Server, Private Networking aus: Die Referenz funktioniert trotzdem — sie ist nur nicht privat. Sie löst stattdessen zur normalen öffentlichen
https://-Adresse der App auf, statt schlicht zu versagen. Eine Referenz zwischen zwei Apps auf verschiedenen Servern degradiert zu „funktioniert, aber übers öffentliche Internet”, statt zu brechen. - Anderer Server, Private Networking an: Jeder Server im Team tritt einem verschlüsselten WireGuard-Mesh bei (
10.210.0.0/16), und derselbe Name löst jetzt auf, wo die App tatsächlich läuft, über Provider und Regionen hinweg, geroutet über das Mesh statt über das öffentliche Internet.
Der Teil, der es wert ist, sich länger damit zu befassen: Eine App, die ${{api.RAILYARD_PRIVATE_URL}} referenziert, ändert sich nicht, wenn sich davon etwas ändert. Verschiebe api auf einen anderen Server, binde einen Server eines völlig anderen Cloud-Providers an, schalte Private Networking zum ersten Mal ein — die Referenz löst weiter auf, nur jedes Mal über einen anderen Mechanismus.
Warum graceful degradation besser ist als eine harte Anforderung
Die Alternative — Private Networking ist Pflicht, oder Referenzen schlagen schlicht fehl, bis es konfiguriert ist — wäre in einem abstrakten Sinn „korrekter” und in der Praxis schlechter: Ein kleines Team auf einem Server braucht serverübergreifendes Networking überhaupt nie und sollte kein WireGuard-Mesh konfigurieren müssen, um zwei Apps zu deployen, die zufällig am selben Ort leben. Dass der Fallback „funktioniert trotzdem, über öffentliches HTTPS” ist statt „funktioniert nicht, bis du das einrichtest”, bedeutet, dass dieselbe App-Konfiguration am ersten Tag mit einem Server gültig ist und auch nach dem Skalieren auf fünf Server über zwei Provider hinweg weiterhin gültig bleibt — nichts muss umgeschrieben werden, wenn die Topologie wächst.
Was das Einschalten tatsächlich ändert
Servers → Private network → Turn on (nur Admin) ist die eine Aktion: Jeder Server, der bereits im Team ist, tritt dem Mesh bei, und bereits laufende Container übernehmen den neuen Resolver bei ihrem nächsten Deploy oder Restart — nicht sofort, was relevant ist, wenn eine Referenz latenzempfindlich ist und aktuell übers öffentliche Internet auflöst. Von diesem Punkt an tritt jeder Server, den das Team später hinzufügt — auf jedem Provider, in jeder Region — automatisch demselben Mesh bei, da das Mesh eine Eigenschaft des Teams ist, nicht etwas, das pro Server neu konfiguriert wird.
Vollständige Referenz: Networking docs, Variables and secrets.