为什么容器重要？
在本单元中，你将跟随 Tailspin 团队讨论其 DevOps 流程急需做出的一些改进。 在本案例中，团队使用 Docker 容器化 Web 应用程序。 然后，团队会更新其 CI/CD 管道以支持它。
这是多么艰难的几周
过去的几周对 Tailspin 来说是巨大的挑战。 团队出于多种原因难以在截止日期前完成工作，而且整个公司都在关注工作效率。 Andy 召集了 Space Game 网站团队的一些关键利益干系人，一起收集反馈，为即将到来的面向管理层的演示做准备。
Andy：感谢抽空参见会议。 我知道过去的几周对每个人来说都很艰难，但我这里有一些好消息。 管理层明天将举行场外会议，听取我们有关性能改进的相关更改建议。 他们已邀请我去展示 DevOps 成功案例，并欢迎我们表达想法。 我希望我们可以在这次会议中来一次集思广益。 谁先开始？
每个人都看向了 Amita。 最近她尤其沮丧。
Amita：我先来吧。 如你所知，我为多个团队进行测试，这可能很有挑战性，因为每个团队都使用他们自己的技术堆栈。 即使他们使用相同的基础平台（如 .NET 或 Java），但经常会针对不同的版本。 我觉得我有时光是为了让测试环境处于一个我测试时所需要的代码运行状态，就需要花半天之久。 当有些内容无法正常运行时，我就很难判断是由于代码中存在 Bug，还是由于我意外配置了版本 4.2.3 而不是 4.3.2。
Andy 在白板上写到“QA 的依赖项版本控制问题”。
Tim：其中操作方面的问题也同样让人沮丧。 我们有几个有特殊版本要求的团队，我们不得不将他们的应用发布到他们自己的虚拟机上，只是为了确保他们的版本和组件要求不会与其他应用冲突。 除了维护额外一组 VM 所涉及的开销外，所需要的相关成本比这些应用并行运行时的成本要高。
Andy 在白板上写到“因使用 VM 解决应用隔离问题而产生的开销”。
Mara：我想从开发角度说一说。 几周前，我一直在开发对等更新系统，并且全部都是在我的计算机上进行的。 但当我将它移交到部署环节时，它却无法在生产环境中正常运行。 我忘记了在服务中我需要打开端口 315。 这耗费了我们一整天的时间来进行故障排除，以了解哪里出错了。 在生产环境中打开该端口后，一切立刻就正常运行了。
Andy 在白板上写到“各部署阶段的配置不一致”。
Andy：我认为此次对话是一个很好的开端。 让我来研究这些问题并看看我能提出什么想法。 下面是我刚听到的问题：
- 依赖项版本控制对 QA 的挑战
- 因使用 VM 解决应用隔离问题而产生的开销
- 各部署阶段的配置不一致
全部放在一起（放在一个容器中）
第二天早上，Andy 召集大家开会，向团队提出新想法。
Andy：我昨天和一些同事就我们正在面临的挑战进行了交流，然后他们提出了一些有趣的建议。 有一个我很有兴趣尝试的是 Docker。 这是一种将整个应用程序打包为容器的技术。
Amita：什么是容器？ 是否类似于 .zip 文件？
Andy：不完全是。 它更像是一个专为直接在主机操作系统上运行而设计的轻型虚拟机。 生成项目时，输出是一个包含软件及其依赖项的容器。 然而，它不是一个完整的虚拟化系统，所以它可以在不到一秒的时间内运转起来。
Tim：它如何处理安全性和隔离？
Andy：由主机操作系统处理安全性和隔离。 容器在主机进程中运行时，容器与同一主机上的其他进程是相互隔离的。 通过此隔离，容器可以加载所需的任何版本的组件，无需考虑其他容器正在执行的操作。 这也意味着你可以在同一台主机上同时运行多个容器。
Amita：对于生产环境，这听起来很棒，但它能否解决我们早先在管道中面临的挑战？
Andy：当然可以！ 不需要传送源代码或一组二进制文件，整个容器就是一个项目。 这意味着，当 Mara 正在进行开发时，她的调试会话在本地针对计算机上承载的容器运行。 当 Amita 测试时，她针对同一容器的副本进行测试，该副本已包含其所有所需版本的依赖项。 当 Tim 管理我们的生产环境时，他所监视的容器是由 Mara 开发并由 Amita 测试的同一容器的独立副本。
Mara：开发容器应用程序有多困难？ 是否需要对现有代码进行重大更改？
Andy：容器更多涉及的是打包和部署技术。 它们不会影响我们正在编写的基本软件。 我们可以直接指示我们的工具在生成结束时生成 Docker 容器。 然后，当我们进行调试时，应用程序会从本地容器而不是本地 Web 服务器运行。 事实上，Visual Studio 之类的工具甚至让你能够在调试环境（例如 Docker 和 IIS Express）之间切换，从而为我们提供所需的灵活性。 实际上，我昨晚为我们的网站项目创建了分支，并将其进行转换以生成为 Docker 容器，以便测试这个过程。 我只需要添加一些基本容器配置；无需更改现有代码。
Mara：这太棒了。 我敢说，我们甚至可以在 Azure Pipelines 中从分支更新发布管道，来生成和部署 Docker 版本。
Andy：你懂我。
什么是 Docker？
Docker 是一种用于自动打包和部署可移植和自给自足的容器的技术。 Docker 容器可以在任何具有 Docker 主机的位置运行，无论是在开发计算机上、部门服务器、企业数据中心还是在云中。 Azure 提供了运行基于容器的应用程序的多种方法，包括在应用服务中运行或在通过 Kubernetes 等业务流程技术管理的群集中运行。
Tailspin 团队选择了对此方案使用 Docker 容器，原因它满足他们的全部需求：
QA 的依赖项版本控制问题：应用程序被打包成容器，而这些容器带来了正确版本的依赖关系。
因使用 VM 解决应用隔离问题而产生的开销：许多独立容器可以在同一主机上运行，其优势大于虚拟机，包括更快的启动时间和更高的资源效率。
各 DevOps 阶段的配置不一致：容器随附了可自动实施配置要求的清单，如需要公开的端口等。
采用 Docker 容器是实现微服务体系结构的关键步骤。 稍后我们将对此进行详细介绍。