Docker應用程序實時升級

Question

我是新來的docker，並且在涉及docker時設計一個簡單的實時升級解決方案時遇到一些問題。要求時

• 舊服務器fork()孩子：目前我使用一個fork()/exec()基於模式的應用程序實時升級。
• 子服務器exec()新的可執行文件，加載新的數據/配置。
• 舊服務器將必要的信息（套接字，內存數據等）傳遞給子級服務器，以便它可以接管服務。
• 舊的服務器在孩子準備好後將停止處理新的請求（舊服務器不會exit() ATM）。
• 如果升級成功，手動停止舊服務器（這可以在未來升級直播之前被延遲，直到不久），否則停止子服務器，並通知舊服務器重新啓動處理請求。

正如您所看到的，這種實時升級策略通常不會造成停機，無論升級是否失敗。

我們的大部分服務都是無狀態或者有非常簡單的狀態，所以上面的圖案可以輕鬆實現，這是非常可靠的。

我的問題是如何在Docker中實現上述模式（或類似的東西）？也許我走錯了方向，我都是耳朵。

Answer 1

當你的服務已經無狀態的，並在同一時間處理舊的連接和新的連接，也可以爲你服務，使用你的服務的前負載平衡器和某種形式的滾動升級策略是什麼可能最適合。

fork方法不適合Docker和容器背後的想法。 Docker鏡像及其結果容器應始終包含運行該服務所需的所有內容。另外，如果另一個容器基於相同的圖像啓動，它應該始終啓動完全相同的服務。

在基於叉升級的解決方案，二進制文件/容器內的可執行程序將初始啓動後更改。這意味着如果出於任何原因您決定啓動基於同一圖像的另一個容器，它將不會運行相同版本的服務。當然，您可以添加一些圖片，以便在啓動時自動升級到最新版本，但這會使部署複雜化。在我看來，這會違反Docker世界中太多的書面和不成文的規則，我會考慮這種不好的做法。

我有這樣的感覺，樸素的Docker對於你想使用它的東西是不夠的。我建議你看看更高級的容器編排解決方案，它提供了諸如服務負載均衡和滾動更新等功能。當人們有這些更高級的要求時，Kubernetes是我腦中總是首先想到的東西。

通過引入Deployment對象，Kubernetes獲得關於更新策略了大量的電能。您應該通讀Kubernetes Deployments。如果與適當的健康檢查一起使用，Deployment的滾動更新策略應該會爲您提供所需的一切，包括回滾失敗的部署。

Kubernetes的缺點是需要更多的努力來設置和維護羣集。但取決於您的應用程序的大小，基礎設施和服務的數量，這可能是值得的。