本次分享從以下三方面進(jìn)行：使用Docker對(duì)OpenStack平臺(tái)壓力測(cè)試實(shí)踐、使用Docker加速Sahara-Hadoop、Docker在 Nova項(xiàng)目的使用和實(shí)踐。

無(wú)Docker不OpenStack，當(dāng)前討論OpenStack總是離不開(kāi)Docker。這里我先嚼一下剩飯，下面是OpenStack上Docker技術(shù)分布的老圖。

我們包括生產(chǎn)化/測(cè)試/調(diào)研階段的Docker化項(xiàng)目包括了：Heat、Magnum、Sahara、Nova、以及OpenStack平臺(tái)本身的自動(dòng)打包和平臺(tái)穩(wěn)定性測(cè)試方面。

1. Docker OpenStack平臺(tái)穩(wěn)定性測(cè)試

OpenStack平臺(tái)本身是一個(gè)SOA的項(xiàng)目，具體服務(wù)的參數(shù)設(shè)置需要依據(jù)集群規(guī)模，服務(wù)搭建架構(gòu)等進(jìn)行相關(guān)測(cè)試和調(diào)優(yōu)。Fake是OpenStack Nova Compute下的一個(gè)Driver，絕大多數(shù)Compute API走到這里簡(jiǎn)單處理后返回成功。

我們使用Docker來(lái)封裝Nova Compute，并在Nova 配置中使用Fake。這樣每個(gè)Docker Container便成為一個(gè)虛擬的Nova Hypervisor Node, 便可以模擬Controller集群管理超大量Compute節(jié)點(diǎn)的狀況;同時(shí)Fake Driver 收到請(qǐng)求直接返回成功的特性，讓我們可以測(cè)試超大量的VM同時(shí)創(chuàng)建和同時(shí)銷毀時(shí)給控制節(jié)點(diǎn)和MQ帶來(lái)的壓力狀況。

這里Docker模擬了物理服務(wù)器，解決了測(cè)試服務(wù)器不足的狀況。這只是一個(gè)測(cè)試?yán)樱捎跍y(cè)試的不同需求，可能 Nova Fake需要頻繁的變更配置，Docker 的快速啟動(dòng)和快速銷毀也提供了變更測(cè)試環(huán)境的便利，Dockerfile的定制化需求不僅為鏡像頻繁變更帶來(lái)方便也讓測(cè)試環(huán)境本身更易追溯。

2. OpenStack 自動(dòng)打包

個(gè)人認(rèn)為私有云平臺(tái)壓力通常沒(méi)有公有云高，但是個(gè)性化定制更強(qiáng)。我們內(nèi)部的定制化需求也很高(例如集群中計(jì)算資源的主機(jī)級(jí)別和機(jī)架級(jí)別的反親和等等)。OpenStack的平臺(tái)的組件需要頻繁更新。

我們內(nèi)部使用的是Puppet推送RPM更新的方式進(jìn)行，且維護(hù)了兩個(gè)OpenStack的版本，大量編譯的依賴和依賴的沖突以及編譯后的臟數(shù)據(jù)成為我們的痛點(diǎn)。于是我們將OpenStack所涉及的包括Nova、Neutron、Glance、Cinder、Trove、Sahara等等項(xiàng)目的編譯依賴環(huán)境統(tǒng)統(tǒng)放進(jìn)一個(gè)Docker Image中。

我們維護(hù)了一個(gè)腳本，通過(guò)參數(shù)來(lái)指定要編譯的OpenStack的版本和組件。該腳本會(huì)自動(dòng)從Docker Registry服務(wù)器中pull一個(gè)指定版本的的編譯環(huán)境鏡像。并將GIT服務(wù)器其中指定版本的分支代碼clone到容器中，通過(guò)掛卷的方式將編譯后的 RPM包輸出到外部打包服務(wù)器上。編譯結(jié)束后輸出編譯的狀態(tài)結(jié)果。

這樣我們便不需要再維護(hù)一個(gè)編譯環(huán)境了，只需要維護(hù)編譯鏡像和GIT庫(kù)內(nèi)部源碼?？梢栽谌我夤P記本環(huán)境來(lái)生成打包環(huán)境。

3. Docker 加速 Sahara

Sahara是OpenStack中 "大數(shù)據(jù)即服務(wù)"的項(xiàng)目，支持Hadoop、Spark、CDH 5.x等。通過(guò)Heat編排可以使用KVM或者Docker作為計(jì)算資源。我們測(cè)試使用了Hadoop的服務(wù)，通過(guò)運(yùn)行KVM和Docker的測(cè)試，Docker在啟動(dòng)速度、資源利用率、以及性能開(kāi)銷上具有優(yōu)勢(shì)，我這里簡(jiǎn)單羅列一下測(cè)試對(duì)比。

基本測(cè)試環(huán)境：

• 服務(wù)器：2臺(tái) 24Core 128G memory
• hadoop： 1.2
• job：*streaming MapperReduce
• 集群規(guī)模10

KVM測(cè)試數(shù)據(jù)

Docker測(cè)試數(shù)據(jù)

說(shuō)明：

1. 不同的配置參數(shù)，不同的MapReduce程序，Hadoop計(jì)算的時(shí)間都不相同，這里只是給出在相同環(huán)境下Docker和KVM建的差別。
2. Docker的測(cè)試數(shù)據(jù)是在Container內(nèi)部的。

4. Docker Nova項(xiàng)目

這個(gè)是大家爭(zhēng)議最大的項(xiàng)目，不過(guò)對(duì)于我們平臺(tái)來(lái)說(shuō)，服務(wù)云化這是第一步。需要其他開(kāi)發(fā)團(tuán)隊(duì)逐步熟悉面向容器的開(kāi)發(fā)以及我們對(duì)Docker本身逐步的摸索，才敢真正把環(huán)境切換到Kubernetes/Mesos上來(lái)，進(jìn)而推進(jìn)Magnum。借用京東鮑永成的那句話：”讓能夠接受新世界的團(tuán)隊(duì)慢慢先適應(yīng)“。

通過(guò)Nova API調(diào)度Nova Compute生產(chǎn) Nova instance，而Nova instance的類型由具體配置的hypervisor Driver來(lái)決定，這里我們?cè)O(shè)置Docker作為Driver就可以讓Nova Compute節(jié)點(diǎn)生產(chǎn)Docker。Nova Docker項(xiàng)目來(lái)自于社區(qū)，我們結(jié)合社區(qū)代碼進(jìn)行了一定量的修改，并且在鏡像定制，具體使用上有一些自己不同的方式。

承載業(yè)務(wù)方面：

Nova Docker這塊目前最主要的是Tomcat的服務(wù)，Docker用于搭建java tomcat運(yùn)行環(huán)境 dockerfile中將jdk和tomcat安裝好，之后Docker啟動(dòng)后通過(guò)ansible-playbook 個(gè)性化修改Tomcat配置，推送war包至遠(yuǎn)程容器.

鏡像方面：

1. 引入Supervisor作為進(jìn)程管理器。
2. 設(shè)計(jì)了3層的鏡像管理格式，最底層為最小化系統(tǒng)，中間層引入了公司yun源，入侵檢測(cè)設(shè)置、ssh/pam等安全設(shè)置。 上層可以最小化的實(shí)現(xiàn)APP的環(huán)境版本管理。支持了Tomcat/Cloudinit/Hadoop的完全或者初步測(cè)試使用。
3. 設(shè)計(jì)了Docker的hostname、dns、網(wǎng)卡名稱每次都重置的問(wèn)題，提供固化機(jī)制。
4. Container實(shí)現(xiàn)了支持類似于物理機(jī)的FirstBoot和init機(jī)制。
5. Glance管理Docker鏡像和Docker快照鏡像。

計(jì)算方面：

1. 支持Compute節(jié)點(diǎn)配置的超分，Docker節(jié)點(diǎn)能夠超分相對(duì)KVM更多的CPU/MEM等資源。
2. Nova配置文件設(shè)置cpushare、cpuset、cpumix三種cpu的管理模式，可以針對(duì)不同模式的Container環(huán)境來(lái)設(shè)置CPU模式。
3. nova 配置為主機(jī)預(yù)留CPU，保證Container不會(huì)侵占預(yù)留資源。
4. 上層鏡像開(kāi)機(jī)隨機(jī)生成用戶UID，避免映射到宿主機(jī)相同的UID。
5. NOVA 配置不同的Docker API版本。
6. 快照、快照恢復(fù)、遷移等基本實(shí)現(xiàn)。
7. 支持通過(guò)flavor配置元數(shù)據(jù)，生成一組類似于Kubernetes 的pod。

存儲(chǔ)：

1. 使用Direct LVM代替 Docker默認(rèn)loop模式，增強(qiáng)穩(wěn)定性。
2. 初步支持了Container掛卷的Feature。
3. 依據(jù)不同的OpenStack Aggregate 設(shè)置不同的Contianer存儲(chǔ)空間。

網(wǎng)絡(luò)：

1. Docker使用OpenStack的網(wǎng)絡(luò)組建Neutron網(wǎng)絡(luò)提供Vlan服務(wù)。
2. Docker配置ovs直連和混在模式。



3. Docker支持安全組的添加、刪除、查詢、更新等操作。
4. Switch APR Proxy 老化時(shí)間過(guò)問(wèn)題，開(kāi)機(jī)發(fā)送free arp。
5. 虛擬網(wǎng)卡TSO的自動(dòng)關(guān)閉。
6. 解決Docker的hostname、dns、網(wǎng)卡名稱每次都重置的問(wèn)題，提供固化機(jī)制。
7. 網(wǎng)絡(luò)限流。

5. 遇到的問(wèn)題

5.1 幽靈容器問(wèn)題

我們環(huán)境中早期的Docker是1.5版本的，在升級(jí)1.7的時(shí)候，部分container的進(jìn)程從容器逃逸，容器處于Destroyed狀態(tài)，容器進(jìn)行任何stop、remove都會(huì)出現(xiàn)如下報(bào)錯(cuò)：

Container does not exist：container destroyed。這是個(gè)社區(qū)已知的問(wèn)題，目前社區(qū)沒(méi)有完整的解決方案。升級(jí)過(guò)程中先關(guān)閉老的容器后再升級(jí)Docker可以避免該問(wèn)題。出現(xiàn)問(wèn)題之后要恢復(fù)相對(duì)麻煩。

5.2 用戶隔離不足

我們測(cè)試環(huán)境中，容器密度較大。Container新建用戶對(duì)外全部映射為 UID 500或者501，出現(xiàn)了Resource Temporarily unavailable。

CentOS默認(rèn)用戶UID從500開(kāi)始，雖然ulimit設(shè)置上限是相對(duì)獨(dú)立的，但是統(tǒng)計(jì)已經(jīng)使用資源時(shí)卻是一起統(tǒng)計(jì)的。所以在密度較大的測(cè)試和預(yù)生產(chǎn)環(huán)境可能會(huì)出現(xiàn)這樣的問(wèn)題。我們的解法是在我們添加的FirstBoot中創(chuàng)建一個(gè)隨機(jī)UID的用戶。這樣相同的鏡像創(chuàng)建出的用戶UID也不同。大家各自統(tǒng)計(jì)，盡可能避免問(wèn)題。

5.3 NFS Server無(wú)法啟動(dòng)

這個(gè)問(wèn)題是兩個(gè)小問(wèn)題：

1. kernel模塊的reload設(shè)置。
2. kthreadd創(chuàng)建進(jìn)程。

第一個(gè)問(wèn)題代表了一系列問(wèn)題，這個(gè)是由于因?yàn)槲募到y(tǒng)沒(méi)有kernel的目錄，模塊依賴關(guān)系無(wú)從查起。通常此類服務(wù)都可以在配置文件中關(guān)閉模塊的 reload過(guò)程，例如NFS就可以配置。第二個(gè)問(wèn)題是rpc.nfsd 通知kernel去建立nfsd服務(wù)，kernel通過(guò)kthreadd來(lái)創(chuàng)建nfsd服務(wù)。所以nfsd進(jìn)程不會(huì)出現(xiàn)在Container內(nèi)部，而是暴露在宿主機(jī)上。

5.4 線程數(shù)量上限" fork: Cannot allocate memory"

我們的環(huán)境中出現(xiàn)過(guò)1次，表現(xiàn)為宿主機(jī)無(wú)法ssh登錄，通過(guò)IPMI Console進(jìn)行登錄閃斷。這個(gè)問(wèn)題原因是由于某個(gè)應(yīng)用的問(wèn)題導(dǎo)致生成大量的線程，達(dá)到了系統(tǒng)線程的上線。

我們認(rèn)為：

1. pid_max 和 threads-max 值如何設(shè)置不影響單個(gè)進(jìn)程的線程數(shù)量，上限目前為32768。
2. pid_max 和 threads-max 影響所有線程的總量，二者較小者為系統(tǒng)上限。超過(guò)系統(tǒng)上限后部分系統(tǒng)命令都無(wú)法使用。
3. 調(diào)整系統(tǒng)上限后雖然可以有更多的線程，但是太多的線程將會(huì)對(duì)系統(tǒng)穩(wěn)定性造成影響。

解決思路

1. 環(huán)境中所有宿主機(jī)將/proc/sys/kernel/pid-max設(shè)置為65535，并通過(guò)nagios監(jiān)控告警宿主機(jī)上的線程數(shù)量。
2. 從應(yīng)用層(tomcat)限制線程上限。

5.5 .device mapper discard導(dǎo)致的宕機(jī)

這個(gè)問(wèn)題反復(fù)出現(xiàn)在某些服務(wù)器上，宕機(jī)重啟后通過(guò)IPMI consule進(jìn)入時(shí)系統(tǒng)已經(jīng)重新掛載了CoreDump的Kernel，看到CoreDump生成dump之前進(jìn)行Recover操作和Data Copying操作，導(dǎo)致恢復(fù)時(shí)間很慢。通過(guò)Coredump分析屬于Kernel在DM discard方面的一個(gè)BUG，方法為禁用docker devicemapper的discard。具體為設(shè)置Docker啟動(dòng)參數(shù)"--storage-opt dm.mountopt=nodiscard --storage-opt dm.blkdiscard=false”。該問(wèn)題已經(jīng)在多個(gè)公司分享中看到，解決思路也基本一致。

6. 未來(lái)

1. Cobbler puppet in Docker 快速部署OpenStack 。
2. Magnum + Kubernetes的微服務(wù)架構(gòu)管理。
3. Neutron 插件服務(wù)用Docker替換 Netns。

Q&A

Q ：能否詳細(xì)敘述一下幽靈容器問(wèn)題?

A：從低于1.5(包括1.5)向高于1.6及其以上進(jìn)行docker daemon過(guò)程中，如果沒(méi)有關(guān)閉所有的Containe。那么當(dāng)高版本Docker Daemon啟動(dòng)后再次start新的Container時(shí)，這些Container將無(wú)法關(guān)閉。大量操作都會(huì)報(bào)錯(cuò)。

執(zhí)行stop或者remove命令將會(huì)有如下報(bào)錯(cuò)：Server Error: Internal Server Error ("Cannot stop container XXX: [2] Container does not exist: container destroyed")

Remote API 針對(duì)該Contianer的報(bào)錯(cuò)如下：json, stats, changes, top, logs returned valid responses;stop, pause, wait, kill reported 404 (!)

復(fù)現(xiàn)方法：

1. 在1.5版本的Docker中run一個(gè)Container。
2. 將docker daemon升級(jí)為1.7。
3. 重新start該Container。
4. 嘗試執(zhí)行stop 該 Container。
5. 高版本Docker的升級(jí)過(guò)程：
6. 當(dāng)docker Daemon非正常關(guān)閉的情況下，所有Container首進(jìn)程都會(huì)失去父進(jìn)程，從而被 init 收養(yǎng)。此時(shí)Contaienr內(nèi)部進(jìn)程逃逸。
7. 當(dāng)docker Daemon重新啟動(dòng)時(shí)，將會(huì)針將已經(jīng)處于關(guān)閉狀態(tài)的Container原有已經(jīng)逃逸的進(jìn)程 Kill 掉。

1.5版本之前向高版本升級(jí)過(guò)程：

1. 當(dāng)docker Daemon非正常關(guān)閉的情況下，所有Container首進(jìn)程都會(huì)失去父進(jìn)程，從而被 init 收養(yǎng)。此時(shí)Contaienr內(nèi)部進(jìn)程逃逸。
2. 當(dāng)docker Daemon重新啟動(dòng)時(shí)，Docker Daemon 無(wú)法殺死老版本Docker創(chuàng)建的現(xiàn)在已經(jīng)逃逸的進(jìn)程。
3. 當(dāng)逃逸進(jìn)程對(duì)應(yīng)的Container啟動(dòng)時(shí)，逃逸進(jìn)程將會(huì)和新進(jìn)程同時(shí)存在。
4. 當(dāng)該Contaienr關(guān)閉時(shí)，新進(jìn)程被殺死，逃逸進(jìn)程依舊存活。Container標(biāo)記Destroyed。

解決方案：

1. 目前來(lái)看方案如下只能重啟物理服務(wù)器來(lái)解決。由于我們內(nèi)部Contianer首進(jìn)程一定是Supervisor，可以先關(guān)閉Docker Daemon后殺死全部的幽靈Supervisor后再重啟Docker Daemon后就沒(méi)問(wèn)題了。
2. 預(yù)防方案還是要在升級(jí)過(guò)程中，保證關(guān)閉所有的Container，首先保證不會(huì)有逃逸進(jìn)程，從而避免形成Ghost Container。

Q：Hostname DNS 貴方 用什么方案固定?

A：首先Container創(chuàng)建之初，hostname和DNS都是通過(guò)Docker API來(lái)設(shè)置的。Hostname是nova instance的name，DNS是公司內(nèi)部設(shè)置。如果想修改Container默認(rèn)設(shè)置也是可以的，我們?cè)趦?nèi)部鏡像預(yù)留了一個(gè)目錄，該目錄下的 hosts、hostname、DNS如果存在都會(huì)在Container啟動(dòng)后主動(dòng)覆蓋Container外部掛載的內(nèi)容。

Q：在使用Docker去封裝nova compute模擬大規(guī)模集群測(cè)試時(shí)，運(yùn)行一段時(shí)間后總出現(xiàn)部分使用Docker封裝的nova compute服務(wù)出現(xiàn)down的狀態(tài)，不知道你們是否遇到過(guò)這樣的問(wèn)題?

A：我們這邊沒(méi)有遇到，有沒(méi)有可能是模擬的nova compute進(jìn)程數(shù)量過(guò)多消息有所積壓。NOVA方面考慮增加NOVA時(shí)間戳超時(shí)設(shè)置。Docker方面建議Docker的網(wǎng)絡(luò)使用host模式，并在 NOVA配置文件中設(shè)置不同的host，以便成為不同的hypervisor node。

Q：Sahara在使用Docker替代KVM創(chuàng)建Hadoop集群時(shí)，是直接使用heat創(chuàng)建Docker，還是使用nova-docker?Sahara相關(guān)的代碼是否需要改動(dòng)，遇到過(guò)哪些坑?

A：我們是使用nova docker的driver創(chuàng)建docker container的，Sahara本身相關(guān)的代碼有部分改動(dòng)，但是不大，主要改動(dòng)在使用container和虛機(jī)的差別，比如hostname、cloudinit的部分配置等等。

Q：Docker 的網(wǎng)絡(luò)模式中，中間添加一層linux bridge的原因是什么，這么做是否會(huì)有性能問(wèn)題?

A：這個(gè)還是為了安全組，實(shí)際上我們支持配置兩種模式，linux bridge并不是默認(rèn)配置的。OpenvSwitch 2.4以后可以根據(jù)流表設(shè)置安全組。

Q：Container限速是如何實(shí)現(xiàn)的，是否有必要針對(duì)Container進(jìn)行限速?

A：我們的環(huán)境中使用的OpenvSwitch，通過(guò)veth pair的方式建立虛擬網(wǎng)絡(luò)設(shè)備的關(guān)系。限速主要是使用tc，畢竟OpenvSwitch的限速也是使用tc做的。

Q：NOVA組件中Docker的高級(jí)特性無(wú)法使用你怎么看，是否使用docker api來(lái)控制容器?

A：上面已經(jīng)說(shuō)過(guò)這個(gè)問(wèn)題了，其實(shí)通過(guò)flavor metadata的設(shè)置，nova docker driver 可以實(shí)現(xiàn)生成一組容器。nova docker這塊過(guò)去確實(shí)是直接調(diào)用Docker API的，但是為了應(yīng)對(duì)不斷變化的API，我們使用了docker-py作為Client，并在nova 配置文件中增加了API版本的設(shè)置。從而盡可能拿到Docker本身升級(jí)帶來(lái)的福利。

Q：OPS已經(jīng)有超分設(shè)置，你設(shè)置超分的意義是什么?

A：我們Docker和KVM都在一個(gè)openstack平臺(tái)中，而nova的超分實(shí)在NOVA Conductor中生效的。Nova compute Libvirt Driver是直接上報(bào)的服務(wù)器核數(shù)。而我們認(rèn)為Docker在密度上存在比KVM密度更高的需求，所以在Compute上支持超分是有必要的。

Q：使用CPU share是否會(huì)出現(xiàn)單個(gè)容器負(fù)載很高的場(chǎng)景，出現(xiàn)這種情況如何處理?

A：還是會(huì)出現(xiàn)的，記得有個(gè)容器CPU占用1600%的場(chǎng)景(32核心)。通常這種情況還是應(yīng)用出現(xiàn)了問(wèn)題，最簡(jiǎn)單的方法是通過(guò) cgroup本身的命令進(jìn)行限制。容器重啟之后該限制就會(huì)丟失。限制方法例如： cgset -r cpuset.cpus=20-23 cpuset:/docker/91d943c55687630dd20775128e2ba70ad1a0c9145799025e403be6c2a7480cb2

Q：Docker 的監(jiān)控和scale-auto是如何實(shí)現(xiàn)的?

A：監(jiān)控方面目前主要是通docker stats api 和 部分腳本來(lái)實(shí)現(xiàn)，集成到Zabbix中，后面會(huì)考慮使用CAdvisor。

后者目前不支持，計(jì)劃上會(huì)在Kubernetes平臺(tái)中支持，而非heat或NOVA中。畢竟這是Kubernetes、Mesos它們的專長(zhǎng)。

Q：你的三層鏡像中，第一層和第二層都是系統(tǒng)層，為什么不合并成為一層?

A：首先我們的第一層鏡像并不是通過(guò)dockerfile創(chuàng)建的，而是依據(jù)官方文檔從0建立的最小的鏡像，這一層是很少變動(dòng)的。而第二層的設(shè)置是為上層設(shè)計(jì)的通用層，涉及到進(jìn)程管理器、SSH設(shè)置、pam設(shè)置、入侵檢測(cè)設(shè)置、開(kāi)機(jī)初始化設(shè)置、還是有很大可能變動(dòng)的，我們希望有關(guān)配置都應(yīng)該放入dockerfile以便管理。

Q：nova-docker如何支持cloudinit?

A：因?yàn)樵趎ovadocker中就是完全模擬KVM的網(wǎng)絡(luò)模式，所以cloudinit除了一些小幅配置變更之外沒(méi)有什么特殊的。

sed -e 's/disable_root./disable_root: 0/' -e 's/ssh_pwauth./ssh_pwauth: 1/' -e '/ssh_pwauth:/a\ndatasource:\n OpenStack:\n max_wait: 120\n timeout:30' cloud.cfg

Q：能否詳細(xì)介紹下ARP問(wèn)題?

A：由于建立的vm的ip之前分配給了已經(jīng)刪除的vm，導(dǎo)致mac被記錄在交換機(jī)上。數(shù)據(jù)交換經(jīng)過(guò)3層，3層交換機(jī)會(huì)將mac直接返回給ping的一方，導(dǎo)致無(wú)法ping通、

啟動(dòng)container后通過(guò)arping -c 3 -f -U -I eth0 172.28.19.243 -c 3開(kāi)機(jī)發(fā)送免費(fèi)arp來(lái)處理。

Q：NOVA Docker實(shí)現(xiàn)了熱遷移嗎?如何做快照?

A：熱遷移目前還沒(méi)有支持，nova docker快照就是將容器commit成一個(gè)鏡像，然后使用glance的接口上傳glance中。通過(guò)快照可以重新建立新的container。

Q：nova-docker不是早在H版本就廢棄了嗎?你們自己維護(hù)的?

A：確實(shí)廢棄了，我們自己維護(hù)。不過(guò)GitHub上有了更新，我們剛剛merge機(jī)那里一些特性?？梢栽訇P(guān)注一下。

Q：OpenStack 如何對(duì)novadocker環(huán)境的container進(jìn)行監(jiān)控?在監(jiān)控指標(biāo)上是否與其他hypervisor driver有區(qū)別?

A：監(jiān)控方面目前主要是通docker stats api 和 部分腳本來(lái)實(shí)現(xiàn)，集成到Zabbix中，后面會(huì)考慮使用CAdvisor。監(jiān)控上有一些區(qū)別。主要是pid_max、docker daemon存活，和Docker自身存儲(chǔ)pool等Docker特有的，其他方面沒(méi)有太大區(qū)別。

Q：您好，貴公司只維護(hù)Git代碼和鏡像容器。請(qǐng)問(wèn)假如同一個(gè)編譯環(huán)境，能編譯不同操作系統(tǒng)版本的庫(kù)嗎?或者鏡像。因?yàn)橥惶状a會(huì)部署到不同的系統(tǒng)上?

A：我們這條編譯環(huán)境只是用來(lái)編譯OPS本身的，如果需要增加新的編譯環(huán)境，我們會(huì)向Registry推送一個(gè)新的編譯鏡像。

Q：glance管理鏡像和快照時(shí)有沒(méi)有能用到Docker的分層?如果有，如何利用的?

A：沒(méi)有，tar包形式，compute節(jié)點(diǎn)下載之后load到compute節(jié)點(diǎn)上。

Q：生產(chǎn)環(huán)境相比測(cè)試環(huán)境有什么不同嗎?

A：Docker在CPU超分系數(shù)不同，系統(tǒng)pid_max等調(diào)優(yōu)參數(shù)略有不同。

Q：Nova Docker快照是如何實(shí)現(xiàn)的?

A：將操作的Container commit成為一個(gè)鏡像，并上傳到glance中。