2018年Docker調(diào)查報(bào)告分析

隨著越來越多的組織轉(zhuǎn)向devops和微服務(wù)模型，并在這樣的現(xiàn)代堆棧中獲得更多專業(yè)知識(shí)，Docker容器生態(tài)系統(tǒng)每年都有巨大的發(fā)展變化。Sysdig發(fā)布的第二個(gè)年度Docker使用情況報(bào)告，顯示了容器環(huán)境特有的更多活動(dòng)，更多擴(kuò)展和生命周期屬性。

該報(bào)告基于從生產(chǎn)環(huán)境的90,000個(gè)容器中收集的實(shí)際數(shù)據(jù)，是去年樣本量的兩倍，并在多個(gè)垂直行業(yè)廣泛分布。公司規(guī)模從北美，拉丁美洲，歐洲，中東和非洲以及亞太地區(qū)的中型市場到大型企業(yè)。

該研究的數(shù)據(jù)來自Sysdig Monitor和Sysdig Secure云服務(wù)報(bào)告的容器使用情況的時(shí)間點(diǎn)快照，這些工具可以監(jiān)視容器之間的系統(tǒng)調(diào)用及其主機(jī)環(huán)境，以提供有關(guān)容器的信息。

以下是主要調(diào)查結(jié)果的摘要。這里有五個(gè)有助于透視容器使用趨勢：

1.Apps

毫不奇怪，用戶始終致力于開源工具來構(gòu)建他們的微服務(wù)和應(yīng)用程序。Java虛擬機(jī)(JVM)位于配置文件容器中的應(yīng)用程序組件列表的頂部。雖然Java已經(jīng)長期依賴于應(yīng)用程序服務(wù)，但很明顯Java和容器作為現(xiàn)代交付模型聚集在一起。

在容器中運(yùn)行的PostgreSQL和MongoDB等數(shù)據(jù)庫的使用也在增加，這表明移動(dòng)是在容器中的有狀態(tài)服務(wù)。容器的短暫性質(zhì)使許多人擔(dān)心運(yùn)行收集有價(jià)值的公司數(shù)據(jù)的服務(wù)，但隨著組織開始轉(zhuǎn)向完全由容器驅(qū)動(dòng)的環(huán)境，這種擔(dān)憂似乎變得緩和。

2.Runtime

Docker仍然占據(jù)主導(dǎo)地位，但其份額從去年的99%下降到今年的83%，因?yàn)槠渌萜鱎untime獲得了立足點(diǎn)。來自CoreOS的Rkt(最近被Red Hat收購)獲得了最多，攀升至12%的份額，而Mesos的容器工具份額達(dá)到4%。LXC 1%也增長，但速度明顯較低。但很顯然，公司越來越習(xí)慣在生產(chǎn)中使用非Docker解決方案。

3. Orchestrators

Kubernetes仍然是最常用的Orchestrators(51%)的領(lǐng)先地位，這并不意外，因?yàn)槭袌鏊坪跞娼邮芰薑ubernetes。微軟，亞馬遜，IBM，當(dāng)然谷歌為他們的云容器服務(wù)提供Kubernetes，甚至Docker和Mesosphere也為Kubernetes增加了支持和功能。

Docker Swarm在今年的研究中以11%的比例進(jìn)入了第二位，超過了基于Mesos的工具，Mesos從去年的9%下降到本報(bào)告中的4%。鑒于Docker接受了Kubernetes，這是出乎意料的。但Swarm的進(jìn)入門檻非常低，因此隨著越來越多的人開始使用容器，這可能是編排的第一站。

我們還著手確定集群大小是否會(huì)影響組織可能選擇的Orchestrators。雖然基于Mesos的編排(包括Mesos Marathon和Mesosphere DC / OS)在本研究中降至第三，但使用Mesos部署的容器的中位數(shù)比Kubernetes環(huán)境高50%。鑒于Mesos傾向于針對大規(guī)模容器和云部署，這是有道理的。因此，盡管數(shù)量較少，但Mesos集群通常是企業(yè)級的。相反，與Kubernetes相比，Swarm集群小30%。

今年，我們還按品牌剖析了Kubernetes的使用情況，以查看使用的版本是上游開源版本還是特定供應(yīng)商提供的軟件包。我們發(fā)現(xiàn)開源Kubernetes繼續(xù)占據(jù)最大份額，但看起來OpenShift正在取得進(jìn)展，Rancher也取得了一些進(jìn)展。

4.密度

從裸機(jī)和以VM為中心的環(huán)境向容器過渡的催化劑之一是有效利用服務(wù)器資源的承諾。與2017年的報(bào)告相比，每位客戶每個(gè)主機(jī)的容器中位數(shù)從10個(gè)增加到15個(gè)。最高的，在本次調(diào)查中，我們看到一個(gè)組織在一臺(tái)主機(jī)上運(yùn)行154個(gè)容器! 這比我們?nèi)ツ暧^察到的95還要多。

5.壽命

由于有很多關(guān)于容器快速生成和終結(jié)的行業(yè)討論，我們決定研究容器，容器鏡像和基于容器的服務(wù)的生命周期。容器存活多久? 不久：

17%不到一分鐘

78%不到一個(gè)小時(shí)

89%不到一天

95%不到一周

最大的一類--27%，是在5到10分鐘之間消失的容器。

為什么容器壽命如此之短?我們知道許多客戶擁有可根據(jù)需要進(jìn)行擴(kuò)展的架構(gòu)系統(tǒng)，只有在增加價(jià)值的情況下才能生存。容器被創(chuàng)建，完成他們的工作，然后消失。例如，一個(gè)客戶為其在Jenkins中創(chuàng)建的每個(gè)作業(yè)開啟一個(gè)容器。它測試更改，然后關(guān)閉容器。對于該客戶，這種情況每天發(fā)生數(shù)千次。

我們還研究了容器鏡像的使用時(shí)間。通過查看這些數(shù)據(jù)，我們可以了解客戶部署更新容器的頻率，作為其DevOps CI / CD流程的一部分?？偟膩碚f，69%的鏡像在一周內(nèi)更新。

當(dāng)談到服務(wù)的生命周期時(shí)，在Kubernetes中，服務(wù)抽象定義了一組pod，它們提供特定的功能以及如何訪問它們。服務(wù)允許pod在不影響應(yīng)用程序的情況下死亡和復(fù)制。大多數(shù)服務(wù)占67%超過一周。容器可能來來往往，但大多數(shù)公司都希望服務(wù)能夠保持穩(wěn)定，因?yàn)閼?yīng)用程序可以全天候工作。

今年的研究表明，組織仍在嘗試新堆棧中的不同層，但很明顯，容器在計(jì)算環(huán)境中扮演著越來越重要和獨(dú)特的角色。