采用容器技术的关键策略

日期:2015-10-21作者:Chris Riley

【TechTarget中国原创】本文中,我将研讨利用强有力的策略和工具,如何帮助你确保容器技术采用的可持续和在开发组织中的延伸——而不是分裂成不同的部分。我会指出其中的功能差异,及处理的方式。此外,我还会建议把容器应用到测试与开发环境(test/dev)以外以及进入应用发布流程的方式。
在对开发伙伴进行了30次访谈之后,我意识到很显然有一些大的拦路石需要搬走才能让容器技术步入正轨。这30人里面,只有4人提过有可能是产品级的用例,剩下的只是在test/dev环境下玩玩而已。在被问到为什么不做生产中使用容器时,典型的回答往往不是技术本身,而是与它如何稳定地融入到范围更广的交付链当中有关。
在没有明确战略的情况下采用容器技术会引起应用质量的下降以及治理风险的增高。产品质量下降是因为非法容器引入的隐藏变量最终会以bug或中断的形式浮出水面。治理也受到威胁,因为对容器缺乏清晰的监视,你不知道哪些遵循了策略,哪些没有遵循。还有变更管理的问题,对于任何开发团队来说这都是一个可怕的词,在专家离开团队之后会成为一个问题。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

网格计算与云计算>更多

  • ThoughtWorks技术雷达:直指四大趋势

    今天随着智能硬件、 IoT、云计算等等新技术的兴起,使得产品与技术结合在了一起,如产品都嵌入也芯片传感器;另外,商业的创新也完全由技术驱动。

  • 容器技术的间接后果

    本文探讨了为什么和容器技术可能带来的好处比起来可能更容易造成问题。我会尝试在错误发生之前就深入地思考,利用可用的工具来避免错误的发生。

  • AWS OpsWorks交付健壮应用管理服务

    Amazon Web服务(AWS)的 OpsWorks是基于云的应用管理服务,使用AWS OpsWorks,用户能够定义应用架构以及每个组件的规范,包括包安装,软件配置和资源,比如存储。

  • 仅凭SOA和云无法解决业务数据管理风险问题

    SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。

相关推荐

  • 中国市场DevOps应用趋势分析

    为了解决开发人员与运维之间的协作问题,从而提升工作效率,DevOps方法论应运而生。几年的发展,DevOps现在国内市场的应用情况如何?如何才能取得DevOps实施的成功?

  • 容器技术的间接后果

    本文探讨了为什么和容器技术可能带来的好处比起来可能更容易造成问题。我会尝试在错误发生之前就深入地思考,利用可用的工具来避免错误的发生。

  • 如何通过自动化Kubernetes集群管理容器

    围绕着容器集的启动以及为了让它们能够协作而连带的相关设置和配置又引发了一系列新的挑战。

  • 容器安全概览:看看你了解多少

    对很多企业来说,容器化相对VM而言,可以帮助企业更快更高效地发布稳定的软件。同时,容器引入了一种全新的部署模型,要求企业架构师和安全专家重新思考保护应用程序的方式。

技术手册>更多

  • 开源PaaS技术手册

    开源业界向来不太平,关于诸多技术的开源未来足以让很多粉丝兴奋躁动起来。商业软件开始揉进开源技术,开源技术也成为IT大佬们得基础架构,这一种趋势蔓延的缓慢有有力。在广告漫天飞得云计算中,开源的分量有多重?是否走向云端就意味着走向开源?开源的PaaS如何选择?如何为开源项目选择PaaS厂商?哪些服务平台值得我们关注,下面我们一一来揭晓。

  • 敏捷扩展:大型网站项目最佳实践

    其实从某种意义上讲,敏捷软件开发是自身成功的一个牺牲品。随着项目的进行,焦点一直集中在需求定义上,一边编写一测试,一边交付工作软件的各个部分,所以可以看出敏捷是多么好,以致于许多组织都在试图扩展它的使用,而不仅只是局限在单一的团队项目中。但怎样才能把敏捷方法从小项目转移到大型项目中呢?

  • 开源关键技术选型指南

    随着开源技术越来越成熟,一个稍有开发经验的人通过学习就可以用开源的产品和技术构建一套可用的系统。对于从事软件开发的人员,尤其是对Java或动态语言相关领域的人来说,“开源”也许是他们最喜爱的单词。但是,很多时候我们需要的不仅仅是一个可用的系统,而是希望这个系统开发更简易、性能更高和扩展性更好等。这确实是一个令人头痛的问题。本指南很多地方都是点到为止,要深入了解相关信息的读者请借助参考资料、网站等自行挖掘。

  • 企业敏捷开发实践

    敏捷却是一把双刃剑,这一方法并不是适合所有人,当然也不会适合所有的项目。敏捷要求有合适的团队,合适的业务经理理念,当然也要有适合的项目。没有一种方法是适合一切的,所以本文讲了六种方法来确定你的云项目是否已经足够敏捷性,或者确定你的组织是否足够敏捷。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算
【TechTarget中国原创】

本文中,我将研讨利用强有力的策略和工具,如何帮助你确保容器技术采用的可持续和在开发组织中的延伸——而不是分裂成不同的部分。我会指出其中的功能差异,及处理的方式。此外,我还会建议把容器应用到测试与开发环境(test/dev)以外以及进入应用发布流程的方式。

在对开发伙伴进行了30次访谈之后,我意识到很显然有一些大的拦路石需要搬走才能让容器技术步入正轨。这30人里面,只有4人提过有可能是产品级的用例,剩下的只是在test/dev环境下玩玩而已。在被问到为什么不做生产中使用容器时,典型的回答往往不是技术本身,而是与它如何稳定地融入到范围更广的交付链当中有关。

在没有明确战略的情况下采用容器技术会引起应用质量的下降以及治理风险的增高。产品质量下降是因为非法容器引入的隐藏变量最终会以bug或中断的形式浮出水面。治理也受到威胁,因为对容器缺乏清晰的监视,你不知道哪些遵循了策略,哪些没有遵循。还有变更管理的问题,对于任何开发团队来说这都是一个可怕的词,在专家离开团队之后会成为一个问题。

以下是目前容器技术需要帮助以便缓和风险的关键差距:

网络限制:容器网络(Docker Network )让你可以方便地在同一主机下对容器进行网络连接。加上一些其他的工作,你就可以跨主机使用叠加网络功能。然而,也就到此为止了。网络配置操作是受限的,而且到目前为止可以说这些手段都是人工的。尽管容器脚本化可以规模化,因为你必须给网络定义增加预分配实例,每次提供容器时还需要额外步骤,这容易引起错误。

库控制受限:库已经成为任何容器会话的中心议题。公共库是最有价值的,因为他贡献了大量的预置容器,节省了许多的配置时间。然而,在沙盒里使用它是有风险的。在不知道谁以及如何创建镜像的情况下,可能会存在任意数量的有意或无意的稳定性和安全性风险。对于企业来说,有必要建立和维护一个私有库,这个库的建立挑战不大,但管理是个问题。Docker为大型库的镜像管理提供了一个有限的元数据模型,确保未来实例如预期的能力受限,也没有叠加功能。

没有清晰的审计跟踪:提供容器是很简单的,但知道提供容器的时间、原因、方式以及提供方却不容易。因此,在提供之后,你并不掌握多少出于审计目的的历史。

运行实例的低可见性:如果没有经过深思熟虑的行动,实例提供后很难接触到运行容器的对象,也很难知道哪些应该出现在那里,哪些不应该出现在那里。这个就是我所谓的容器蔓生问题—这个问题严重起来会导致:

这些挑战并非不可克服的。同时,尽管Docker并未将其列入开发路线图,该公司现在还在积极地处理着。比方说,在DockerCon15发布的Notary可以让组织设置策略,策略可以针对所有新的容器进行检查。而第三方市场甚至还有更强的产品。

以下是应对这些挑战的关键办法:

最大的抑制因素也许是新的工具和功能来得太快。组织往往会按下暂停键等等看有一个关键功能能够一揽子解决。或者进一步限制容器的使用,直到能确保更新不会导致大规模的中断。

总有一天我们会把应用比作容器而不是代码,要为这一天做好准备。同时,什么地方围绕着基础设施的考虑最小,要找到这个点,并且应该在应用生命周期的早期去考虑。未来几年容器技术的面目将会焕然一新,也因此会改变应用的本质。