Web应用程序部署方法

Question

当前，我们的产品是一个Web应用程序，具有SQL Server作为DBMS，ASP.NET后端以及经典的HTML / JavaScript / CSS前端。该产品正在积极开发中，每个月我们都必须将其新版本部署到生产中。

在此部署期间，我们更新了上面列出的所有组件（应用了一些SQL脚本，更新二进制文件和客户端文件），但仅部署了增量（自上一发行版以来已更改的文件集）。它具有一些好处，例如我们不重置自定义数据/配置/客户端调整。

现在，我们将在Azure，AWS等云内部迁移。调整产品架构以使其与Docker / Kubernetes兼容，并以SaaS的形式提供产品。

现在的问题是：“建议在云中使用哪种部署方式？”我们可以仅应用增量吗？还是我们必须重新组织流程以始终从头开始部署？

如果我错过了一些Internet资源，请分享。

Answer 1

这个问题非常广泛，但是也许您可以通过一些澄清将问题引向正确的方向：

在整个SLDC可以投资的工具上，CAN可以大不相同，因此源代码部署（如应用增量）和容器部署是两个非常不同的方向。一些测试管道/产品将重点（或排他性地）放在与另一方的合作上。当然会有一些工具可以处理这两种情况。

他们在尝试解决的问题上也有所不同，并附带了一些优缺点：

源代码部署/应用差异：

• 易于理解和设置，非常适合小型团队和快速部署。
• 当您需要升级主机操作系统或应用程序依赖项时开始引入风险
• 当主机的生产开始随时间推移而更加剧烈地波动时（开始有更多与预期不同的文件），这会带来风险

Slack对他们的经历here有很好的记录。

容器部署

• 提供与应用程序（开发人员空间）和主机操作系统（sysadmin / ops空间）的隔离。这通常意味着他们可以相互独立地工作。
• 给出在部署之间不会更改的“工件”，即标记为v1的容器将始终相同，除非您做的事情确实很时髦。您不能真的保证
• 隔离无状态组件的做法使自动缩放这些组件变得非常容易，最终您可以将更多时间用于较难的组件（通常是有状态的）上。
• 引入了一个新的抽象，它包含了您的团队必须成熟的新问题。测试管道，开发工具，监视/登录体系结构可能都需要随着时间的推移而进行调整，这会带来成本和风险。
• 有状态的容器很难解决（例如，将现有数据库放入容器中可能是一个令人惊讶的挑战）。

为了使用Kubernetes，您需要一个容器化的应用程序。这并不意味着您需要在一夜之间将整个产品包装起来。拆分前端以使用cloudfront / s3进行部署，然后对无状态应用程序进行容器化将使您不知所措。

一些关于devops哲学的书籍（在这种过渡中很重要）

The Devops Handbook

Accelerate

Effective Devops

SRE book