本文主要從IaaS視角，分享SCE通過怎樣的實踐來支持上層產(chǎn)品線的容器化訴求。首先聊聊我們?yōu)槭裁醋鲋С諨ocker技術(shù)這件事情，然后介紹下Docker支持實踐的方方面面。***給出實踐過程中總結(jié)出來的一些經(jīng)驗及踩過的一些坑，以及后續(xù)需要深耕的點。

先假定今晚的聽眾至少已經(jīng)小范圍使用過Docker技術(shù)，熟悉相關(guān)概念及原理。

前幾期DockOne技術(shù)分享已經(jīng)針對Docker的幾個技術(shù)要點做了深入分析，所以我今晚主要從IaaS視角，分享SCE通過怎樣的實踐來支持上層產(chǎn)品線的容器化訴求。

----------

為何支持Docker技術(shù)

為何做這件事

先介紹下我浪SCE。SCE是新浪研發(fā)中心主推私有云產(chǎn)品，已經(jīng)覆蓋到公司內(nèi)部所有產(chǎn)品線?；贠penStack定制，整合了公司通道機(jī)、CMDB，為公司內(nèi)部全產(chǎn)品線提供IaaS服務(wù)。公有云版本近期開始內(nèi)測。

首先，OpenStack與Docker天生互補。

• OpenStack面向IaaS，以資源為中心，打包OS;能夠提供成熟的資源限制與隔離能力;多OS系列支持;
• Docker則面向PaaS，以服務(wù)為中心，打包service;輕快好省;

目前IaaS業(yè)界主要以提供云主機(jī)服務(wù)為主，有著成熟的資源限制、資源隔離能力，但本質(zhì)上是對OS的打包，無法滿足在應(yīng)對峰值訪問、快速伸縮、快速部署等方面訴求。而docker與生俱來的特性”輕、快、好、省“，則恰恰可以彌補IaaS在此方面的不足。當(dāng)然OpenStack社區(qū)為了能夠更好的支持docker也嘗試做了很多努力，這個后面會講到。

其次，SCE運維過程發(fā)現(xiàn)，產(chǎn)品線對容器技術(shù)需求相當(dāng)旺盛。

• 快速部署;
• 快速起停、創(chuàng)建與銷毀;
• 一致的開發(fā)測試環(huán)境;
• 演示、試用環(huán)境;
• 解決設(shè)備成本，充分利用資源;
• 技術(shù)方案快速驗證;
• 更多......

IaaS短板+需求驅(qū)動，讓我們意識到：SCE很有必要也很適合做支持容器技術(shù)這件事。

IaaS廠商Docker支持概況

調(diào)研分析了幾個IaaS圈子比較有代表性的巨頭及新貴，從調(diào)研結(jié)果可以看出，目前IaaS廠商對Docker的支持還比較薄弱。

只有阿里云為Docker用戶多做了一些事情，提供了阿里官方Registry。但沒有提供較新的支持Docker的云主機(jī)，只有一個第三方提供了一個很老的鏡像，幾乎沒有可用性。

UnitedStack和青云只提供了CoreOS。而實際上，CoreOS的用戶接受度很低。我們SCE也嘗試過提供CoreOS，但由于和公司CentOS系統(tǒng)使用方式差異太大，基本沒有產(chǎn)品線愿意使用并遷移到CoreOS上面來。

----------

Docker支持實踐的方方面面

基于以上需求及調(diào)研，SCE主要在Registry、Hub、支持Docker的虛擬機(jī)鏡像、日志存儲與檢索、網(wǎng)絡(luò)及存儲驅(qū)動等方面做了一些實踐，致力于讓產(chǎn)品線用戶更方便高效的使用Docker技術(shù)，推動Docker在公司內(nèi)的使用。

Registry+Hub方案

Registry后端存儲方案方面，其實大家已分享較多，大多是用dev及s3。SCE當(dāng)然使用自家新浪 S3了，當(dāng)時的***個方案就是Docker Registry sinastorage driver + sina s3?？煽啃孕宰匀徊挥枚嘌裕捎谝蕾噑torage driver，追查問題過程中，調(diào)試及維護(hù)都比較麻煩，并且更新后還需要自動構(gòu)建新鏡像。

既然自家提供可靠云硬盤，為什么不為自己提供服務(wù)呢。果斷將忍了老鼻子時間的方案一改為了localstorage + SCE云硬盤，不再依賴driver的日子舒服多了，另外還能享受到云硬盤的snapshot、resize等高級特性。

所以，對于正在Registry storage backend選型的朋友，給出一些建議以供參考：

• 對鏡像存儲可靠性無要求的使用場景，建議直接使用dev;
• 對鏡像存儲可靠性要求較高的使用場景，如果你是在IaaS上跑，強烈建議使用localstorage + 云硬盤方案;
• 對鏡像存儲可靠性要求較高的使用場景，如果你沒在IaaS上跑，可以拿點大洋出來用S3等;
• 對鏡像存儲可靠性要求較高的使用場景，如果你沒在IaaS上跑，又不想花錢，想用自家存儲，就只能寫個自家的driver了。我才不會告訴你，這種情況排查問題有多么糟心。

為了給產(chǎn)品線提供便捷的鏡像查看及檢索服務(wù)，SCE與微博平臺合作，共同推出了SCE docker hub，基于docker-registry-frontend開發(fā)實現(xiàn)。與SCE現(xiàn)有服務(wù)打通，并支持repo、tag、詳細(xì)信息、 Dockerfile的查看、檢索與管理等。

為了產(chǎn)品線更方便使用Docker官方鏡像，我們的自動同步工具會依據(jù)鏡像注冊表，周期性的自動同步Docker官方鏡像到SCE分布式后端存儲集群，使得產(chǎn)品線用戶可以通過內(nèi)網(wǎng)快速pull到Docker官方鏡像。

由于SCE不保證也不可能保證Docker Hub官方鏡像的安全性，所以建議產(chǎn)品線***使用SCE官方發(fā)布的image或構(gòu)建自己的baseimage。

對于產(chǎn)品線私有Registry的需求，SCE也提供了相應(yīng)的一鍵構(gòu)建工具集。

#p#

CentOS 7 + Docker鏡像

SCE在Docker支持方面主要做了如下一些工作：

1)集成Docker 1.5、Docker-Compose 1.2環(huán)境;

2)提供docker-ip、docker-pid、docker-enter等cli，簡化用戶使用;

3)與DIP合作，支持rsyslog-kafka，解決日志監(jiān)控檢索問題;

4)與微博平臺合作，提供muti-if-adapter工具，解決同一主宿機(jī)相同服務(wù)端口沖突的問題;

5) 更多......

SCE上使用Docker

有了如上工作支撐，在SCE上使用docker就變得相當(dāng)便捷。

日志方案

目前SCE主要支持3中日志方案：

app打container logfile;

app打stdout，stderr;

app+agent打遠(yuǎn)端;

前兩種方案適用于對日志要求不高的使用場景，如開發(fā)測試。

第三種方案則適用于真實的業(yè)務(wù)場景、生產(chǎn)環(huán)境，這些場景對日志持久化、檢索、監(jiān)控、告警等方面都有較強需求;

Docker 1.6的syslog driver目前可用性、易用性都還不太理想，但值得關(guān)注。

app+rsyslog-kafka方案

上面提到的第三種日志方案，我們是通過ELK方案實現(xiàn)的。

架構(gòu)圖

日志流

app >>> container rsyslog-kafka >>> kafka >>> logstash >>> elasticsearch >>> kibana

業(yè)務(wù)流

1.產(chǎn)品線走DIP實時日志分析服務(wù)接入;

• DIP審批;
• config_web基于Docker Swarm api動態(tài)擴(kuò)展logstash集群;

2. 給出用戶接入所需數(shù)據(jù)，如Kafka broker、topic;

產(chǎn)品線依據(jù)接入數(shù)據(jù)創(chuàng)建container;

1)

docker run -d -e KAFKA_ADDR=... -e KAFKA_TOPIC=... -e LOG_FILE=... -v $(pwd)/kafka_config.sh:${SOME_DIR}/kafka_config.sh ... 

2)遵守SCE log接入規(guī)范，container中的run.sh需要調(diào)用SCE提供給的日志配置工具docker/tools/rsyslog_config.sh;

3) rsyslog_config.sh會按需自動配置rsyslog，接入過程及細(xì)節(jié)對產(chǎn)品線透明;

#p#

網(wǎng)絡(luò)模式

目前產(chǎn)品線大多使用的還是bridge和host，雖然這兩種模式都存在一些問題。

兩者雖存在一些問題，但還是能夠滿足中小規(guī)模集群網(wǎng)絡(luò)需求的。

但規(guī)模上來后，上面兩種模式就不適用了。對于大規(guī)模網(wǎng)絡(luò)解決方案，我們后續(xù)將積極跟進(jìn)，主要計劃調(diào)研ovs/weave/Flannel等方案。

Libnetwork driver除了平移過來的bridge、host、null，還提供了remote，以支持分布式bridge;后續(xù)計劃提供更多driver以解決目前的網(wǎng)絡(luò)問題，值得重點關(guān)注。

另外，對于產(chǎn)品線提出的一些有意義的需求，如微博平臺提出的“同一主宿機(jī)相同服務(wù)端口沖突的問題”，SCE會和產(chǎn)品線一道積極探索相應(yīng)的解決方案;

存儲驅(qū)動選型

這部分主要是開始時，存儲驅(qū)動方案選型的一些考慮。

• aufs。Docker最初采用的文件系統(tǒng)，一直沒能合入內(nèi)核，因此兼容性差，僅有Ubuntu支持。需要用戶自己編譯，使用起來比較麻煩;
• btrfs。數(shù)據(jù)并沒有直接被寫入而是先是被寫入到日志，在有連續(xù)地寫入流的情況下，性能可能會折半;
• overlayfs。一種新的unionfs，但對內(nèi)核版本要求太高，需要kernel 3.18+;
• devicemapper。默認(rèn)driver?？梢哉f是目前一般情況下的***方案了。SCE就是采用此driver。

devicemapper相關(guān)的一些實踐及坑會在稍后提到。

集群管理

目前SCE主要推薦3個集群管理工具：Shipyard、Swarm、Kubernetes。

Shipyard

• 支持跨主機(jī)的container集群管理
• 輕量級，學(xué)習(xí)成本低
• 支持簡單的資源調(diào)度
• 支持GUI圖表展示
• 支持實例橫向擴(kuò)展

Swarm

• Docker官方主推的集群管理方案
• 相對輕量級，學(xué)習(xí)成本較低
• 支持多discovery backend
• 豐富的資源調(diào)度Filter
• Rest API，完全兼容Docker API
• 尚有一些坑
• 目前產(chǎn)品線最易接受，且使用率最多的方案

Kubernetes

• Google Borg/Omega開源實現(xiàn)
• 更新迭代太塊，架構(gòu)及實現(xiàn)相對復(fù)雜，學(xué)習(xí)成本、改造成本較高
• 資源調(diào)度
• 擴(kuò)容縮容
• 故障自動恢復(fù)
• 多實例負(fù)載均衡
• 對OpenStack支持較好
• 跟進(jìn)中

三者各有優(yōu)劣，具體使用哪個工具還是需要依據(jù)具體的業(yè)務(wù)需要而定，而并不是說Kubernetes強大就一定是好的。

根據(jù)目前產(chǎn)品線使用及反饋來看，swarm還是更容易被接收一些。

與OpenStack集成進(jìn)展

接下來，我們是IaaS，所以必須要說一下與OpenStack集成進(jìn)展。如何與OpenStack更好的集成，充分發(fā)揮兩者優(yōu)勢，是我們一直關(guān)注的一個點。

目前主要有三種方案：

1. nova + docker driver;
2. heat + docker driver;
3. magnum;

Nova driver及heat driver兩種方案，都存在一些硬傷。如nova driver方案把container當(dāng)作VM處理，會犧牲掉Docker的所有高級特性，這顯然是不能被接收的;又如heat driver方案，沒有資源調(diào)度，創(chuàng)建時必須要指定host，這顯然只能適用于小微規(guī)模。

OpenStack社區(qū)本年初終于開始發(fā)力CaaS新項目magnum。通過集成Heat，來支持使用Docker的高級功能;可以集成 Swarm、Gantt或Mesos，實現(xiàn)Docker集群資源調(diào)度(現(xiàn)計劃是使用swarm做調(diào)度);Magnum還將與Kubernetes深度整合。

Magnum已找準(zhǔn)此前兩種解決方案的痛點，并正在用恰當(dāng)?shù)姆绞浇鉀Q此問題。非常值得跟進(jìn)。

另外，此次溫哥華OpenStack Summit上，OpenStack基金會除了還表示將積極推進(jìn)Magnum子項目，在技術(shù)上實現(xiàn)容器與OpenStack的深度整合。

----------

#p#

實踐經(jīng)驗&踩過的坑

下面介紹的內(nèi)容，大多是產(chǎn)品線問到的，以及SCE在Docker實踐過程中總結(jié)出來的經(jīng)驗教訓(xùn)，都已文檔化到SCE官方Docker wiki。從SCE Docker wiki里摘取了一些實踐經(jīng)驗&踩過的坑，想必大家或多或少已經(jīng)實踐過或踩過。如果還沒遇到這些問題，希望我們的這些經(jīng)驗總結(jié)能對你有所幫助。

鏡像制作方面

• 建議用Dockerfile build鏡像，鏡像文檔化;
• Dockerfile中，value千萬別加""。因為docker會把你的""作為value的一部分;
• 最小化鏡像大小，分層設(shè)計，盡量復(fù)用;

運行容器方面

• 一容器一進(jìn)程，便于服務(wù)監(jiān)控與資源隔離;
• 不建議用latest
• 對于提供服務(wù)的container，建議養(yǎng)成加--restart的習(xí)慣

數(shù)據(jù)存放方面

• 建議采用volume掛載方式
• 不依賴host目錄，便于共享與遷移;

資源限制方面

• cgroup允許進(jìn)程超限使用，即：在有空余資源的情況下，允許使用超出資源限制的更多資源。
• cgroup僅在必要時(資源不足時)限制資源使用，比如：當(dāng)若干進(jìn)程同時大量地使用CPU。
• cpu share enforcement僅會在多個進(jìn)程運行在相同核上的情況下發(fā)生。也就是說，即使你機(jī)器上的兩個container cpu限制不同，如果你把一個container綁定在core1，而把另外一個container綁定在core2，那么這兩個container都能打滿各自的核。

資源隔離方面

• user ns是通過將container的uid、gid映射為node上的uid、gid來實現(xiàn)user隔離的;
• 也就是說，你在node上只能看到container的uid，而看不到uname，除非這個uid在container和node上的uname相同;
• 也就是說，你在node上看到的container上的進(jìn)程的所屬用戶的uname不一定是container上運行這個進(jìn)程的uname，但uid一定是container上運行這個進(jìn)程的uid;

swarm & compose使用方面

• 注意swarm strategies尚不成熟，binpack strategy實現(xiàn)存在一些問題，會導(dǎo)致***調(diào)度出來的node不是你預(yù)期的。
• 注意compose尚不成熟，可能會遇到單個啟container沒問題，放到compose啟就失敗的問題。如：部署啟動時間依賴性強的容器很可能會導(dǎo)致失敗;

container方面

• 注意dm默認(rèn)pool及container存儲空間大小問題。container默認(rèn)10G，pool默認(rèn)100G，你可能需要通過dm.basesize、dm.loopdatasize按需擴(kuò)容;
• 注意nsenter進(jìn)容器，看不到配置在container里的env變量;查看env建議用docker exec或docker inspect;
• 注意docker daemon、docker daemon的default-ulimit和docker run的ulimit三者間的繼承關(guān)系;

由于篇幅所限，這里就不再過多列舉。

----------

后續(xù)計劃

下面給出SCE后續(xù)需要繼續(xù)深耕的幾個點。

• 提供CI & CD解決方案
• 探索大規(guī)模集群網(wǎng)絡(luò)方案
• 持續(xù)跟進(jìn)大規(guī)模集群管理方案
• 深入調(diào)研OpenStack與Docker整合方案

----------

Q&A

問：如何實現(xiàn)跨機(jī)部署?

答：shipyard和swarm都可，當(dāng)然還有其它方案。shipyard有不錯的web UI，支持container多機(jī)部署，調(diào)度基于tag，還可以scale。swarm調(diào)度策略比較靈活，可以依據(jù)你指定的filter、weighter進(jìn)行調(diào)度部署。

問：Compose能否實現(xiàn)跨機(jī)編排?

答：不行。目前只支持單機(jī)編排。

問：container監(jiān)控是如何實現(xiàn)的?

答：cadvisor做container監(jiān)控。監(jiān)控這部分也是有一定工作需要去想去做的，比如說可以考慮和EK結(jié)合提來，提供一個獨立的docker集群監(jiān)控解決方案出來。

問：如何對某一容器進(jìn)行擴(kuò)容?

答：目前沒有比較好的解決辦法，我們的建議的做法是刪了再啟個大的。

數(shù)據(jù)存放方案如何選擇，以保證數(shù)據(jù)安全性和易擴(kuò)展、易遷移?

對于保證數(shù)據(jù)安全性需求，建議使用local + 云硬盤方案;

對于易擴(kuò)展、易遷移需求，建議使用數(shù)據(jù)寫image或volume掛載方案;

如果有高性能需求，并且你的container是跑在物理機(jī)上的，建議使用local volume + host dev方案;

沒有方案是***的，具體方案選型還是需要依據(jù)具體的使用場景而定。

問：SCE方案中，docker container大概是跑在那一層?

答：大概的棧是IaaS >>> CaaS，SCE docker container是跑在CaaS。

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

以上內(nèi)容根據(jù)2015年6月2日晚微信群分享內(nèi)容整理。分享人趙海川，新浪SCE工程師，主要負(fù)責(zé)虛擬化和Docker相關(guān)工作，致力于推動Docker在公司內(nèi)的使用。微博：wangzi19870227。

原文鏈接：http://dockone.io/article/416