Web應用部署方式

Question

目前，我們的產品是 web 應用程序，其中 SQL 服務器作為 DBMS，ASP.NET 后端和經典的 HTML/JavaScript/CSS 前端。 該產品正在積極開發中，每個月我們都必須將其新版本部署到生產環境中。

在此部署期間，我們更新了上面列出的所有組件（應用一些 SQL 腳本、更新二進制文件和客戶端文件），但我們僅部署了增量（自上次發布以來更改的文件集）。 它有一些好處，比如我們不會重置自定義數據/配置/客戶端調整。

現在我們將在 Azure、AWS 等雲內部移動。調整產品架構以兼容 Docker/Kubernetes 並將產品作為 SaaS 提供。

現在是問題本身：“在雲中推薦哪種部署方法？” 我們可以繼續只應用增量嗎？ 還是我們必須重新組織流程以始終從頭開始部署？

如果有一些我錯過的互聯網資源，請分享。

Answer 1

這個問題非常廣泛，但也許一些澄清可以引導你朝着正確的方向前進：

源代碼部署（如應用增量）和容器部署是兩個非常不同的方向，因為您在整個 SLDC 期間投資的工具可能存在很大差異。 一些測試管道/產品主要（或專門）專注於與其中一個或另一個一起工作。 當然會有工具可以同時處理這兩種情況。

他們在試圖解決的問題上也有所不同，並帶有一些優點和缺點：

源代碼部署/應用差異：

• 適合小型團隊和快速部署，因為它們易於理解和設置。
• 當您需要升級主機操作系統或應用程序依賴項時開始引入風險
• 當主機在生產中開始漂移（具有比預期更多的不同文件）隨着時間的推移變得更加顯着時，開始引入風險

Slack在這里很好地記錄了他們的經歷。

容器部署

• 提供與應用程序（開發人員空間）和主機操作系統（系統管理員/操作空間）的隔離。 這通常意味着他們可以獨立地相互合作。
• 給出一個在部署之間不會改變的“工件”，即標記為 v1 的容器將始終相同，除非您做一些非常時髦的事情。 你不能真正保證這一點
• 隔離無狀態組件的做法使自動縮放這些組件變得非常容易，並且您最終可以將更多時間花在更難的組件上（通常是有狀態的）。
• 引入了一個新的抽象，其中包含您的團隊必須成熟的新問題。 測試管道、開發工具、監控/登錄架構可能都需要隨着時間的推移進行調整，這會帶來成本和風險。
• 有狀態的容器幾乎不是一個已解決的問題（即，將現有數據庫放入容器中可能是一個令人驚訝的挑戰）。

為了使用 Kubernetes，您需要有一個容器化的應用程序。 這並不意味着您需要在一夜之間將整個產品容器化。 拆分前端以使用 cloudfront/s3 進行部署，並將無狀態應用程序容器化將讓您大吃一驚。

一些談論 devops 哲學的書（這種轉變在其中發揮了作用）

Devops 手冊

加速

有效的 DevOps

SRE 書