Nginx configurare reîncărcare fără timp de nefuncționare (Administrarea sistemului, Nginx)

Saurav Shah a intrebat.

Folosesc nginx ca un proxy invers. ori de câte ori actualizez configurația pentru el folosind

sudo "cp -r #{nginx_config_path}* /etc/nginx/sites-enabled/"
sudo "kill -s HUP `cat /var/run/nginx.pid`"

mă confrunt cu o scurtă perioadă de întrerupere. Cum pot evita acest lucru?

Comentarii

  • Sunt menite să fie comenzi în linie de comandă? Nu am văzut niciodată pe nimeni să înfășoare o întreagă comandă sudo în ghilimele așa, s-ar putea să nu fie necesar. –  > Por brianmearns.
  • Doar un comentariu general: Cred că practica standard/recomandată este de a crea o legătură soft/simbolică pentru configurația site-ului dvs. sub sites-enabled, și nu să o copiați. Nu are legătură cu problema dvs. particulară, dar este posibil să doriți să verificați acest lucru. –  > Por brianmearns.
  • Nu ar trebui să vă confruntați cu o perioadă de indisponibilitate. kill HUP este modalitatea de a face o reîncărcare grațioasă în nginx. –  > Por Jonathan Vanasco.
6 răspunsuri
Hengjie

Rulați service nginx reload sau /etc/init.d/nginx reload

Se va face o reîncărcare la cald a configurației fără timp de nefuncționare. Dacă aveți cereri în așteptare, atunci vor exista procese nginx care vor persista și care se vor ocupa de aceste conexiuni înainte de a muri, deci este o modalitate extrem de grațioasă de reîncărcare a configurațiilor.

Uneori, este posibil să doriți să adăugați în prealabil cu sudo

Comentarii

  • Ambele ar trebui să facă exact ceea ce spune întrebarea: trimiteți SIGHUP către procesul principal nginx. Nu ar trebui să existe nicio diferență. nginx.org/en/docs/control.html –  > Por Gnarfoz.
  • Când emit comanda pe CentOS, continuă să spună „Usage /etc/init.d/nginx (start..stop…restart..reload)” .. și exact așa am folosit-o. În cadrul fișierului /init.d/nginx am găsit kill -HUP cat $PIDFILE || echo -n ” can’t reload” –  > Por mashup.
  • știți care este diferența dintre service nginx reload și nginx -s reload? Dacă îl execut pe primul, obțin acest rezultat: Reloading nginx configuration: nginx., , dar modificările mele nu sunt actualizate. Dacă îl execut pe cel de-al doilea, nu obțin niciun rezultat, dar modificările mele sunt reflectate. –  > Por Ryan Quinn.
  • Tocmai am încercat acest lucru după ce am adăugat un log_not_found directivă, dar am constatat că a trebuit să fac o repornire pentru a o face să funcționeze. Presupun că reîncărcarea nu funcționează pentru toate directivele? –  > Por mydoghasworms.
  • Eu am timp de nefuncționare când fac asta. De exemplu, primesc semnale de tip 502 bad gateway, ceea ce distruge unele cereri. Rulez o versiune veche de nginx – nu sunt sigur dacă acesta este motivul –  > Por Mark.
Shiv Kumar Sah

Rulați /usr/sbin/nginx -s reload

Consultați http://wiki.nginx.org/CommandLine pentru mai multe opțiuni de linie de comandă.

Comentarii

  • În sfârșit, o comandă care funcționează în Debian Jessie. –  > Por danger89.
  • Aceasta este o modalitate mai bună. Deoarece serverul dvs. jos dacă configurațiile dvs. au erori (în acest caz arată doar erori). –  > Por Mir-Ismaili.
  • dacă pid-ul implicit al nginx nu se află în locația implicită , aveți nevoie de ‘-p’. adică: ` /opt/gitlab/embedded/sbin/nginx -s reload -p /var/opt/gitlab/nginx` –  > Por qxo.
cnst

Nu, sunteți incorect, nu ar trebui să vă confruntați cu niciun timp de nefuncționare cu procedura pe care o descrieți. (Nginx poate face nu numai reîncărcarea configurației din mers, fără niciun timp de nefuncționare, ci chiar și actualizarea executabilului din mers, tot fără niciun timp de nefuncționare).

Conform http://nginx.org/docs/control.html#reconfiguration, , trimiterea fișierului HUP semnal către nginx se asigură că acesta efectuează o repornire grațioasă și, dacă fișierele de configurare sunt incorecte, întreaga procedură este abandonată și rămâneți cu nginx ca înainte de a trimite semnalul HUP semnal. În niciun moment nu ar trebui să fie posibil vreun timp de nefuncționare.

Pentru ca nginx să citească din nou fișierul de configurare, trebuie trimis un semnal HUP către procesul principal. Procesul master verifică mai întâi validitatea sintaxei, apoi încearcă să aplice noua configurație, adică să deschidă fișiere de jurnal și noi socket-uri de ascultare. Dacă acest lucru eșuează, acesta anulează modificările și continuă să lucreze cu vechea configurație.

Selcuk

Pentru a fi completă, se adaugă la această listă și aplicația systemd mod de a face acest lucru:

systemctl reload nginx

Khaled

De obicei, reîncărcarea fișierului de configurare al unui serviciu nu ar trebui să afecteze serviciul în curs de execuție. Cu toate acestea, acest lucru depinde de modul în care se utilizează SIGHUP este procesat semnalul.

Dacă un anumit serviciu se confruntă cu un timp de nefuncționare în timpul reîncărcării, acest lucru poate fi ocolit prin rularea aceluiași serviciu pe mai multe servere, de preferință folosind un load balancer. În acest caz, puteți scoate din funcțiune câte un server pe rând și îl puteți reîncărca/reporni. Apoi, acesta poate fi reintrodus după ce se confirmă că este în regulă.

Comentarii

  • Deși acest lucru nu răspunde în mod direct la întrebare, acesta este cu siguranță un scenariu de bune practici pe care OP ar fi deștept să îl urmeze pentru a evita timpii de nefuncționare în general. –  > Por Andrew M..
  • Detalii despre modul în care nginx gestionează diferite semnale: nginx.org/en/docs/control.html –  > Por Gnarfoz.
Lirt

Nginx și semnalele

kill abordare pe care ați folosit-o (kill -s HUP $(cat /var/run/nginx.pid) este corectă. Scripturile de init pentru distribuțiile RH sau Debian sunt în cele din urmă implementate și ele folosind kill comanda. Puteți verifica Exemplul Init de pe site-ul web nginx sau conținutul din Pachetul Ubuntu Nginx.

Există mai multe semnale, pe care nginx le poate asculta (menționate în wiki):

  • TERM, , INT – Oprire rapidă.
  • QUIT – Oprire grațioasă.
  • KILL – Oprește un proces încăpățânat.
  • HUP – Reîncărcarea configurației. Pornește noile procese worker cu o nouă configurație. Oprește în mod grațios vechile procese lucrătoare.
  • USR1 – Redeschideți fișierele jurnal.
  • USR2 – Actualizați executabilul din mers.
  • WINCH – Opriți în mod grațios procesele de lucru.

Reîncărcarea Nginx

Reîncărcarea Nginx (HUP signal) este implementată mai exact ca mai mulți pași [1,2]:

  • Procesul master verifică validitatea sintaxei.
  • Aplică noua configurație, adică pentru a deschide fișiere de jurnal și noi socket-uri de ascultare.
  • Dacă acest lucru eșuează, anulează modificările și continuă să lucreze cu vechea configurație.
  • Dacă reușește, pornește noi procese de lucru și trimite mesaje către vechile procese de lucru solicitându-le să se închidă în mod elegant.
  • Vechile procese de lucru închid socket-urile de ascultare și continuă să deservească vechii clienți.
  • După ce toți clienții au fost deserviți, procesele de lucru vechi sunt închise.

Singura problemă la care mă pot gândi de ce ați avut timp de nefuncționare (pe baza procesului de reîncărcare) este că ați folosit un singur proces de lucru (worker_processes ), care, prin proiectare, deservea clienții vechi, dar care a închis socket-ul de ascultare, prin urmare nu ați putut deschide o nouă conexiune.

De asemenea, vă pot recomanda să utilizați întotdeauna /usr/sbin/nginx -t pentru a valida fișierele de configurare înainte de a aplica noua configurație.

Reîncărcarea Nginx în profunzime

Semnalul de reconfigurare este gestionat în fișierul ngx_process_cycle.c și putem vedea că pornește noi procese de lucru în funcția ngx_start_worker_processes(...) iar la sfârșit oprește procesele vechi de lucru în funcția ngx_signal_worker_processes(...), , care itera peste ele cu NGX_SHUTDOWN_SIGNAL semnal.

Resurse:

Comentarii

  • Deci, asta înseamnă că „nginx -s reload” nu repornește serviciul nginx (adică are ca rezultat un nou pid), ci doar instruiește serviciul nginx să își reîncarce configurația fără o repornire? Dacă am un container docker în care sunt atașat la procesul nginx cu „nginx -g ‘daemon off;’ „, atunci o reîncărcare nu ar ucide containerul meu? –  > Por Crine.
  • @Crine Nu, nu vă va ucide containerul. –  > Por Lirt.

Tags: