技術分享：新浪SCE的Docker實踐經驗
本文主要從IaaS視角，分享SCE通過怎樣的實踐來支持上層產品線的容器化訴求。首先聊聊我們為什么做支持Docker技術這件事情，然后介紹下Docker支持實踐的方方面面。***給出實踐過程中總結出來的一些經驗及踩過的一些坑，以及后續需要深耕的點。
先假定今晚的聽眾至少已經小范圍使用過Docker技術，熟悉相關概念及原理。
前幾期DockOne技術分享已經針對Docker的幾個技術要點做了深入分析，所以我今晚主要從IaaS視角，分享SCE通過怎樣的實踐來支持上層產品線的容器化訴求。
----------
為何支持Docker技術
為何做這件事
先介紹下我浪SCE。SCE是新浪研發中心主推私有云產品，已經覆蓋到公司內部所有產品線?；贠penStack定制，整合了公司通道機、CMDB，為公司內部全產品線提供IaaS服務。公有云版本近期開始內測。
首先，OpenStack與Docker天生互補。
- OpenStack面向IaaS，以資源為中心，打包OS;能夠提供成熟的資源限制與隔離能力;多OS系列支持;
- Docker則面向PaaS，以服務為中心，打包service;輕快好省;
目前IaaS業界主要以提供云主機服務為主，有著成熟的資源限制、資源隔離能力，但本質上是對OS的打包，無法滿足在應對峰值訪問、快速伸縮、快速部署等方面訴求。而docker與生俱來的特性”輕、快、好、省“，則恰恰可以彌補IaaS在此方面的不足。當然OpenStack社區為了能夠更好的支持docker也嘗試做了很多努力，這個后面會講到。
其次，SCE運維過程發現，產品線對容器技術需求相當旺盛。
- 快速部署;
- 快速起停、創建與銷毀;
- 一致的開發測試環境;
- 演示、試用環境;
- 解決設備成本，充分利用資源;
- 技術方案快速驗證;
- 更多......
IaaS短板+需求驅動，讓我們意識到：SCE很有必要也很適合做支持容器技術這件事。
IaaS廠商Docker支持概況
調研分析了幾個IaaS圈子比較有代表性的巨頭及新貴，從調研結果可以看出，目前IaaS廠商對Docker的支持還比較薄弱。
只有阿里云為Docker用戶多做了一些事情，提供了阿里官方Registry。但沒有提供較新的支持Docker的云主機，只有一個第三方提供了一個很老的鏡像，幾乎沒有可用性。
UnitedStack和青云只提供了CoreOS。而實際上，CoreOS的用戶接受度很低。我們SCE也嘗試過提供CoreOS，但由于和公司CentOS系統使用方式差異太大，基本沒有產品線愿意使用并遷移到CoreOS上面來。
----------
Docker支持實踐的方方面面
基于以上需求及調研，SCE主要在Registry、Hub、支持Docker的虛擬機鏡像、日志存儲與檢索、網絡及存儲驅動等方面做了一些實踐，致力于讓產品線用戶更方便高效的使用Docker技術，推動Docker在公司內的使用。
Registry+Hub方案
Registry后端存儲方案方面，其實大家已分享較多，大多是用dev及s3。SCE當然使用自家新浪 S3了，當時的***個方案就是Docker Registry sinastorage driver + sina s3?？煽啃孕宰匀徊挥枚嘌?，但由于依賴storage driver，追查問題過程中，調試及維護都比較麻煩，并且更新后還需要自動構建新鏡像。
既然自家提供可靠云硬盤，為什么不為自己提供服務呢。果斷將忍了老鼻子時間的方案一改為了localstorage + SCE云硬盤，不再依賴driver的日子舒服多了，另外還能享受到云硬盤的snapshot、resize等高級特性。
所以，對于正在Registry storage backend選型的朋友，給出一些建議以供參考：
- 對鏡像存儲可靠性無要求的使用場景，建議直接使用dev;
- 對鏡像存儲可靠性要求較高的使用場景，如果你是在IaaS上跑，強烈建議使用localstorage + 云硬盤方案;
- 對鏡像存儲可靠性要求較高的使用場景，如果你沒在IaaS上跑，可以拿點大洋出來用S3等;
- 對鏡像存儲可靠性要求較高的使用場景，如果你沒在IaaS上跑，又不想花錢，想用自家存儲，就只能寫個自家的driver了。我才不會告訴你，這種情況排查問題有多么糟心。
為了給產品線提供便捷的鏡像查看及檢索服務，SCE與微博平臺合作，共同推出了SCE docker hub，基于docker-registry-frontend開發實現。與SCE現有服務打通，并支持repo、tag、詳細信息、 Dockerfile的查看、檢索與管理等。
為了產品線更方便使用Docker官方鏡像，我們的自動同步工具會依據鏡像注冊表，周期性的自動同步Docker官方鏡像到SCE分布式后端存儲集群，使得產品線用戶可以通過內網快速pull到Docker官方鏡像。
由于SCE不保證也不可能保證Docker Hub官方鏡像的安全性，所以建議產品線***使用SCE官方發布的image或構建自己的baseimage。
對于產品線私有Registry的需求，SCE也提供了相應的一鍵構建工具集。
#p#
CentOS 7 + Docker鏡像
SCE在Docker支持方面主要做了如下一些工作：
1)集成Docker 1.5、Docker-Compose 1.2環境;
2)提供docker-ip、docker-pid、docker-enter等cli，簡化用戶使用;
3)與DIP合作，支持rsyslog-kafka，解決日志監控檢索問題;
4)與微博平臺合作，提供muti-if-adapter工具，解決同一主宿機相同服務端口沖突的問題;
5) 更多......
SCE上使用Docker
有了如上工作支撐，在SCE上使用docker就變得相當便捷。
日志方案
目前SCE主要支持3中日志方案：
app打container logfile;
app打stdout，stderr;
app+agent打遠端;
前兩種方案適用于對日志要求不高的使用場景，如開發測試。
第三種方案則適用于真實的業務場景、生產環境，這些場景對日志持久化、檢索、監控、告警等方面都有較強需求;
Docker 1.6的syslog driver目前可用性、易用性都還不太理想，但值得關注。
app+rsyslog-kafka方案
上面提到的第三種日志方案，我們是通過ELK方案實現的。
架構圖
日志流
app >>> container rsyslog-kafka >>> kafka >>> logstash >>> elasticsearch >>> kibana
業務流
1.產品線走DIP實時日志分析服務接入;
- DIP審批;
- config_web基于Docker Swarm api動態擴展logstash集群;
2. 給出用戶接入所需數據，如Kafka broker、topic;
產品線依據接入數據創建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接入規范，container中的run.sh需要調用SCE提供給的日志配置工具docker/tools/rsyslog_config.sh;
3) rsyslog_config.sh會按需自動配置rsyslog，接入過程及細節對產品線透明;
#p#
網絡模式
目前產品線大多使用的還是bridge和host，雖然這兩種模式都存在一些問題。
兩者雖存在一些問題，但還是能夠滿足中小規模集群網絡需求的。
但規模上來后，上面兩種模式就不適用了。對于大規模網絡解決方案，我們后續將積極跟進，主要計劃調研ovs/weave/Flannel等方案。
Libnetwork driver除了平移過來的bridge、host、null，還提供了remote，以支持分布式bridge;后續計劃提供更多driver以解決目前的網絡問題，值得重點關注。
另外，對于產品線提出的一些有意義的需求，如微博平臺提出的“同一主宿機相同服務端口沖突的問題”，SCE會和產品線一道積極探索相應的解決方案;
存儲驅動選型
這部分主要是開始時，存儲驅動方案選型的一些考慮。
- aufs。Docker最初采用的文件系統，一直沒能合入內核，因此兼容性差，僅有Ubuntu支持。需要用戶自己編譯，使用起來比較麻煩;
- btrfs。數據并沒有直接被寫入而是先是被寫入到日志，在有連續地寫入流的情況下，性能可能會折半;
- overlayfs。一種新的unionfs，但對內核版本要求太高，需要kernel 3.18+;
- devicemapper。默認driver?？梢哉f是目前一般情況下的***方案了。SCE就是采用此driver。
devicemapper相關的一些實踐及坑會在稍后提到。
集群管理
目前SCE主要推薦3個集群管理工具：Shipyard、Swarm、Kubernetes。
Shipyard
- 支持跨主機的container集群管理
- 輕量級，學習成本低
- 支持簡單的資源調度
- 支持GUI圖表展示
- 支持實例橫向擴展
Swarm
- Docker官方主推的集群管理方案
- 相對輕量級，學習成本較低
- 支持多discovery backend
- 豐富的資源調度Filter
- Rest API，完全兼容Docker API
- 尚有一些坑
- 目前產品線最易接受，且使用率最多的方案
Kubernetes
- Google Borg/Omega開源實現
- 更新迭代太塊，架構及實現相對復雜，學習成本、改造成本較高
- 資源調度
- 擴容縮容
- 故障自動恢復
- 多實例負載均衡
- 對OpenStack支持較好
- 跟進中
三者各有優劣，具體使用哪個工具還是需要依據具體的業務需要而定，而并不是說Kubernetes強大就一定是好的。
根據目前產品線使用及反饋來看，swarm還是更容易被接收一些。
與OpenStack集成進展
接下來，我們是IaaS，所以必須要說一下與OpenStack集成進展。如何與OpenStack更好的集成，充分發揮兩者優勢，是我們一直關注的一個點。
目前主要有三種方案：
- nova + docker driver;
- heat + docker driver;
- magnum;
Nova driver及heat driver兩種方案，都存在一些硬傷。如nova driver方案把container當作VM處理，會犧牲掉Docker的所有高級特性，這顯然是不能被接收的;又如heat driver方案，沒有資源調度，創建時必須要指定host，這顯然只能適用于小微規模。
OpenStack社區本年初終于開始發力CaaS新項目magnum。通過集成Heat，來支持使用Docker的高級功能;可以集成 Swarm、Gantt或Mesos，實現Docker集群資源調度(現計劃是使用swarm做調度);Magnum還將與Kubernetes深度整合。
Magnum已找準此前兩種解決方案的痛點，并正在用恰當的方式解決此問題。非常值得跟進。
另外，此次溫哥華OpenStack Summit上，OpenStack基金會除了還表示將積極推進Magnum子項目，在技術上實現容器與OpenStack的深度整合。
----------
#p#
實踐經驗&踩過的坑
下面介紹的內容，大多是產品線問到的，以及SCE在Docker實踐過程中總結出來的經驗教訓，都已文檔化到SCE官方Docker wiki。從SCE Docker wiki里摘取了一些實踐經驗&踩過的坑，想必大家或多或少已經實踐過或踩過。如果還沒遇到這些問題，希望我們的這些經驗總結能對你有所幫助。
鏡像制作方面
- 建議用Dockerfile build鏡像，鏡像文檔化;
- Dockerfile中，value千萬別加""。因為docker會把你的""作為value的一部分;
- 最小化鏡像大小，分層設計，盡量復用;
運行容器方面
- 一容器一進程，便于服務監控與資源隔離;
- 不建議用latest
- 對于提供服務的container，建議養成加--restart的習慣
數據存放方面
- 建議采用volume掛載方式
- 不依賴host目錄，便于共享與遷移;
資源限制方面
- cgroup允許進程超限使用，即：在有空余資源的情況下，允許使用超出資源限制的更多資源。
- cgroup僅在必要時(資源不足時)限制資源使用，比如：當若干進程同時大量地使用CPU。
- cpu share enforcement僅會在多個進程運行在相同核上的情況下發生。也就是說，即使你機器上的兩個container cpu限制不同，如果你把一個container綁定在core1，而把另外一個container綁定在core2，那么這兩個container都能打滿各自的核。
資源隔離方面
- user ns是通過將container的uid、gid映射為node上的uid、gid來實現user隔離的;
- 也就是說，你在node上只能看到container的uid，而看不到uname，除非這個uid在container和node上的uname相同;
- 也就是說，你在node上看到的container上的進程的所屬用戶的uname不一定是container上運行這個進程的uname，但uid一定是container上運行這個進程的uid;
swarm & compose使用方面
- 注意swarm strategies尚不成熟，binpack strategy實現存在一些問題，會導致***調度出來的node不是你預期的。
- 注意compose尚不成熟，可能會遇到單個啟container沒問題，放到compose啟就失敗的問題。如：部署啟動時間依賴性強的容器很可能會導致失敗;
container方面
- 注意dm默認pool及container存儲空間大小問題。container默認10G，pool默認100G，你可能需要通過dm.basesize、dm.loopdatasize按需擴容;
- 注意nsenter進容器，看不到配置在container里的env變量;查看env建議用docker exec或docker inspect;
- 注意docker daemon、docker daemon的default-ulimit和docker run的ulimit三者間的繼承關系;
由于篇幅所限，這里就不再過多列舉。
----------
后續計劃
下面給出SCE后續需要繼續深耕的幾個點。
- 提供CI & CD解決方案
- 探索大規模集群網絡方案
- 持續跟進大規模集群管理方案
- 深入調研OpenStack與Docker整合方案
----------
Q&A
問：如何實現跨機部署?
答：shipyard和swarm都可，當然還有其它方案。shipyard有不錯的web UI，支持container多機部署，調度基于tag，還可以scale。swarm調度策略比較靈活，可以依據你指定的filter、weighter進行調度部署。
問：Compose能否實現跨機編排?
答：不行。目前只支持單機編排。
問：container監控是如何實現的?
答：cadvisor做container監控。監控這部分也是有一定工作需要去想去做的，比如說可以考慮和EK結合提來，提供一個獨立的docker集群監控解決方案出來。
問：如何對某一容器進行擴容?
答：目前沒有比較好的解決辦法，我們的建議的做法是刪了再啟個大的。
數據存放方案如何選擇，以保證數據安全性和易擴展、易遷移?
對于保證數據安全性需求，建議使用local + 云硬盤方案;
對于易擴展、易遷移需求，建議使用數據寫image或volume掛載方案;
如果有高性能需求，并且你的container是跑在物理機上的，建議使用local volume + host dev方案;
沒有方案是***的，具體方案選型還是需要依據具體的使用場景而定。
問：SCE方案中，docker container大概是跑在那一層?
答：大概的棧是IaaS >>> CaaS，SCE docker container是跑在CaaS。
===========================
以上內容根據2015年6月2日晚微信群分享內容整理。分享人趙海川，新浪SCE工程師，主要負責虛擬化和Docker相關工作，致力于推動Docker在公司內的使用。微博：wangzi19870227。
