Nội dung
- Yêu cầu - Cách thức hoạt động của nâng cấp - Tìm PID tiến trình Nginx - Tạo ra một bộ Nginx Master / worker mới - Đóng cửa các công nhân đầu tiên của ông chủ - Đánh giá kết quả và thực hiện các bước tiếp theo - Kết luận

Thứ hai, 15/06/2015 | 00:00 GMT+7

Cách nâng cấp Nginx tại chỗ mà không làm rớt kết nối client

Nginx là một web server mạnh mẽ và Reverse Proxy được sử dụng để phục vụ nhiều trang web phổ biến nhất trên thế giới. Trong hướng dẫn này, ta sẽ trình bày cách nâng cấp file thi hành Nginx tại chỗ mà không làm mất kết nối client .

Yêu cầu

Trước khi bắt đầu hướng dẫn này, bạn nên có một user không phải root trên server của bạn , được cấu hình với các quyền sudo . Bạn cũng cần phải cài đặt Nginx.

Nếu bạn đang sử dụng Ubuntu 14.04, bạn có thể tìm hiểu cách cài đặt user có quyền sudo tại đây . Bạn có thể cài đặt Nginx theo hướng dẫn này .

Nếu bạn đang sử dụng CentOS 7, bạn có thể cài đặt bằng cách chạy qua hướng dẫn này cho user sudo , tiếp theo là hướng dẫn này để cài đặt Nginx.

Cách thức hoạt động của nâng cấp

Nginx hoạt động bằng cách tạo ra một quy trình chính khi dịch vụ bắt đầu. Dịch vụ chính, đến lượt nó, khởi động một hoặc nhiều quy trình công nhân xử lý các kết nối client thực tế. Nginx được thiết kế để thực hiện các hành động nhất định khi nhận được tín hiệu cụ thể từ administrator . Sử dụng các tín hiệu này cung cấp cho bạn cơ hội dễ dàng nâng cấp Nginx hoặc cấu hình của nó tại chỗ mà không làm mất kết nối client .

Các tập lệnh dịch vụ nhất định được cung cấp bởi những người bảo trì gói phân phối sẽ cung cấp khả năng này để sử dụng với các bản nâng cấp thông thường. Tuy nhiên, nâng cấp theo cách thủ công mang lại sự linh hoạt hơn trong cách tiếp cận và cho phép bạn kiểm tra nâng cấp để hoàn nguyên nhanh chóng nếu có sự cố. Điều này cũng sẽ cung cấp một tùy chọn để nâng cấp một cách duyên dáng nếu bạn đã cài đặt Nginx từ nguồn hoặc sử dụng phương pháp không cung cấp khả năng này.

Các tín hiệu sau sẽ được sử dụng:

USR2 : Điều này tạo ra một tập hợp các quy trình chính / công nhân mới mà không ảnh hưởng đến tập hợp cũ.
WINCH : Điều này cho biết quy trình chính của Nginx dừng một cách duyên dáng các version worker liên quan của nó.
HUP : Điều này yêu cầu một quy trình chính của Nginx đọc lại các file cấu hình của nó và thay thế các quy trình của worker bằng những quy trình tuân theo cấu hình mới. Nếu một cái cũ và mới đang chạy, việc gửi cái này đến cái cũ sẽ sinh ra các nhân viên sử dụng cấu hình ban đầu của chúng.
QUIT : Điều này làm tắt một cách duyên dáng chủ và các công nhân của nó.
TERM : Điều này bắt đầu tắt server và công nhân của nó nhanh chóng.
KILL : Điều này ngay lập tức giết chủ và công nhân của nó mà không cần dọn dẹp.

Tìm PID tiến trình Nginx

Để gửi tín hiệu đến các quá trình khác nhau, ta cần biết PID cho quá trình đích. Có hai cách dễ dàng để tìm thấy điều này.

Trước tiên, bạn có thể sử dụng ps tiện ích và sau đó grep cho Nginx trong các kết quả. Điều này rất đơn giản và cho phép bạn xem quy trình chính và quy trình công nhân:

ps aux | grep nginx

output
root     10846  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 nginx

Cột thứ hai chứa các PID cho các quy trình đã chọn. Đánh dấu là PID cho quy trình. Cột cuối cùng làm rõ rằng kết quả đầu tiên là một quy trình tổng thể Nginx.

Một cách khác để tìm PID cho tiến trình Nginx chính là in ra nội dung của file /run/nginx.pid :

cat /run/nginx.pid

output
10846

Nếu có hai quy trình chính Nginx đang chạy, quy trình cũ sẽ được chuyển đến /run/nginx.pid.oldbin .

Tạo ra một bộ Nginx Master / worker mới

Bước đầu tiên để cập nhật file thực thi của ta một cách duyên dáng là thực sự cập nhật file binary của bạn. Thực hiện việc này bằng bất kỳ phương pháp nào phù hợp với cài đặt Nginx của bạn, cho dù thông qua trình quản lý gói hay cài đặt nguồn.

Sau khi có bản binary mới, bạn có thể tạo ra một bộ quy trình chính / công nhân thứ hai sử dụng file thực thi mới.

Bạn có thể thực hiện việc này bằng cách gửi tín hiệu USR2 trực tiếp đến số PID mà bạn đã truy vấn (đảm bảo thay thế PID của quy trình chính Nginx của bạn tại đây):

sudo kill -s USR2 10846

Hoặc, bạn có thể đọc và thay thế giá trị được lưu trữ trong file PID của bạn trực tiếp vào lệnh, như sau:

sudo kill -s USR2 `cat /run/nginx.pid`

Nếu bạn kiểm tra các quy trình hiện tại của bạn , bạn sẽ thấy rằng bạn hiện có hai bộ Nginx master / worker:

ps aux | grep nginx

output
root     10846  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     11003  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 nginx

Bạn cũng có thể thấy rằng file /run/nginx.pid root đã được chuyển đến /run/nginx.pid.oldbin và PID của quy trình chính mới hơn đã được ghi vào /run/nginx.pid :

tail -n +1 /run/nginx.pid*

output
==> /run/nginx.pid <== 11003  ==> /run/nginx.pid.oldbin <== 10846

Đến đây bạn có thể gửi tín hiệu đến một trong các quy trình chính bằng cách sử dụng PID có trong các file này.

Đến đây, cả bộ master / worker đều hoạt động và có khả năng phục vụ các yêu cầu của khách hàng. Tập hợp đầu tiên đang sử dụng cấu hình và file thực thi Nginx ban đầu và tập hợp thứ hai sử dụng các version mới hơn. Chúng có thể tiếp tục hoạt động song song, nhưng để nhất quán, ta nên bắt đầu chuyển sang bộ mới.

Đóng cửa các công nhân đầu tiên của ông chủ

Để bắt đầu chuyển đổi sang tập hợp mới, điều đầu tiên ta có thể làm là dừng các quy trình công nhân của chủ nhân ban đầu. Các công nhân ban đầu sẽ hoàn thành việc xử lý tất cả các kết nối hiện tại của họ và sau đó thoát ra.

Dừng công nhân của bộ ban đầu bằng cách phát tín hiệu WINCH cho quy trình chính của họ:

sudo kill -s WINCH `cat /run/nginx.pid.oldbin`

Điều này sẽ cho phép các công nhân của bậc thầy mới xử lý các kết nối khách hàng mới một mình. Quy trình tổng thể cũ sẽ vẫn chạy, nhưng không có nhân công:

ps aux | grep nginx

output
root     10846  0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf root     11003  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 nginx

Điều này cho phép bạn kiểm tra các nhân viên mới khi họ chấp nhận các kết nối một cách tách biệt trong khi vẫn duy trì khả năng hoàn nguyên về file thực thi cũ nếu có điều gì đó không ổn.

Đánh giá kết quả và thực hiện các bước tiếp theo

Bạn nên kiểm tra và kiểm tra hệ thống của bạn tại thời điểm này đảm bảo rằng không có dấu hiệu của sự cố. Bạn có thể để cấu hình của bạn ở trạng thái này miễn là bạn muốn đảm bảo rằng file thực thi Nginx mới không có lỗi và có thể xử lý lưu lượng truy cập của bạn.

Bước tiếp theo của bạn sẽ hoàn toàn phụ thuộc vào việc bạn có gặp sự cố hay không.

Nếu nâng cấp của bạn thành công, hãy hoàn thành quá trình chuyển đổi

Nếu bạn không gặp sự cố nào với công nhân của bộ mới, bạn có thể tắt quy trình chính cũ một cách an toàn. Để thực hiện việc này, chỉ cần gửi cho server cũ tín hiệu QUIT :

sudo kill -s QUIT `cat /run/nginx.pid.oldbin`

Quy trình chính cũ sẽ thoát một cách duyên dáng, chỉ để lại tập hợp chính / công nhân Nginx mới của bạn. Đến đây, bạn đã thực hiện thành công cập nhật binary tại chỗ của Nginx mà không làm gián đoạn các kết nối client .

Nếu Công nhân mới gặp vấn đề, hãy hoàn nguyên về hệ binary cũ

Nếu group công nhân mới của bạn dường như đang gặp sự cố, bạn có thể chuyển đổi trở lại cấu hình cũ và binary . Điều này có thể xảy ra trong cùng một phiên.

Cách tốt nhất để làm điều này là khởi động lại các công nhân cũ của bạn bằng cách gửi cho nó tín hiệu HUP . Thông thường, khi bạn gửi tín hiệu HUP chính của Nginx, nó sẽ đọc lại các file cấu hình của nó và bắt đầu các công nhân mới. Tuy nhiên, khi mục tiêu là một master cũ hơn, nó sẽ chỉ sinh ra các worker mới bằng cách sử dụng cấu hình hoạt động ban đầu của nó:

sudo kill -s HUP `cat /run/nginx.pid.oldbin`

Đến đây bạn sẽ quay lại có hai bộ quy trình chính / công nhân:

ps aux | grep nginx

output
root     10846  0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf root     11003  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 nginx

Công nhân mới nhất được liên kết với công nhân cũ. Cả hai group công nhân sẽ chấp nhận kết nối client tại thời điểm này. Bây giờ, hãy dừng quy trình tổng thể mới hơn, có lỗi và các công nhân của nó bằng cách gửi tín hiệu QUIT :

sudo kill -s QUIT `cat /run/nginx.pid`

Bạn sẽ trở lại với chủ cũ và công nhân của bạn :

ps aux | grep nginx

output
root     10846  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 nginx

Bản root ban đầu sẽ lấy lại file /run/nginx.pid cho PID của nó.

Nếu cách trên không hoạt động vì bất kỳ lý do gì, bạn có thể thử chỉ gửi cho server chính mới tín hiệu TERM , tín hiệu này sẽ bắt đầu tắt máy. Thao tác này sẽ dừng chế độ chủ mới và bất kỳ công nhân nào trong khi tự động đá qua chế độ chính cũ để bắt đầu các quy trình công nhân của nó. Nếu có vấn đề nghiêm trọng và nhân viên sửa lỗi không thoát ra ngoài, bạn có thể gửi cho từng người trong số họ một tín hiệu KILL để dọn dẹp. Tuy nhiên, đây nên được xem là phương sách cuối cùng vì nó sẽ cắt đứt các kết nối.

Sau khi chuyển đổi trở lại hệ binary cũ, hãy nhớ rằng bạn vẫn cài đặt version mới trên hệ thống của bạn . Bạn nên xóa version có lỗi và quay lại version trước của bạn để Nginx sẽ chạy mà không gặp sự cố khi khởi động lại.

Kết luận

Bây giờ, bạn có thể chuyển đổi liền mạch các máy của bạn từ hệ binary Nginx này sang hệ binary Nginx khác. Khả năng của Nginx để xử lý hai tập hợp chủ / công nhân trong khi duy trì thông tin về mối quan hệ của họ cung cấp cho ta khả năng nâng cấp phần mềm server mà không cần sử dụng server offline .

Tags:

Các tin liên quan

Cách cấu hình Nginx để sử dụng các trang lỗi tùy chỉnh trên Ubuntu 14.04
2015-06-05
Cách cấu hình Nginx để sử dụng các trang lỗi tùy chỉnh trên CentOS 7
2015-06-05
Cách chuyển hướng www sang không có www với Nginx trên CentOS 7
2015-05-04
Cách chuyển hướng www thành không có www với Nginx trên Ubuntu 14.04
2015-05-04
Cách triển khai ứng dụng Rails với Puma và Nginx trên Ubuntu 14.04
2015-04-01
Cách triển khai ứng dụng Rails với Unicorn và Nginx trên Ubuntu 14.04
2015-03-26
Cách cung cấp ứng dụng flask với Gunicorn và Nginx trên CentOS 7
2015-03-23
Cách cung cấp các ứng dụng Flask với Gunicorn và Nginx trên Ubuntu 14.04
2015-03-20
Cách cung cấp các ứng dụng Flask với uWSGI và Nginx trên CentOS 7
2015-03-20
Cách cung cấp các ứng dụng Flask với uWSGI và Nginx trên Ubuntu 14.04
2015-03-19