細說Mammut大數據系統測試環境Docker遷移之路

時間 2019-11-29

標籤細說 mammut 數據系統測試環境 docker 遷移之路欄目 Docker 简体版

原文原文鏈接

歡迎訪問網易雲社區，瞭解更多網易技術產品運營經驗。html

前言

最近幾個月花了比較多精力在項目的測試環境Docker遷移上，從最初的docker「門外漢」到如今組裏的同窗（大部分測試及少數的開發）均可以熟練地使用docker環境開展測試工做，中間也積累了一些經驗和踩過很多坑，藉此2017覆盤的機會，總結一下整個環境的搭建過程，但願能夠給其餘有志於向docker遷移的項目提供些許參考，同時也想跟其餘docker的老司機們一塊兒探討改進方式。python

Docker遷移的必要性

這篇文章不對docker的基本概念和基本使用進行細講，網上也有很是多關於docker的資料供你們參考。若是是對docker很是陌生的讀者，建議能夠本身google一下docker的入門資料，或者推薦你們看一下《第一本Docker書》，能夠對docker有一個基本的概念和了解。mysql

可是展開全篇介紹以前，我仍是想簡單介紹下「Docker遷移的必要性」，記得許家滔在《微服務在微信的架構實踐》一文中提過：「技術的演進來源於業務的需求」（原話記不太清了，大體是這樣），任何技術的改進不會是無故進行的。git

從咱們的大數據測試團隊來看：web

測試人員增長sql
隨着網易猛獁技術團隊業務線和人員的擴張，咱們的測試人員從以前的2-3個已經增加到了如今的7-8個，將來是否會繼續擴張不得而知。docker
測試類型豐富shell
從最初的僅有功能測試保障，到如今自動化測試、異常測試、穩定性測試、性能測試、tpcds兼容性／基準測試多種類型同步鋪開。json
多版本並行開展後端
隨着產品方「對外私有化部署」和「內部版本開發」兩條線的同時推動，咱們常常會面臨須要多版本同步測試的處境，並且後端組件可能同時須要測試「社區版本」和「內部開發版本」兩個版本。

伴隨着上述三方面的影響，而咱們有且僅有一套測試環境。在測試過程當中，常常會出現某一我的在執行測試活動時，其餘測試人員被block，須要等待其執行完成後，再開始本身的測試，並且測試執行時不能被其餘人影響的狀況。此外，最近的一個版本上線後，出現了一個線上問題是跟「跨集羣」業務有關的功能，而這一塊在上線前不管是開發仍是測試都是沒有測試過的，由於不管是測試仍是開發，咱們都只部署了一套集羣，沒有辦法進行跨集羣的測試，僅經過開發的Code Review來保證上線。

至於爲何咱們再也不多部署幾套測試環境呢？大數據整套系統很是的龐大，下面是我簡單羅列的大數據組件的種類（可能會有遺漏）：

1. Mammut：Webserver、Executor、Redis Server、MySQL
2. Azkaban：Az-FC、Az-Webserver、Az-Executor、MySQL
3. Hadoop-Meta：Scheduler RPC、Service、KDC-RPC、MySQL
4. Kerberos：KDC Server、Kadmin、Kerberos Client
5. LDAP：Client、LDAP Server、LdapAdmin Server
6. Hive：HiveServer二、Hive Metastore、Hive Client、MySQL
7. Spark：Spark History Server、Spark Thrift Server、Spark Client
8. Ranger：RangerAdmin、MySQL
9. HDFS：NameNode、DataNode、JournalNode、HDFS Client、ZKFailoverController
10. YARN：ResourceManager、NodeManager
11. MapReduce：MapReduce History Server、MapReduce Client
12. ZooKeeper：Zookeeper Server、Zookeeper Clinet
13. Ambari：Ambari Server、Ambari Agent、MySQL
14. Hbase：待補充
15. Impala：待補充

組件的種類大體有15類，每一個組件各自有本身的多個服務須要部署，而且其中大部分（80%以上）的服務都是集羣式地多節點部署以支持高可用/負載均衡。從咱們測試環境的Ambari管理頁面上看下咱們具體部署的組件數量：

能夠看到集成Ambari的「進程」級別的組件數量已經總計多達106個，還不包括其它未集成ambari的組件，如hadoop-meta、ldap、hbase、impala等等。

上述介紹的是猛獁系統的組件規模，而部署一套系統的成本到底有多大？記得在咱們第一次進行私有化部署演練的時候，當時尚未使用ambari，項目組讓每一個開發、運維事先整理好本身所要部署的組件的詳細操做記錄，而後十來個開發加運維一塊兒坐在「小黑屋」，部署了三天，沒有部署成功。更不用說，部署完成後，投入使用過程當中的環境維護成本。若是離開ambari，相信沒有多少人敢獨自去部署一套猛獁系統。

在「環境亟待擴張」和「環境搭建維護成本巨大」的矛盾對立下，將測試環境向docker遷移的思路應運而生，docker的引進能夠很好地解決咱們的困境。

下面開始進入正題，介紹整個測試環境向Docker遷移演化的過程。主要包含的內容以下：

基於Ambari的容器鏡像製做
基於Swarm的容器雲搭建
跨雲主機的容器私有網絡組建和容器內部通訊
支持多套環境的容器管理和組網方案
基於鏡像的環境自動部署
Rancher——集羣環境的監控和管理

1.基於Ambari的容器鏡像製做

首先介紹下鏡像的製做過程。你們都知道，docker的鏡像製做有兩種方式：

（1）基於容器的commit   （2）基於Dockerfile的構建

從Docker官方的推薦和業界大量的實踐證實，Dockerfile是更好的鏡像製做方式，它從一個基礎鏡像開始，記錄全部的操做過程，以及workspace、環境變量、volumn卷掛載、端口映射等一系列的重要信息。而且，它是可重錄的，在任何安裝了docker的環境下，只要基於一份簡單的Dockerfile文件就能夠構建出所要的鏡像。當鏡像發生更改時，也只須要修改部份內容，便可以完成新鏡像的構建。對於頻繁更新的鏡像來講，這絕對是一種最佳的實踐方式，由於從基礎鏡像到目標鏡像的全部操做一目瞭然，不會引入額外的冗餘文件系統。

然而，在大數據組件的鏡像製做過程當中，並無採用Dockerfile的方式，而是選擇了第一種commit的方式。這主要是由於前面介紹過了大數據組件規模的龐大，若是要爲每一個組件的每一個服務去製做單獨的鏡像，可能須要製做上百個鏡像，而且，各個組件的服務之間存在着繁雜的依賴關係，無論是採起何種方式（組件間的依賴處理通常有兩種方式：1.手動地將服務的端口映射到宿主機的端口，依賴服務調被依賴服務所在宿主機的相應端口；2.藉助編排工具，如compose、kubernetes等，建立service，處理service之間的關係），我以爲由我一我的在短期內都是沒法實現的，更不論你須要去詳細瞭解每一個組件的單獨部署方式。

此外，由於咱們的私有化部署環境和現有測試後端集羣的搭建都是基於Ambari（大數據環境部署工具，能夠經過ambari-server將衆多集成的大數據組件，批量部署到若干檯安裝了ambari-agent的機器上）搭建的，若是咱們脫離ambari去製做各個單獨的組件服務鏡像，即便最終組合到一塊兒成功完成環境的搭建，那與咱們現有的環境也是不相符的。

基於上述背景，咱們採起了一種新的環境搭建思路：

（1）使用基礎鏡像（如debian7官方鏡像），先啓動一組容器（好比8個）  
（2）在其中一個容器上部署ambari-server，在每一個容器上部署ambari-agent   
（3）使用Ambari Web將集成了ambari的大數據組件（如Hive、Azkaban、YARN、Zookeeper、Spark、HDFS、Mammut、Ranger、MapReduce等）部署到各個容器內部  
（4）在各個容器內手動部署未集成ambari的組件（如Hadoop-meta、LDAP、Kerberos等）  
（5）執行docker commit將所有8個容器製做爲「容器鏡像套件」

而容器間的通訊方式，最容易實現的固然是藉助端口映射，將容器內部端口映射到宿主機端口，經過訪問宿主機IP加端口的方式來通訊。可是，ambari-web在配置各個組件服務的地址時，有一部分配置必須使用主機名的格式，不支持ip加host的方式。並且考慮到後續想要在多套環境中基於鏡像去快速部署，基於ip加端口的方式顯然會對擴展形成嚴重的阻礙，須要額外地編寫腳本去動態獲取對端服務的宿主機ip、映射端口，甚至可能在部署完成後須要對一些配置進行大量手動修改。

爲了解決上述問題，在咱們的鏡像製做過程當中，採起了固定hostname的方式。爲每一個容器加上特定的hostname（mammut-qa-docker-1.server.org～mammut-qa-docker-8.server.org），這樣在任何須要配置服務依賴的地方，咱們能夠直接填寫對端服務的hostname。而容器之間的通訊，咱們爲每套大數據環境，建立一個特定的私有網絡（network），將同一套環境的容器掛載到同一個特定網絡下，這樣每一個容器會被分配到一個私有ip，同一個私有網絡下的私有ip之間是互通的。而後經過自動化腳本去修改每一個容器內部的/etc/hosts文件，添加ip-hostname的映射到容器內部的路由列表中。

到此，介紹了基於ambari的鏡像製做思路和容器內部通訊的方式。已經能夠在一臺物理機器上，完成整套大數據環境的搭建。然而，在實踐過程當中發現，整個容器的鏡像套件，文件「體積」很是地大：

整個鏡像套件佔用的磁盤空間可達到70多G。對於一個新的機器，去下載70G的鏡像，顯然仍是須要挺久的時間。經過對鏡像內部文件的分析，能夠發現，鏡像中有一大部分的文件來自於ambari-web在部署組件過程當中產生的日誌文件，存儲在各個容器內部的/var/log文件下，而這部分日誌其實並非咱們部署所必須的，徹底能夠不打進鏡像中。所以，經過將/var/log目錄以volumn卷方式掛載到宿主機磁盤中，從新制做鏡像，整個鏡像套件的「體積」大幅度縮小，約30G：

2.基於Swarm的容器雲搭建

上節介紹了容器鏡像的製做，已經能夠在一臺物理機上完成整套環境的搭建。然而，對於咱們大多數項目來講，物理機資源是很是奢侈和稀缺的，咱們不太可能讓公司採購那麼多的高規格的物理機。相對來講，雲主機資源比較容易申請。目前經過「運維夸父系統」申請的雲主機的配置能夠達到8核cpu、32G內存、掛載500G雲盤。顯然，這麼多的組件若是要所有部署在一臺雲主機上，暫不說該雲主機是否能夠支持這麼多的進程資源，即便你部署成功，後續在執行任務的時候確定會出現資源不足的場景，要知道你的機器要支持的但是YARN、HDFS等。因此，如何將多臺雲主機聯合起來組成一個容器雲，讓鏡像套件中的8個容器鏡像，分散地部署到不一樣的雲主機上，成爲咱們一個突破機器瓶頸的思路。

業界處理容器編排的主要工具備Kubernertes、Swarm、Mesos。從GitHub上的活躍度來講，Kubernetes是遠超其它兩者。並且，沸沸揚揚的容器編排之爭最近也已經結束，Kubernetes成爲了容器編排最佳實踐的典範，Docker官方也已經宣佈在下一個企業版本開始支持Kubernetes。然而，經過對Kubernetes的調研，它很是依賴於嚴格的微服務的架構，經過yaml能夠很容易處理好服務之間的關係，很是適合企業級應用的生產環境部署。而咱們的環境，其實是經過ambari將多個不一樣組件服務揉合到了一塊兒，並無爲每一個組件去製做單獨的鏡像。組件之間的依賴配置還嚴格依賴於特定的主機名，從各個角度來看Kubernetes都不適用於咱們的場景（固然我並非反對使用k8s，其實我是很想使用k8s。可是要使用k8s的前提應該是須要爲每一個服務去製做單獨的鏡像，而不是雜糅在一塊兒，可能須要去除ambari工具的使用，這須要更上層的架構師來推進。此處若是個人理解有誤差，但願k8s的前輩指出）。

而Swarm（官方原生支持），基於容器的調度，能夠說是很是適合咱們的場景。將多臺雲主機聯合成一個容器集羣，經過swarm-manage將這批容器鏡像調度到不一樣的雲主機上，便可完成容器的部署。同時，若是環境中的雲主機出現資源不足的場景，咱們能夠很方便地添加新的機器，而後將環境部署到更多的雲主機上來實現動態擴容。

關於Swarm集羣的搭建，官方的樣例中，服務發現使用的是Consul，其實Consul包含的功能Zookeeper都有。因爲對Zookeeper更加熟悉，就使用了 Zookeeper來代替Consul作了服務發現後端（discovery backend）。

3.跨雲主機的容器私有網絡組建和容器內部通訊

不一樣於Kubernetes其自身有健全的網絡機制，經過pod能夠很好的管理service的網絡，Swarm並無提供任何容器間網絡的支持。因此，咱們須要本身解決當容器被調度到多個不一樣的雲主機以後，它們之間的通訊問題。

前面提到過，在一臺雲主機上，咱們能夠建立一個私有網絡，而後將8個容器所有掛載到該私有網絡下，讓它們各自擁有本身的私有ip，而後添加ip-hostname的映射，以支持經過hostname的方式互相通訊。如今容器被分配到了不一樣的雲主機上，是否還能夠建立這樣的私有網絡呢？

幸運的是，docker1.9版本以後，docker採用VXLAN的覆蓋網技術，原生地提供了對「跨宿主機組網」很是便利的支持。

這裏簡要介紹下跨主機組網的實現方式，對於實踐過程當中遇到問題的同窗能夠再私下單獨探討。

（1）部署服務發現後端，如Zookeeper  
（2）修改DOCKER_OPTS，加入-H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock --cluster-advertise=eth1:2375 --cluster-store zk://zk_path，重啓docker進程
（3）建立overlay網絡 ：docker network create -d overlay netzni  
（4）建立docker_gwbridge網橋：
    docker network create --subnet 192.168.48.0/20 \
        --opt com.docker.network.bridge.name=docker_gwbridge \
        --opt com.docker.network.bridge.enable_icc=false \
        --opt com.docker.network.bridge.enable_ip_masquerade=true \
        docker_gwbridge
（5）建立容器加入網絡：docker run --net netzni {image}
（6）將已經運行的容器加入網絡：docker network connect netzni {container}

其中第2步是將雲主機加入集羣中，讓集羣知道有哪些機器在集羣中。-H tcp://0.0.0.0:2375是開啓經過tcp socket的方式訪問本機的docker進程，默認狀況下本地的docker進程只有-H unix://var/run/docker.sock的方式，即只支持unix socket的方式訪問本地docker進程。而eth1，必須是你雲主機機房網ip對應的網卡。若是是debian8的系統，修改DOCKER_OPTS參數會出現不生效的問題，能夠參見附錄中第1個問題的解答。

對於第4步，建立docker_gwbridge網橋，這個網橋的做用在跨主機容器網絡中的做用就至關於單主機容器網絡中的docker0網橋的做用，用於連通不一樣主機容器之間的通訊網絡。

自此，咱們又實現了在不一樣雲主機環境下的私有網絡的建立，仔細觀察容器內部的網絡能夠看到：

每一個容器內部有兩個虛擬網卡，eth0對應的就是私有網絡分配的私有ip，而eth1對應的就是docker_gwbridge網橋分配的ip。當兩個容器經過私有ip進行互相通訊時，須要通過docker_gwbridge網橋的轉發。

相似地，當跨主機的容器部署完成後，咱們也須要經過自動化腳本去預置每一個容器內部的/etc/hosts文件，加上ip-hostname的映射。

4.支持多套環境的容器管理和組網方案

前面介紹瞭如何在多臺雲主機上搭建私有網絡以及部署容器。那麼當部署的環境逐漸增多時，咱們如何去部署和管理多套不一樣的環境呢？答案仍是Swarm。

Swarm提供了「Label」的功能，便可以給每一個雲主機貼上相應的標籤。全部基於docker搭建的大數據環境，都加入到一個統一的Swarm集羣，受同一個swarm-manage管理。對不一樣的機器，給它們貼上對應的標籤。好比我有一批新的機器，都給它們都貼上「onwner=hznizhifeng」的標籤，代表是用來部署個人一套測試環境。而後相對應地，建立一個overlay私有網絡networkl_hznizhifeng。在使用swarm-manange進行容器調度時，經過過濾地方式指定容器能夠被調度的機器，以及指定容器須要加入的網絡名，如：

docker -H ${HOST} run -d -e constraint:owner==${OWNER} --net network_${OWNER} --name mammut-qa-docker-7-$OWNER ${REGISTRY}/mammut-qa-docker-7:${VERSION} ./startup.sh

能夠看到，容器名字的命名也能夠經過{OWNER}來進行區分。

5.基於鏡像的環境自動部署

在完成前期的環境搭建工做後，咱們須要將整個部署過程整合成自動化腳本，以實現快速部署，並下降部署的門檻，使得任何測試人員均可以輕鬆地完成環境部署。

下面簡單列下幾個部署腳本的內容，其它項目使用時能夠參考。

（1）debian_init.sh：完成新機器環境的初始化工做，包括安裝docker、給docker守護進程打上owner標籤、掛載雲盤、加入docker swarm集羣、建立docker_gwbridge網橋、建立docker私有網絡等。

（2）mammut-docker-service.sh：容器調度腳本，包含容器啓動、中止、鏡像提交等。

（3）reset_container_hosts.sh：修改容器內部的hosts文件，預置ip-hostname的映射關係。

（4）setup_hosts.py：python腳本，獲取各個容器與所被分配到的雲主機之間的映射信息

關於gitlab的權限，有興趣的能夠私下popo聯繫我開通訪問。

在自動化腳本編輯過程當中，有幾個有意思的實現方式能夠給你們介紹下：

（1）容器鏡像的拉取

從前文能夠看到，咱們即便使用了volumn卷對日誌文件進行掛載，可是鏡像套件「體積」依然有30G，如何提高拉取速度呢？咱們能夠在shell腳本里，在腳本命令後增長「&」的方式，將該條拉取命令掛到後臺執行，以實現多線程拉取的方式提高拉取鏡像的速度，而後在後面加上「wait」命令，以等待全部線程執行完了再執行後續的命令。

docker -H ${HOST} run -d -e constraint:owner==${OWNER} --net network_${OWNER} --name mammut-qa-docker-7-$OWNER -h mammut-qa-docker-7.server.org -v /root/log/mammut-qa-docker7:/var/log -p3306:3306 -p8080:8080 --cap-add=ALL  ${REGISTRY}/mammut-qa-docker-7:${VERSION} ./startup.sh &

docker -H ${HOST} run -d -e constraint:owner==${OWNER} --net network_${OWNER} --name mammut-qa-docker-6-$OWNER -h mammut-qa-docker-6.server.org -v /root/log/mammut-qa-docker6:/var/log -p80:80 -p8042:8042 --cap-add=ALL ${REGISTRY}/mammut-qa-docker-6:${VERSION} ./startup.sh &

docker -H ${HOST} run -d -e constraint:owner==${OWNER} --net network_${OWNER} --name mammut-qa-docker-1-$OWNER -h mammut-qa-docker-1.server.org -v /root/log/mammut-qa-docker1:/var/log -p18081:18081 -p10000:10000 -p50070:50070 ${REGISTRY}/mammut-qa-docker-1:${VERSION} ./startup.sh &

docker -H ${HOST} run -d -e constraint:owner==${OWNER} --net network_${OWNER} --name mammut-qa-docker-2-$OWNER -h mammut-qa-docker-2.server.org -v /root/log/mammut-qa-docker2:/var/log -p19888:19888 ${REGISTRY}/mammut-qa-docker-2:${VERSION} ./startup.sh &

docker -H ${HOST} run -d -e constraint:owner==${OWNER} --net network_${OWNER} --name mammut-qa-docker-3-$OWNER -h mammut-qa-docker-3.server.org -v /root/log/mammut-qa-docker3:/var/log -p8088:8088 ${REGISTRY}/mammut-qa-docker-3:${VERSION} ./startup.sh &

docker -H ${HOST} run -d -e constraint:owner==${OWNER} --net network_${OWNER} --name mammut-qa-docker-4-$OWNER -h mammut-qa-docker-4.server.org -v /root/log/mammut-qa-docker4:/var/log -p8088:8088 --cap-add=ALL ${REGISTRY}/mammut-qa-docker-4:${VERSION} ./startup.sh &

docker -H ${HOST} run -d -e constraint:owner==${OWNER} --net network_${OWNER} --name mammut-qa-docker-5-$OWNER -h mammut-qa-docker-5.server.org -v /root/log/mammut-qa-docker5:/var/log -p50070:50070 -p8042:8042 ${REGISTRY}/mammut-qa-docker-5:${VERSION} ./startup.sh &

docker -H ${HOST} run -d -e constraint:owner==${OWNER} --net network_${OWNER} --name mammut-qa-docker-8-$OWNER -h mammut-qa-docker-8.server.org -v /root/log/mammut-qa-docker8:/var/log -p10001:10001 -p6080:6080  ${REGISTRY}/mammut-qa-docker-8:${VERSION} ./startup.sh &

wait

（2）容器內部hosts文件預置ip-hostname的映射關係

當容器部署完成後，咱們能夠經過docker network inspect network_hznizhifeng的方式，來查看該私有網絡下各個容器所分配到的私有ip信息，該信息是一個json格式，經過對該json的解析，即可以獲得每一個hostname對應的ip地址。這邊用的是python的方式，解析腳本能夠參考：

#!/usr/bin/python# -*- coding: utf-8 -*__author__ = 'zni.feng'import osimport  sys
reload (sys)
sys.setdefaultencoding('utf-8')import jsonclass HostsParser:
    def __init__(self, owner):
        self.owner = owner
        self.network_info_file = 'docker_network_%s' % owner
        self.network_info_dict = None
        self.ip_hosts_mapping = list()    def get_network_info(self):
        if not self.network_info_dict:            with open(self.network_info_file, 'r') as f:
                self.network_info_dict = json.load(f)[0]        return self.network_info_dict.copy()    def get_ip_host_mapping(self):
        if not self.ip_hosts_mapping:
            network_info_dict = self.get_network_info()
            containers_dict = network_info_dict['Containers']            for container in containers_dict.values():
                ipv4 = container['IPv4Address'].split('/')[0]
                hostname = container['Name'][:container['Name'].find(self.owner)-1]
                ip_hosts_mapping="{0}  {1}.server.org".format(ipv4, hostname)
                self.ip_hosts_mapping.append(ip_hosts_mapping)        return self.ip_hosts_mapping    def save_hosts(self):
        ip_hosts_mapping = self.get_ip_host_mapping()
        open('hosts','w').write('%s' % '\n'.join(ip_hosts_mapping))if __name__ == '__main__':    if len(sys.argv) <2:        print 'USAGE: python setup_hosts.py [LABEL]'
        print 'LABEL: hznizhifeng|hzzhangyongbang|hzzhangjun15|e.g.'
        sys.exit(1)

    owner = sys.argv[1]
    parser = HostsParser(owner)
    parser.save_hosts()

6.Rancher——集羣環境的監控和管理

完成集羣的自動部署後，咱們的測試集羣已經能夠輕鬆的部署使用了。而且，經過swarm-manage也能夠對集羣的容器進行管理。可是，swarm並無提供集羣的監控，以及沒有友好的管理頁面。天然而然，咱們但願有一種相似Web頁面的方式，能夠對集羣進行監控和管理。

在對業界的一些集羣監控工具進行了調研後，最終選擇了Rancher（http://rancher.com/）做爲咱們的集羣管理工具。它能夠跟Kubernetes、Swarm等都很好地兼容，並提供了ldap等權限管理的方式，和豐富的管理api。此外它的一大特點就是它的「鏡像應用商店」，就好像App Store同樣。

Rancher的架構跟Swarm相似，由一個rancher-manage，多個rancher-agent和一個mysql組成。其部署方式這裏不細講，你們能夠參考下rancher的官方文檔，或者私下交流。

下面截兩張rancher界面的圖，看看是否是你想要的：

（1）Rancher機器管理頁面

（2）Rancher容器監控頁面

此外，咱們還能夠在Rancher頁面上進入集羣中的任一容器，進行內部操做，截圖可見「3.跨雲主機的容器私有網絡組建和容器內部通訊」這一節中的圖。

總結和展望

能耐着性子看完的，相信都是真的想使用docker進行環境遷移的「真愛粉」，以及願意指點迷津幫助咱們繼續改進的老司機。

從目前的現狀來看，我以爲當前的docker環境基本知足了咱們測試的須要，可是從整個大數據系統的部署來講，確定不是最佳實踐。我相信若是能將各個組件製做成單獨的鏡像，借用k8s的service理念，確定是可讓整個結構更加完善。

從版本升級和鏡像維護的角度來講，咱們目前實際上是比較痛苦的。由於沒有使用Dockerfile，咱們須要基於已有的鏡像，不斷地疊加新的文件系統而後commit，中間勢必會引入冗餘的操做影響容器的整個「體積」。由於沒有爲每一個服務製做單獨的鏡像，不容易實現單個服務鏡像的升級。目前，咱們也只是人爲地創建了一套「版本鏡像套件升級規範」，以一個版本爲一個迭代的方式，統一升級所有的鏡像套件。

目前，咱們全部的部署操做都是在後臺執行腳本的方式來完成自動部署。將來，咱們能夠基於咱們已有的技術棧，搭建一個基於docker的測試平臺，來實現環境的自動部署、回收、擴容，以及基於大數據的特色，實現多類型數據源（如DDB、Oracle、SQLServer、MySQL、PostgreSQL等）的一鍵生成和自動化測試工做。

附錄

debian8系統/etc/default/docker配置沒生效的問題

（1）修改/etc/default/docker文件，用OPTIONS替代DOCKER_OPTS。如：

    OPTIONS="--insecure-registry registry.hz.netease.com -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock"

（2）修改/lib/systemd/system/docker.service文件，加入EnvironmentFile，並在ExecStart中加入$OPTIONS

    EnvironmentFile=-/etc/default/docker
    ExecStart=/usr/bin/dockerd  $OPTIONS -H fd://
（3）執行systemctl daemon-reload使之生效
（4）重啓docker守護進程: /etc/init.d/docker restart
（5）ps -ef|grep docker 或  docker info 看配置是否生效

網易大數據爲您提供網易猛獁等服務，歡迎點擊免費試用。

本文來自網易實踐者社區，經做者倪志風受權發佈。

相關文章：
【推薦】如何有效推動事項的執行？
【推薦】直播平臺杜絕違規內容之道
【推薦】 SimpleDateFormat併發隱患及其解決