本文來自Rancher Labs
在以前關於CI/CD的文章中,咱們簡單討論了藍綠部署和金絲雀發佈以及它們在持續交付中所扮演的角色。這些都是十分有效的方法,可以大大下降與應用程序部署相關的風險。因此,這篇文章咱們來深刻介紹藍綠部署和金絲雀發佈。數據庫
藍綠部署和金絲雀發佈經過讓IT人員能夠在發佈過程當中發生問題時可以還原到先前版原本減輕應用程序部署的風險。這兩個方法讓版本之間來回切換就像輕按開關同樣容易,而且能夠自動執行,從而最大程度減小了用戶暴露在錯誤代碼的時間。在咱們更進一步討論這兩種方法以前,讓咱們先區分部署和發佈。
架構
雖然這兩個詞常常混淆使用,但實際上部署和發佈是兩個獨立的過程。部署是指在特定環境(包括生產環境)安裝指定軟件版本的過程,更可能是一種技術行爲。它不必定必須與發佈相關聯。而發佈則是指向客戶羣提供新功能,是一種業務決策。ide
傳統過程當中,會在發佈日期前一天部署好更新或是新功能,該更新或功能發佈後可能會在媒體中普遍傳播。衆所周知,在部署過程當中可能會出錯,而由於發佈時間與部署時間十分相近,所以幾乎沒有解決問題的空間。而若是將部署和發佈解耦,那麼在整個功能開發過程當中頻繁進行生產部署能夠下降IT部門的風險。那麼,要實現部署和發佈的解耦,須要代碼和架構可以知足新功能發佈不須要變動應用程序的代碼。
工具
在藍綠髮布過程當中,有兩套生產環境:藍環境和綠環境。藍色是當前版本並擁有實時流量,綠色是包含更新代碼的環境。不管任什麼時候候,只有一套環境有實時流量。性能
要發佈一個新版本,須要先將代碼部署到沒有流量的環境中,這是執行最終測試的地方。當IT人員確認應用程序已經準備就緒,就會將全部流量都將路由到綠色環境。那麼綠色環境就已經生效,而且執行發佈。
測試
這是新代碼首次在生產負載(實際流量)進行測試。在實際發佈代碼以前,風險仍然存在,而且永遠不會消失。可是,若是出現問題,IT部門能夠快速將流量從新路由回藍色版本。所以,他們所要作的就是密切監控代碼行爲,甚至可使用適當的工具將其自動化,以查看綠色環境中的版本是否運行良好或是否須要回滾。
藍綠部署:不管什麼時候,只有一套生產環境有實時流量
這種方法已經不是新方法了。IT部門總會建立一個新版本,而後將實時流量從新路由到該版本。而版本控制中經過組件編碼提供可靠性和可重複性是這一方法的亮點。
編碼
咱們應該如何得到可靠性和可重複性?開發人員將全部參數編入版本控制中,該版本控制是一個跟蹤全部代碼更改的系統,相似於數據庫。其中包括應用程序邏輯、構建過程、測試、部署過程、升級過程以及恢復過程等。總之,包含全部影響應用程序的因素。而後,計算機執行代碼,在相應的環境中部署應用程序,該環境與版本控制中編碼的exact state相匹配。版本控制
在DevOps出現以前,該流程一般是手動的,而且容易出錯。由於全部更改都只能記錄在文檔中,基於此,開發人員能夠從新建立應用程序和環境。因爲須要手動執行兩個關鍵步驟,所以此過程過於不可靠,從而致使頻繁出現問題。code
雖然將應用程序和環境進行編碼也是一項須要手動進行的任務,可是它畢竟只是開發過程的一部分,而不是單獨的工做,例如建立文檔。在版本控制中編入了與生產環境相同的代碼。任何更改或更新都將自動觸發測試,以確保代碼處於可部署狀態。這樣,若是出現人爲錯誤,系統也可以很快發現它。
blog
與藍綠部署相似,金絲雀發佈也是始於兩套環境:有實時流量的環境以及沒有實時流量但包含了更新的代碼的環境。與藍綠部署不一樣的是,流量是逐漸遷移到更新的代碼。一開始是1%,而後10%、25%,以此類推,直至100%。經過自動化發佈,當確認代碼可以正確運行時,它就能夠逐步推廣到更大、更關鍵的環境中。若是在任什麼時候候發生了問題,全部流量都會被回滾到以前的版本。這在很大程度上下降了風險,由於僅有一小部分用戶會使用到新的代碼。
IT不只能夠控制用戶部署的比例,並且金絲雀發佈還能夠從不過重要的用戶開始,例如使用免費帳戶的用戶或相對來講不過重要的業務市場。
金絲雀發佈:實時流量逐漸從舊版本遷移到新版本直到更新生效
Cluster Immune System可讓金絲雀發佈更進一步。它會鏈接到生產監控系統,當面向用戶的性能偏離預約義範圍(例如,錯誤率高出2%)時,將會自動回滾版本。這種方法能夠識別經過自動測試難以發現的錯誤,並減小了檢測和響應性能降低所需的時間。
經過將發佈與部署解耦並利用藍綠部署或金絲雀發佈,風險將會顯著下降。在任什麼時候候,IT都可以將應用程序回滾到以前的版本——這已經與傳統的應用程序發佈流程相去甚遠了。
新的技術和方法首次讓這一切成爲可能:版本控制、做爲代碼的基礎架構(Infrastructure as code)、容器和Kubernetes都能在這個嶄新的、靈活的、面向DevOps的IT世界中發揮着做用。