摘要：有贊容器化方案我們的容器化方案基于和，下面介紹一下我們在各個方面遇到的問題以及解決方案。不過對于上線來說，需要整個運維體系來適配容器化，比如監(jiān)控發(fā)布日志等等。

容器化已經成為一種趨勢，它可以解決很多運維中的痛點，比如效率、成本、穩(wěn)定性等問題，而接入容器的過程中往往也會碰到很多問題和不便。在有贊最開始做容器化是為了快速交付開發(fā)測試環(huán)境，在容器化的過程中，我們碰到過容器技術、運維體系適配、用戶使用習慣改變等各種問題，本文主要介紹有贊容器化過程中碰到的問題以及采取的方案。

在有贊同時會有很多個項目、日常在并行開發(fā)，環(huán)境的搶占問題嚴重影響了開發(fā)、測試和上線的效率，我們需要給每個項目提供一套開發(fā)聯(lián)調(daily)、測試環(huán)境(qa)，并且隨著項目、日常的生命周期項目環(huán)境也會隨著創(chuàng)建和銷毀，我們最早的容器化需求就是怎么解決環(huán)境快速交付的問題。

[有贊環(huán)境]

上面是有贊大致的研發(fā)流程，在標準流程中我們有四套穩(wěn)定環(huán)境，分別是 Daily 環(huán)境、Qa 環(huán)境、預發(fā)環(huán)境和測試環(huán)境。我們的開發(fā)、測試、聯(lián)調工作一般并不會直接在穩(wěn)定環(huán)境中進行，而是會拉一套獨立的項目環(huán)境出來，隨著代碼經過開發(fā)、測試、預發(fā)驗收最終發(fā)布到生產環(huán)境后再同步回 Daily/Qa 的穩(wěn)定環(huán)境中。

[項目環(huán)境]

我們提供了一套以最小的資源投入滿足最大項目并行度的環(huán)境交付方案，在 Daily/Qa 穩(wěn)定環(huán)境的基礎上，隔離出N個項目環(huán)境，在項目環(huán)境里只需要創(chuàng)建該項目所涉及應用的計算資源，其它缺失的服務調用由穩(wěn)定環(huán)境提供，在項目環(huán)境里，我們大量使用了容器技術。

[持續(xù)交付]

后面我們又在項目環(huán)境快速交付的解決方案的基礎上實現(xiàn)了持續(xù)交付流水線，目前已經有超過 600 套項目/持續(xù)交付環(huán)境，加上 Daily/Qa 穩(wěn)定環(huán)境，涉及計算實例四五千個，這些計算實例無論是 cpu 還是內存使用率都是非常低的，容器化可以非常好的解決環(huán)境交付的效率問題，以及提高資源使用率來節(jié)省成本的投入。

我們的容器化方案基于 kubernetes(1.7.10)和 docker(1.12.6)、docker(1.13.1)，下面介紹一下我們在各個方面遇到的問題以及解決方案。

有贊后端主要是 java 應用，采用定制的 dubbo 服務化方案，過程中無法做到整個單元全量容器化，和原有集群在網絡路由上互通也就成了剛需，由于我們無法解決公有云上 overlay 網絡和公有云網絡的互通問題，所以一開始我們放棄了 overlay 網絡方案，采用了托管網絡下的 macvlan 方案，這樣既解決了網絡互通的問題也不存在網絡性能問題，但是也就享受不到公有云彈性資源的優(yōu)勢了。隨著有贊多云架構的發(fā)展以及越來越多的云廠商支持容器 overlay 網絡和 vpc 網絡打通，彈性資源的問題才得到了緩解。

容器的隔離主要利用內核的 namespace 和 cgroup 技術，在進程、cpu、內存、IO等資源隔離限制上有比較好的表現(xiàn)，但其他方面和虛擬機相比存在著很多的不足，我們在使用過程中碰到最多的問題是容器里看到的 cpu 數和內存大小不準確，因為/proc文件系統(tǒng)無法隔離，導致容器里的進程"看到"的是物理機的 cpu 數以及內存大小。

我們的 java 應用會根據服務器的內存大小來決定 jvm 參數應該怎么配置，我們是采用 lxcfs 方案來規(guī)避的。

因為我們有超賣的需求以及 kubernetes 默認也是采用 cpu share 來做 cpu 限制，雖然我們使用了 lxcfs，CPU 數還是不準的。jvm 以及很多 Java sdk 都會根據系統(tǒng)的 CPU 數來決定創(chuàng)建多少線程，導致 java 應用在線程數和內存使用上都比虛擬機多的多，嚴重影響運行，其他類型的應用也有類似的問題。
我們會根據容器的規(guī)格內置一個環(huán)境變量 NUM_CPUS，然后比如 nodejs 應用就會按照這個變量來創(chuàng)建它的 worker 進程數。在解決 java 類應用的問題時，我們索性通過 LD_PRELOAD 將 JVM_ActiveProcessorCount 函數覆蓋掉，讓它直接返回 NUM_CPUS 的值[1]。

在容器化之前，有贊的應用已經全部接入到發(fā)布系統(tǒng)，在發(fā)布系統(tǒng)里已經標準化了應用的打包、發(fā)布流程，所以在應用接入方面成本還是比較小的，業(yè)務方無需提供 Dockerfile。

nodejs, python，php-soa 等用 supervisord 托管的應用，只需要在 git 倉庫里提供 app.yaml 文件定義運行需要的 runtime 和啟動命令即可。

java 標準化啟動的應用業(yè)務方無需改動

java 非標準化的應用需要做標準化改造

容器鏡像我們分了三層，依次為 stack 層（os），runtime 層（語言環(huán)境），應用層（業(yè)務代碼和一些輔助agent），應用以及輔助 agent 由 runit 來啟動。由于我們的配置還沒有完全分離，在應用層目前還是每個環(huán)境獨立打包，鏡像里除了業(yè)務代碼之外，我們還會根據業(yè)務的語言類型放一些輔助的 agent。我們一開始也想將各種 agent 拆成多個鏡像，然后每個 pod 運行多個容器，后來因為解決不了 pod 里容器的啟動順序（服務啟動有依賴）問題，就把所有服務都扔到一個容器里去運行了。

我們的容器鏡像集成過程也是通過 kubernetes 來調度的（會調度到指定的打包節(jié)點上），在發(fā)布任務發(fā)起時，管控系統(tǒng)會在集群中創(chuàng)建一個打包的 pod，打包程序會根據應用類型等參數編譯代碼、安裝依賴，并且生成 Dockerifile，然后在這個 pod 中使用 docker in docker 的方式來集成容器鏡像并推送到倉庫。
為了加速應用的打包速度，我們用 pvc 緩存了 python 的 virtualenv，nodejs 的 node_modules，java 的 maven 包等文件。另外就是 docker 早的版本里，Dockerfile ADD 指令是不支持指定文件屬主和分組的，這樣會帶來一個問題就是需要指定文件屬主時（我們的應用是以 app 賬號運行的）需要多運行一次 RUN chown，這樣鏡像也就多了一層數據，所以我們打包節(jié)點的 docker 版本采用了官方比較新的 ce 版本，因為新版本支持 ADD --chown 特性。

有贊的應用內部調用有比較完善的服務化和 service mesh 方案，集群內的訪問不用過多考慮，負載均衡只需要考慮用戶和系統(tǒng)訪問的 http 流量，在容器化之前我們已經自研了一套統(tǒng)一接入系統(tǒng)，所以在容器化負載均衡上我們并沒有完整按照 ingress 的機制來實現(xiàn) controller，ingress 的資源配置是配在統(tǒng)一接入里的，配置里面轉發(fā)的 upstream 會和 kubernetes 里的 service 關聯(lián)，我們只是做了一個 sync 程序 watch kube-api，感知 service 的變化來實時更新統(tǒng)一接入系統(tǒng)中 upstream 的服務器列表信息。

在容器化接入過程中開發(fā)會反饋是控制臺比較難用，雖然我們優(yōu)化了多次，和 iterm2 等的體驗還是有所不足，最終我們還是放開了項目/持續(xù)交付環(huán)境這種需要頻繁登陸調試的 ssh 登陸權限。
另外一個比較嚴重的問題是，當一個應用啟動后健康檢查有問題會導致 pod 一直在重新調度，而在開發(fā)過程中開發(fā)肯定是希望看到失敗現(xiàn)場的，我們提供了調試發(fā)布模式，讓容器不做健康檢查。

有贊有專門的日志系統(tǒng)，我們內部叫天網，大部分日志以及業(yè)務監(jiān)控數據都是通過 sdk 直接打到天網里去了，所以容器的標準輸出日志僅僅作為一種輔助排查問題的手段。我們容器的日志收集采用的是 fluentd，經過 fluentd 處理后按照天網約定的日志格式打到 kafka，最終由天網處理進入 es 做存儲。

我們涉及到灰度發(fā)布的流量主要包含三部分：

用戶端的 http 訪問流量

應用之間的 http 調用

應用之間的 dubbo 調用

首先，我們在入口的統(tǒng)一接入上統(tǒng)一打上灰度需要用的各種維度的標簽（比如用戶、店鋪等），然后需要對統(tǒng)一接入、http client 以及 dubbo client 做改造，目的是讓這些標簽能夠在整個調用鏈上透傳。我們在做容器灰度發(fā)布時，會發(fā)一個灰度的 deployment，然后在統(tǒng)一接入以及灰度配置中心配置灰度規(guī)則，整個鏈路上的調用方都會感知這些灰度規(guī)則來實現(xiàn)灰度發(fā)布。

和項目環(huán)境類似，標準穩(wěn)定環(huán)境中的 daily，qa，pre 以及 prod 中超過一半運行在低水位的服務器的資源非常浪費。

因為成本考慮 daily，qa，pre 里都是以單臺虛擬機運行的，這樣一旦需要發(fā)布穩(wěn)定環(huán)境將會造成標準穩(wěn)定環(huán)境和項目環(huán)境的短暫不可用。

虛擬機交付速度比較慢，使用虛擬機做灰度發(fā)布也比較復雜。

虛擬機往往會存在幾年甚至更長的時間，運行過程中操作系統(tǒng)以及基礎軟件版本的收斂非常麻煩。

經過之前項目/持續(xù)交付的上線和迭代，大部分應用本身已經具備了容器化的條件。不過對于上線來說，需要整個運維體系來適配容器化，比如監(jiān)控、發(fā)布、日志等等。目前我們生產環(huán)境容器化準備基本完成，生產網已經上了部分前端 nodejs 應用，其他應用也在陸續(xù)推動中，希望以后可以分享更多生產環(huán)境中的容器化經驗。

以上是有贊在容器化上的應用，以及在容器化過程中碰到的一些問題和解決方案，我們生產環(huán)境的容器化還處于開始階段，后面還會碰到各種個樣的問題，希望能夠和大家互相學習，后面能夠有更多的經驗分享給大家。

[1] https://github.com/fabianenar...