为什么我应该使用容器而不是直接将构建工件部署到Azure artifacts或AWS ElasticBean秸秆？

Question

最近，其他人告诉我研究我的无状态web应用程序的容器化(在本例中是.NET Core2.x和3.1)。我的所有依赖项都从公共和私有Nuget提要中检索。

几年来，我一直部署到Azure应用服务(Web应用程序)，没有问题，只有一些非常简单的配置创建应用服务。Azure (我猜AWS)似乎能够很好地处理常见的配置，比如我的配置。不使用容器我错过了什么？

码头集装箱真的能解决我没有的问题吗？

Answer 1

在一个很高的层次上，你不会错过任何重要的东西。Docker (和Kubernetes)提供了一个运行时环境、控制平面、部署、网络抽象等等，这些都是由云供应商提供的。它们是不同的机制，但它们解决了同样的问题。

有了容器，就更容易避免供应商的锁定。虽然AWS和Azure执行类似的功能，但如果需要的话，迁移将非常痛苦。此外，运行不是由云供应商提供的服务也更方便。只是另一个容器。

这有点像Netflix，一个接一个地买电影。如果你对Netflix上的内容组合很满意，你就没事了。在未来，内容组合可能会发生变化，或者在功能上落后于竞争对手。但我不一定会把晚上的时间都花在研究IMDB上，而不仅仅是看一些东西。

Answer 2

对您的问题的完整答案取决于部署的复杂性。如果你想托管一个单一的ASP.Net (核心或经典)网站，没有额外的服务，那么我会特别推荐Azure。

在测试Azure应用程序服务时，端到端的故事真的很好：

• 与github或Bitbucket git存储库的集成使您能够在将更改合并到主版之后进行部署(Azure app Services将签出回购、构建应用程序并进行部署)
• 托管网站是坚如磐石的，大小也很合适。

在测试AWS ElasticBeanstalk时，端到端的故事并不是那么漂亮：

• 没有与git直接集成，所以您必须使用AWS插件发布。该包不是标准的Visual部署包
• 主持是不稳定的。如果VM太小，它们会随机重新启动，启动时间以分钟为单位。

超越了简单的web应用程序

当您拥有一组作为一个整体应用程序协同工作的web服务时，容器就开始值得投资了。通常情况下，容器的启动速度比AWS EC2实例(您的应用程序在ELB中运行的情况)要快得多，这意味着使用EKS这样的业务流程服务来扩展您的应用程序更有吸引力。

接下来要考虑的是成本。在AWS中，您直接或间接地为所使用的每个EC2实例付费。不确定Azure中的一些托管服务是如何工作的，但这可能是一个类似的故事。很多时候，您的EC2实例中有空闲的容量，可以用来承载应用程序的另一个实例或另一个微服务。容器允许您在确保配置正确的同时使用该空间。

Answer 3

在这种情况下，我要说的是容器为您的应用程序带来的灵活性。当然，现在dotnet是跨平台的，但是容器使您能够在可以运行容器的任何地方运行它。App服务、AKS、ACI甚至AWS或其他云提供商。我经常用的比喻是容器图像很像DVD --只要有人有DVD播放机，他们就能播放你的DVD。这是一个类似的故事，集装箱应用程序。您可以在任何地方托管容器应用程序，从提供业务流程和规模的复杂服务(如AKS )到更简单的、不像ACI那样提供规模的单实例服务。App服务提供了两者之间的一种混合，但为了证明我的观点，严格来说，如果容器应用程序安装了容器运行时，它也应该运行在Pi设备上(不是说您会这么做)。

因此，简而言之，可移植性和灵活性。