微服务实施笔记（五）——生产环境部署

上回书，把服务注册的整个流程在本地单机上完整的走完了，接下来就要把这些东西部署到虚拟的生产环境中去了。整个服务注册的流程都是依靠docker进行打包和部署的。当要发布到生产环境中的时候就涉及到docker镜像的集中管理了。众所周知，docker的镜像管理服务器是在国外的，国内访问那是一个慢，怎么办？最好的办法就是搭建一个私有的docker仓库了。说干就干。

部署私有docker仓库

打开虚拟机，ssh远程登录上去。执行如下命令：

sudo docker run -d \
  -p 5000:5000 \
  --restart=always \
  --name registry \
  --privileged=true \
  -v /mnt/registry:/var/lib/registry \
  registry

还是一行代码搞定，docker的世间就是这样。不过这次是在虚拟电脑上执行，在server1上执行。

• -v /home/hzq/registry:/var/lib/registry` 默认情况下，会将仓库存放于容器内的/var/lib/registry目录下，指定本地目录挂载到容器。
• -p 5000:5000 端口映射
• --restart=always1 在容器退出时总是重启容器,主要应用在生产环境
• --name registry 指定容器的名称

服务已经启动。然后添加防火墙规则：

sudo ufw allow 5000

然后就是把前章中建立的3个服务镜像发布到这个刚建立起来的私有仓库中。

因为要发布到私有的仓库中，在发布之前还有几个准备工作要做，第一个是配置docker的客户端，因为docker的客户端在和服务器进行通信的时候默认是使用https协议的，而我们目前搭建的服务端是http协议（开启服务端的https协议请参考https://docs.docker.com/registry/deploying/），那么就需要配置客户端在和私有仓库进行通讯的时候使用http协议。配置方法如下：

Ubuntu中修改配置

在/etc/docker/daemon.json文件中添加{ “insecure-registries”:[“192.168.1.231:5000”]}。

sudo vim /etc/docker/daemon.json

修改后的内容如下：

第一行是配置的加速器地址。

配置完成后重启docker

sudo systemctl restart docker

Mac os X中修改配置

打开docker for mac 的Preferences项。

在insecure registries中添加一条数据即可。

配置完成后点击 Apply & Restart 按钮重启docker服务。

Wndows中修改配置

发布镜像

客户端的配置修改好后接下来就是修改要发布的镜像了，要把发布的镜像的tag改为【要发布的私有仓库地址/镜像名字】的形式。接下来分别发布server1、server2和server3三个docker镜像。

第一步在每个项目文件夹下，重新打包docker镜像：

docker build -t 192.168.1.231:5000/server1 .
docker build -t 192.168.1.231:5000/server1 .
docker build -t 192.168.1.231:5000/server1 .

打包后如下图所示：

然后就是发布这三个镜像了：

docker push 192.168.1.231:5000/server1
docker push 192.168.1.231:5000/server1
docker push 192.168.1.231:5000/server1

发布完成后在server1虚拟机中运行：

sudo docker run --rm -d \
-p 3000:3000 \
192.168.1.231:5000/server1:latest
sudo ufw allow 3000

然后在浏览器中验证

发布成功！

部署服务注册和发布

在服务器server1中执行如下命令：

sudo docker run -d -e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' --name=node1  -p 8300:8300 -p 8301:8301 -p 8301:8301/udp -p 8302:8302/udp -p 8302:8302 -p 8400:8400 -p 8500:8500 -p 53:53/udp -h consul_node1 consul agent -server -bootstrap -node=node1 -client 0.0.0.0 -ui
sudo ufw allow 8500
sudo ufw allow 8300
sudo ufw allow 8301/udp
sudo ufw allow 8302
sudo ufw allow 8400
sudo ufw allow 53

用浏览器验证一下:

可以看到consul已经正常运行，接下来是registrator服务。在server1的home文件夹下新建文件docker-compose.yml

vim /home/docker-compose.yml

并在其中写入如下内容：

version: '2'
services:
  registrator1:
    image: gliderlabs/registrator
    restart: always
    network_mode: "host"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock
    command: "-ip 192.168.1.232 consul://192.168.1.231:8500"

然后使用浏览器验证一下，可以看到服务注册正常，服务健康检查正常。

然后以同样的方法在server2中部署一个registrator服务，然后再部署server2

sudo docker run --rm -d \
-p 3001:3001 \
192.168.1.231:5000/server2:latest
sudo ufw allow 3001

验证一下看看

server2服务注册正常，健康检查地址正常，健康检查结果正常。

然后再用相同的方法部署server3服务就完成了微服务架构应用场景的最后一环，建立webapi集群：

服务集群的工作方式

这样一个建立好的集群的工作方式如下图所示：

这个集群的正常工作完全建立在docker之上。每台物理服务器有一个registrator服务，这个服务的作用就是监视本服务器上的docker引擎。每当一个docker容器开始运行后，registrator服务就能监视到，通过docker引擎和docker中配置的服务信息向指定的consul服务注册中心注册服务。当监视到docker停机后就自动向consul注销服务。consul也会通过服务提供的健康检查接口检查服务的健康状况，及时的移除不健康的服务。

这套架构的优点是：

• 足够简单，基于docker，开发、部署和运维都比较简单；
• 服务和服务之间耦合度较低，如果要更换服务注册中心，无需改动服务，registrator可以自动适配多种服务注册中心。
• 自动化程度较高。