蓝海云 Docker 2017 用户使用报告分析(图文)


许多Docker使用报告是基于用户调查。 这些对于理解意图和目标是非常有用的,但有时与人们目前在现有环境如何使用Docker 不一致。通过上万个真实的Docker 使用数据分析发现,无论在规模上还是复杂程度上Docker都呈现增长趋势。


这里的数据代表2017年客户行为。涵盖所有环境的数据以提供客户目前如何使用Docker容器的独特洞察。  该分析不代表整个市场而只是针对现有用户数据。


Docker使用情况调查的样本量


Docker6.jpg


监控数据对45,000 Docker 容器使用做了分析。



容器使用密集度


Docker8.JPG


许多团队在使用容器时看到的最初优势之一是与hypervisors相比,它们能够提供“轻量级虚拟化”。轻量级本质意味着它们可以在高容器密度下运行,更好地利用底层的物理资源,从而节省资金。

 

我们想知道用户是否真的看到了这种好处。其中一个问题是“在现有环境中运行容器的中位数是多少?” 以每台主机10个容器的中位数计算,这似乎是Docker用户开始看到一些密度的好处。注意,求出这个中位数是一个两步的过程:这个中位数是通过首先计算每个客户的每个主机的平均容器数来得出的,然后计算客户的中位数。我们还看到了非常广泛的部署密度。

 

我们看到一些客户每台主机运行高达95个容器,其他则在每个主机上运行单一容器。后一种情况,虽然听起来可能不寻常,但有其深层的逻辑。与这些客户交谈时,我们了解到他们的核心软件使用机器上的所有资源。对他们而言容器化的好处不是提供容器密度,相反它是一种更快开发、部署和扩展软件的能力,Docker价值不可忽略。


用什么编排Docker容器

D1.webp.jpg


Kubernetes的流行并不令人惊讶。在采用Docker这一阶段,我们看到Kubernetes率先与其他编排厂商抗衡。然而,随着Swarm较新版本的推出以及开放DC/OS背后越来越多的努力,我们看到越来越多的编排平台在使用。在我们所分析的客户群中虽然这些平台还没有Kubernetes,但预计随着这些平台的成熟,竞争将持续下去。


举例: 

· Kubernetes 包括 Openshift, Tectonic 及其他

· Mesos包括 Mesosphere DC/OS

· Swarm 包括老版本及原生Swarm


归在“其他”类别的用户要么不使用编排工具(可能是非常小的部署),要么建立自己的自定义编排, 或者只需使用Docker标签手动管理一切。

随着时间的推移,属于“其他类别”的公司将大幅减少,且这一趋势将继续下去。

 

最流行的容器注册中心

D2.webp.jpg


容器注册表是存储和分发Docker映像的地方。你可以把注册表想象成加油站 - 无论你去哪里,汽油都是一样的,但是有的加油站可能提供像样的咖啡,有的提供免费洗车,还有的是与连锁店合作(这样就可以立刻得到食品和汽油)。

 

使用Docker容器的任何人都可能使用注册表,无论是作为服务还是作为内部软件(也称为私有注册表)。您可以从上面的数字中看出,即使将位居前三位相加总和也并非是使用Docker容器的大多数。这表明注册中心提供的服务非常分散。这里有两个备注:(1)这些百分比是根据容器数量计算的,而不是根据每个客户的注册情况;(2)对于部分样本,数据无法准确识别正在使用的容器注册,所以假定这些都是均匀分布的。

在容器中运行的前12个应用程序组件


D3.webp.jpg


人们究竟在容器里跑什么?上面列出在Docker 容器上运行的12个最常见的应用程序。Nginx, etcd, 及Consul位于三甲。令我们感兴趣的是,Nginx是最受欢迎的。它经常在服务的端点上服务,或者作为传统的负载均衡器使用。还有一点让我们感到惊讶的是,Consul与etcd运行得非常接近,预期他们之间会拉开距离。注意,这些数据并不侧重于编程语言:大多数用户至少用不同的语言编写了一些自定义应用程序代码,如果客户选择编写自己的应用程序检查,我们将这些代码视为“自定义应用程序”。


Docker 容器常用的警报条件


D4.webp.jpg


我们希望更好地理解docker的采用是否改变了人们架设和操作他们的软件的方式。虽然警报并不是理解如此深层次问题的完美方式,但它们确实能让人们了解在生产中是如何思考自己的软件的。最重要的是,这些数据显示,我们正在从主机/物理基础设施警报中迁移,但较早的警报条件仍在使用中。上面的图片显示了最流行的警报条件,没有排名。

考虑到警报条件确实需要与其范围配对(请参阅下一节),最好不要对实际使用的条件进行计数。例如,高CPU/内存/磁盘等靠得住的警告仍然在大量使用中。同时,还有较新的警报条件,这些条件与当今抽象的基础结构更相关。这里的一个很好的例子是“POD Restart Count”。我们还看到了一些适应现代的警报:“Entity is Down”现在除了用于主机之外,还可以跨容器使用,而“High CPU shares”是一个为容器调优的CPU警报。

 

最后,我们看到一些警报没有改变,也不应该改变。关于Response Time of Service的警报和HTTP Error Codes上的警报仍然流行,因为它们代表应用程序的状态,而不仅仅是容器基础结构的状态。这些警报的最大变化往往是它们触发的范围,接下来我们将讨论这些范围。


Docker容器常用警报范围

Docker3 (1).jpg


在检查与客户如何使用Docker容器有关的警报范围时有如下发现:

首先是标签的概念。 这允许DevOps团队为特定目的制作非层次结构的容器组。示例包括环境(开发/生产/测试)、物理位置(云提供区域或数据中心),或微服务名称。


用于显示警报的最常见的标签数是2到3个。实际上,许多警报范围都是跨编排器结构运行的,例如Kubernetes部署、Pod或类似的东西。然而,我们也看到很多人都在使用容器名称,这意味着用户对其基础设施中运行的内容有更多的了解。

 

最后,也看到了一些与物理基础设施相关的重要标签。云提供程序标签通常表示部署的某些物理方面,例如主机、区域或可用性。

 

结论:Docker的使用继续提高


在Docker生态系统中的经验发现用户在其Docker使用规模和复杂程度上都不断进步。这份报告让读者很好地了解用户现在的情况,提供了更多相关的洞察力。


金蓝海科技有限公司 京ICP备18017748号-1