约定Service构建方式

　　对于DevOps中，将开发好的软件交付给运维人员去部署与维护，过程当中参杂着诸多不可控制的变量，如环境问题、版本问题等等，而Docker容器极大程度上解决了这些问题，同时对于服务的持续交付，也变得方便和简洁，本次讲讲个人整个生成流水线中服务部署方面的一些想法和执行方式，或许不是很中意的想法，而且还可能被认为存在漏洞和错误，可是，至少是这个环节是通了的。最完美的前提至少是运行完成，在设计过程当中，考虑到了几种状况，主要是针对服务器中镜像生产者和服务承载者之间的关系，也有不一样的实现方式。 

 

1、无需交付

　　镜像生产和服务部署共用服务器集群，服务器之间经过Docker Swarm完成集群，同时Docker Swarm中的Manager与镜像生产者在同一台服务器上，管理整个服务集群。

　　

　　注意：仍然须要将生产完毕的镜像推送到镜像仓库中，由于在同一个集群中的其余Worker节点须要指定镜像下载，镜像生产结束后，推送到仓库，此时发起一个建立服务或是更新服务的命令，指定本服务器上的集群完成相应工做。在交付服务时，能够有两种方式进行交付，采用单个服务的建立脚本docker service create或是采用多个服务的批量建立脚本docker stack deploy指定.yaml文件，将.yaml文件中的服务进行批量建立或更新。

　　对于多个服务的建立脚本，我没有去尝试，有兴趣的能够查看Docker官网相关资料，对于单个服务的建立或更新脚本能够采用命令行方式或是使用UI工具去完成建立和更新，如使用Portainer工具，在Portainer中操做是很方便的。

 

2、手动交付

　　当镜像生产者和服务部署分离时，一般也是这种情形，镜像生产者只做为镜像的生产，职责即是生产镜像，而做为部署服务器，职责即是承载服务，对外提供服务。这个过程当中就存在着，服务由谁建立，何时更新，由谁更新的一些问题，对于这些问题，也在一步一步设计中解答，本次先使用手动交付的形式，使用命令行来完成服务建立和更新，当镜像生产完毕后，即是交付环节，手动交付是最为基本的交付方式了。

　　经过命令行方式完成手动交付：

　　一、在Jenkins中使用命令行完成交付，当镜像生产完毕，执行建立服务或是更新服务，这有点随着镜像的变动而变动，无需人为操做，可是也是有问题的，就单个来说，镜像的变动每每是由开发人员将代码合并到主干中，才触动镜像更新，这也在必定程度上受限于合并到主干的时机，若是合并太过频繁，则镜像生产者须要连续生产，而且中间的镜像生产过程变得毫无心义了。

　　二、在Swarm Cluster内使用命令行建立服务完成交付，在Swarm集群中的Manager节点上单个操做，是可行的，若是集群数量少，且没有安装图形管理工具之类的，可使用这种方式，只是若是Swarm Cluster数量过多，须要一个一个切换\登陆，也是比较繁琐的。

　　三、在其余主机上操控Swarm Cluster使用命令行完成交付，这个过程同直接操做Swarm Cluster也是差很少的，只是可使用额外的管理主机管理多个Swarm Cluster的Manager节点，这样一来，也较为方便，直接在一台非Swarm Cluster内的主机上便可完成全部Swarm Cluster的建立和更新过程。

　　

　　图例：直接在Jenkins所在主机上操控Swarm Cluster完成交付

 

3、借助工具手动交付

　　对于命令行来说，多条复杂命令老是难记，有能够直接操做的工具每每是更受欢迎的，而对于Docker来说，Portainer工具是极受欢迎的，快速安装，简单的操做界面，丰富的功能等，一样还有其余不错的图形化容器管理工具，如Seagull、Shipyard等。

　　一、利用Portainer工具完成手动交付，在Portainer界面中，配置好仓库地址和用户名密码，便于私有镜像的拉取，至于仓库，能够是本身搭建的镜像仓库，也可使用第三方提供的镜像仓库，如阿里云、腾讯云镜像仓库。

　　

　　二、利用其余Docker及Docker Swarm集群管理工具完成手动交付，至于使用其余的工具，我也没有使用过，可是工具只不过是将命令行进行了分装，所以，其余图形化管理工具也是应该存在这些功能。

　　

　　图例：利用Portainer工具操控Swarm Cluster完成交付

 

4、借助工具自动交付

　　对于自动交付，这个功能，只是见到过其余人这么玩过，猜测了一下工做方式，至于实际尝试，并无去作，由于思考了一些操做过程，感受我对这个自动交付的环节并不太感冒，由于按照生产来说，追求稳定才是重要的，若是存在测试人员，测试相应服务完毕后，推送测试好的镜像，这是运维人员将镜像交付到生产环境中，可以保证不出差错，虽然失去了效率，可是也在是问心无愧。至此，我只能简单描述下借助工具完成自动交付过程，在Docker Swarm集群中的Manager节点或单独弄一台服务器做为镜像更新后的交付服务器，在服务器中加入Jenkins工具，指定镜像版本更新，则拉取最新镜像完成服务更新，镜像首次推送，则完成服务建立，对于使用批量建立/更新服务的脚本文件，没有使用的太深，可是那个是很是有价值的。

　　

 

 　　至此，几种我用过的方式也讲完了，在其中对于docker stack deploy使用的较少，由于docker stack deploy使用场景是为了批量服务的建立和更新而存在的，若是对于单个服务我都使用这个命令，有点杀鸡用牛刀的感受，而对于之后的k8s学习，使用批量服务建立更新脚本文件，将会是常态。目前我如今采用的是“借助工具手动交付“这种方式，缘由有几点，主要是，思考了下，服务交付的意义，主要是为了稳定，少出问题，必须在确保稳定后才能交付部署，经测试人员测试完毕后完成交付到生产环境，这应该是咱们所但愿可以见到的，不管开发人员天天或每周有多少个版本更新，经测试人员测试后的稳定版本，才能交付到生产环境中，而不是说开发人员一将分支代码合并到主干中，有新的镜像生成了，就直接将新的镜像推送到生产环境中，而作到所谓的持续交付的目的，实际的持续交付应该是保证测试完毕到生产部署这个环节具备连续性，稳定性，每一次交付都经得起推敲，具体其中发生了什么，稳定性如何等，虽然这种方式效率较低，但对于持续交付来说，这个效率也算是能够接受的。

 

　本文地址：http://www.javashuo.com/article/p-xegmhjlg-ew.html

　欢迎关注微信订阅号，有新的文章将同步到订阅号中

　

2018-12-10,望技术有成后能回来看见本身的脚步