为什么Docker技术是企业成功的秘诀
企业互联网开发者都在看
来源：Docker
在当今日益增长的数字时代，快速创新是成功的关键。
以Uber、Spotify和Google三个公司为例，这些公司在尖端技术开发方面处于领先地位。Uber是近年来打破世界舞台的最具破坏性的玩家之一，它迅速成为服务行业的国王，在60多个国家每天运行一百万次，雇用了4000名员工。同时，Spotify通过每天向超过6000万用户提供快速、可靠的流传输和下载服务来支配音乐领域，而Google则更不用说了。
这些公司如何能够以这样的速度进行创新，让客户和竞争对手困惑？答案很简单。为了提供一个无缝和高效的24h/7d服务，要求后端基础设施建设提供持续交付能力来保护快速增长并通过消除敷衍了事“失败快速”的开发陷阱来帮助保持竞争优势。
一个工程师的选择
容器技术是这个目标所固有的，因为它允许软件工程师将一个软件打包成一个完整的文件系统，包扩所需的所有功能——运行时，系统工具，代码和系统库。因此，软件可以每次以相同的方式运行，而不管其运行的环境如何，这提供了更可预测可靠的服务。此外，由于在单个机器上运行的容器共享同一主机的操作系统，与虚拟机相比，容器化应用程序还可以快速启动，并更有效地利用底层硬件资源，例如CPU和内存。
Docker可以帮助企业实现达到生产率，效率和交付的神圣目标所需的组织效率。这是因为它们有助于打破传统上存在于开发者和运维之间的障碍。曾经我们希望开发人员独立编写代码，然后交给运维团队，而容器使开发人员能够在此过程的早期考虑运维。
这种方法的好处是，可能只在之后的在开发过程中可以追溯的问题现在可以从一开始就解决了。这在人员和资源利用上付出了红利-最终节省成本。
颠覆或被颠覆
这是商业世界的新常态，归功于技术和全球化的快速进步，使得新的商业模式能够以不断增长的速度和迅速下降的成本被引入。在外部环境以闪电般的速度演变的中断世界中生存的一个关键是在内部改变游戏。这需要公司加快执行速度，以及他们抓住新机会的能力。
因此，Docker技术最具吸引力的优势之一是其能够提高敏捷性，从而通过减少部署失败来加快开发周期。容器很容易启动，停止和移动，这意味着可以在beta阶段设置强大的测试基础设施。有了这一切，软件工程师就可以确信他们正在部署的东西每次都会做同样的事情，这意味着在发布更新时会有更少的意外。
这对于依赖频繁软件更新的企业，例如电子商务网站或消费者应用，是绝对必要的。当他们想要发布一个新功能时，他们可以通过一个经过良好测试的流水线，将他们的代码推送到生产环境，使他们能够快速，自信地前进。从竞争的角度来看，这种功能是无价的，因为它有助于企业跟上颠覆性的竞争。
条款和条件
你可能会想知道为什么每家公司都不愿意投资于Docker技术，即使它们可以增加明显的好处。然而，事实是，Docker只能对已经在结构和技术上准备好容纳它们的企业有效。换句话说，它们只能在DevOps工作文化中运行——当公司实现持续交付时。
这不是说Docker应该被那些尚未达到这一点的公司拒绝。容器仍然可以在帮助这些组织准备DevOps上发挥重要作用，通过开始打破开发和运维两个团队之间的障碍。
用友开发者
微信号：yonyouudn
UDN社区是目前业内唯一完全【面向企业互联网技术开发者】的线上中文技术社区和产品服务平台。
用友开发者作为官方微信公众号，每个工作日下午四点准时与大家分享大数据、软件架构、开发、开源、数据库、云计算、运维docker、devops等精彩内容……
·如有任何问题，请联系微信号jiabaoUDN，并咨询
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
今日搜狐热点他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)&Docker在企业应用中的有趣数据
Docker在企业应用中的有趣数据
日11时36分来源：
转载自：灵雀云官网
为了了解当前美国市场对 Docker 和其它操作系统虚拟化工具（OSVP）的使用情况，VMblog.com 和 CloudCow.com 共同组织了一次问卷调查。来自 VMblog 社区和 CloudCow 社区的一共 745 人参与了本次调查，样本大小足以代表美国市场。
本文为 StackEngine 对本次调查结果进行分析后得出的一些观点。
65% 的调查对象当前在其基础设施中使用了 VMware，和当前实际的市场份额基本相符；
40% 的调查对象使用了公有云，比如 AWS，Rackspace；
34% 的调查对象使用了私有云解决方案，比如 OpenStack；
Linux、Windows、bare metal 或 OpenStack 的采用率不相上下；
Linux 的使用率正在上升，在进行操作系统选型时，32% 的人表示会选择 Linux，而选择 Windows 的在 23%。Windows 仍然是 VMware 环境下被优先选择的操作系统。未来 Linux 的增长点在公有云和私有云等这些广泛使用了云计算技术，并积极拥抱开源的领域。
关于 Docker 有以下几个结论：
1. 企业对 Docker 的接受程度在不断提高
70% 的调查对象已经正在使用或考虑使用 Docker；
23% 的调查对象虽然没在用，但对 Docker 很熟悉；
只有 7% 的调查对象完全不知道 Docker；
2.Docker 的早期用户中，63% 的用于 QA/Test，53% 的用于开发，并且 31% 的用户计划在生产环境中使用 Docker
这个结果也向我们提出了一个疑问：为何在开发环境中得采用会落后于 QA/Test 环境？
3.Docker 实践的最大挑战
阻碍企业使用 Docker 的最大因素在于其安全性以及缺少生产环境下的运维工具（两个原因各占 49% 左右）。
4. 促使企业使用 Docker 的原因
混合云（45.1%）
VMware 太贵（43.8%）
Test 的压力（41.6%）
5. 一半的调查对象都表示愿意接受 Docker 管理的新工具
44% 的调查对象更倾向于采用当前已有的 VMware 的工具，他们更希望 Docker 能够和其当前的 VMware 环境结合起来使用。当然，这并不代表这些用户在等着 VMware 造出轮子，他们表示可以接受第三方提供的相应的解决方案。
6.Docker 应用最广泛的三个领域
Test/QA 应用
大数据，企业应用
7.Docker 的使用多是由中层管理者驱动的
Docker 得到了广泛的草根支持，但是 IT 经理和架构师级别的人对其并不重视；
公司使用 Docker 的决定中，47% 的是由中层管理人员决定的，24% 是由『草根』开发者驱动的；
调查结果可视化版本（图片转自 StackEngine）
T客汇 Docker系列报道：登录以解锁更多InfoQ新功能
获取更新并接收通知
给您喜爱的内容点赞
关注您喜爱的编辑与同行
966,690 十二月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
迁移到Docker：在RightScale，我们为什么要全部迁移？
迁移到Docker：在RightScale，我们为什么要全部迁移？
Tim Miller
0&他的粉丝
4&他的粉丝
日. 估计阅读时间:
：开启与Netflix、微软、ThoughtWorks等公司的技术创新之路！
亲爱的读者：我们最近添加了一些个人消息定制功能，您只需选择感兴趣的技术主题，即可获取重要资讯的。
相关厂商内容
Tim Miller将以周为单位来分别记录迁移过程，分享他们的尝试和痛苦、面临的挑战以及解决这些问题的方案。Tim Miller希望能够将痛苦降到最低，并让其经历帮助到决定跟随（或不跟随）其步伐的其他人。
由于其并没有和Docker合作或为Docker工作，读者你至少可以得到一个开发团队基于其经历所得出的原始意见。这就像是，你或许可以通过看别人将车开出悬崖掉到湖中，来决定自己是否要继续前进。
过去使用Docker的经历让Tim Miller团队觉得，Docker的确值得使用。尽管Docker的确还不成熟，还有很多问题需要修复，但其概念很扎实，实现也正在不断改进。在早期使用Docker时，该团队就发现，使用Docker的开发团队由于迭代速度更快，从而可以明显的加快研发速度。此外，在若干服务中增加宿主机的密度使得Docker可以节约花费。公司的运维团队也因为看到了Docker带来的效率提升而非常喜欢该容器。
Tim Miller团队相信，容器在未来的软件交付中肯定会成为主要技术迁移的其中一种。它将影响RightScale以及其客户在未来交付软件的方式。其客户群采用Docker的速度也非常快。当传统企业客户已经开始注意容器时，倾向于与尖端科技更接近的&数字&客户已经正在深入了解并使用。
由此，RightScale云管理平台将会需要在现有云负载之外支持容器化的负载。那么，还有什么比直接开始研究并迁移到Docker更能精确了解客户的需求呢？！通过在开发、测试和产品中使用Docker，Tim Miller团队希望能够扩展现在看到的优势，并在已有平台中加速对容器的支持，使得客户也可以更好的使用Docker。
预期的结果
RightScale公司希望能够从Sherpa项目中获得如下好处：
基于在已经容器化的服务中所看到的情况的开发速度的提升。
减少配置框架所需要的ServerTemplate（RightScale中模板机制的名字）的复杂度和数量。
减少云平台的开销。该团队认为，容器化可以节约开发/测试框架中70%的花费以及产品中至少40%的开销。开发所取得的节约部分是来自现在可以通过笔记本电脑来开发。
学习一个新的炫酷技术。
了解到团队需要哪些特性来支持Docker（以及希望在那些特性上得到巨大提升）。
内容和时间
现在，RightScale公司共有52个服务，其中7个已经在容器中。所以尚有45个服务要容器化。这部分工作包含了特别简单和特别复杂的部分。由此，他们会重新设计开发工作流来使得开发人员可以通过笔记本电脑来设计系统以及开发操作发布的自动化工具。所有这些都将会在4周内完成。那么，什么可能会出问题呢？
在夏尔巴人（Sheerpa）帮助登山者登顶珠峰后，Tim Miller团队将初始项目命名为Project Sherpa。为了开启Project Sherpa，团队成员决定开始穿着登山所需的衣服。
其中一个设计人员甚至专门选择了带有Project Sherpa图标的背景。那么，印有Project Sherpa的T-Shrit也不远了吧？
为了未来在未来4周内完成这么多工作，所有非紧急特征的开发将会暂停。当然，那些已经向客户保证的工作肯定会继续。但其他工作肯定要等1个月左右。
由于公司有九个工程团队分别负责平台的不同部分，这些任务分别被分派了下去。每一个研发团队将会负责若干服务，并配备一个运维工程师进行合作。因此，整个工程团队将会在1个月后变成Docker专家。幸运的是，在过去18个月中已经参与Docker迁移工作的工程师可以帮助其他人快速展开工作。
查看英文原文：
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（，），微信（微信号：）关注我们。
Author Contacted
语言 & 开发
181 他的粉丝
架构 & 设计
474 他的粉丝
82 他的粉丝
25 他的粉丝
80 他的粉丝
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
订阅InfoQ每周精要，加入拥有25万多名资深开发者的庞大技术社区。
架构 & 设计
文化 & 方法
InfoQ.com及所有内容，版权所有 ©
C4Media Inc. InfoQ.com 服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
找回密码....
InfoQ账号使用的E-mail
关注你最喜爱的话题和作者
快速浏览网站内你所感兴趣话题的精选内容。
内容自由定制
选择想要阅读的主题和喜爱的作者定制自己的新闻源。
设置通知机制以获取内容更新对您而言是否重要
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。为什么 Docker 也适合初创公司
原文：Why Docker makes sense for startups
作者：Carlos Vega
翻译：Vincent
译者注：以Docker为代表的容器技术已经持续成为话题好几年了，那么对于创业型公司来说，刚起步时有必要采用Docker吗？作者在本文给出了肯定的理由。以下为译文。
Docker正在渐渐成为开发和运行容器应用程序的标准。
很久以前，这一技术可能只对系统管理员和PaaS(平台作为服务)才有实际意义。但几乎没有听过哪家创业型公司会使用Docker，尤其是那种发展前景很明朗的公司。Datadog总部最近做的研究也与这些观念基本一致：
也许你会说对于创业型公司来说，这么做是否值得，那么接下来我们就详细介绍一下那些友好的容器体系结构对这些创业型公司到底提供了哪些帮助。如果你还没有使用Docker，我们会告诉你为什么需要选择使用Docker？
如果你在一家小型的具有两个披萨原则的公司工作，那么团队中的每个人很有可能都是上知天文，下知地理的。一旦手头的项目结束了或者再也不需要了，那么你就会被打回进入到开发的深渊中去。
让我们设想一个简单的场景，某位前端工程师需要从后端工程师那里获取一份API，但是该API还没有上生产。你可以通过使用模拟数据来解决这个问题，也可以部署一个预生产环境。这些方案都很不错。但是，与后端代码本身进行集成的敏捷性相比，它们就要逊色很多了。
类似于docker-compose这样的工具为我们创造了奇迹。新人所要做的全部工作就是安装某件东西。docker-compose这类工具所需要做的事情就是祈祷Docker已经为用户安装好了所有的东西，因此就可以跳过中间所有的步骤直接到编码环节即可。
关于各个运行时组件之间是如何进行相互通信的，这些工具的声明性特性都会提供一个概述。因此也使得对顶级架构的推理变得更加容易。
image: redis:alpine
- frontend
image: postgres:9.4
- db-data:/var/lib/postgresql/data
image: dockersamples/examplevotingapp_vote:before
- frontend
depends_on:
image: dockersamples/examplevotingapp_result:before
depends_on:
image: dockersamples/examplevotingapp_worker
- frontend
除了在开发中有用外，Docker还使得生产代码打包变得更加简单了。这是因为它使开发和生产环境更加对称。这是12factor的dev/prod对等点的重要作用之一。
有一些很好的语言专用工具，比如rbenv(Ruby版本管理)和nvm(节点版本管理器)。这些工具使得即使在运行时版本出现错误匹配，也不会受到什么影响。如果代码依赖于一些不知名的本地二进制文件或特定的文件系统结构，那么功能可能会更加强大。
这就是由于容器做得太过于出色而产生的结果。容器允许将应用程序和所需要的环境组合在一起。
这种可移植性在混合云的设置上也发挥了作用。关于这一点，我无需赘述太多，只需要告诉你目前我们也正在迁移到混合云上面。
由于混合云供应商当时无法提供稳定的可靠性，而且支持度也不够，因此我们非常不满。我们决定转到IaaS(基础设施作为服务)中最出色的云上面，即AWS(Amazon Web Services)。
我们能够预见这种迁移将会很快发生。因此已经将应用程序迁移到Docker上运行了好几个月。当我们告别旧云的时候，整个过渡过程只花了几天的时间。
这种范围如此之大的迁移可能被认为是非常罕见的事件。但我也没觉得迁移后灵活度方面存在任何问题。
需要注意的是并不是迁移了所有的应用程序。托管的turnkey解决方案也许可以解决诸如监视和日志记录之类的横切问题。然而，这些都可以用更容易设置的开源解决方案来代替，并也会让你避免上云黑名单。
如果问你是否需要某个编排系统可能不太恰当。如果问该系统你是想让它自我管理，还是希望在凌晨3点的时候叫来修理停机的人进行人工管理更恰当。
这个类比需要考虑很多运动部件。软件系统在运行时只会比这个更加复杂和分散。当面对网络分区时，它们就会遇到很多问题。
现在，容器本身并不能解决这个问题——事实上恰恰相反。他们短暂的天性使你的系统变得如此有活力。这使得在部署时很难在石头上设置依赖项。
扩展到集群化的基础设施，情况变得更糟。它达到了永远不确定您的流程最终可能运行在何处的问题。这使得定位和处理它们变得更加困难。但是，我们需要接受这种自然，从而给一整套解决方案让路。
我们尝试了几个集群系统。其中包括谷歌的Kubernetes、Mesosphere的马拉松和Hashicorp的Nomad。
我们在Docker自己的Docker集群上解决了大多数部署，使用的是AWS cloud生成模板的简单Docker。
首先声明表示您的系统的期望状态，它应该运行的服务。然后蜂群会不断监测你的容器的实际状态。它将在节点失败的情况下将工作负载重新调度到其他节点，从而达到预期的状态。它还可以通过重新配置新服务器来自我修复，因为节点不能恢复。
提供您自己的容器集群可能会逃避您的需求。然而，新的Caas(容器- as-a- service)平台正在涌现，通常没有比基础设施使用的额外成本。
您将发现服务发现、负载平衡、软件定义的网络、持久存储、任务调度和筏筏共识。这保证了一个可怕但有趣的旅程，通过一个听起来很酷的行话。
削减基础设施费用
你没有必须要再去读那些“在切换到{ { rand_language } }之后，应该如何通过{ { rand_amount } }将服务器成本削减”之类的文章了，因为本文我会提出一些不同的方法。
如今，微服务风靡一时。我们已经在Beta Labs里面把应用程序分成了几个不同的服务。这样就可以把不同的开发语言和框架进行整合和适配了，而且还可以随时使用最好的工具来工作。
请对我做一些包容。因为我将试着用十个或更少的字来简单说明一下微服务的情况。
在读完12factor的“一个代码库，多重部署”之后，我认为每个服务都应该作为它自己的应用程序部署在PaaS术语中。这恰好是大多数PaaS定价模型的规模。
我们来简单算一下。在Heroku上运行一个Ruby应用程序的设置意味着至少需要运行两个web标准的dynos。如果一个应用程序的内存限制在512MB以内，那你每个月返回$50。
每月前端服务将需要$50 GB的。为后台添加一个运行的dyno进行简单处理，那么每月就是$25。
可能还需要一些轻量级的后端服务，比如带有自定义逻辑的中间件或代理，它可以使用1个实例。你可以轻松地超过每月100美元。
那是在我们开始讨论附加组件之前。为基本的Redis和PostgreSQL实例增加每月30美元。Heroku的Logplex只是流媒体。因此，如果您想让日志保持更长时间，您还需要添加一个可以跨应用程序共享的日志服务。
让我们看看如何能够做得更好。
一个VM每个(单一的)服务vs每个VM的多个(微)服务。数据提供者:Martin Fowler
让我们借用Martin Fowler对微服务的描述。使用带有集群系统的容器，为动态扩展服务提供了一个很赞的合适的平台。
容器被放置在具有最多可用资源的节点上。所有节点共享一个内部SDN(软件定义网络)。因此，服务可以在不离开集群的情况下互相通信。
一个3 -node- strong集群运行的例子- voting-app
让我们回到前面的例子。这样的系统适合3个节点，t2。基于微技术的Docker集群集群，每个月大约有50美元。你可以有3GB的内存。如果你敢这么大胆的话，你甚至可以有额外的空间来运行你自己的容器。
Heroku的dynos在CPU部门更有天赋，拥有8个虚拟内核。但是，除非您使用本机线程的语言运行，否则一个多进程/ dyno设置可能会使您发现512MB内存不够快。另外，如果您的工作负载是I / O密集型的，则不会有太大的差别。
不要误会我的意思，就像让DevOps一个非问题一样，它也没有比Heroku好得多。我并不是建议你或你的团队中的任何人单独行动，花上几个晚上学习如何在PostgreSQL中获得高可用性设置。我们将把苹果比作桔子。
尽管如此，我还是觉得很重要的一点是，你要为所有的可靠性和易用性支付额外的费用。有了这些，你就可以自己判断什么是真正值得的，什么是你可以自己做的。
哦，当我们在这里的时候，别忘了你可以在Heroku运行你的Docker容器。
固有安全性
在拿Docker平台与PaaS进行比较时，这种讨论可能不会产生多大的影响。然而，你会发现，如果是跟运行多个应用程序的Ubuntu相比，某些风险漏洞会大大降低。
为什么会有所不同呢?答案就是Linux容器。这个有趣的概念是由曾经那些很喜欢使用Heroku的人在阅读指南时提出来的，现在已经成为Docker的核心了。随之而来的是一个广为人知的安全特性名词:隔离。
试想一下在服务器中远程执行代码的最坏情况。听起来太牵强?查看ImageTragick。应用程序趋向于与容器有一对一的关系。应该将那些能够对该应用程序域产生破坏的进行隔离，保留选择在主机上运行的其他内容。
这与VM(虚拟机)在相当长的一段时间内提供的特性非常类似。VM有一个比较僵化的特性，需要更长的启动和供应时间，以及运行完整的操作系统。
人们几乎可以原谅，给他们更长的生命周期，对待他们更像宠物而不是牛。这允许运行更多的应用程序，并可能带来更多秘密的妥协。
在运行集装箱化应用程序的同时，降低了这种风险，这并不是说你就是对开发商的不当行为不管不顾了。例如，您不希望妥协访问主机的Docker守护程序。 但总而言之，集装箱化的环境确实有助于减少攻击面。
只要保持谨慎，不要让你的照片公开出来。
那么，Docker是一条通往天堂的丝绸之路吗?不是。
在Docker把粗糙的问题解决完之前我们能不能先用更稳定的工具来解决?可能。
作为创业公司，如果没有采用Docker，会不会肯定失败呢?绝对不会。
是否需要再投资采用容器?我会大声的告诉你“绝对需要”。
这些观点远不是初创公司独有的。我想说这些与公司的规模无关。请放心，我的想法绝不会损害Docker在公司中的声誉。
我们并不主张Docker是解决这些一直存在得问题的唯一方法。我们还没有怎么讨论它的缺点。
但就目前而言，它仍然是最接近我们上面提到的所有常见问题的一站式解决方案。
（来源网络，著作权归原作者所有。不代表本公众号立场）
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
今日搜狐热点