容器技术的间接后果

日期:2016-2-3作者:Chris Riley翻译:崔婧雯来源:TechTarget中国 英文

容器技术   Docker   

【TechTarget中国原创】

容器技术的快速兴起和采用已经导致了一些不可预料且令人困惑的后果,比如监管的缺失,以及流程改变地太快接近崩溃。有计划以及正确的工具生态系统,CTO和开发经理才能够确保容器的引入在其团队里不会造成短视混乱的局面。

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

容器将宿主Linux操作系统的某些部分隔离出来,它们看上去就像拥有独特配置和应用实例。容器基于LXC技术,该技术自2008年开始就包涵了多个流行的Linux发行版。该方案和虚拟机(VM)技术类似。但是,容器能够无损地保持宿主操作系统的性能,并且更小。它们帮助开发人员更加快速地搭建工作所需的整个环境。它们还能够使得应用发布更加快速、更加可预测。

如今使用的主要容器技术是Docker。为了进一步推进容器驱动的流水线,Docker团队已经添加了一系列命令行接口,管理工具,公开和私有库,以及一些配置,比如网络和安全。所有这些都使得容器技术成为整个开发团队更为实用的技术方案。

现状概览

将应用作为整个堆栈(操作系统、系统配置和代码)来划分层次并不是什么新想法。虚拟化技术就是来源于这样的想法。但是,虚拟化的缺点在于VM很大,并且和不可变的hypervisor层紧密耦合。这意味着如果想要给VM做快照,并且像容器一样移动,就需要很大的带宽和强大的服务器能力。但是,这还不是最严重的问题:你还需要丢弃已经习惯的服务器旧式IT维护方式。Hypervisor一直属于IT,IT习惯于将VM当作物理服务器对待,生成一次然后直到出现问题才需要再作处理。这样的方式不适用于软件开发。

达到更好的层次划分的动力来自于应用复杂度的增加:使用更多的组件,更加强调安全性,以及代码和系统级别组件的更紧密的集成。这些全都强化了开发人员和基础架构之间的空白之处,并且尝试调和这两者之间的问题。

这意味着发布只有代码的应用不太理想。然而,如果你能够作为整体堆栈发布应用,那么定位并解决系统到代码的问题会更加容易。在开发领域,全栈部署是未来。对于开发团队而言,容器意味着开发人员、QA和IT能够更加具体地讨论应用,并且更快地定位问题的根本原因。

当优势成为问题

几分钟之内,开发人员就可以从公开库里拉取一个容器镜像,并且在其本地机器上生成一个实例。一个小时内,开发人员就能够完成该实例的改动,将其转换成自己的镜像,并且再次发布到其他10台宿主机器里,或者在同一台机器里创建出10个新实例。如果将这样的能力扩展到单个开发人员之外、拉取、修改和容器生成能够病毒式地传播。并且很快,团队就会拥有之前根本无法想象的容器实例数量。

这也正是优势迅速转化出问题之处:当出现未受管容器的生态系统的时候。先不谈那些不太严重的问题,比如浪费的资源,除此之外,容器技术带来了一些更加严重的问题:

1.治理和审计

2.变更管理

3.IT安全

4.应用集成

5.资源规划

6.管控和审计

这些问题使得新方案面临新的威胁,甚至是一些能够摧毁企业的问题,比如黑客攻击或者低劣的应用质量。容器是为了移动而构建的,它们不是为了监管和管理而生。因此,如今容器的使用还很有限,很少企业真正地实现了容器技术驱动的流水线愿景。

容器的主要用例在于开发人员,以非常随机的方式使用容器。他们为了快速测试,以及能够随时销毁并替换开发环境,而生成容器。但是大部分常见的容器用例有一个独特的元素,这正是容器正好能融入应用程序之处。如今,容器对于应用程序前端而言最为有用,因为其最大的价值之一就是保持小和敏捷。因此在容器里添加数据库是违反这一价值的。

容器非常值得投资

容器技术必须和一系列实践及工具共存,使其能够在团队范围内以可持续的方式工作,这一观念得到越来越多的共识。对于看到优势的企业而言,现实有些遥不可及,这也将其置于更广泛的现代开发实践之后。对于全栈开发,或者持续集成,交付和开发来说,容器并不是不可或缺的,但容器的确能够让这些实践更加容易。

容器能够带给企业的好处使得其非常值得投资,来帮助解决上述问题,以及推进应用交付发展到交付容器,而不是代码的阶段。并且,幸运的是,该领域有用的技术和生态系统战略正在飞速地向前发展。

因此不要放弃希望。容器引入的成熟阶段正在来临,它一定会改变我们看待应用和软件开发的方式。

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

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

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

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

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

网格计算与云计算>更多

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

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

  • 容器技术的间接后果

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

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

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

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

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

相关推荐

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

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

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

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

  • 采用容器技术的关键策略

    在对开发伙伴进行了30次访谈之后,我意识到很显然有一些大的拦路石需要搬走才能让容器技术步入正轨。

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

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

技术手册>更多

  • 智能BPM与业务流程工具

    Gartner认为iBPM要比运营型智能平台更优秀,表现在以下几个方面:iBPM套件提供更好的工作流,适配性案例管理以及结构化流程协调能力。

  • 事件驱动架构EDA

    EDA是事件驱动架构,在面向服务架构领域,一个比较重要的概念就是事件驱动的体系结构。英文全称为Event-driven Architecture。EDA允许您将创建或遇到事件的过程中的所有这些事件发布到一个中央事件处理主干上,从而使所有感兴趣的相关方可以从此处找到它们。

  • SOA与敏捷开发实战演练

    SOA是一种架构,敏捷是一种方法论,架构和方法论是可以一同使用的,它们本质上是互补的。而且,SOA和敏捷的目标相同,它们都承认(1)变化是必然的(2)组织需要有效地应对变化。所以,我们期望在构建SOA时,能够选择敏捷方法论,反之亦然。本技术手册给出了二者结合的完美之道。

  • Gartner指南:赢在BPM

    Gartner公司的BPM专家在谈到重要方法论发展的预测时,坦率地说道:想要获取竞争优势?让BPM成为核心竞争力。而这个建议尤其是针对大型上市公司。很多相关行业的网友对此也表示强烈赞同。未来BPM会为企业交付价值并借由拥有卓越BPM的企业淘汰掉一些流程混乱的企业,这也许对于某些行业将会是一次洗牌,产业格局会有所变化。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算