Vue d'ensemble de l'ingress

Opfield utilise des nœuds nginx gérés comme ingress public. Un service public complet combine un domaine, un certificat, une Route, un upstream, une politique de santé et un placement sur un nœud.

Les Routes peuvent faire office de proxy, rediriger ou renvoyer 404. Les upstreams de proxy peuvent être des adresses manuelles, des conteneurs autonomes, des Deployments, des services Compose ou des tags Pages prêts. Les Additional Routes rattachent des préfixes de chemin littéraux, comme /api, à des upstreams distincts.

Utilisez le mode nginx managed lorsque Opfield doit détenir une configuration de base réputée saine. Utilisez le mode integrate lorsqu’une installation nginx existante doit conserver sa configuration de base et charger des fichiers inclus gérés par Opfield.

Sur le plan opérationnel, vérifiez le DNS, la distribution des certificats, la validation de la configuration générée, la santé de la Route et le comportement public après chaque changement de placement ou de TLS. Une configuration n’est pas terminée simplement parce qu’elle a été enregistrée avec succès.

Propriété des ressources

Les ressources d’ingress ont des cycles de vie distincts, même lorsqu’elles apparaissent comme une seule application publique :

• un domaine détient le nom d’hôte et le placement nginx ;
• un certificat SSL détient le matériel du certificat et l’état de renouvellement ;
• une Route détient le comportement des requêtes, la politique de santé et son upstream principal ;
• une Additional Route détient un remplacement de préfixe de chemin littéral ;
• une Access List est une politique réutilisable qui peut être rattachée à plusieurs Routes ;
• un Secure Link appartenant à une Route suit la Route et ne peut pas être retiré indépendamment.

Supprimer une ressource ne doit pas supprimer silencieusement une autre ressource réutilisable. Avant une suppression, examinez les ressources liées et décidez si l’action voulue est une désactivation, une maintenance, un détachement, une migration ou un retrait définitif.

Ordre de création recommandé

1. Enrôlez et validez le nœud Ingress cible.
2. Enregistrez le domaine et confirmez son placement prévu.
3. Émettez ou téléversez le certificat TLS.
4. Créez la Route et sélectionnez son upstream.
5. N’ajoutez une politique d’accès, des en-têtes, des WebSockets, des réécritures ou des délais personnalisés que si nécessaire.
6. Activez la Route et attendez la validation de la configuration nginx.
7. Testez HTTP et HTTPS depuis un client externe.
8. Confirmez l’historique de santé, les journaux d’accès et la distribution des certificats.

Règles d’exploitation sûres

• Gardez un seul propriétaire canonique pour chaque nom d’hôte ; ne créez pas de Routes concurrentes pour le même hôte hors d’Opfield.
• Considérez la configuration nginx brute comme une échappatoire réservée aux experts. Elle désactive certaines fonctionnalités de validation et de cycle de vie gérées.
• Ne publiez pas un port de charge de travail privée simplement parce qu’un Secure Link est temporairement défaillant.
• Utilisez le mode maintenance pour les interventions délibérées visibles par les clients, et ne désactivez une Route que lorsque le trafic doit s’arrêter complètement.
• Migrez le placement via le processus explicite afin que les domaines, les Routes, les certificats, l’état de santé et les changements DNS restent coordonnés.

Responsabilités d’Opfield et de l’opérateur

Opfield valide et distribue la configuration nginx, suit le placement souhaité, gère les processus de certificats pris en charge et enregistre les opérations qui modifient le trafic public. Il ne contrôle pas un fournisseur DNS externe, sauf si une intégration configurée détient cette zone, n’ouvre pas de pare-feu en amont et ne rend pas prête une application défaillante. Ces dépendances restent de la responsabilité de l’opérateur.

Cette distinction est importante pendant les incidents. Un nœud Ingress sain prouve que le démon et nginx sont disponibles ; il ne prouve pas que le DNS public pointe vers ce nœud, que chaque Route a un upstream joignable ni qu’un réseau externe laisse passer le trafic. À l’inverse, l’échec d’une vérification de santé applicative n’exige pas de reconstruire l’hôte nginx. Diagnostiquez la chaîne de ressources depuis le nom d’hôte public vers l’application et ne modifiez que la couche en échec.

Pour la propriété en production, consignez qui peut modifier le DNS, les certificats, les Routes, les Access Lists et les publications applicatives. Gardez un accès d’urgence à Opfield indépendant du nom d’hôte de l’application exploitée. Examinez les certificats et Access Lists partagés avant de les modifier, car une seule modification peut affecter plusieurs Routes.

Recette de production

Avant de déclarer un nom d’hôte prêt, vérifiez-le depuis un réseau extérieur aux hôtes gérés. Confirmez les réponses DNS, le comportement de redirection HTTP, la chaîne de certificats HTTPS et le nom d’hôte, la réponse applicative attendue et le comportement WebSocket le cas échéant. Comparez ensuite cette requête avec l’historique de santé d’Opfield et les journaux d’accès nginx.

Lorsque c’est possible, gardez disponibles le placement DNS ou la révision applicative précédents pendant une bascule. Si la recette échoue, rétablissez l’upstream ou le placement réputés sains plutôt que de supprimer les nouvelles ressources. La suppression retire un état souhaité et un historique d’opérations utiles, et constitue rarement le retour arrière le plus sûr.

Poursuivez avec Domaines, Routes et TLS pour la configuration, Upstreams sécurisés pour les cibles Docker privées et Dépannage de l’ingress pour le diagnostic des échecs.