新搬家了,暂时没有网,今天就纯文字描述下吧,今天我们继续接着昨天的话题进行完善,大家看了昨天的文档,会看出来当前存在不少问题,那今天我们就把这些问题解决下。
github仓库地址[1]
参考上两篇文档:
从零打造自己的CI/CD系统|php项目部署v1版本
从零打造自己的CI/CD系统|php项目部署v2版本
•命令行传递参数过多,稍不注意就可能会出错,而且只能是ops
才能操作,不能交付给开发自助发布•本地执行和远程执行在同一个roles里,整体不是很完美•服务么有重新加载(视语言而定)•没有实现滚动更新•没有实现通知机制(甭管是失败还是成功)
从上面两篇文章我们能看得出,命令行传递的参数有些是在项目的生命周期内是固定不变的,这个时候就没有必要进行每次的传入来,可以写到一个文件里,运行roles的时候进行加载即可,我们看看那些是可以抽出来的固化的参数:
•pname•env•git_repo•laravel_releases•smoketest_url
•branch
抛开生产环境来说,我们需要支持研发在非主干分支上进行自测工作,所以传递分支就成了必备功能。
拆分使得本地操作和远程操作更清晰,roles的复用性更强。
•directory create•git clone•compile•deploy(upload)•pre-commit(非必须放在这里做,理论上入仓库之前就需要做)•code-style check•unit-test
•sync•symlinks•disable slb•disable monitor•reload(restart)•verify•enable slb•enable monitor•notify
这一步看情况而定,其实PHP并不需要重新加载,但是如果开启opcache的情况下,可能会导致代码不生效的问题,所以如何操作要看你的场景是什么样的。
其实这里引入一个参数即可,就是serial, 这个参数可以设置百分比,也可以设置为数字,默认不设置的话,整个task的执行是并行的(默认并行数是在ansible.cfg里定义的), 比如serial:1, 意思就是一台一台的操作,这样的话就能实现我们想要的滚动更新的操作,但是,这里要注意,及时我们实现里滚动更新,并不意味着已经实现里零宕机
发布,因为发布的上下文里有很多东西是需要适配的,比如前面的SLB
的超时时间, 比如注册中心的健康检测周期等等。
一个部署操作,甭管是成功的还是失败的,我们都希望有一个反馈,这个时候不能单纯的靠人工去盯着,所以整个流程里我们需要通知,成功里就正常通知,失败的话,不单单要通知,还要有对应的补偿机制。所谓的补偿机制是要清理当前不成功操作的所有痕迹,然后重新回滚到正常的哪一个版本,然后在通知进行人工干预。
•为发布添加一个web页面操作入口(引入Jenkins
),这其中针对Jenkins会穿插讲解一些其他的内容•回滚roles操作的编写•如何秒级别创建job并关联对应的项目的palybook
文件•总结篇
一个好的发布系统需要考虑的边界点实在是很多很多,前面我们也提到过文件分发,也包括上千台机器的情况下如何快速的分发,并保障可用性,还有就是灰度,加油吧,要学的还有很多很多。
[1]
github仓库地址: https://github.com/zhuima/kylin