对于DevOps中，将开发好的软件交付给运维人员去部署与维护，过程中参杂着诸多不可控制的变量，如环境问题、版本问题等等，而Docker容器极大程度上解决了这些问题，同时对于服务的持续交付，也变得方便和简洁，本次讲讲我的整个生成流水线中服务部署方面的一些想法和执行方式，或许不是很中意的想法，并且还可能被认为存在漏洞和错误，但是，至少是这个环节是通了的。最完美的前提至少是运行完成，在设计过程中，考虑到了几种情况，主要是针对服务器中镜像生产者和服务承载者之间的关系，也有不同的实现方式。
一、无需交付
镜像生产和服务部署共用服务器集群，服务器之间通过Docker Swarm完成集群，同时Docker Swarm中的Manager与镜像生产者在同一台服务器上，管理整个服务集群。
注意：仍然需要将生产完毕的镜像推送到镜像仓库中，因为在同一个集群中的其他Worker节点需要指定镜像下载，镜像生产结束后，推送到仓库，此时发起一个创建服务或是更新服务的命令，指定本服务器上的集群完成相应工作。在交付服务时，可以有两种方式进行交付，采用单个服务的创建脚本docker service create或是采用多个服务的批量创建脚本docker stack deploy指定.yaml文件，将.yaml文件中的服务进行批量创建或更新。
对于多个服务的创建脚本，我没有去尝试，有兴趣的可以查看Docker官网相关资料，对于单个服务的创建或更新脚本可以采用命令行方式或是使用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工具是极受欢迎的，快速安装，简单的操作界面，丰富的功能等，同样还有其他不错的图形化容器管理工具，如DockerUI、Shipyard等。
1、利用Portainer工具完成手动交付，在Portainer界面中，配置好仓库地址和用户名密码，便于私有镜像的拉取，至于仓库，可以是自己搭建的镜像仓库，也可以使用第三方提供的镜像仓库，如阿里云、腾讯云镜像仓库。