细说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并发隐患及其解决