本次主要想分享一下過(guò)去一年時(shí)間里，我們?cè)诮ㄔO(shè)基于Docker的私有云實(shí)踐過(guò)程中，曾經(jīng)遇到過(guò)的問(wèn)題，如何解決的經(jīng)驗(yàn)，還有我們的體會(huì)和思考，與大家共勉。

蘑菇街在生產(chǎn)環(huán)境中使用Docker有一些經(jīng)歷和經(jīng)驗(yàn)。蘑菇街的私有云項(xiàng)目是2014年圣誕節(jié)期間上線的，從無(wú)到有，經(jīng)過(guò)了半年多的發(fā)展，經(jīng)歷了3次大促，已經(jīng)逐漸形成了一定的規(guī)模。

[[154982]]

架構(gòu)

• 集群管理

大家知道，Docker自身的集群管理能力在當(dāng)時(shí)條件下還很不成熟，因此我們沒(méi)有選擇剛出現(xiàn)的 Swarm，而是用了業(yè)界最成熟的OpenStack，這樣能同時(shí)管理Docker和KVM。我們把Docker當(dāng)成虛擬機(jī)來(lái)跑，是為了能滿(mǎn)足業(yè)務(wù)上對(duì)虛擬化的需求。今后的思路是微服務(wù)化，把應(yīng)用進(jìn)行拆分，變成一個(gè)個(gè)微服務(wù)，實(shí)現(xiàn)PaaS基于應(yīng)用的部署和發(fā)布。

通過(guò)OpenStack如何管理Docker?我們采用的是OpenStack+nova-docker+Docker的架構(gòu)模式。nova- docker是StackForge上一個(gè)開(kāi)源項(xiàng)目，它做為nova的一個(gè)插件，通過(guò)調(diào)用Docker的RESTful接口來(lái)控制容器的啟停等動(dòng)作。

我們?cè)贗aaS基礎(chǔ)上自研了編排調(diào)度等組件，支持應(yīng)用的彈性伸縮、灰度升級(jí)等功能，并支持一定的調(diào)度策略，從而實(shí)現(xiàn)了PaaS層的主要功能。

同時(shí)，基于Docker和Jenkins實(shí)現(xiàn)了持續(xù)集成(CI)。Git中的項(xiàng)目如果發(fā)生了git push等動(dòng)作，便會(huì)觸發(fā)Jenkins Job進(jìn)行自動(dòng)構(gòu)建，如果構(gòu)建成功便會(huì)生成Docker Image并push到鏡像倉(cāng)庫(kù)?；贑I生成的Docker Image，可以通過(guò)PaaS的API或界面，進(jìn)行開(kāi)發(fā)測(cè)試環(huán)境的實(shí)例更新，并最終進(jìn)行生產(chǎn)環(huán)境的實(shí)例更新，從而實(shí)現(xiàn)持續(xù)集成和持續(xù)交付。

• 網(wǎng)絡(luò)和存儲(chǔ)

網(wǎng)絡(luò)方面，我們沒(méi)有采用Docker默認(rèn)提供的NAT網(wǎng)絡(luò)模式，NAT會(huì)造成一定的性能損失。通過(guò)OpenStack，我們支持Linux bridge和Open vSwitch，不需要啟動(dòng)iptables，Docker的性能接近物理機(jī)的95%。

• 容器的監(jiān)控

監(jiān)控方面，我們自研了container tools，實(shí)現(xiàn)了容器load值的計(jì)算，替換了原有的top、free、iostat、uptime等命令。這樣業(yè)務(wù)方在容器內(nèi)使用常用命令時(shí)看到的是容器的值，而不是整個(gè)物理機(jī)的。目前我們正在移植Lxcfs到我們的平臺(tái)上。

我們還在宿主機(jī)上增加了多個(gè)閾值監(jiān)控和報(bào)警，比如關(guān)鍵進(jìn)程監(jiān)控、日志監(jiān)控、實(shí)時(shí)pid數(shù)量、網(wǎng)絡(luò)連接跟蹤數(shù)、容器oom報(bào)警等等。

• 冗災(zāi)和隔離性

冗災(zāi)和隔離性方面，我們做了大量的冗災(zāi)預(yù)案和技術(shù)準(zhǔn)備。我們能夠在不啟動(dòng)docker daemon的情況下，離線恢復(fù)Docker中的數(shù)據(jù)。同時(shí)，我們支持Docker的跨物理機(jī)冷遷移，支持動(dòng)態(tài)的CPU擴(kuò)容/縮容，網(wǎng)絡(luò)IO磁盤(pán)IO的限速。

遇到的問(wèn)題及解決方法

接近一年不到的產(chǎn)品化和實(shí)際使用中我們遇到過(guò)各種的問(wèn)題，使用Docker的過(guò)程也是不斷優(yōu)化Docker、不斷定位問(wèn)題、解決問(wèn)題的過(guò)程。

我們現(xiàn)在的生產(chǎn)環(huán)境用的是CentOS 6.5。曾經(jīng)有個(gè)業(yè)務(wù)方誤以為他用的Docker容器是物理機(jī)，在Docker容器里面又裝了一個(gè)Docker，瞬間導(dǎo)致內(nèi)核crash，影響了同一臺(tái)物理機(jī)的其他Docker容器。

經(jīng)過(guò)事后分析是2.6.32-431版本的內(nèi)核對(duì)network namespace支持不好引起的，在Docker內(nèi)創(chuàng)建bridge會(huì)導(dǎo)致內(nèi)核crash。upstream修復(fù)了這個(gè)bug，從2.6.32-431升級(jí)到2.6.32-504后問(wèn)題解決。

還有一個(gè)用戶(hù)寫(xiě)的程序有bug，創(chuàng)建的線程沒(méi)有及時(shí)回收，容器中產(chǎn)生了大量的線程，***在宿主機(jī)上都無(wú)法執(zhí)行命令或者ssh登陸，報(bào)的錯(cuò)是"bash: fork: Cannot allocate memory"，但通過(guò)free看空閑的內(nèi)存卻是足夠的。

經(jīng)過(guò)分析，發(fā)現(xiàn)是內(nèi)核對(duì)pid的隔離性支持不完善，pid_max(/proc/sys/kernel/pid_max)是全局共享的。當(dāng)一個(gè)容器中的pid數(shù)目達(dá)到上限32768，會(huì)導(dǎo)致宿主機(jī)和其他容器無(wú)法創(chuàng)建新的進(jìn)程。***的4.3-rc1才支持對(duì)每個(gè)容器進(jìn)行pid_max限制。

我們還觀察到docker的宿主機(jī)內(nèi)核日志中會(huì)產(chǎn)生亂序的問(wèn)題。經(jīng)過(guò)分析后發(fā)現(xiàn)是由于內(nèi)核中只有一個(gè)log_buf緩沖區(qū)，所有printk打印的日志先放到這個(gè)緩沖區(qū)中，docker host以及container上的rsyslogd都會(huì)通過(guò)syslog從kernel的log_buf緩沖區(qū)中取日志，導(dǎo)致日志混亂。通過(guò)修改 container里的rsyslog配置，只讓宿主機(jī)去讀kernel日志，就能解決這個(gè)問(wèn)題。

除此之外，我們還解決了device mapper的dm-thin discard導(dǎo)致內(nèi)核crash等問(wèn)題。

體會(huì)和思考

***分享一下我們的體會(huì)和思考，相比KVM比較成熟的虛擬化技術(shù)，容器目前還有很多不完善的地方，除了集群管理、網(wǎng)絡(luò)和存儲(chǔ)，最重要的還是穩(wěn)定性。影響穩(wěn)定性的主要還是隔離性的不完善造成的，一個(gè)容器內(nèi)引起的問(wèn)題可能會(huì)影響整個(gè)系統(tǒng)。

容器的memcg無(wú)法回收slab cache，也不對(duì)dirty cache量進(jìn)行限制，更容易發(fā)生OOM問(wèn)題。還有，procfs上的一些文件接口還無(wú)法做到per-container，比如pid_max。

另外一點(diǎn)是對(duì)容器下的運(yùn)維手段和運(yùn)維經(jīng)驗(yàn)的沖擊。有些系統(tǒng)維護(hù)工具，比如ss，free，df等在容器中無(wú)法使用了，或者使用的結(jié)果跟物理機(jī)不一致，因?yàn)橄到y(tǒng)維護(hù)工具一般都會(huì)訪問(wèn)procfs下的文件，而這些工具或是需要改造，或是需要進(jìn)行適配。

雖然容器還不完善，但是我們還是十分堅(jiān)定的看好容器未來(lái)的發(fā)展。Kubernetes、Mesos、Hyper、CRIU、runC等容器相關(guān)的開(kāi)源軟件，都是我們關(guān)注的重點(diǎn)。

#p#

Q&A

Q：請(qǐng)問(wèn)容器間的負(fù)載均衡是如何做的?

A： 容器間的負(fù)載均衡，更多是PaaS和SaaS層面的。我們的P層支持4層和7層的動(dòng)態(tài)路由，通過(guò)域名的方式，或者名字服務(wù)來(lái)暴露出對(duì)外的接口。我們能夠做到基于容器的灰度升級(jí)，和彈性伸縮。

Q：請(qǐng)問(wèn)你們的OpenStack是運(yùn)行在CentOS 6.5上的嗎?

A: 是的，但是我們針對(duì)OpenStack和Docker依賴(lài)的包進(jìn)行了升級(jí)。我們維護(hù)了內(nèi)部的yum源。

Q：請(qǐng)問(wèn)容器IP是靜態(tài)編排還是動(dòng)態(tài)獲取的?

A: 這個(gè)跟運(yùn)維所管理的網(wǎng)絡(luò)模式有關(guān)，我們內(nèi)部的網(wǎng)絡(luò)沒(méi)有DHCP服務(wù)，因此對(duì)于IaaS層，容器的IP是靜態(tài)分配的。對(duì)于PaaS層來(lái)說(shuō)，如果有DHCP服務(wù)，容器的App所暴露出來(lái)IP和端口就可以做到動(dòng)態(tài)的。

Q：請(qǐng)問(wèn)你們當(dāng)時(shí)部署的時(shí)候有沒(méi)有嘗試過(guò)用Ubuntu，有沒(méi)有研究過(guò)兩個(gè)系統(tǒng)間的區(qū)別，另外請(qǐng)問(wèn)你們?cè)贠penStack上是怎樣對(duì)這些虛擬機(jī)監(jiān)控的?

A: 我們沒(méi)有嘗試過(guò)Ubuntu，因?yàn)楣旧a(chǎn)環(huán)境上用的是CentOS。我們的中間件團(tuán)隊(duì)負(fù)責(zé)公司機(jī)器的監(jiān)控，我們和監(jiān)控團(tuán)隊(duì)配合，將監(jiān)控的agent程序部署到宿主機(jī)和每個(gè)容器里，這樣就可以當(dāng)成虛擬機(jī)來(lái)進(jìn)行監(jiān)控。

當(dāng)然，容器的數(shù)據(jù)是需要從cgroups里來(lái)取，這部分提取數(shù)據(jù)的工作，是我們來(lái)實(shí)現(xiàn)的。

Q：容器間的網(wǎng)絡(luò)選型有什么建議，據(jù)說(shuō)采用虛擬網(wǎng)卡比物理網(wǎng)卡有不小的性能損失，Docker自帶的weaves和ovs能勝任嗎?

A: 容器的網(wǎng)絡(luò)不建議用默認(rèn)的NAT方式，因?yàn)镹AT會(huì)造成一定的性能損失。之前我的分享中提到過(guò)，不需要啟動(dòng)iptables，Docker的性能接近物理機(jī)的95%。Docker的weaves底層應(yīng)該還是采用了網(wǎng)橋或者Open vSwitch。建議可以看一下nova-docker的源碼，這樣會(huì)比較容易理解。

Q：靜態(tài)IP通過(guò)LXC實(shí)現(xiàn)的嗎?

A: 靜態(tài)IP的實(shí)現(xiàn)是在nova-docker的novadocker/virt/docker/vifs.py中實(shí)現(xiàn)的。實(shí)現(xiàn)的原理就是通過(guò)ip命令添加 veth pair，然后用ip link set/ip netns exec等一系列命令來(lái)實(shí)現(xiàn)的，設(shè)置的原理和weaves類(lèi)似。

Q：容器內(nèi)的進(jìn)程gdb你們?cè)趺磁?，把gdb打包到容器內(nèi)嗎?

A: 容器內(nèi)的gdb不會(huì)有問(wèn)題的，可以直接yum install gdb。

Q：共享存儲(chǔ)能直接mount到容器里嗎?

A: 雖然沒(méi)試過(guò)，但這個(gè)通過(guò)docker -v的方式應(yīng)該沒(méi)什么問(wèn)題。

Q：不啟動(dòng)Docker Daemon的情況下，離線恢復(fù)Docker中的數(shù)據(jù)是咋做到的?

A: 離線恢復(fù)的原理是用dmsetup create命令創(chuàng)建一個(gè)臨時(shí)的dm設(shè)備，映射到Docker實(shí)例所用的dm設(shè)備號(hào)，通過(guò)mount這個(gè)臨時(shí)設(shè)備，就可以恢復(fù)出原來(lái)的數(shù)據(jù)。

Q：Docker的跨物理機(jī)冷遷移，支持動(dòng)態(tài)的CPU擴(kuò)容/縮容，網(wǎng)絡(luò)IO磁盤(pán)IO的限速，是怎么實(shí)現(xiàn)的，能具體說(shuō)說(shuō)嗎?

A：Docker的冷遷移是通過(guò)修改nova-docker，來(lái)實(shí)現(xiàn)OpenStack遷移的接口，具體來(lái)說(shuō)，就是在兩臺(tái)物理機(jī)間通過(guò)docker commit，docker push到內(nèi)部的registry，然后docker pull snapshot來(lái)完成的。

動(dòng)態(tài)的CPU擴(kuò)容/縮容，網(wǎng)絡(luò)IO磁盤(pán)IO的限速主要是通過(guò)novadocker來(lái)修改cgroups中的cpuset、iops、bps還有TC的參數(shù)來(lái)實(shí)現(xiàn)的。

Q：請(qǐng)問(wèn)你們未來(lái)會(huì)不會(huì)考慮使用Magnum項(xiàng)目，還是會(huì)選擇Swarm?

A：這些都是我們備選的方案，可能會(huì)考慮Swarm。因?yàn)镸agnum底層還是調(diào)用了Kubernetes這樣的集群管理方案，與其用Magnum，不如直接選擇Swarm或者是Kubernetes。當(dāng)然，這只是我個(gè)人的看法。

Q：你們的業(yè)務(wù)是基于同一個(gè)鏡像么，如果是不同的鏡像，那么計(jì)算節(jié)點(diǎn)如何保證容器能夠快速啟動(dòng)?

A：運(yùn)維會(huì)維護(hù)一套統(tǒng)一的基礎(chǔ)鏡像。其他業(yè)務(wù)的鏡像會(huì)基于這個(gè)鏡像來(lái)制作。我們?cè)诔跏蓟?jì)算節(jié)點(diǎn)的時(shí)候就會(huì)通過(guò)docker pull把基礎(chǔ)鏡像拉到本地，這也是很多公司通用的做法，據(jù)我了解，騰訊、360都是類(lèi)似的做法。

Q：做熱遷移，有沒(méi)有考慮繼續(xù)使用傳統(tǒng)共享存儲(chǔ)的來(lái)做?

A： 分布式存儲(chǔ)和共享存儲(chǔ)都在考慮范圍內(nèi)，我們下一步，就計(jì)劃做容器的熱遷移。

Q：請(qǐng)問(wèn)你們是直接將公網(wǎng)IP綁定到容器嗎，還是通過(guò)其他方式映射到容器的私有IP，如果是映射如何解決原本二層的VLAN隔離?

A：因?yàn)槲覀兪撬接性疲簧婕癴loating ip的問(wèn)題，所以你可以認(rèn)為是公網(wǎng)IP。VLAN的二層隔離完全可以在交換機(jī)上作。我們用Open vSwitch劃分不同的VLAN，就實(shí)現(xiàn)了Docker容器和物理機(jī)的網(wǎng)絡(luò)隔離。

Q：Device mapper dm-thin discard問(wèn)題能說(shuō)的詳細(xì)些嗎?

A：4月份的時(shí)候，有兩臺(tái)宿主機(jī)經(jīng)常無(wú)故重啟。首先想到的是查看/var/log/messages日志，但是在重啟時(shí)間點(diǎn)附近沒(méi)有找到與重啟相關(guān)的信息。而后在/var/crash目錄下，找到了內(nèi)核crash的日志vmcore-dmesg.txt。日志的生成時(shí)間與宿主機(jī)重啟時(shí)間一致，可以說(shuō)明宿主機(jī)是發(fā)生了kernel crash然后導(dǎo)致的自動(dòng)重啟。“kernel BUG at drivers/md/persistent-data/dm-btree-remove.c:181!”。 從堆棧可以看出在做dm-thin的discard操作(process prepared discard)，雖然不知道引起bug的根本原因，但是直接原因是discard操作引發(fā)的，可以關(guān)閉discard support來(lái)規(guī)避。

我們將所有的宿主機(jī)配置都禁用discard功能后，再?zèng)]有出現(xiàn)過(guò)同樣的問(wèn)題。

在今年CNUTCon的大會(huì)上，騰訊和大眾點(diǎn)評(píng)在分享他們使用Docker的時(shí)候也提到了這個(gè)crash，他們的解決方法和我們完全一樣。

Q：閾值監(jiān)控和告警那塊，有高中低多種級(jí)別的告警嗎，如果當(dāng)前出現(xiàn)低級(jí)告警，是否會(huì)采取一些限制用戶(hù)接入或者砍掉當(dāng)前用戶(hù)正在使用的業(yè)務(wù)，還是任由事態(tài)發(fā)展?

A：告警這塊，運(yùn)維有專(zhuān)門(mén)的PE負(fù)責(zé)線上業(yè)務(wù)的穩(wěn)定性。當(dāng)出現(xiàn)告警時(shí)，業(yè)務(wù)方和PE會(huì)同時(shí)收到告警信息。如果是影響單個(gè)虛擬機(jī)的，PE會(huì)告知業(yè)務(wù)方，如果嚴(yán)重的，甚至可以及時(shí)下掉業(yè)務(wù)。我們會(huì)和PE合作，讓業(yè)務(wù)方及時(shí)將業(yè)務(wù)遷移走。

Q：你們自研的container tools有沒(méi)有開(kāi)源，GitHub上有沒(méi)有你們的代碼，如何還沒(méi)開(kāi)源，后期有望開(kāi)源嗎，關(guān)于監(jiān)控容器的細(xì)粒度，你們是如何考慮的?

A：雖然我們目前還沒(méi)有開(kāi)源，單我覺(jué)得開(kāi)源出來(lái)的是完全沒(méi)問(wèn)題的，請(qǐng)大家等我們的好消息。關(guān)于監(jiān)控容器的細(xì)粒度，主要想法是在宿主機(jī)層面來(lái)監(jiān)控容器的健康狀態(tài)，而容器內(nèi)部的監(jiān)控，是由業(yè)務(wù)方來(lái)做的。

Q：請(qǐng)問(wèn)容器的layer有關(guān)心過(guò)層數(shù)么，底層的文件系統(tǒng)是ext4么，有優(yōu)化策略么?

A：當(dāng)然有關(guān)心，我們通過(guò)合并鏡像層次來(lái)優(yōu)化docker pull鏡像的時(shí)間。在docker pull時(shí)，每一層校驗(yàn)的耗時(shí)很長(zhǎng)，通過(guò)減小層數(shù)，不僅大小變小，docker pull時(shí)間也大幅縮短。

Q：容器的memcg無(wú)法回收slab cache，也不對(duì)dirty cache量進(jìn)行限制，更容易發(fā)生OOM問(wèn)題。----這個(gè)緩存問(wèn)題你們是怎么處理的?

A：我們根據(jù)實(shí)際的經(jīng)驗(yàn)值，把一部分的cache當(dāng)做used內(nèi)存來(lái)計(jì)算，盡量逼近真實(shí)的使用值。另外針對(duì)容器，內(nèi)存報(bào)警閾值適當(dāng)調(diào)低。同時(shí)添加容器OOM的告警。如果升級(jí)到CentOS 7，還可以配置kmem.limit_in_bytes來(lái)做一定的限制。

Q：能詳細(xì)介紹下你們?nèi)萜骶W(wǎng)絡(luò)的隔離?

A：訪問(wèn)隔離，目前二層隔離我們主要用VLAN，后面也會(huì)考慮VXLAN做隔離。 網(wǎng)絡(luò)流控，我們是就是使用OVS自帶的基于port的QoS，底層用的還是TC，后面還會(huì)考慮基于flow的流控。

Q：請(qǐng)問(wèn)你們這一套都是用的CentOS 6.5嗎，這樣技術(shù)的實(shí)現(xiàn)。是運(yùn)維還是開(kāi)發(fā)參與的多?

A：生產(chǎn)環(huán)境上穩(wěn)定性是***位的。CentOS 6.5主要是運(yùn)維負(fù)責(zé)全公司的統(tǒng)一維護(hù)。我們會(huì)給運(yùn)維在大版本升級(jí)時(shí)提建議。同時(shí)做好虛擬化本身的穩(wěn)定性工作。

Q：請(qǐng)問(wèn)容器和容器直接是怎么通信的?網(wǎng)絡(luò)怎么設(shè)置?

A：你是指同一臺(tái)物理機(jī)上的嗎?我們目前還是通過(guò)IP方式來(lái)進(jìn)行通信。具體的網(wǎng)絡(luò)可以采用網(wǎng)橋模式，或者VLAN模式。我們用Open vSwitch支持VLAN模式，可以做到容器間的隔離或者通信。

Q：你們是使用nova-api的方式集成Dcoker嗎，Docker的高級(jí)特性是否可以使用，如docker-api，另外為什么不使用Heat集成Docker?

A：我們是用nova-docker這個(gè)開(kāi)源軟件實(shí)現(xiàn)的，nova-docker是StackForge上一個(gè)開(kāi)源項(xiàng)目，它做為nova的一個(gè)插件，替換了已有的libvirt，通過(guò)調(diào)用Docker的RESTful接口來(lái)控制容器的啟停等動(dòng)作。

使用Heat還是NOVA來(lái)集成Docker業(yè)界確實(shí)一直存在爭(zhēng)議的，我們更多的是考慮我們自身想解決的問(wèn)題。Heat本身依賴(lài)的關(guān)系較為復(fù)雜，其實(shí)業(yè)界用的也并不多，否則社區(qū)就不會(huì)推出Magnum了。

Q：目前你們有沒(méi)有容器跨DC的實(shí)踐或類(lèi)似的方向?

A：我們已經(jīng)在多個(gè)機(jī)房部署了多套集群，每個(gè)機(jī)房有一套獨(dú)立的集群，在此之上，我們開(kāi)發(fā)了自己的管理平臺(tái)，能夠?qū)崿F(xiàn)對(duì)多集群的統(tǒng)一管理。同時(shí)，我們搭建了Docker Registry V1，內(nèi)部準(zhǔn)備升級(jí)到Docker Registry V2，能夠?qū)崿F(xiàn)Docker鏡像的跨DC mirror功能。

Q：我現(xiàn)在也在推進(jìn)Docker的持續(xù)集成與集群管理，但發(fā)現(xiàn)容器多了管理也是個(gè)問(wèn)題，比如容器的彈性管理與資源監(jiān)控，Kubernetes、Mesos哪個(gè)比較好一些，如果用在業(yè)務(wù)上，那對(duì)外的域名解析如何做呢，因?yàn)槎际峭ㄟ^(guò)宿主機(jī)來(lái)通信，而它只有一個(gè)對(duì)外IP?

A： 對(duì)于Kubernetes和Mesos我們還在預(yù)研階段，我們目前的P層調(diào)度是自研的，我們是通過(guò)etcd來(lái)維護(hù)實(shí)例的狀態(tài)，端口等信息。對(duì)于7層的可以通過(guò)Nginx來(lái)解析，對(duì)于4層，需要依賴(lài)于naming服務(wù)。我們內(nèi)部有自研的naming服務(wù)，因此我們可以解決這些問(wèn)題。對(duì)外雖然只有一個(gè)IP，但是暴露的端口是不同的。

Q：你們有考慮使用Hyper Hypernetes嗎? 實(shí)現(xiàn)容器與宿主機(jī)內(nèi)核隔離同時(shí)保證啟動(dòng)速度?

A：Hyper我們一直在關(guān)注，Hyper是個(gè)很不錯(cuò)的想法，未來(lái)也不排除會(huì)使用Hyper。其實(shí)我們最希望Hyper實(shí)現(xiàn)的是熱遷移，這是目前Docker還做不到的。

Q：你們宿主機(jī)一般用的什么配置?獨(dú)立主機(jī)還是云服務(wù)器?

A：我們有自己的機(jī)房，用的是獨(dú)立的服務(wù)器，物理機(jī)。

Q：容器跨host通信使用哪一種解決方案?

A： 容器跨host就必須使用3層來(lái)通信，也就是IP，容器可以有獨(dú)立的IP，或者宿主機(jī)IP+端口映射的方式來(lái)實(shí)現(xiàn)。我們目前用的比較多的還是獨(dú)立ip的方式，易于管理。

Q：感覺(jué)貴公司對(duì)Docker的使用比較像虛擬機(jī)，為什么不直接考慮從容器的角度來(lái)使用，是歷史原因么?

A：我們首先考慮的是用戶(hù)的接受程度和改造的成本。從用戶(hù)的角度來(lái)說(shuō)，他并不關(guān)心業(yè)務(wù)是跑在容器里，還是虛擬機(jī)里，他更關(guān)心的是應(yīng)用的部署效率，對(duì)應(yīng)用本身的穩(wěn)定性和性能的影響。從容器的角度，一些業(yè)務(wù)方已有的應(yīng)用可能需要比較大的改造。比如日志系統(tǒng)，全鏈路監(jiān)控等等。當(dāng)然，最主要的是對(duì)已有運(yùn)維系統(tǒng)的沖擊會(huì)比較大。容器的管理對(duì)運(yùn)維來(lái)說(shuō)是個(gè)挑戰(zhàn)，運(yùn)維的接受是需要一個(gè)過(guò)程的。

當(dāng)然，把Docker當(dāng)成容器來(lái)封裝應(yīng)用，來(lái)實(shí)現(xiàn)PaaS的部署和動(dòng)態(tài)調(diào)度，這是我們的目標(biāo)，事實(shí)上我們也在往這個(gè)方向努力。這個(gè)也需要業(yè)務(wù)方把應(yīng)用進(jìn)行拆分，實(shí)現(xiàn)微服務(wù)化，這個(gè)需要一個(gè)過(guò)程。

Q：其實(shí)我們也想用容器當(dāng)虛擬機(jī)使用。你們用虛擬機(jī)跑什么中間件?我們想解決測(cè)試關(guān)鍵對(duì)大量相對(duì)獨(dú)立環(huán)境WebLogic的矛盾?

A：我們跑的業(yè)務(wù)有很多，從前臺(tái)的主站W(wǎng)eb，到后端的中間件服務(wù)。我們的中間件服務(wù)是另外團(tuán)隊(duì)自研的產(chǎn)品，實(shí)現(xiàn)前后臺(tái)業(yè)務(wù)邏輯的分離。

Q：貴公司用OpenStack同時(shí)管理Docker和KVM是否有自己開(kāi)發(fā)Web配置界面，還是單純用API管理?

A：我們有自研的Web管理平臺(tái)，我們希望通過(guò)一個(gè)平臺(tái)管理多個(gè)集群，并且對(duì)接運(yùn)維、日志、監(jiān)控等系統(tǒng)，對(duì)外暴露統(tǒng)一的API接口。

Q：上面分享的一個(gè)案例中，關(guān)于2.6內(nèi)核namespace的bug，這個(gè)低版本的內(nèi)核可以安裝Docker環(huán)境嗎，Docker目前對(duì)procfs的隔離還不完善，你們開(kāi)發(fā)的container tools是基于應(yīng)用層的還是需要修改內(nèi)核?

A：安裝和使用應(yīng)該沒(méi)問(wèn)題，但如果上生產(chǎn)環(huán)境，是需要全面的考慮的，主要還是穩(wěn)定性和隔離性不夠，低版本的內(nèi)核更容易造成系統(tǒng) crash或者各種嚴(yán)重的問(wèn)題，有些其實(shí)不是bug，而是功能不完善，比如容器內(nèi)創(chuàng)建網(wǎng)橋會(huì)導(dǎo)致crash，就是network namespace內(nèi)核支持不完善引起的。

我們開(kāi)發(fā)的container tools是基于應(yīng)用的，不需要修改內(nèi)核。

Q：關(guān)于冗災(zāi)方面有沒(méi)有更詳細(xì)的介紹，比如離線狀態(tài)如何實(shí)現(xiàn)數(shù)據(jù)恢復(fù)的?

A：離線狀態(tài)如何實(shí)現(xiàn)恢復(fù)數(shù)據(jù)，這個(gè)我在之前已經(jīng)回答過(guò)了，具體來(lái)說(shuō)，是用dmsetup create命令創(chuàng)建一個(gè)臨時(shí)的dm設(shè)備，映射到docker實(shí)例所用的dm設(shè)備號(hào)，通過(guò)mount這個(gè)臨時(shí)設(shè)備，就可以恢復(fù)出原來(lái)的數(shù)據(jù)。其他的冗災(zāi)方案，因?yàn)閮?nèi)容比較多，可以再另外組織一次分享了。你可以關(guān)注一下http://mogu.io/，到時(shí)候我們會(huì)分享出來(lái)。

Q：貴公司目前線上容器化的系統(tǒng)，無(wú)狀態(tài)為主還是有狀態(tài)為主，在場(chǎng)景選擇上有什么考慮或難點(diǎn)?

A：互聯(lián)網(wǎng)公司的應(yīng)用主要是以無(wú)狀態(tài)的為主。有狀態(tài)的業(yè)務(wù)其實(shí)從業(yè)務(wù)層面也可以改造成部分有狀態(tài)，或者完全不狀態(tài)的應(yīng)用。不太明白你說(shuō)的場(chǎng)景選擇，但我們盡量滿(mǎn)足業(yè)務(wù)方的各種需求。

對(duì)于一些本身對(duì)穩(wěn)定性要求很高，或?qū)r(shí)延IO特別敏感，比如redis業(yè)務(wù)，無(wú)法做到完全隔離或者無(wú)狀態(tài)的，我們不建議他們用容器。

=============================================================

以上內(nèi)容根據(jù)2015年11月03日晚微信群分享內(nèi)容整理。分享人：郭嘉，蘑菇街平臺(tái)技術(shù)部高級(jí)工程師，虛擬化組責(zé)任人。2014年加入蘑菇街，目前主要專(zhuān)注于蘑菇街的私有云建設(shè)，關(guān)注Docker、KVM、OpenStack、Kubernetes等領(lǐng)域

關(guān)于OpenStack

OpenStack是一個(gè)由NASA(美國(guó)國(guó)家航空航天局)和Rackspace合作研發(fā)并發(fā)起的，是一個(gè)開(kāi)源的云計(jì)算管理平臺(tái)項(xiàng)目，由幾個(gè)主要的組件組合起來(lái)完成具體工作。OpenStack支持幾乎所有類(lèi)型的云環(huán)境，項(xiàng)目目標(biāo)是提供實(shí)施簡(jiǎn)單、可大規(guī)模擴(kuò)展、豐富、標(biāo)準(zhǔn)統(tǒng)一的云計(jì)算管理平臺(tái)。

OpenStack除了有Rackspace和NASA的大力支持外，還有包括戴爾、Citrix、Cisco、Canonical等重量級(jí)公司的貢獻(xiàn)和支持，致力于簡(jiǎn)化云的部署過(guò)程并為其帶來(lái)良好的可擴(kuò)展性。