Đảm bảo một quy trình luôn chạy


23

Tôi bắt đầu lưu trữ các trang web một thời gian trước bằng cách sử dụng Cherokee. Đối với các nguồn bên ngoài (FastCGI, v.v.), nó có tùy chọn để khởi chạy quy trình nếu không thể tìm thấy một nguồn chạy trên ổ cắm hoặc cổng được chỉ định. Điều này thật tuyệt vời bởi vì điều đó có nghĩa là nếu PHP hoặc một trang Django bị đổ (như họ thỉnh thoảng làm) thì nó sẽ tự động khởi động lại.

Trên máy chủ mới sử dụng PHP-FPM, tôi không thể sử dụng Cherokee (nó có lỗi với PHP) vì vậy tôi đã chuyển sang NGINX. Tôi thực sự thích NGINX (vì phong cách cấu hình của nó) nhưng tôi gặp vấn đề nghiêm trọng với các quá trình xảy ra và không bao giờ hồi sinh. PHP làm điều này đôi khi nhưng các trang web Django là một vấn đề. Tôi đã tạo các tập lệnh init cho chúng và chúng khởi động nhưng điều này không giúp tôi nếu chúng chuyển đổi giữa các lần khởi động lại.

Tôi đoán tôi đang tìm kiếm một proxy FastCGI. Một cái gì đó, như Cherokee, biết những quy trình nào nên được chạy trên ổ cắm / cổng nào và đáp ứng chúng theo yêu cầu. Có một điều như vậy tồn tại? Có cách nào để xây dựng cái này thành NGINX (để dễ cấu hình) không?

Câu trả lời:


13

Làm thế nào về daemontools và cụ thể là công cụ giám sát

giám sát giám sát một dịch vụ. Nó khởi động dịch vụ và khởi động lại dịch vụ nếu nó chết. Thiết lập một dịch vụ mới rất dễ dàng: tất cả các nhu cầu giám sát là một thư mục có tập lệnh chạy dịch vụ.


+1 cho daemontools. Tuy nhiên, bạn thường không thể ném một kịch bản như thế /etc/init.d/apachectlvào nó. Bạn thường cần phải viết lại kịch bản khởi động đơn giản của riêng bạn để sử dụng exec. Mặc dù tôi rất thích xem thêm một số ví dụ sử dụng daemontools
Stefan Lasiewski

daemontools có một hóa thân khác là runit. Bây giờ không quá quan trọng rằng daemontools là miền công cộng, nhưng một bản phân phối cũ hơn có thể chỉ có runit.
camh


5

Tôi thứ hai daemontoolsgợi ý, nhưng nếu bạn không thích cách phần mềm của DJB hoạt động (vì bất kỳ lý do gì), thì cũng có supervisord.

Tôi đã thiết lập một hình ảnh FreeBSD trước đây được sử dụng supervisordđể quản lý nginxgunicorntôi đã sử dụng để lưu trữ một số ứng dụng WSGI đơn giản và toàn bộ quá trình này khá đơn giản.

Nếu bạn đang làm điều này cho Django, Gunicorn thực sự đơn giản để triển khai các ứng dụng Django, btw. Xem bài đăng trên blog này để biết thêm chi tiết.


4

Một lựa chọn khác có thể là sử dụng monit , đó là cách tôi thường sử dụng.


3

Bạn đã xem xét godchưa?

Chúa là một cấu hình dễ dàng để cấu hình, dễ dàng mở rộng khung giám sát được viết bằng Ruby.

Giữ cho các quy trình và tác vụ máy chủ của bạn chạy là một phần đơn giản trong quy trình triển khai của bạn. Thiên Chúa đặt mục tiêu trở thành ứng dụng giám sát đơn giản nhất, mạnh mẽ nhất hiện có.

Tôi sử dụng nó để đảm bảo rằng nếu các trường hợp Rails / nginx bị đổ, chúng sẽ được hồi sinh và mặc dù tôi không thấy hỗ trợ tích hợp để kiểm tra xem nó có sử dụng đúng cổng hay không, nhưng nếu vấn đề là quá trình thất bại hoặc không còn chạy, bạn không thể đi sai với god.



0

Một giải pháp hackish sẽ là định kỳ khởi chạy một tập lệnh (thông qua cron) để phát hiện ra nếu quá trình không hoạt động, và trong trường hợp này khởi chạy lại nó.


0

Có nhiều cách khác nhau để khởi động lại một daemon thất bại, khuyến nghị thông thường là "hồi sinh trong inittab" nhưng với một số xem xét về giới hạn nếu máy thực sự bị vặn.

Trình nền giám sát cũng có thể theo dõi một quá trình thông qua tệp PID của nó. Tuy nhiên, đó chỉ nên được coi là một tuyến phòng thủ thứ cấp để khởi động lại một cỗ máy quá ốm để chạy đúng cách (ví dụ như hết bộ nhớ, ném bom, v.v.), chứ không phải là cách chính hoặc theo dõi và khởi động lại một daemon.

Cuối cùng, bạn có thể xem xét giám sát các hệ thống phức tạp bằng cách sử dụng nagios để cung cấp cho người quản trị một cái nhìn toàn cầu. Nó có thể chạy các trình cắm để thăm dò hoạt động của daemon bên ngoài, đây là một thử nghiệm đầy đủ hơn về chức năng của nó, đơn giản là bộ vi xử lý đang hoạt động.


-1

Câu trả lời đơn giản - bắt đầu, viết pid của bạn ở đâu đó và mỗi lần x (giây, phút, đặt cược của bạn) kiểm tra xem quá trình đã kết thúc chưa.

Câu trả lời dài - tất cả các phương pháp trên là phương pháp tốt. Nhưng hơi phức tạp.

Cũng nên nhớ rằng sống và trả lời các yêu cầu là những điều khác nhau.


1
Chặt và bắt chéo ngón tay của bạn và hy vọng rằng không có gì viết nguệch ngoạc trên tệp PID, hoặc xóa nó hoặc sử dụng lại nó cho một trình nền khác, hoặc chỉ lại nó vào một quy trình vô tội và không liên quan khác sẽ không phản ứng tốt với kiểm tra vì đã lên Đó là lý do tại sao câu trả lời dài của người giám sát daemon thích hợp chạy daemon như các tiến trình con và giám sát chúng bằng các cơ chế hệ thống Unix / Linux thông thường là cách tốt hơn được chấp nhận từ lâu.
JdeBP
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.