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

前言

最近幾個月花了比較多精力在專案的測試環境Docker遷移上，從最初的docker“門外漢”到現在組裡的同學（大部分測試及少數的開發）都可以熟練地使用docker環境開展測試工作，中間也積累了一些經驗和踩過不少坑，藉此2017覆盤的機會，總結一下整個環境的搭建過程，希望可以給其他有志於向docker遷移的專案提供些許參考，同時也想跟其他docker的老司機們一起探討改進方式。

Docker遷移的必要性

這篇文章不對docker的基本概念和基本使用進行細講，網上也有非常多關於docker的資料供大家參考。如果是對docker非常陌生的讀者，建議可以自己google一下docker的入門資料，或者推薦大家看一下《第一本Docker書》，可以對docker有一個基本的概念和了解。

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

從我們的大資料測試團隊來看：

1. 測試人員增加

   隨著網易猛獁技術團隊業務線和人員的擴張，我們的測試人員從之前的2-3個已經增長到了現在的7-8個，未來是否會繼續擴張不得而知。

2. 測試型別豐富

   從最初的僅有功能測試保障，到現在自動化測試、異常測試、穩定性測試、效能測試、tpcds相容性／基準測試多種型別同步鋪開。

3. 多版本並行開展

   隨著產品方“對外私有化部署”和“內部版本開發”兩條線的同時推進，我們經常會面臨需要多版本同步測試的處境，而且後端元件可能同時需要測試“社群版本”和“內部開發版本”兩個版本。

伴隨著上述三方面的影響，而我們有且僅有一套測試環境。在測試過程中，經常會出現某一個人在執行測試活動時，其他測試人員被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：HiveServer2、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遷移演化的過程。主要包含的內容如下：

1. 基於Ambari的容器映象製作

2. 基於Swarm的容器雲搭建

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

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

5. 基於映象的環境自動部署

6. 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等）的一鍵生成和自動化測試工作。

附錄

1. 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 看配置是否生效

網易大資料為您提供網易猛獁等服務，歡迎點選免費試用。

本文來自網易實踐者社群，經作者倪志風授權釋出。  

相關文章：
【推薦】 clojure.spec庫入門學習
【推薦】 值得細讀！如何系統有效地提升Android程式碼的安全性？
【推薦】 盤點大資料在遊戲行業中的應用