当前位置:云计算技术专区 → 正文

欢迎来到被容器技术改变的世界!

责任编辑:editor005 作者:布加迪编译 |来源:企业网D1Net  2015-07-03 14:13:02 本文摘自:51CTO

如果你将容器整合到构建工作流程中,我们未来的多云环境的所有要素都开始落实到位。

现代应用程序取得发展很大程度上归功于方兴未艾的开发运营(DevOps)潮流以及由此带来的各种自动化工具。如今,广大开发人员在考虑问题时需要着眼于使用的工具以及这些工具从最初设想到实际应用程序的整个流程中如何协同使用,而不是仅仅着眼于编写代码。

容器是这种新工作流程中最重要的新工具之一。诸如Docker之类的新技术帮助我们获得关键服务后,将它们从底层基础设施中抽象出来。这种方法让我们得以重新思考如何部署应用程序,以及如何才能充分地利用云基础设施。

完整的基础设施

在亚马逊公司近日于伦敦召开的一次大会上,AWS的一位用户描述了他的团队如何处理应用程序的更新:他们不是简单地推送更改后的代码,而是让构建过程的输出成为“完整的基础设施”。

只有该基础设施部署并测试完毕后,他才会切换到DNS,让它成为一个活动系统。这种方法具有诸多优点,尤其是让你可以在投入运行的头几天当中将旧的虚拟基础设施当成备用系统,之后再删除。

推出完整的基础设施这一想法最初看起来似乎很奇怪,但是当你考虑了云部署的经济性后,它比部署更新要来得省钱多了。它还意味着你部署的是一种已知状态,而不是更新可能运行了一段时间,操作系统或软件可能自动更新的服务器和服务。

这种办法不需要投资硬件。开发、测试和生产可以使用同样的云平台――只需要为每种环境提供不同的虚拟网络就行,另外辅以适当的访问控制措施。你甚至可以在开发过程中使用生产数据,需要干净数据时只要克隆数据存储区。

无所不包的容器

使用Docker对应用程序进行容器化处理,让你易于从基础设施抽象出关键的应用程序元素。用这种方式处理软件从开发运营方面来看颇为明智,你还更容易对需求不断变化的服务进行扩展。如果用容器来封装Node.js/Seneca微服务,就可以快速部署新的实例,可以根据需要部署在同一个主机上,或者部署在新的虚拟机中。

这种方法带来了一种令人关注的开发运营模式:幂等容器(idempotent container)。你构建的容器可以一并封装应用程序、服务以及所有的依赖项,而不是让应用程序或服务当成构建的终点。你啥时作出改变,你就构建一个新的容器;你测试和部署容器时将其视为一个整体,而不是单个元素。这种方法非常明智,消除了开发过程中的某些风险。在传统的构建模式中,我们很容易走捷径,仅仅测试变更部分,而不是测试整体部分。

一旦容器构建并部署完毕,它应该不会发生变化,除非又有新的容器已部署。由于容器就是沙盒,因此想与其中的内容进行交互,唯一的办法就是通过API或(对最终用户而言)通过容器提供的任何用户界面(UI)。这使得容器成了微服务的理想抽象机制,服务API是唯一的接触点。由于API定义好比是开发运营团队之间的一份契约,在小型服务器实例(比如CoreOS或微软新的Nano Server)上运行的容器就成了一种标准的基础设施构建模块。

随流而行

所以,看到Jenkins构建流水线工具增添了对Docker的支持就不足为奇了。Jenkins已经成为许多构建流程中的一种标准构建工具。其可以定制的模块化架构让你很容易针对特定的工作流进行调优,也很容易与源代码控制工具和开发及测试平台进行整合。

正如Cloudbees的首席技术官兼Jenkins项目创始人Kohsuke Kawaguchi在大会上所言,为Jenkins增添支持Docker的功能很有必要:“这促进了对Jenkins的需求,将Docker当作一种可执行的程序包格式。你可以编译并打包成二进制代码块,然后你可以拿来运行,不再需要时可以一扔了之。”

从Kawaguchi的这番话中显然能看出,Docker及其他容器格式很吻合Cloudbees在Jenkins方面的愿景,“你可将其用于测试、用于生产。测试未通过,可以重新构建。可以将代码编译成模块,就像Ruby gem那样,然后放入到容器,发送给Puppet用于部署。”

作为整个开发运营策略的一部分,这种做法有其道理:从基础设施往下的一切都是代码。正如Kawaguchi指出的那样,如果一切都是代码,“Git和Jenkins好比是相对代码这些钉子的锤子。”

虽然Docker的文件格式对容器界来说目前是通用格式,不过看到Linux基金会赞助开发一种通用、开放的容器格式是件好事。这个项目已将许多容器开发人员和厂商聚集到一起,包括微软等公司。如果有一种通用的容器格式得到业界的广泛支持,我们就能够利用同一个构建流程,向多家云提供商(私有云和公有云)交付容器了。

一种通用的容器格式解决不了管理不同的云基础设施定义方面的的所有问题,但是无疑多少会有助于让人们更容易在Azure与AWS或在OpenStack与谷歌云之间迁移服务。同样,借助由Puppet或Chef描述,并由Git软件库管理的的基础设施,就有可能开发出一种转换层,这种转换层拿来应用程序普通的虚拟机和网络描述后,就能为你的任何目标云提供商交付适当的编排功能。

一切都是代码这种想法并不新颖,但现在迈出了让这成为现实的步伐。由于Docker和Jenkins等工具相辅相成,我们现在开始看到它实际上有可能如何发挥效果。

关键字:代码编译CoreOSChef

本文摘自:51CTO

x 欢迎来到被容器技术改变的世界! 扫一扫
分享本文到朋友圈
当前位置:云计算技术专区 → 正文

欢迎来到被容器技术改变的世界!

责任编辑:editor005 作者:布加迪编译 |来源:企业网D1Net  2015-07-03 14:13:02 本文摘自:51CTO

如果你将容器整合到构建工作流程中,我们未来的多云环境的所有要素都开始落实到位。

现代应用程序取得发展很大程度上归功于方兴未艾的开发运营(DevOps)潮流以及由此带来的各种自动化工具。如今,广大开发人员在考虑问题时需要着眼于使用的工具以及这些工具从最初设想到实际应用程序的整个流程中如何协同使用,而不是仅仅着眼于编写代码。

容器是这种新工作流程中最重要的新工具之一。诸如Docker之类的新技术帮助我们获得关键服务后,将它们从底层基础设施中抽象出来。这种方法让我们得以重新思考如何部署应用程序,以及如何才能充分地利用云基础设施。

完整的基础设施

在亚马逊公司近日于伦敦召开的一次大会上,AWS的一位用户描述了他的团队如何处理应用程序的更新:他们不是简单地推送更改后的代码,而是让构建过程的输出成为“完整的基础设施”。

只有该基础设施部署并测试完毕后,他才会切换到DNS,让它成为一个活动系统。这种方法具有诸多优点,尤其是让你可以在投入运行的头几天当中将旧的虚拟基础设施当成备用系统,之后再删除。

推出完整的基础设施这一想法最初看起来似乎很奇怪,但是当你考虑了云部署的经济性后,它比部署更新要来得省钱多了。它还意味着你部署的是一种已知状态,而不是更新可能运行了一段时间,操作系统或软件可能自动更新的服务器和服务。

这种办法不需要投资硬件。开发、测试和生产可以使用同样的云平台――只需要为每种环境提供不同的虚拟网络就行,另外辅以适当的访问控制措施。你甚至可以在开发过程中使用生产数据,需要干净数据时只要克隆数据存储区。

无所不包的容器

使用Docker对应用程序进行容器化处理,让你易于从基础设施抽象出关键的应用程序元素。用这种方式处理软件从开发运营方面来看颇为明智,你还更容易对需求不断变化的服务进行扩展。如果用容器来封装Node.js/Seneca微服务,就可以快速部署新的实例,可以根据需要部署在同一个主机上,或者部署在新的虚拟机中。

这种方法带来了一种令人关注的开发运营模式:幂等容器(idempotent container)。你构建的容器可以一并封装应用程序、服务以及所有的依赖项,而不是让应用程序或服务当成构建的终点。你啥时作出改变,你就构建一个新的容器;你测试和部署容器时将其视为一个整体,而不是单个元素。这种方法非常明智,消除了开发过程中的某些风险。在传统的构建模式中,我们很容易走捷径,仅仅测试变更部分,而不是测试整体部分。

一旦容器构建并部署完毕,它应该不会发生变化,除非又有新的容器已部署。由于容器就是沙盒,因此想与其中的内容进行交互,唯一的办法就是通过API或(对最终用户而言)通过容器提供的任何用户界面(UI)。这使得容器成了微服务的理想抽象机制,服务API是唯一的接触点。由于API定义好比是开发运营团队之间的一份契约,在小型服务器实例(比如CoreOS或微软新的Nano Server)上运行的容器就成了一种标准的基础设施构建模块。

随流而行

所以,看到Jenkins构建流水线工具增添了对Docker的支持就不足为奇了。Jenkins已经成为许多构建流程中的一种标准构建工具。其可以定制的模块化架构让你很容易针对特定的工作流进行调优,也很容易与源代码控制工具和开发及测试平台进行整合。

正如Cloudbees的首席技术官兼Jenkins项目创始人Kohsuke Kawaguchi在大会上所言,为Jenkins增添支持Docker的功能很有必要:“这促进了对Jenkins的需求,将Docker当作一种可执行的程序包格式。你可以编译并打包成二进制代码块,然后你可以拿来运行,不再需要时可以一扔了之。”

从Kawaguchi的这番话中显然能看出,Docker及其他容器格式很吻合Cloudbees在Jenkins方面的愿景,“你可将其用于测试、用于生产。测试未通过,可以重新构建。可以将代码编译成模块,就像Ruby gem那样,然后放入到容器,发送给Puppet用于部署。”

作为整个开发运营策略的一部分,这种做法有其道理:从基础设施往下的一切都是代码。正如Kawaguchi指出的那样,如果一切都是代码,“Git和Jenkins好比是相对代码这些钉子的锤子。”

虽然Docker的文件格式对容器界来说目前是通用格式,不过看到Linux基金会赞助开发一种通用、开放的容器格式是件好事。这个项目已将许多容器开发人员和厂商聚集到一起,包括微软等公司。如果有一种通用的容器格式得到业界的广泛支持,我们就能够利用同一个构建流程,向多家云提供商(私有云和公有云)交付容器了。

一种通用的容器格式解决不了管理不同的云基础设施定义方面的的所有问题,但是无疑多少会有助于让人们更容易在Azure与AWS或在OpenStack与谷歌云之间迁移服务。同样,借助由Puppet或Chef描述,并由Git软件库管理的的基础设施,就有可能开发出一种转换层,这种转换层拿来应用程序普通的虚拟机和网络描述后,就能为你的任何目标云提供商交付适当的编排功能。

一切都是代码这种想法并不新颖,但现在迈出了让这成为现实的步伐。由于Docker和Jenkins等工具相辅相成,我们现在开始看到它实际上有可能如何发挥效果。

关键字:代码编译CoreOSChef

本文摘自:51CTO

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^