Comprendre F5 · NGINX

NGINX : validation, reload et cycle des processus

Distinguer fichier modifié, test syntaxique, rechargement et comportement effectivement servi par les workers NGINX.

Thomas SAUTIER · Publié le · Révisions de certification

Références et objectifs de certification (2)

Ce guide concerne NGINX Open Source. Vérifiez la version, les modules compilés ou chargés et les particularités de votre paquet.

Une modification sur disque n’est pas un changement servi

Le master gère les workers et reçoit les signaux de contrôle. Une modification de fichier prépare un état ; elle ne remplace pas automatiquement la configuration des workers. Le test de configuration et le rechargement sont deux opérations distinctes, suivies d’une observation du service.

nginx -t contrôle la syntaxe et l’ouverture des fichiers requis selon les règles documentées. Ce test ne démontre pas le fonctionnement métier de l’application ou la disponibilité de tous les upstreams. Une validation réussie doit être suivie d’une recette représentative.

Les signaux de contrôle distinguent également l’arrêt rapide et l’arrêt gracieux. Dans la commande nginx -s, stop demande un arrêt rapide et quit un arrêt gracieux. Ne remplacez pas un reload par un stop/start sans analyser l’impact sur les échanges en cours et le gestionnaire de services.

Comprendre en imagevalidation, reload et cycle des processus
validation, reload et cycle des processus Le test précède le rechargement. Le master lance de nouveaux workers tandis que les anciens terminent leurs échanges ; la recette confirme le comportement. Objets, conditions et comparaisons du guide Fichier état préparé Test syntaxe et fichiers Master application tentée Nouveaux nouveaux échanges Anciens fin des échanges Recette service observé Une modification sur disque n’est pasun changement servi Le master gère les workers et reçoit les signauxde contrôle. Une modification de fichier prépareun état ; elle ne remplace pas automatiquementla configuration des workers. Le test deconfiguration et le rechargement sont deuxopérations distinctes, suivies d’une observationdu service. Comprendre le rechargement gracieux Lors d’un rechargement, le master vérifie et tented’appliquer la nouvelle configuration. Sil’opération réussit, de nouveaux workers sontlancés et les anciens terminent leurs échangesselon le cycle documenté. Les connexions longuesdoivent être examinées dans le plan demaintenance.

Le test précède le rechargement. Le master lance de nouveaux workers tandis que les anciens terminent leurs échanges ; la recette confirme le comportement.

Télécharger le schéma en SVG · version claire

Sources : NGINX / F5, Controlling nginx ; NGINX / F5, Command-line parameters.

Comprendre le rechargement gracieux

Lors d’un rechargement, le master vérifie et tente d’appliquer la nouvelle configuration. Si l’opération réussit, de nouveaux workers sont lancés et les anciens terminent leurs échanges selon le cycle documenté. Les connexions longues doivent être examinées dans le plan de maintenance.

Les commandes ci-dessous modifient le service uniquement après un test réussi. Utilisez l’outil de gestion propre à votre installation si elle est pilotée par un gestionnaire de services. Vérifiez que la commande cible le bon binaire, le bon fichier et la bonne instance.

Recharger uniquement après validation réussieBash · changement en laboratoire
sudo nginx -t && sudo nginx -s reload

Sources : NGINX / F5, Controlling nginx ; NGINX / F5, Command-line parameters.

Prévoir observation et retour arrière

Conservez une version connue de la configuration, l’état avant changement et une requête de recette. Après rechargement, vérifiez le journal, les workers et le comportement attendu. La fin de la commande ne remplace pas ces observations, notamment si plusieurs instances ou conteneurs sont présents.

Un retour arrière consiste à rétablir une configuration appropriée, la valider puis l’appliquer par la procédure prévue. Il ne répare pas automatiquement une dépendance externe devenue indisponible. Distinguez erreur de configuration, permissions et panne d’un backend avant de relancer plusieurs fois le service.

Sources : NGINX / F5, Controlling nginx ; NGINX / F5, Module ngx_http_log_module.

Exercice : test réussi, réponse inchangée

Une configuration est valide mais la requête reçoit toujours l’ancienne réponse. Vérifiez instance, inclusion, signal, journal et sélection du server. Imaginez aussi une connexion longue encore prise en charge par un ancien worker ; elle ne signifie pas nécessairement que le reload a échoué.

Notez chaque étape : préparation du fichier, validation, application et vérification du service. Cet exemple ne provient pas d’un test sur serveur. Une commande réussie ne suffit pas à confirmer que le service utilise la nouvelle configuration.

Sources : NGINX / F5, Controlling nginx ; NGINX / F5, Module ngx_http_core_module.

Sources et portée

Les dates de consultation et les versions applicables sont précisées pour chaque référence ci-dessous. Les exemples utilisent des noms et adresses de documentation à remplacer. Les commandes de lecture affichent l’existant ; les captures et requêtes de diagnostic sont à limiter au périmètre autorisé.

Retrouver le parcours de lecture F5 NGINX

Continuer la série F5

Explorer tous les guides du parcours F5 NGINX

Découvrir l’expertise F5 de Samhan

Échange

Besoin d’éclaircir votre architecture F5 ?

Échangeons sur vos flux, vos contraintes de disponibilité et vos services applicatifs.