你好,游客 登錄
背景:
閱讀新聞

六合图库手机版下载:新浪SCE的Docker實踐經驗

[日期:2015-06-04] 來源: dockone  作者: [字體: ]

六合图库118万众图库 www.xorsm.icu   本文主要從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也提供了相應的一鍵構建工具集。

  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,接入過程及細節對產品線透明;

  網絡模式

  目前產品線大多使用的還是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??梢運凳悄殼耙話闈榭魷碌淖鈑歐槳噶?。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的深度整合。

  ----------

  實踐經驗&踩過的坑

  下面介紹的內容,大多是產品線問到的,以及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。

推薦 打印 | 錄入: | 閱讀:
相關新聞      
本文評論   
評論聲明
  • 尊重網上道德,遵守中華人民共和國的各項有關法律法規
  • 承擔一切因您的行為而直接或間接導致的民事或刑事法律責任
  • 本站管理人員有權保留或刪除其管轄留言中的任意內容
  • 本站有權在網站內轉載或引用您的評論
  • 參與本評論即表明您已經閱讀并接受上述條款