如何开始容器化 ?
2017-07-19 18:52:55
Angela
  • 访问次数: 250
  • 注册日期: 2017-03-15
  • 最后登录: 2017-10-12
  • 当前积分: 1287

Original 2017-07-19 范彬 译 Docker

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


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


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


1. 加快应用开发和部署


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


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

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



3. 转向微服务


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


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


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


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


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


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


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


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


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


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


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


原文链接:https://dzone.com/articles/how-to-get-started-with-containerization

Angela 最后编辑, 2017-07-19 18:53:34