在本篇博文的姊妹篇《五步走戰略建立良好的持續交付流程》中，我們看到了高效能IT團隊如何採用Docker來實現持續交付（CD）的最佳實踐。其中，CD可以透過大量的部署方法實現，而Docker只是幫助實現必要的可定製的“基於工作流”的整合/構建過程的一種工具而已。
下麵，我們就四種主要的部署型別，來聊一聊它們各自的優缺點。
-
服務內最小部署
-
應用程式滾動部署
-
藍/綠部署
-
A / B測試
這四種部署型別又可分為兩個子類別：應用程式和基礎架構部署。
透過這種方法，我們指定了在更新剩餘百分比的同時保持在服務狀態的應用程式中的最小實體數，因此可以部署到盡可能多的標的。重覆此過程，直到所有伺服器都更新為新版本。
例如：如果我們有5個容器，每個容器執行我們當前的應用程式A，那麼我們設定我們的策略以保持繼續提供服務的數量最小為2。我們使3個伺服器離線，以將它們更新到我們的新版本B。一旦這些完成並正常對外提供服務，我們就可以更新剩下的2個了。
考慮將滾動部署作為最小服務內容的擴充套件。但是，我們並沒有定義應該保持聯機狀態的容器數量，而是指定最大數量的容器進行更新。
例如：我們有和前面一樣的5個容器，但是這次我們透過指定可以同時更新的容器的數量來初始化滾動更新，例如2個。這個過程一次移動兩個容器的更新，直到叢集中的所有伺服器被更新。
註意：Docker Swarm支援滾動更新。預設情況下是一次更新一個容器。也可以自定義，使用 -update-parallelism引數設定即可。
-
不用停機
-
可以暫停，允許有限的多版本測試
-
允許進行自動化測試——在繼續之前評估部署標的
當遵循藍/綠（又名紅/黑）方法時，我們短時間複製我們的“整個”基礎設施。複製的基礎架構託管新的應用程式，而舊的基礎架構繼續執行，直到測試完成並切到新的系統。這種部署方式已經存在很長一段時間，但在雲之前，這是一個非常昂貴的部署方法。現在，我們可以將系統部署到一個全新的環境中，從而實現獨立的評估，並且由於Cloud的原因，成本也將大大降低。一旦測試完成，我們將應用程式切換到新版本並關閉舊版系統。
如圖所示，藍色表示你當前的環境版本，而你要部署的新變體是“綠色”。通常，藍綠切換源於DNS的更改，儘管你也可以透過修改Auto Scaling來部署Blue / Green。
-
由於基礎設施不動，所以降低了風險
-
接近零停機，無需停服務
-
使用DNS更改時，交換機是乾凈的並受控制的
-
過程是完全自動化的，並提供一個更好的驗證視窗
-
在切換之前可以測試整個環境的健康和效能
A / B部署與Blue / Green幾乎完全相同，但是在這種方法中，我們只將少部分流量傳送到我們的新環境（綠色）。這種方法能夠切換環境，同時改變基礎設施，但比Blue / Green部署更精確。
-
與前述的部署方法相比，需要移動很多部件
-
更複雜，風險更高
-
需要完全自動化一切操作
-
我們可以提前預知規模和在生產中進行灰度釋出
-
用來測試新功能並逐步評估效能，穩定性和健康狀況
-
方便獲得客戶反饋，同時減少致命的影響和低階的錯誤
綜上所述，那生產上選擇哪種部署方法最合適呢？這取決於哪種方法最適合你的業務和技術需求。如果你的應用程式對使用者群強依賴，我們強烈建議盡可能利用A / B測試。
如果你希望將整個過程自動化，那麼我們希望邀請你檢視我們的SaaS平臺Caylent，以便在你的雲中部署應用程式（如WordPress）。我們的DevOps容器管理系統可以自動完成上面說的整個流程以及更多你需要的。
原文連結：https://dzone.com/articles/docker-amp-continuous-delivery-deployment-types
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球
