如何开始集装箱化


作为我工作的一部分,我定期与DevOps人员会面,讨论他们的集装箱策略。大多数时候,我与之交谈的人都渴望获得容器提供的许多好处,但是他们对与容器一起工作是陌生的。他们可能有一个基于容器的系统或两个内部系统或在云中,但没有明确的策略。

鉴于集装箱是多么具有破坏性,人们很容易兴奋起来,想要全力以赴。但是我鼓励人们清楚地定义他们的短期和长期目标,建造跑道来适应集装箱和他们周围的文化。

DevOps团队希望开始使用容器的主要原因如下。

1.加快应用程序开发和部署

容器是精简的、轻便的和快速的——你可以基于流行的开源项目,使用现成的样板图像轻松地开始开发容器。一旦准备好了,您就可以将您的工作打包成一个容器映像,将它发送出去,并像在开发环境中一样在生产环境中运行。如果你给过程增加自动化,比如配置项/光盘工具,那么事情会变得更快。

2.将应用程序移至云

容器的另一个非常有用的特性是它们的便携性。将一个应用程序封装起来,可以将其从主机操作系统和物理基础架构中抽象出来。同一个容器可以在内部或云中(私有或公共)运行,而不需要转换部署格式或更改一行代码。

3.过渡到微服务

每个容器通常都是单一用途、单一进程的,这与微服务架构非常吻合。组织正在寻找更好的方法来开发和维护他们的应用程序,从难以维护的大型单一应用程序转向更易于开发和升级的微服务应用程序。容器是微服务的完美平台,围绕它们涌现的生态系统使即使是最大的组织也能扩展微服务战略。

将应用程序打包有很多好处,但问题是,从哪里开始?你应该把你的遗留单片应用程序重构成现代的微服务容器,或者你应该把“新东西”装在容器里?

那么,从另一种方法开始怎么样?将现有的遗留应用程序打包,而不将其重构为微服务。当将一个不是为容器构建的遗留、单一应用程序进行容器化时,您会失去微服务应用程序必须提供的一些优势,尤其是易于维护和更新选项,但仍有许多优势需要考虑。

集装箱化应用程序使您能够将容器引入到环境中,您可以让您的团队熟悉它们,同时构建团队并建立流程,以优化他们向基于微服务的方法的过渡。

在一天结束时,您将希望有一个管道和工具链——使用容器,它可以用来打包新的微服务管理遗留应用程序。这样,您可以规范化容器周围的所有过程,即使您正在容器内运行遗留的单片应用程序。这种方法的好处在于,您可以开始将微服务连接到现有的应用程序上,这样任何新的功能都是基于微服务的。

一种混合方法最近引起了一些轰动,它是一个用例,用德文的话说就是提升和转移。“提升和转移”指的是将一个内部的、单一的应用程序进行集装箱化的过程,以提升它(通常是从一个旧的数据中心)并将其转移到其他地方(通常是转移到一个现代的公共云或私有云)。

然而,作为一个整体DockerCon attendee noted,提升和移动可以而且应该不仅仅是一种运输机制。它提供了过渡到微服务模型的基础,并以可管理的方式将容器引入到环境中。这就是为什么它很快成为一种让DevOps团队熟悉容器的流行方法。但是,即使用于提供更有限的一系列好处,对于那些希望在集装箱战略上展示切实的前进动力的人来说,这也可能是一个快速的胜利。

如果你的目标是使用容器重新构建一个遗留的应用程序,那么完全重写到微服务中是一个很大的进步。有许多中间步骤,比如将应用程序重构成几个更大的块——“宏观服务”,如果你愿意的话。它还将提供一些好处,并允许您逐渐钻研真正的微服务。

当DevOps团队决定首先将什么装箱,以及为什么他们可能会考虑与外部利益相关者建立关系,以帮助支持进一步的创新。鉴于我的博客名为“DevSecOps”,我支持将安全团队放在第一位也就不足为奇了,因为他们有潜力成为DevOps极具战略意义的有用合作伙伴。

无论安全性和DevOps之间存在什么障碍(我在previous post),DevOps的协作精神对安全人员来说是一种强大的诱惑。安全团队不仅可以成为强有力的盟友,他们还可以洞察安全/信息技术风险考虑因素,从而加强由开发部门驱动的将特定应用打包的业务合理性。

在一天结束时,就像“重建或整合现有应用程序”一样常见困境在于,没有放之四海而皆准的解决方案。这就是速战速决如此重要的原因——所以无论你决定做什么,都要做好计划,创造现实的成功标准。