新浪SCE Docker最佳實踐

yg3n 9年前發布 | 38K 次閱讀 Docker

本文主要從IaaS視角，分享SCE通過怎樣的實踐來支持上層產品線的容器化訴求。首先聊聊我們為什么做支持Docker技術這件事情，然后介紹下Docker支持實踐的方方面面。最后給出實踐過程中總結出來的一些經驗及踩過的一些坑，以及后續需要深耕的點。

先假定今晚的聽眾至少已經小范圍使用過Docker技術，熟悉相關概念及原理。

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

----------

為何支持Docker技術

為何做這件事

先介紹下我浪SCE。SCE是新浪研發中心主推私有云產品，已經覆蓋到公司內部所有產品線。基于OpenStack定制，整合了公司通道機、CMDB，為公司內部全產品線提供IaaS服務。公有云版本近期開始內測。

首先，OpenStack與Docker天生互補。

  • OpenStack面向IaaS，以資源為中心，打包OS；能夠提供成熟的資源限制與隔離能力；多OS系列支持；

  • Docker則面向PaaS，以服務為中心，打包service；輕快好省；
    • </ul>
    目前IaaS業界主要以提供云主機服務為主，有著成熟的資源限制、資源隔離能力，但本質上是對OS的打包，無法滿足在應對峰值訪問、快速伸縮、快 速部署等方面訴求。而docker與生俱來的特性”輕、快、好、省“，則恰恰可以彌補IaaS在此方面的不足。當然OpenStack社區為了能夠更好的 支持docker也嘗試做了很多努力，這個后面會講到。

    其次，SCE運維過程發現，產品線對容器技術需求相當旺盛。

    • 快速部署；

    • 快速起停、創建與銷毀；

    • 一致的開發測試環境；

    • 演示、試用環境；

    • 解決設備成本，充分利用資源；

    • 技術方案快速驗證；

    • 更多......
      • </ul>
      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了。我才不會告訴你，這種情況排查問題有多么糟心。
        • </ul>
        為了給產品線提供便捷的鏡像查看及檢索服務，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 Docker最佳實踐

        日志方案

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

        • app打container logfile；

        • app打stdout，stderr；

        • app+agent打遠端；
          • </ul>
          前兩種方案適用于對日志要求不高的使用場景，如開發測試。
          第三種方案則適用于真實的業務場景、生產環境，這些場景對日志持久化、檢索、監控、告警等方面都有較強需求；

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

          app+rsyslog-kafka方案

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

          架構圖

          新浪SCE Docker最佳實踐


          日志流
          app >>> container rsyslog-kafka >>> kafka >>> logstash >>> elasticsearch >>> kibana

          業務流

          1. 產品線走DIP實時日志分析服務接入；

          2. DIP審批；

            1. config_web基于Docker Swarm api動態擴展logstash集群；

              1. 給出用戶接入所需數據，如Kafka broker、topic； </ol> </li>
              2. 產品線依據接入數據創建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，接入過程及細節對產品線透明； </ol> </li> </ol>

                  網絡模式

                  目前產品線大多使用的還是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。

                  ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

                  感謝我們合作伙伴首都在線對本次群分享的支持。

                  以上內容根據2015年6月2日晚微信群分享內容整理。 分享人趙海川，新浪SCE工程師，主要負責虛擬化和Docker相關工作，致力于推動Docker在公司內的使用。微博：wangzi19870227。接下來，DockOne每周都會組織定向的技術分享，歡迎感興趣的同學參與。

                  來自： http://dockone.io/article/416
 本文由用戶 yg3n 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！