這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
【編者的話】本次主要分享Docker在暴漫中的應用主要包括：開發環境的Service搭建，代碼託管、持續整合、Docker鏡像等若干Support服務、部分微服務以及整個資料服務系統。
暴走漫畫是一家文化傳媒公司。公司除了有若干視頻娛樂節目，還有相應的社區網站及移動APP。流量UV是200萬/天左右，PV大概是千萬層級。為了更加有效地運營以及推薦使用者個人化，2015年成立了資料部，負責暴漫的資料分析和資料採礦相關服務。
暴漫沒有自己的伺服器，是使用的國內某雲端服務。暴漫的後端主要是基於Ruby開發。也有基於Go、Python的一些微服務。
Docker在暴漫中的應用主要包括：
- 開發環境的Service搭建
- 代碼託管，持續整合，Docker鏡像，等若干Support服務
- 部分微服務以及整個資料服務系統
所以今天的內容是一些中小規模以及國內雲端服務下的Docker實踐的相關心得，主要包括在資料服務的架構及Docker化的部署。
1. 簡單介紹下開發環境以及Support服務Docker應用
由於開發環境主要是Mac，也有少量Ubuntu和Windows，所以主要採用Vagrant+Docker方式。 將微服務做成鏡像，在 Vagrant 中起相應的容器，把連接埠暴露給 Host（Vagrant），本地跑 Ruby（on Rails）。
Support 服務的話，其他都很簡單，只有持續整合介紹下。我們用的GitLab CI。GitLab CI支援將 task 跑在Docker Container 裡面，所以我們為不同的項目準備不同的測試環境（鏡像）以及外部依賴（eg. MySQL、Redis），然後在對應的Container裡面跑測試。
關於部署的話，我們平時的開發在develop分支，一旦向Masters分支合并後，會觸發部署的task。 部署的 task 跑在特定的Container裡面，這個Container共用了 Host 的
docker unix sock檔案，可以執行
docker build、
docker push等命令。
關於開發環境和Support服務的Docker應用，因為不是今天的重點，並且前面也有很多朋友做過類似的介紹，所以先簡單介紹到這裡。
2. 微服務和資料服務系統的Docker應用
今年我們做了很多微服務的嘗試，例如訊息推送，推薦系統，反垃圾系統，資料分析系統，視頻抓取等等若干子系統的拆分上線。 雖然過程是痛苦的，但是結果卻是令人欣慰的。這些微服務，幾乎都是基於Docker的。
2.1 Rails +Docker化的微服務
整體來說，我們是個混合的架構，Rails是正常的跑在雲主機中的，微服務跑在Docker中。為了協調好各方，我們對基礎服務做了一點小小的調整。
這裡不得不說說我做架構的一點心得。好的架構除了能滿足業務需求，還要是與特定的團隊，特定的資源所配套的。在暴漫，由於技術力量有限，開發排期滿，所以我都是盡量採用“非侵入式”的方案，這在後面的資料服務的構建中也有體現。
首先，我們給所有的機器都裝上了Docker。 其次，我們搭建了一個 etcd叢集，將所有的雲主機都納入了etcd叢集。而etcd也是跑Docker裡的。
為了方便的跑起來etcd，我們寫了個一套bash+Python的指令碼（Python 的指令碼也是跑在Docker裡的），然後所有的機器直接存取本機IP可以訪問和操作etcd。
這裡插一句，我們沒有去折騰如何讓Docker跨主機群組網，而是直接採用映射到host的方式。一方面國內雲主機只能這麼幹。另一方面，我們之前使用雲主機也是單個主機特定用途的。 另外，在生產環境中，我們大量的使用了shell + etcd來啟動Docker Container的方式。可以給大家看個 etcd 的啟動指令碼。這個script放到最初的機器上就可以方便地啟動起來etcd 叢集。
#!/bin/sh
# pull pycsa docker image
docker pull xxxx/pycsa:latest
# nodes list to init the cluster
ClusterNodes=$(docker run —rm \
-v .:/data \
xxxx/pycsa:latest \
python initial-cluster.py getnodes)
# get host ip
HostIP=$(ifconfig eth0 | awk '/\<inet\>/ { print $2}' | sed 's/addr://g')
# get the etcd node name
EtcdName=$(docker run —rm \
-v .:/data \
xxxx/pycsa:latest \
python initial-cluster.py getname ${HostIP})
# create dir structure
EtcdData=/data/etcd/data
mkdir -p ${EtcdData}
# pull etcd docker image
docker pull quay.io/coreos/etcd:latest
# create etcd container
docker run -d \
-v /usr/share/ca-certificates/:/etc/ssl/certs \
-v ${EtcdData}:/data \
-p 4001:4001 -p 2380:2380 -p 2379:2379 \
—name etcd quay.io/coreos/etcd:latest \
-name ${EtcdName} \
-data-dir /data \
-advertise-client-urls http://${HostIP}:2379,http://${HostIP}:4001 \
-listen-client-urls http://0.0.0.0:2379,http://0.0.0.0:4001 \
-initial-advertise-peer-urls http://${HostIP}:2380 \
-listen-peer-urls http://0.0.0.0:2380 \
-initial-cluster-token bzetcd-cluster \
-initial-cluster ${ClusterNodes} \
-initial-cluster-state new
解釋下，initial-cluster.py 是個Python的指令碼，跑在一個pycassa的容器裡，這個容器有Python環境以及相關的package這樣原來的服務幾乎不受任何影響，我們可以利用 etcd+Docker+Shell Script來組建新的服務。
2.2 資料服務
我們的資料服務包括資料分析和資料採礦兩大塊。資料分析主要是為了給運營提供量化的效果評估以及指導。資料採礦則包括推薦，反垃圾等。
資料服務的基礎是資料流，即：資料收集->資料分發->資料處理<->資料存放區。
先給大家看個整體的架構圖，由於本人不擅作圖，所以直接用手畫的，還請見諒。。
首先資料收集部分，就像之前說的，我盡量採用“非侵入式”的方案，所以，我們的整個資料收集都是基於日誌的。我們在每個應用伺服器上裝了Logstash（跑在Docker中）來收集各個應用伺服器的日誌，然後打到Kafka（跑在Docker 中）裡，給不同的用途使用。
一份COPY 直接由Kafka一端的Logstash儲存到Elasticsearch（跑在Docker中）中。 一份COPY 經過Spark（跑在Docker中）Stream做即時處理（包括一些特定日誌的提取），然後將處理的結果儲存在 Elasticsearch 裡 還有一份 COPY 直接儲存到 HDFS（由雲端服務商提供）。
這裡有個小問題，比如有些資料本身日誌裡並沒有，比如使用者的點擊行為。這個時候，我們專門開發了一些 "ping" 介面，這些介面通過 Nginx 直接返回 200，並記錄相關日誌。
此外還有一部分資料，例如一些比較需要“較嚴格的完備”的，例如用於推薦系統，反垃圾系統學習的資料，我們儲存在 SQL 資料庫中 下面我做些稍微詳細的介紹。
2.2.1 資料分析
資料分析有兩種：即時資料分析和離線資料分析。
即時資料分析從Kafka到Spark stream，處理結果進Elasticsearch，離線分析是定時任務，從 HDFS 到 Spark，處理結果進Elasticsearch。一般來說，離線的結果會逐步包含即時的結果，同時即時的結果領先於離線分析的結果。
這裡的分析有些抽象，我來舉個例子：
Q：統計某個板塊同時線上人數的變化趨勢。
A：使用者每次訪問都有日誌，日誌裡包括訪問內容以及使用者標識。首先 spark stream 從日誌裡抽取出特定板塊不同使用者的訪問事件，以秒為單位合并相同使用者事件。
這就是分析結果：時間戳記：人數。 然後這個結果怎麼用？
Elasticsearch有很強大的agg介面。你可以以1秒、10秒、1分等等各種時間間隔單位彙總這段時間內的線上人數，彙總方式用 「平均」或「最大」。
2.2.2 資料採礦
我們主要做了2個具體的資料採礦系統：推薦+反垃圾。今天主要講下架構。
這兩個系統基本上步驟是一樣的，分為2步：訓練（train）和 服務（serve）。
在train階段，定時起一個spark job，從訓練資料集中讀取資料，學習出Model，然後將Model儲存成檔案。
在serve階段，起一個帶 serve 的 Spark job，load 之前學習出來的model 檔案進記憶體，然後接受外部API調用，返回結果。
關於服務的開發這部分因為涉及到太多額外的知識，我就不多說了。 這裡講個痛點：Spark的Docker化。
2.2.3 Spark的Docker化
Spark的Docker化分為兩個部分：
- Docker化的Spark叢集
- Docker化的Spark調用
Spark和我們一般用的服務不太一樣，它的叢集不是提供運算服務的，而是一種資源費配的調度器。
讓 Spark 跑 Job，其實是起的一個 Spark 的本地程式，這個本地程式會向cluster（要資源其他機器），cluster 分配資源以後，這個Spark程式就把一些工作放在這些資源當中運行（進程）。
所以Spark的Docker化分為兩個部分。
對於Spark調用，也就是啟動Spark的本地程式，我們就是在跑程式的鏡像中整合Java環境，Spark程式。
對於Spark叢集，稍微複雜一些。Spark 支援三種叢集：Mesos、Yard還有Spark自己的一個Standalone。
我們搭建的Spark Standalone叢集，這還是考慮到我們自身的資源與需求。 由於沒找到官方的Spark Docker image，我們自己做了一個，就是Java環境+Spark程式，然後利用script+etcd以不同的姿勢（master 或 slave）在不同的雲主機上啟動Spark容器。
官方推薦要起3個Master，用ZooKeeper做quorum，這個我們最近正在搞，還沒上線，就不分享。我們現線上上跑的是 1 master + 7 slave。
Q&A
Q：請問Docker是部署在裸機還是虛擬機器，Docker的管理用的什嗎？部署是人工嗎？
A：Docker 是跑在國內某雲主機上的，所以應該算虛機。
Q：傳統關聯式資料庫怎麼Docker化的？
A：我們傳統關聯式資料庫並沒有Docker化，一方面我們直接用的雲主機提供的sql資料庫服務，另一方面，也許這部分原有的方案太成熟，短期Docker完全取代可能比較困難。
Q：每台機器上都部署Logstash，那filter部分在哪處理？為什麼不用syslog來轉寄日誌到Log Service器？
A：filter部分是通過spark stream來做的，Logstash純粹收集轉寄， kafka是一個 MQ 系統，而且即時分析從Kafka到spark stream很方便。
Q：如何做微服務拆分的，經驗是什嗎？
A：這個問題我感覺有點大，我嘗試回答下：先做好詳細的計劃，盡量保證服務的平穩過渡，必要的時候，老系統和新系統同時保留一段時間。
Q：Docker用的時候可以掛載儲存？就是想把靜態網站圖文資料Docker化，這些靜態檔案我們儲存在單獨的分布式儲存和陣列中，走的nfs協議和私人api的形式。
A：這個放image裡好像不是好主意，要不用一些分布式的儲存方案，要不用雲端儲存體服務?
Q：“一份copy存到hdfs裡”考慮過其他的儲存嗎？
A：Spark有方便的對hdfs的介面，且雲端服務商有現成的hdfs服務提供，所以我們就用了。
Q：為什麼選擇Logstash，而不選擇Flume，它們有什麼差異，比如對安裝端的資源開銷投入產出比等？
A：最近在研究用heka，開始用Logstash的話是因團隊本身的知識偏好(Ruby 團隊)。
Q：我覺得在資料服務部分講了太多，我更想知道Docker在開發，測試或生產環境怎麼使用，利用什麼方式管理Docker叢集，部署服務？比如那個shell+etcd來啟動Docker是怎麼回事，為什麼不用一些Docker生態相關的開源工具，比如k8s、swarm之類 ？
A：關於為什麼沒用k8s。我開始也說了，選擇技術架構不光要考慮技術本身，還要考慮團隊資源，以及現有的限制。我們用的國內的雲主機，這樣的前提下要在生產環境中用k8s本身就不太可能。另外技術團隊人手也很欠缺。
Q：請問Docker容器是如何進行遠程部署和自動部署的？
A：我們用了傳統的部署工具(Ansible)。
Q：Ansible如何擷取Docker主機列表，所有的Docker容器？
A：Ansible 是操作雲主機的，就和以前的用法一樣。
Q：請問ping nginx獲得使用者點擊是怎麼做的，可以詳細介紹下嗎？
A：將某些統計資料放在ping介面的參數裡，這樣定製nginx的日誌可以記錄下來。
Q：反垃圾系統資料庫的資料是通過什麼方式進入Kafka的，ogg、sqoop嗎？
A：樣本資料的話是rails程式推進mq的。
Q：搜尋引擎選Elasticsearch而不是Solr，可以講一下這樣選擇都有哪些考慮嗎？
A：Elasticsearch不僅僅是個搜尋引擎，更是我們用來做結果彙總的database，而且有很好的水平擴充特性。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以上內容根據2015年9月29日晚群分享內容整理。分享人
丁彥，暴走漫畫技術總監。負責暴走漫畫資料分析、資料採礦系統的設計與實現。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加：liyingjiesx，進群參與，您有想聽的話題可以給我們留言。
