introduction
Nginx est un puissant serveur Web et proxy inverse utilisé pour desservir de nombreux sites parmi les plus populaires au monde. Dans ce guide, nous montrerons comment mettre à niveau l’exécutable Nginx sur place sans perdre les connexions client.
Conditions préalables
Avant de commencer ce guide, vous devez avoir un utilisateur non root sur votre serveur, configuré avec les privilèges + sudo +. Vous devrez également avoir installé Nginx.
Si vous utilisez Ubuntu 14.04, vous pouvez apprendre à configurer un utilisateur avec les droits sudo + https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04 [ ici]. Vous pouvez installer Nginx en suivant this guide.
Si vous utilisez CentOS 7, vous pouvez vous y rendre en parcourant this guide pour le + sudo + utilisateur, suivi de this guide pour installer Nginx.
Comment fonctionne la mise à niveau
Nginx crée un processus maître au démarrage du service. Le service principal, à son tour, lance un ou plusieurs processus de travail qui gèrent les connexions client réelles. Nginx est conçu pour effectuer certaines actions lorsqu’il reçoit des signaux spécifiques de l’administrateur. L’utilisation de ces signaux vous offre la possibilité de mettre à niveau facilement Nginx ou sa configuration sur place, sans perdre les connexions client.
Certains scripts de service fournis par les responsables de package de distribution offriront cette possibilité d’utilisation avec les mises à niveau conventionnelles. Toutefois, la mise à niveau manuelle offre une plus grande souplesse dans l’approche et vous permet de procéder à un audit de la mise à niveau pour revenir rapidement en cas de problème. Cela fournira également une option de mise à niveau en douceur si vous avez installé Nginx à partir du code source ou si vous utilisez une méthode qui ne fournit pas cette fonctionnalité.
Les signaux suivants seront utilisés:
-
*
+ USR2 +*: Ceci génère un nouvel ensemble de processus maître / ouvrier sans affecter l’ancien. -
*
+ WINCH +*: Ceci indique au processus maître Nginx d’arrêter gracieusement ses instances de travail associées. -
*
+ HUP +*: Ceci indique à un processus maître Nginx de relire ses fichiers de configuration et de remplacer les processus de travail par ceux qui adhèrent à la nouvelle configuration. Si un ancien et un nouveau maître sont en cours d’exécution, son envoi à l’ancien maître engendrera des travailleurs utilisant leur configuration d’origine. -
*
+ QUIT +*: Ceci ferme un maître et ses ouvriers en douceur. -
*
+ TERM +*: Ceci déclenche un arrêt rapide du maître et de ses ouvriers. -
*
+ KILL +*: Ceci tue immédiatement un maître et ses ouvriers sans nettoyage.
Recherche des PID de processus Nginx
Afin d’envoyer des signaux aux différents processus, nous devons connaître le PID du processus cible. Il y a deux façons simples de trouver cela.
Tout d’abord, vous pouvez utiliser l’utilitaire + ps + puis + grep + pour Nginx parmi les résultats. C’est simple et vous permet de voir les processus maître et ouvrier:
ps aux | grep nginxoutputroot 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 10847 0.0 0.1 47936 1908 ? S 13:26 0:00 nginx: worker process
user 10961 0.0 0.0 112640 964 pts/0 S+ 13:53 0:00 grep --color=auto nginxLa deuxième colonne contient les PID pour les processus sélectionnés. Le PID du processus est mis en surbrillance. La dernière colonne précise que le premier résultat est un processus maître Nginx.
Un autre moyen de trouver le PID du processus maître Nginx consiste à imprimer le contenu du fichier + / run / nginx.pid +:
cat /run/nginx.pidoutputSi deux processus principaux Nginx sont en cours d’exécution, l’ancien sera déplacé vers + / run / nginx.pid.oldbin +.
Créer un nouveau groupe de maîtres / travailleurs Nginx
La première étape pour mettre à jour gracieusement notre exécutable consiste à mettre à jour votre binaire. Faites-le en utilisant la méthode appropriée pour votre installation Nginx, que ce soit par le biais d’un gestionnaire de packages ou d’une installation source.
Une fois que le nouveau fichier binaire est en place, vous pouvez générer un second ensemble de processus maître / ouvrier utilisant le nouvel exécutable.
Vous pouvez le faire en envoyant le signal + USR2 + directement au numéro de PID que vous avez interrogé (assurez-vous de remplacer ici le PID de votre propre processus maître Nginx):
sudo kill -s USR2Ou, vous pouvez lire et substituer la valeur stockée dans votre fichier PID directement dans la commande, comme ceci:
sudo kill -s USR2 `cat /run/nginx.pid`Si vous vérifiez vos processus actuels, vous verrez que vous avez maintenant deux ensembles de maîtres / travailleurs Nginx:
ps aux | grep nginxoutputroot 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 10847 0.0 0.1 47936 1908 ? S 13:26 0:00 nginx: worker process
root 0.0 0.3 47564 3132 ? S 13:56 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 11004 0.0 0.1 47936 1912 ? S 13:56 0:00 nginx: worker process
user 11031 0.0 0.0 112640 960 pts/0 S+ 14:01 0:00 grep --color=auto nginxVous pouvez également voir que le fichier original + / run / nginx.pid + a été déplacé vers + / run / nginx.pid.oldbin + et que le PID du processus maître plus récent a été écrit dans `+ / run / nginx.pid + `:
tail -n +1 /run/nginx.pid*output==> /run/nginx.pid <==
==> /run/nginx.pid.oldbin <==Vous pouvez maintenant envoyer des signaux à l’un des processus maîtres à l’aide des PID contenus dans ces fichiers.
À ce stade, les deux ensembles maître / travailleur sont opérationnels et capables de répondre aux demandes des clients. Le premier jeu utilise l’exécutable et la configuration d’origine de Nginx et le second utilise les versions les plus récentes. Ils peuvent continuer à fonctionner côte à côte, mais par souci de cohérence, nous devrions commencer à effectuer la transition vers le nouvel ensemble.
Fermer les ouvriers du premier maître
Pour commencer la transition vers le nouvel ensemble, la première chose à faire est d’arrêter les processus de travail du maître original. Les employés d’origine finiront par gérer toutes leurs connexions actuelles, puis sortiront.
Arrêtez les travailleurs de l’ensemble initial en envoyant le signal + WINCH + à leur processus maître:
sudo kill -s WINCH `cat /run/nginx.pid.oldbin`Cela permettra aux employés du nouveau maître de gérer seuls les nouvelles connexions client. L’ancien processus master sera toujours en cours d’exécution, mais sans aucun travailleur:
ps aux | grep nginxoutputroot 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
root 0.0 0.3 47564 3132 ? S 13:56 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 11004 0.0 0.1 47936 1912 ? S 13:56 0:00 nginx: worker process
user 11089 0.0 0.0 112640 964 pts/0 R+ 14:13 0:00 grep --color=auto nginxCela vous permet d’auditer les nouveaux employés car ils acceptent les connexions de manière isolée tout en conservant la possibilité de revenir à l’ancien exécutable si quelque chose ne va pas.
Évaluer le résultat et passer aux prochaines étapes
À ce stade, vous devez tester et auditer votre système pour vous assurer qu’il n’ya aucun signe de problème. Vous pouvez laisser votre configuration dans cet état aussi longtemps que vous voulez vous assurer que le nouvel exécutable Nginx est exempt de bogues et capable de gérer votre trafic.
Votre prochaine étape dépendra entièrement de l’éventualité de problèmes.
Si votre mise à niveau a réussi, terminez la transition
Si vous n’avez rencontré aucun problème avec les travailleurs de votre nouvel ensemble, vous pouvez arrêter en toute sécurité l’ancien processus principal. Pour ce faire, envoyez simplement à l’ancien maître le signal + QUIT +:
sudo kill -s QUIT `cat /run/nginx.pid.oldbin`L’ancien processus maître se terminera normalement, ne laissant que votre nouvel ensemble de maîtres / travailleurs Nginx. À ce stade, vous avez effectué avec succès une mise à jour binaire sur place de Nginx sans interrompre les connexions client.
Si les nouveaux travailleurs rencontrent des problèmes, revenez à l’ancien fichier binaire
Si votre nouvel ensemble de travailleurs semble avoir des problèmes, vous pouvez revenir à l’ancienne configuration et au mode binaire. Ceci est possible pendant la même session.
La meilleure façon de le faire est de redémarrer votre ancien maître en lui envoyant le signal + HUP +. Habituellement, lorsque vous envoyez le signal + HUP + à un maître Nginx, il relit ses fichiers de configuration et démarre de nouveaux ouvriers. Cependant, lorsque la cible est un ancien maître, il va simplement engendrer de nouveaux ouvriers en utilisant sa configuration de travail d’origine:
sudo kill -s HUP `cat /run/nginx.pid.oldbin`Vous devriez maintenant avoir à nouveau deux ensembles de processus maître / ouvrier:
ps aux | grep nginxoutputroot 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
root 0.0 0.3 47564 3132 ? S 13:56 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 11004 0.0 0.1 47936 1912 ? S 13:56 0:00 nginx: worker process
nginx 19918 0.0 0.1 47936 1900 ? S 14:47 0:00 nginx: worker process
user 19920 0.0 0.0 112640 964 pts/0 R+ 14:48 0:00 grep --color=auto nginxLes nouveaux travailleurs sont associés au vieux. Les deux postes de travail accepteront les connexions client à ce stade. Maintenant, arrêtez le nouveau processus maître bogué et ses ouvriers en envoyant le signal + QUIT +:
sudo kill -s QUIT `cat /run/nginx.pid`Vous devriez être de retour à votre ancien maître et vos ouvriers:
ps aux | grep nginxoutputroot 0.0 0.3 47564 3280 ? S 13:26 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 19918 0.0 0.1 47936 1900 ? S 14:47 0:00 nginx: worker process
user 19935 0.0 0.0 112640 964 pts/0 R+ 14:50 0:00 grep --color=auto nginxLe maître d’origine récupérera le fichier + / run / nginx.pid + pour son PID.
Si, pour une raison quelconque, ce qui précède ne fonctionne pas, vous pouvez simplement envoyer le signal + TERM + au nouveau serveur maître, ce qui devrait déclencher un arrêt. Cela devrait arrêter le nouveau maître et tous les travailleurs tout en lançant automatiquement l’ancien maître pour démarrer ses processus de travail. S’il y a des problèmes graves et que les préposés au buggy ne s’en vont pas, vous pouvez envoyer à chacun d’eux un signal + KILL + à nettoyer. Cela devrait être considéré comme un dernier recours, cependant, car cela coupera les connexions.
Après être revenu à l’ancien binaire, n’oubliez pas que la nouvelle version est toujours installée sur votre système. Vous devez supprimer la version boguée et revenir à votre version précédente afin que Nginx s’exécute sans problèmes au redémarrage.
Conclusion
À ce stade, vous devriez être en mesure de passer en toute transparence de vos machines d’un binaire Nginx à un autre. La capacité de Nginx à gérer deux ensembles maître / travailleurs tout en conservant des informations sur leurs relations nous permet de mettre à niveau le logiciel serveur sans mettre les ordinateurs du serveur hors ligne.