Konfigurasi nginx reload tanpa downtime

123

Saya menggunakan nginx sebagai proxy terbalik. Setiap kali saya memperbarui konfigurasi untuk menggunakannya

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

Saya menghadapi downtime singkat. Bagaimana saya bisa menghindarinya?

nginx

— Saurav Shah
sumber

1

Apakah itu dimaksudkan untuk menjadi perintah baris perintah? Saya belum pernah melihat orang membungkus seluruh perintah sudo dengan tanda kutip seperti itu, mungkin tidak perlu.

— brianmearns

4

Hanya komentar umum: Saya pikir praktik standar / yang disarankan adalah membuat tautan lunak / simbolis untuk konfigurasi situs Anda sites-enabled, bukan menyalinnya. Tidak terkait dengan masalah khusus Anda, tetapi Anda mungkin ingin melihatnya.

— brianmearns

1

Anda seharusnya tidak menghadapi downtime. kill HUPadalah cara untuk melakukan isi ulang yang anggun di nginx.

— Jonathan Vanasco

180

Jalankan service nginx reloadatau/etc/init.d/nginx reload

Ini akan melakukan reload panas dari konfigurasi tanpa downtime. Jika Anda memiliki permintaan yang tertunda, maka akan ada proses nginx yang tersisa yang akan menangani koneksi tersebut sebelum mati, jadi ini adalah cara yang sangat anggun untuk memuat ulang konfigurasi.

Terkadang Anda mungkin ingin menggunakannya sudo

— Hengjie
sumber

10

Keduanya harus melakukan persis apa yang dinyatakan oleh pertanyaan: kirim SIGHUPke proses master nginx. Seharusnya tidak ada perbedaan. nginx.org/en/docs/control.html

— Gnarfoz

Ketika saya mengeluarkan perintah pada CentOS ia terus mengatakan "Penggunaan /etc/init.d/nginx (start..stop ... restart..reload)" .. dan begitulah cara saya menggunakannya. Di dalam file /init.d/nginx saya temukan kill -HUP cat $PIDFILE|| gema -n "tidak bisa memuat ulang"

— mashup

1

Tahukah Anda apa perbedaan antara service nginx reloaddan nginx -s reload? Jika saya menjalankan yang pertama, saya mendapatkan output ini:, Reloading nginx configuration: nginx.tetapi perubahan saya tidak diperbarui. Jika saya menjalankan yang terakhir, saya tidak mendapatkan output, tetapi perubahan saya tercermin.

— Ryan Quinn

Saya baru saja mencoba ini setelah menambahkan log_not_foundarahan tetapi ternyata saya harus benar-benar melakukan restart untuk membuatnya bekerja. Saya kira memuat ulang tidak berfungsi untuk semua arahan?

— mydoghasworms

81

Lari /usr/sbin/nginx -s reload

Lihat http://wiki.nginx.org/CommandLine untuk opsi baris perintah lainnya.

— Shiv Kumar Sah
sumber

Akhirnya, sebuah perintah yang berfungsi di Debian Jessie.

— hazard89

1

Ini cara yang lebih baik. Karena server Anda tidak down jika konfigurasi Anda memiliki kesalahan (hanya menunjukkan kesalahan dalam hal ini).

— Mir-Ismaili

jika pid nginx default tidak di lokasi default, perlu '-p'. yaitu: `/ opt / gitlab / tertanam / sbin / nginx -s reload -p / var / opt / gitlab / nginx`

— qxo

9

Tidak, Anda salah, Anda tidak seharusnya menghadapi downtime dengan prosedur yang Anda jelaskan. (Nginx dapat melakukan tidak hanya konfigurasi reload on the fly tanpa downtime, tetapi bahkan upgrade executable on the fly, masih tanpa downtime.)

Sesuai http://nginx.org/docs/control.html#reconfiguration , mengirim HUPsinyal ke nginx memastikan bahwa ia melakukan restart dengan baik, dan, jika file konfigurasi salah, seluruh prosedur ditinggalkan, dan Anda ' kembali dengan nginx seperti sebelum mengirim HUPsinyal. Pada saat tidak ada downtime mungkin terjadi.

Agar nginx membaca kembali file konfigurasi, sinyal HUP harus dikirim ke proses master. Proses master pertama memeriksa validitas sintaksis, kemudian mencoba menerapkan konfigurasi baru, yaitu, untuk membuka file log dan soket mendengarkan baru. Jika gagal, ini mengembalikan perubahan dan terus bekerja dengan konfigurasi lama.

— cnst
sumber

2

Biasanya, memuat ulang file konfigurasi layanan tidak boleh memengaruhi layanan yang sedang berjalan. Namun, ini tergantung pada bagaimana SIGHUPsinyal diproses.

Jika layanan tertentu mengalami downtime saat memuat ulang, ini dapat dielakkan dengan menjalankan layanan yang sama di beberapa server, lebih disukai menggunakan penyeimbang beban. Dalam hal ini, Anda dapat mengeluarkan satu server sekaligus dan memuat ulang / memulai ulang. Kemudian, dapat ditambahkan kembali setelah mengonfirmasi itu OK.

— Khaled
sumber

Meskipun ini tidak secara langsung menjawab pertanyaan, ini jelas merupakan skenario praktik terbaik yang akan diikuti OP dengan cerdas untuk menghindari downtime secara umum.

— Andrew M.

1

Detail tentang bagaimana nginx menangani berbagai sinyal: nginx.org/en/docs/control.html

— Gnarfoz