约定Service构建方式 - 好文

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

一、无需交付

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

　　

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

　　对于多个服务的创建脚本，我没有去尝试，有兴趣的可以查看Docker官网 <https://docs.docker.com/>
相关资料，对于单个服务的创建或更新脚本可以采用命令行方式或是使用UI工具去完成创建和更新，如使用Portainer工具，在Portainer中操作是很方便的。

二、手动交付

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

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

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

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

　　3、在其他主机上操控Swarm Cluster使用命令行完成交付，这个过程同直接操作Swarm
Cluster也是差不多的，只是可以使用额外的管理主机管理多个Swarm Cluster的Manager节点，这样一来，也较为方便，直接在一台非Swarm
Cluster内的主机上即可完成所有Swarm Cluster的创建和更新过程。

　　

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

三、借助工具手动交付

　　对于命令行来讲，多条复杂命令总是难记，有可以直接操作的工具往往是更受欢迎的，而对于Docker来讲，Portainer工具是极受欢迎的，快速安装，简单的操作界面，丰富的功能等，同样还有其他不错的图形化容器管理工具，如Seagull、Shipyard等。

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

　　

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

　　

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

四、借助工具自动交付

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

　　

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

　本文地址：https://www.cnblogs.com/CKExp/p/9940469.html
<https://www.cnblogs.com/CKExp/p/9940469.html>

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

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

热门工具换一换