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
欢迎关注微信订阅号，有新的文章将同步到订阅号中