在读完《Docker技术入门与实践》这本书后，基本上已对Docker了有一些入门的理解，以及我们为什么要使用Docker
答：我们发现在实际工作中，通过openstack一旦把一个VM创建给开发，或者测试人员后，便很难再回收回来。
openstack使用的KVM或Xen，均是采用声明内存的方式，并且内存是独占方式，无论开发和测试人员有没有用这台机器，它就占坑在那里，
所以开发和测试环境，最先出现的瓶颈应该就是内存不足，导致后续无法再开通开发或测试的虚拟机。常规小服务器开到十几、二十台左右就没法再开了VM了。
Docker出现无疑是解决这个场景的一大利好，在物理机上，无论它这个容器实例有没有使用，内存资源都是竞争态的，默认没有独占内存。所以一台物理机启用Docker可以很容易开到上千台容器
但也有个一弊端，因为没有内存隔离，那内存隔离的安全性问题上就比较难处理，因此，Docker在企业的应用，绝大部份场景是应用在开发环境和测试环境。生产环境照样可以通过DockerFile的布署步骤，完整拉一套KVM生产机
接下来需要实验Docker的集群环境搭建。
参考上面这条链接，它讲解了以下
Docker 集群工具比对：Kubernetes vs Docker Swarm
最终决定实验使用Docker官网提供的Swarm集群管理工具（目的是组件1-2管理上的高可用），由于是实验环境，在openstack开了几台VM机来实验验证
1、注册服务监控与自动发现组件--consul ，使用3台机器
2、管理组件--manager ，使用2台机器
3、容器启动组件--node ，使用2台机器 （无法高可用，节点销毁后，会丢容器）
4、镜像存储组件--registry ，使用1台机器 (暂无高可用方案，需要验证镜像使用其它备份方式的话（比如rysnc方式），节点销毁重建后，能否使用备份目录进行还原)
注：一台机器当然也可以同时启动多个角色
测试主机分配如下
10.40.100.141 docker-manager0.venic.com
10.40.100.142 docker-manager1.venic.com
10.40.100.143 docker-node0.venic.com
10.40.100.144 docker-node1.venic.com
10.40.100.145 docker-consul0.venic.com
10.40.100.146 docker-consul1.venic.com
10.40.100.147 docker-consul2.venic.com
10.40.100.148 docker-registry.venic.com
上层nginx配置需要用到的域名解析如下
10.40.42.10 docker-manager.venic.com
10.40.42.10 docker-consul.venic.com
均采用CentOS7 ，且配置为1核2G内存。并执行了 yum update -y 更新过了。由于更新了，所以下面的组件一定确保关闭
设置每台主机的上的主机名（hostname）
hostnamectl --static set-hostname XXX
关闭防火墙、Selinux、NetworkManager
systemctl stop firewalld.service #停止firewall
systemctl disable firewalld.service #禁止firewall开机启动
service NetworkManager stop
chkconfig NetworkManager off
vi /etc/selinux/config
重启
配置时钟同步，使用ntpdate或者chrony ，我使用chrony
修改每台主机上的/etc/resolv.conf 配置，实时将DNS服务器指向内网DNS服务器IP地址：10.40.200.100 （当然还要修改/etc/sysconfig/network-script/ifc-eth0 配置DNS1=10.40.200.100）
虽然在主机/etc/hosts上配置上面的域名解析，但我配了，发现Docker集群工作时，它有些服务直接用DNS解析，绕过/etc/hosts，但我也保留了这个/etc/hosts 配置
在10.40.200.100 （dnsmasq） 服务器添加解析记录，将以上9台机器的解析加进入。让其实现域名互访
全部使用有sudo 权限的venic用户执行安装docker-engine安装（当然使用root也可以安装，只是docker它提供它的shell脚本是以普通用户来执行的，不然会提示报错）
# curl -sSL https://get.docker.com/ | sh
切换回root用户
# vi /lib/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target
[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock --insecure-registry docker-registry.venic.com:5000
ExecReload=/bin/kill -s HUP $MAINPID
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
#TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process
[Install]
WantedBy=multi-user.target
service docker start
chkconfig docker on
测试docker功能是否正常，在每台上单独运行一下hello-world，如下正常
# docker run hello-world
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker Hub account:
https://hub.docker.com
For more examples and ideas, visit:
https://docs.docker.com/engine/userguide/