當你開始著手部署應用時,最簡單的方式莫過于使用管理員身份重啟my_app或者所有服務,使產品升級至當前版本。開始的時候一切都很好,但是最終你會發現一旦應用啟動以后,在重啟期間去嘗試連接會得到眾多HTTP 503 錯誤。
最后你可能發現Gunicorn和uWSGI可以在不關閉套接字的情況下重新加載你的應用,這樣在你的應用啟動時,網絡請求僅僅是被延時了一點點。只要你的應用不會花費很長時間在啟動上,它就會工作的很好。不幸的是,現有的許多應用可能會花費1分鐘的時間在啟動上,對于等待在套接字上的鏈接來說,這太長了。
Gunicorn使用kill -HUP $PID,通過關閉所有工作進程,然后再啟動它們來重新加載。但是工作進程緩慢的初始化過程往往會導致問題的產生。uWSGI使用鏈式重載,它每次只會啟動一個工作進程。我需要對Tornado的支持,它當前并不十分適合uWSGI。
使用負載均衡器
一種常見的技術是從負載均衡器中移除單個服務器,升級/重啟應用,然后再把它加載回來。我們正在使用負載均衡器,但是為了調度整個過程,在配置節點的時候需要協調使用HAProxy來管理套接字。我們當前的部署方案是同時部署到所有節點,而不是一個接一個的來,一個相當大的變化。在等待LBs(譯注:負載均衡器)將節點移出池期間,可以使用404'ing狀態頁來欺騙healthcheck。這比我想要的時間要多一點,對于每個服務器來說,兩次healthcheck失敗間隔5秒鐘,這包括了升級完成后web進程恢復的時間。
Gunicorn 重載 ++
Gunicorn會自動重啟失敗的web進程,所以它可能會殺掉每個進程,在其間休眠,直到所有的子進程執行完畢。這很有效,不過如果應用啟動的次數變動顯著的話,我們要么會為重啟等待過長時間,要么會等待不長的時間并承擔一些故障宕機的風險。
因為Gunicorn包含了指向應用的Python鉤子,所以完全可能寫出一小段代碼,在工作進程準備就緒的時候通知重啟進程。Gunicorn并不包含需要的鉤子,但做出改變非常簡單。在新版本發布前它需要一些修改。
現在重啟進程發揮了這樣的事實優勢,就是說單個的soket具有接受連接的多個進程。重啟只會極微弱的減少服務能力(1/N),但我們因此可以繼續處理流量而無需讓連接等待過長時間。
這種進程一般是這樣的
1
2
3
|
for child_pid of gunicorn - master: kill child_pid wait for app startup |
我的第一個版本使用shell和nc來監聽應用啟動的UDP數據包。盡管將我們的進程管理器集成到shell環境比我預想的要麻煩一點,但它工作的很好。
重啟腳本被調用的時候應該帶上Gunicorn的PID,就是masterrestart.sh的 $PID
1
2
3
4
5
6
7
8
9
10
11
12
13
|
echo 'Killing children of ' $ 1 ; children = $(pgrep - P $ 1 ) for child in $children do echo 'Killing' $child kill $child response = $(timeout 60 nc - w 0 - ul 4012 ) if [ "$response" ! = '200 OK' ]; then echo 'BROKEN' exit 1 ; fi done |
在串聯上post_worker_init腳本,以便app運行的時候通知重啟腳本。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
import socket import time def post_worker_init(worker): _send_udp( '200 OK\n' ) def _send_udp(message): udp_ip = "127.0.0.1" udp_port = 4012 sock = socket.socket(socket.AF_INET, # Internet socket.SOCK_DGRAM) # UDP sock.sendto(message, (udp_ip, udp_port)) 如果我們有這樣一個WSGI( Python Web Server Gateway Interface)應用: from werkzeug.wrappers import Request, Response @Request .application def application(request): resp = Response( 'Hello World!' ) if request.path = = '/_status' : resp.status = '200 OK' else : resp.status = '404 Not Found' return resp |
我們甚至可以去做檢查/_status頁面之類的事情,以此來驗證應用是否已運行。
1
2
3
4
5
6
7
8
9
|
def post_worker_init(worker): env = { 'REQUEST_METHOD' : 'GET' , 'PATH_INFO' : '/_status' , } def start_response( * args, * * kwargs): _send_udp(args[ 0 ]) worker.wsgi(env, start_response) |
注意不要試圖在這個健康檢測中運行太多的應用,如果不管什么原因你的post_worker_init產生了一個錯誤,那么工作進程將會退出,并阻止應用的啟動。在你檢查可能失效的DB鏈接的時候這會是一個問題,即使你的應用可以工作,它也無法再次啟動。
現在通過一分鐘的應用啟動,我們實現了滾動重啟,而無需停止應用或者丟棄任何鏈接!