Réseau

Au-delà des domaines publics et des règles par requête de Règles de périphérie, les applications doivent aussi se parler en privé, et parfois passer derrière un CDN tiers ou obtenir un seul certificat pour tout un domaine générique. Cette page couvre ces trois sujets.

Réseau privé entre applications

Chaque application reçoit un nom privé, <name>.railyard.internal, au lieu que les applications se trouvent par IP publique :

• Même serveur : le nom est un alias du réseau Docker, donc il résout directement vers le conteneur sur le port de l’application (container_port). Aucune configuration n’est nécessaire.
• Serveur différent, réseau privé désactivé : une référence vers l’autre application fonctionne quand même, elle n’est simplement pas privée — elle résout vers l’adresse publique normale https:// de cette application plutôt que d’échouer.
• Serveur différent, réseau privé activé : activez-le depuis Servers → Private network → Turn on (admins). Chaque serveur de l’équipe rejoint un réseau WireGuard chiffré (10.210.0.0/16), et <name>.railyard.internal résout alors, depuis n’importe quel serveur de l’équipe, vers l’endroit où l’application tourne réellement — par le réseau privé, vers son port publié. Le canvas dessine ce lien comme privé. Les conteneurs déjà en cours d’exécution récupèrent le nouveau résolveur à leur prochain déploiement ou redémarrage.

Référencez un autre service avec ${{api.RAILYARD_PRIVATE_URL}} (pour une application nommée api) plutôt que de codifier un nom d’hôte en dur — voir Variables et secrets. Elle se résout selon celui des cas ci-dessus qui s’applique, donc la même référence continue de fonctionner si les deux applications finissent plus tard sur des serveurs différents.

Plus de ports publics

Settings → General → More public ports accepte un name:port par ligne (par ex. metrics:9100) pour un second protocole ou une interface d’administration sur la même application. Chacun reçoit sa propre adresse HTTPS — <name>-<app-hostname> — routée et certifiée de la même façon que l’adresse principale de l’application.

Cloudflare devant une application

Settings → Networking → Cloudflare met le CDN, la protection DDoS et le WAF de Cloudflare devant l’adresse de plateforme d’une application, quand l’adresse de cette application est déjà sur le DNS géré de Railyard et que ce DNS tourne sur Cloudflare (pas Route 53, et pas un domaine personnalisé dont Railyard ne détient pas la zone — la carte explique quel cas s’applique).

• L’activer met l’enregistrement DNS en proxy la prochaine fois que Railyard l’écrit — au prochain déploiement ou à un basculement, pas instantanément.
• Le proxy de périphérie fait confiance aux plages IP publiées de Cloudflare et lit l’IP réelle du visiteur depuis CF-Connecting-IP, donc la limitation de débit, le blocage par pays, le WAF et les logs d’accès continuent de voir le vrai visiteur plutôt que la périphérie de Cloudflare une fois que l’application active ceci — voir Règles de périphérie.
• HTTPS continue de fonctionner : le certificat Let’s Encrypt de Railyard est toujours émis et servi à l’origine. Réglez le mode SSL de Cloudflare sur Full (strict), qui vérifie ce certificat plutôt que de faire confiance à ce que l’origine présente.
• Vous devez encore pointer vous-même les serveurs de noms de ce domaine vers Cloudflare — Railyard n’écrit jamais que le seul enregistrement DNS qu’il gère déjà, jamais les serveurs de noms d’une zone.

Certificats génériques par DNS-01

Un domaine générique (*.example.com, voir Domaines) utilise par défaut le TLS à la demande : chaque sous-domaine reçoit son propre certificat Let’s Encrypt à la première visite, donc 20 sous-domaines veulent dire 20 certificats. Pour un seul certificat couvrant tout le domaine générique à la place :

1. Team settings → DNS credentials → ajoutez un jeton API Cloudflare (limité à Zone:DNS:Edit pour la zone, pas la clé API globale) ou une clé d’accès Route 53 (route53:ChangeResourceRecordSets et route53:ListResourceRecordSets sur la zone hébergée). Stocké chiffré, utilisé seulement pour le défi DNS-01.
2. Dans l’onglet Domains de l’application, ajouter ou modifier une adresse générique affiche une liste déroulante DNS credential. Choisissez-en une pour demander un seul certificat générique; laissez-la vide pour garder le comportement à la demande.

Supprimer une clé fait revenir ses domaines génériques aux certificats à la demande plutôt que de les casser.

Trafic sortant

Les connexions sortantes d’une application partent de l’IP publique de son propre serveur — il n’y a pas de pool NAT partagé, et pas de frais supplémentaires pour une adresse stable à donner à la liste blanche d’une API tierce, contrairement à une plateforme multi-locataire. L’IP ne change que si l’application elle-même déménage vers un autre serveur.

Voir aussi

• Domaines — l’adresse par défaut, les domaines personnalisés et la vérification de propriété.
• Règles de périphérie — règles par requête : redirections, en-têtes, CORS, limitation de débit, blocage par pays, le WAF.
• Variables et secrets — référencer l’URL privée d’un autre service.
• Ajouter un serveur — activer le réseau privé.