Publier votre première Route

Une Route relie un ou plusieurs noms d’hôte publics à une application via un nœud Ingress. Dans le cas simple, vous choisissez le domaine, l’application et le port, activez TLS et enregistrez ; Opfield construit la configuration nginx et l’applique sur le nœud Ingress.

Le critère de réussite est une requête HTTPS qui se résout vers le nœud Ingress attribué, présente le certificat prévu, atteint l’application prévue et reste observable et réversible. Ne considérez pas un formulaire enregistré comme une publication réussie.

Comprendre les ressources en jeu

Opfield sépare les responsabilités :

• Un domaine enregistre le nom d’hôte et son placement sur l’ingress.
• Un certificat SSL fournit le matériel TLS et porte la responsabilité du renouvellement.
• Une Route définit le comportement de redirection, d’accès, de maintenance et de santé.
• Un upstream est l’application qui reçoit la requête. Il peut s’agir d’une adresse saisie manuellement, d’une ressource Docker gérée par Opfield et jointe via Secure Link, ou d’un déploiement Pages sélectionné via un tag.

Cette séparation vous permet de changer de révision d’application sans recréer le DNS ni le certificat. Elle implique aussi que ces quatre éléments doivent concorder avant que la route soit prête pour la production.

Avant de créer la Route

Vérifiez que :

• un nœud Ingress est Online, détient l’adresse de service publique prévue et peut accepter les ports 80/443 si nécessaire ;
• l’application existe et répond sur le schéma et le port choisis ;
• le nom d’hôte est approuvé et le responsable de son DNS est disponible ;
• un certificat correspondant est actif ou un chemin d’émission clair existe ;
• l’opérateur a la permission de créer le domaine, de sélectionner le certificat et de créer la Route ;
• le chemin de santé attendu, le code de réponse, le besoin en WebSocket, les limites de requêtes et la politique d’accès sont connus.

Si l’upstream est privé, décidez si la Route doit utiliser un Secure Link géré par Opfield. Un Secure Link fait transiter le trafic par le plan de données Relay sans publier de port d’hôte ordinaire uniquement pour l’ingress. Il ne répare pas une application défaillante et ne contourne pas la responsabilité des charges de travail.

Publier la Route

1. Ouvrez Routes, puis l’onglet Domains, et ajoutez le nom d’hôte.
2. Attribuez-le au nœud Ingress qui recevra le trafic public.
3. Configurez le DNS via l’intégration Cloudflare ou créez l’enregistrement DNS externe requis. Attendez que la réponse faisant autorité pointe vers l’adresse de service prévue.
4. Ouvrez Certificates, puis l’onglet SSL, et émettez, importez ou sélectionnez un certificat qui couvre le nom d’hôte exact ou un wildcard approprié.
5. Ouvrez Routes et choisissez Add Route.
6. Sélectionnez le domaine et la cible de redirection. Pour une cible Docker gérée, sélectionnez la ressource et le port de l’application ; Opfield gère le cycle de vie du Secure Link.
7. Sélectionnez HTTP ou HTTPS pour l’upstream selon ce que l’application sert réellement. Ce paramètre est indépendant de la terminaison TLS publique.
8. Activez le TLS public et sélectionnez le certificat. Activez Force HTTPS lorsque le HTTP en clair doit rediriger au lieu de servir du contenu.
9. N’activez la prise en charge de WebSocket que si l’application utilise des connexions avec upgrade. N’appliquez une Access List, une politique de débit ou un modèle personnalisé que si le service l’exige et que le modèle est réputé compatible.
10. Enregistrez la Route et attendez qu’Opfield produise, valide et applique la configuration nginx.

Vérifier le résultat

Vérifications côté utilisateur

• Le DNS public se résout vers l’adresse Ingress attribuée depuis plusieurs réseaux.
• La réponse HTTPS présente un certificat de confiance qui couvre le nom d’hôte.
• La page applicative ou la réponse d’API attendue est renvoyée.
• HTTP redirige vers HTTPS lorsque Force HTTPS est activé.
• La connexion dans le navigateur, les rappels (callbacks), les réponses en streaming et les WebSockets fonctionnent lorsque l’application les utilise.

Vérifications dans Opfield

• La Route est activée et son état de santé correspond à une vérification directe de l’application.
• La cible affichée est la ressource et le port que vous vouliez, et non un conteneur obsolète ou une adresse manuelle.
• Le nœud Ingress signale une configuration nginx appliquée valide.
• Les journaux d’accès et d’erreurs montrent la requête de test et aucun échec répété de l’upstream.
• L’exécution du Secure Link est saine lorsque la cible l’utilise.
• L’Access List et les contrôles de débit admettent et refusent les clients attendus.

Une réponse applicative correcte ne prouve pas que la politique est correcte. Testez un chemin autorisé et un chemin refusé lorsque des contrôles d’accès sont en place, et testez une vraie connexion WebSocket plutôt que la seule poignée de main HTTP initiale.

Modes de défaillance et reprise

Le DNS se résout mal : corrigez l’enregistrement faisant autorité et attendez l’expiration normale des caches. Ne modifiez pas la cible de la Route pour compenser une erreur DNS.

Le certificat est refusé : vérifiez la couverture du nom d’hôte, la chaîne, la période de validité et le déploiement sur le nœud Ingress sélectionné. Ne désactivez pas la vérification TLS dans les clients pour contourner le problème.

Opfield ne peut pas appliquer la configuration nginx : examinez l’erreur de validation avant de réessayer. Un modèle personnalisé, une option incompatible, un nom d’hôte en double ou une cible managée indisponible peuvent rendre la configuration souhaitée invalide. Opfield conserve la maîtrise du dernier état appliqué ; corrigez l’entrée plutôt que de modifier directement les fichiers nginx générés.

La cible du Secure Link est indisponible : vérifiez que la charge de travail et les nœuds concernés sont en ligne et que Relay est sain. Publier un port de conteneur comme contournement d’urgence modifie le modèle de sécurité et doit être un changement délibéré et revu.

Une mauvaise version est en ligne : activez la maintenance de la Route si c’est pertinent, ou ramenez l’upstream sur le dernier Deployment, la dernière empreinte d’image, la dernière révision Compose ou le dernier tag Pages réputés sains. La Route et le certificat n’ont normalement pas besoin d’être supprimés pour un retour arrière applicatif.

Pour une explication plus approfondie des cibles privées, poursuivez avec Upstreams sécurisés. Pour un processus complet, de la charge de travail à l’URL publique, consultez Publier une application.