Dépannage de l'ingress

L’objectif lors d’un incident est de rétablir le service public sans détruire l’état qui explique la panne. L’ingress traverse plusieurs frontières de responsabilité — DNS, réseau, certificat, configuration nginx, politique de la Route, transport privé et exécution de l’application —, si bien que modifier plusieurs couches à la fois allonge généralement la durée de la panne.

Désignez un responsable de l’incident, consignez le dernier changement réputé sain et vérifiez de l’extérieur vers l’intérieur. Le succès signifie que le comportement externe est rétabli, que l’état souhaité et l’état signalé dans Opfield concordent, et que la couche en échec et l’action de reprise sont suffisamment consignées pour éviter que le problème ne se reproduise.

Suivez cet ordre pour éviter de modifier la mauvaise couche :

1. DNS : résolvez le nom d’hôte depuis un client externe et confirmez qu’il pointe vers le nœud ingress attribué.
2. Réseau : confirmez la joignabilité publique sur 80/443 et les règles de pare-feu de l’hôte.
3. TLS : examinez le nom d’hôte du certificat, la chaîne, l’expiration et l’état de distribution.
4. Configuration nginx : vérifiez que la dernière révision est appliquée et que la validation de la configuration a réussi.
5. Santé de la Route : examinez le code et le corps attendus ainsi que l’état de maintenance.
6. Upstream : testez l’application depuis le nœud nginx ou examinez la santé du Secure Link.
7. Journaux : corrélez les journaux d’accès et d’erreurs nginx avec les journaux de la charge de travail et les identifiants de requêtes.

Les erreurs courantes comprennent un placement du domaine et de la Route sur des nœuds différents, un DNS externe obsolète après une migration, HTTP-01 sur un nœud sans port 80 public, une application WebSocket sans transmission WebSocket, et la sélection d’un port de charge de travail qui n’est en réalité ni publié ni lié.

Guide des symptômes

Symptôme	Couche la plus probable	Premiers éléments à examiner
Le nom d’hôte ne se résout pas	DNS	Résolution externe A/AAAA et placement du domaine
Délai de connexion dépassé	réseau	Adresse publique, pare-feu, ports 80/443, disponibilité du nœud
Avertissement de certificat	TLS	Nom d’hôte du certificat, chaîne, expiration et Route attribuée
La poignée de main TLS échoue immédiatement	correspondance de Route	Aucune Route activée sur ce nœud ne sert le nom d’hôte ; le nœud refuse ces poignées de main au lieu de répondre avec le site d’une autre Route
404 immédiat	correspondance de Route	Nom d’hôte, préfixe de chemin, état d’activation, configuration brute
503 géré	maintenance ou upstream défaillant	État de maintenance et historique de santé
502/504	transport vers l’upstream	Secure Link, port cible, santé de la charge de travail, paramètres de délais
Déconnexions WebSocket	transmission du protocole	Option WebSocket, chemin applicatif, délais du proxy et de lecture
Les modifications n’apparaissent jamais	application/réconciliation	état de la tâche, révision nginx, connexion du nœud, erreur de validation ; une modification refusée échoue avec 422 NGINX_CONFIG_FAILED et indique la sortie de nginx -t
502 d’une Route Docker en Raw Config Mode	configuration brute	La configuration brute doit continuer à faire proxy vers l’upstream Secure Link de la Route ; voir Routes
502 d’un Deployment	routeur du Deployment	L’en-tête X-Opfield-Deployment-Router: upstream-unavailable signifie que le routeur n’a pas pu joindre le slot actif

Recueillir les éléments avant de modifier l’état

Consignez le nom d’hôte en échec, le chemin, l’heure, la catégorie d’IP du client, la réponse attendue, la réponse réelle, le nœud attribué, l’identifiant de la Route, l’identifiant de la dernière tâche et l’identifiant de requête pertinent. Conservez l’erreur de validation de la configuration générée et des journaux limités avant de réessayer ; des modifications répétées peuvent effacer les éléments les plus utiles.

Comparez trois vues :

1. l’état souhaité dans Opfield, dans les détails de la Route et du domaine ;
2. le dernier état acquitté par le nœud nginx ;
3. le comportement DNS, TLS et HTTP observé de l’extérieur.

Une divergence entre ces vues indique si la panne relève de l’état du plan de contrôle, de l’application sur le nœud ou de l’infrastructure externe.

Les échecs de Secure Link sont journalisés une fois par lien, et non une fois par requête. Le démon nginx du nœud Ingress consigne un avertissement proxy secure-link connections failing avec le link_id, le dernier relais, l’étape et l’erreur lorsqu’un lien commence à échouer, still failing avec un décompte toutes les 5 minutes, une ligne d’information lorsque des requêtes ne réussissent qu’après des relances, et recovered avec le nombre de requêtes en échec et relancées à la première connexion propre. Le démon Docker de la cible consigne de la même manière les tunnels entrants en échec, par propriétaire de point de terminaison (relay endpoint tunnels), et séparément les refus sur des routes révoquées (relay endpoint tunnels on revoked routes). Les détails par tentative sont au niveau debug.

Reprise en toute sécurité

• Ne corrigez le DNS qu’après avoir confirmé le placement prévu du nœud.
• Corrigez l’attribution d’un certificat plutôt que de désactiver TLS globalement.
• Corrigez la validation de la configuration avant de forcer une nouvelle application.
• Utilisez le mode maintenance lorsque l’application doit rester indisponible pendant la réparation.
• Ne relancez la réconciliation qu’une fois saine la dépendance à l’origine de la panne.
• Revenez en arrière sur l’application ou la configuration de la Route lorsqu’une révision réputée saine existe.

Ne supprimez pas et ne recréez pas le domaine, le certificat ou la Route en première réponse. Cela détruit l’historique des relations et peut provoquer une seconde panne.

Vérification de la reprise

Testez depuis un client externe, puis confirmez le nom d’hôte canonique, la chaîne de certificats, le code de réponse, le corps, les redirections, les WebSockets, l’historique de santé et les journaux nginx. Ne clôturez l’incident que lorsque le comportement public et l’état d’Opfield concordent.

Retour arrière par couche en échec

Le retour arrière doit annuler le plus petit changement à l’origine de la panne. Pour le DNS, rétablissez les valeurs d’adresses consignées en tenant compte des caches des résolveurs. Pour TLS, rétablissez l’attribution du certificat valide précédent sans désactiver HTTPS. Pour la configuration nginx, revenez aux derniers paramètres gérés réputés sains et attendez l’acquittement. Pour une régression applicative, revenez en arrière sur le Deployment ou la révision Compose propriétaire plutôt que de réécrire la Route autour d’une version défectueuse.

Les échecs de Secure Link exigent de rétablir la connectivité de Relay et des nœuds ou l’exécution de la cible ; modifier le DNS ou les certificats ne peut pas les réparer. Les échecs de politique d’accès exigent de rétablir l’Access List précédente ou l’interprétation des proxys de confiance, et non d’ouvrir le port de la charge de travail. Le mode maintenance est utile pendant la réparation de ces couches, car il garde le nom d’hôte et le chemin TLS explicites tout en empêchant le trafic d’atteindre par accident une application partiellement rétablie.

Éléments pour l’escalade

Lorsque la première tentative de reprise n’explique pas la panne, rassemblez un ensemble limité d’éléments avant d’escalader :

• les identifiants du domaine et de la Route, le nœud Ingress attribué et la dernière révision de configuration acquittée ;
• les réponses DNS externes et les détails du certificat TLS observés au moment de l’incident ;
• l’historique de santé de la Route et le chemin, la méthode, le code et l’horodatage exacts en échec ;
• les entrées pertinentes des journaux d’accès et d’erreurs nginx et l’opération de la charge de travail ou du Secure Link propriétaire ;
• les versions des nœuds et de Relay, l’état de connectivité et le message de la dernière tâche en échec ;
• la dernière révision réputée saine de l’application, de la Route et du DNS.

Masquez les identifiants, cookies, en-têtes d’autorisation, clés privées et valeurs de requête sensibles. L’objectif est de préserver la causalité sans transformer l’enregistrement d’incident en coffre à secrets.