Une référence de service qui ne casse jamais, même avant d'activer le réseau privé
Le conseil habituel pour les appels de service à service est « utilisez le nom d’hôte interne, pas le public » — raisonnable, jusqu’à ce que les deux services finissent sur des hôtes différents, des fournisseurs différents, ou des régions différentes, et que le nom d’hôte interne arrête de se résoudre. La plupart des plateformes résolvent ça en vous faisant penser à la topologie à l’avance. L’approche de Railyard est de faire résoudre la référence correctement peu importe la topologie, et de changer ce qu’il y a dessous à mesure que la topologie change.
Trois cas, une référence
Chaque application obtient <name>.railyard.internal, et ce que ce nom résout réellement dépend entièrement d’où l’autre application tourne par rapport à elle, pas de quoi que ce soit que l’application appelante doit savoir :
- Même serveur : c’est un alias de réseau Docker — se résout directement vers le conteneur sur son propre port. Aucune configuration, aucun réseau à mettre en place.
- Serveur différent, réseau privé désactivé : la référence fonctionne encore — elle n’est simplement pas privée. Elle se résout vers l’adresse publique
https://normale de l’application plutôt que d’échouer carrément. Une référence entre deux applications sur des serveurs différents se dégrade vers « fonctionne, mais sur l’internet public », plutôt que de casser. - Serveur différent, réseau privé activé : chaque serveur de l’équipe rejoint un maillage WireGuard chiffré (
10.210.0.0/16), et le même nom se résout maintenant vers où l’application tourne réellement, à travers les fournisseurs et les régions, routé sur le maillage plutôt que sur l’internet public.
La partie qui mérite réflexion : une application référençant ${{api.RAILYARD_PRIVATE_URL}} ne change pas quand quoi que ce soit de ça change. Déplacez api vers un autre serveur, attachez un serveur d’un fournisseur cloud complètement différent, activez le réseau privé pour la première fois — la référence continue de se résoudre, juste par un mécanisme différent chaque fois.
Pourquoi la dégradation gracieuse vaut mieux qu’une exigence stricte
L’alternative de conception — le réseau privé est obligatoire, ou les références échouent simplement jusqu’à ce qu’il soit configuré — serait plus « correcte » dans un sens abstrait et pire en pratique : une petite équipe sur un seul serveur n’a jamais besoin de réseau entre serveurs du tout, et ne devrait pas avoir à configurer un maillage WireGuard pour déployer deux applications qui se trouvent être au même endroit. Faire que la dégradation soit « fonctionne encore, sur HTTPS public » plutôt que « ne fonctionne pas jusqu’à ce que ce soit configuré » veut dire que la même configuration d’application est valide dès le premier jour avec un seul serveur et reste valide après avoir évolué vers cinq serveurs chez deux fournisseurs — rien à réécrire quand la topologie grandit.
Ce que l’activation change réellement
Serveurs → Réseau privé → Activer (admin seulement) est la seule action : chaque serveur déjà dans l’équipe rejoint le maillage, et les conteneurs déjà en cours d’exécution récupèrent le nouveau résolveur à leur prochain déploiement ou redémarrage — pas instantanément, ce qui compte si une référence est sensible à la latence et se résout actuellement sur l’internet public. À partir de ce moment, chaque serveur que l’équipe ajoute plus tard — chez n’importe quel fournisseur, dans n’importe quelle région — rejoint le même maillage automatiquement, puisque le maillage est une propriété de l’équipe, pas quelque chose reconfiguré par serveur.
Référence complète : Documentation réseau, Variables et secrets.