本文讲的是如何开始容器化【编者的话】这是一篇入门级的文章。这篇文章描述了DevOps团队开始使用容器的原因及指导DevOps工程师明确进行应用容器化的战略。



作为我工作的一部分，我经常会遇到DevOps工程师，与他们讨论容器战略。大多数时候，他们都渴望获得容器提供的好处，但作为新手，他们可能已经有一个基于容器的系统，或部署在本地或云端，却没有明确的战略。

鉴于容器的创新性，我们容易兴奋，想要全力以赴，但我鼓励人们明确界定短期和长期目标，建立适应容器及其周边文化所需的跑道。

DevOps团队想要开始使用容器的主要原因如下：

1. 加快应用开发和部署

容器具有精益、轻便和快速。你可以基于流行的开源项目，使用现成的样板镜像，轻松开发容器。应用作为容器镜像进行打包、装运、并以同样的方式，在开发环境和生产环境中运行。如果流程中添加了自动化功能，例如CI/CD工具，可以达到更高的效率。

2. 将应用程序迁移到云上

容器的另一个非常有用的特性是可移植性。应用容器化是对应用的抽象，使其运行在主机操作系统和物理基础架构上。同一容器可以在本机或云（私有或公共）中运行，而无需转换部署格式或更改一行代码。

3. 转向微服务

每个容器通常是单一用途、单进程，它与微服务架构很好地对齐。组织正在寻找更好的方法来开发和维护他们的应用程序，可以放弃难于维护的大型的单体应用，使用更容易开发和升级的微服务架构。容器是微服务的完美平台，在其周围发展的生态系统，能够使大型组织达到微服务扩展策略。

应用容器化有很多好处 - 但问题是从哪里开始？你应该把遗留的单体应用重构到微服务容器中，或者容器化新的应用。

那么，还有其他方法开始吗？ 将现有的遗留应用容器化，而不是重构为微服务。遗留的单体应用容器化，将失去微服务应用程序提供的一些优势，如: 易于维护和更新，但这样的做法也会带来很多好处。

应用容器化，将容器引入环境中，在构建团队并建立流程的同时，使团队熟悉容器和微服务架构，从而找到转换成微服务的优化方法。

同时，使用容器，你需要一个管道和工具链，可用于封装新的微服务， 管理遗留应用程序。这样，你可以对容器周围的所有流程进行规范化，即使你在容器内运行遗留的单体应用。这种方法的优点是你可以将微服务使用于现有的应用程序上，以便任何新的功能都是以微服务为基础的。

最近流行一种混合方法，做为 DevOps的一种用例，称为 “提升和转移”。 “提升和转移”是指将本地部署的单体应用容器化（通常来自旧数据中心）并将其转移到其他地方（通常进入现代公有云或私有云）的过程。

然而，正如一位 的那样，“提升和转移”不仅是传输机制。它提供了转换到微服务模型的基础，并作为管理的方式将容器引入环境。这就是为什么它很快成为熟悉容器的DevOps团队的流行方法。即使收益有限，但对于想在容器战略上展现明确前进目标，也是快速的胜利。

如果你的目标是使用容器重新构建遗留应用，以微服务架构完整的重写是一大步。这里面有很多中间步骤，例如将应用程序重构成几个更大的块 –“宏观服务”，如果你愿意的话。它还将提供一些好处，并允许你逐渐深入到真正的微服务架构中。

DevOps团队首先决定什么进行容器化，以及他们可能会考虑与外部利益相关者建立关系，以帮助支持进一步的创新。鉴于我的博客的名称是“DevSecOps”，因此我希望将安全性放在首位，因为他们有潜力成为DevOps极具战略意义的合作伙伴。

无论安全和DevOps之间可能存在什么障碍（我之前发布的其中一些内容），DevOps的合作精神可以成为安全工程师的强大诱惑。 安全团队不仅可以成为一个强大的盟友，他们可能会深入了解安全/ IT风险的考虑因素，从而加强DevOps驱动容器化特定的应用程序的商业理由。

“重建或容器化现有应用程序”没有一个适合所有的解决方案。 这就是为什么快速胜利如此重要 - 所以无论你决定做什么，做好准备，创造切合实际的成功标准。

原文链接：（翻译：范彬）

===============================================================

译者介绍：范彬，从事微服务、Docker和Kubernetes容器技术等方面的工作。可以关注译者的微信公众号：范范米饭。