概述:
早期手动部署代码:
- 纯手动scp上传代码
- 纯手动登录,git pull或者svn update #svn update,在之前工作中使用钩子效率相对提高一些
3.纯手动ftp上传代码
4.开发发送压缩包,rz上传,解压部署代码缺点:
1.全程运维参与,占用大量时间。
2.如果节点多,上线速度慢。
- 人为失误多,目录管理混乱。
- 回滚不及时,或者难以回退。
设计自动部署代码
流程设计,确定目标
1. 自动部署环境
- 开发环境
开发者本地有自己的环境,运维配置公共开发环境,大家可共用的服务,如:web环境nginx,开发数据库MySQL,Redis,等。 - 测试环境
功能测试及性能测试 - 预生产环境
生产环境集群中的某一个节点,并且连接生产库。(不对外,不作破坏型操作) - 灰度环境
根据不同的区域进行划分。(生产环境) - 生产环境
对用户提供服务的环境
预生产环境的由来:
- 数据库不一致,测试环境和生产环境数据库是不一样的。
- 使用生产环境的联调接口;例如:支付接口
2.自动部署规划
- 已经有一个可以上线的代码在git仓库
- 我们现在要做10个集群节点的一键部署,秒级回滚。
- 所有的web服务,都应该使用普通用户。
- 所有的web服务都不应该监听在80端口上,除了负载均衡。
- 那我们如何设计一套生产自动化部署系统。
a. 规划
b. 实现
c. 总结和扩展
d. 生产环境应用
实现思路:
- 代码防止位置
git、svn,首选git - 获取最新代码
- 获取最新分支
- 获取版本号
- 获取tag包
- 差异解决
- 各个节点之间的差异
- 代码仓库和实际的差异。配置文件是否放在代码仓库中。(配置文件单独进行存放,config.example),短信接口,支付,等敏感信息不让所有开发知道。
- 统一的集群有10个节点。(job节点crontab.xml配置文件不一样)
- 项目名称如何设计
项目名称环境名称版本分支时间_某开发提交
测试:rainbow_test_v1.1.1_dev_20180518_18:30_daquan
生产:rainbow_pro_v1.1.1_master_20180518_18:58_daquan - 如何更新
php,Tomcat需要重启,重新软连接 - 如何测试
- 测试(关键的页面,API,后台等)
- 测试一个预生产环境,通过则继续部署,如果失败,退出部署操作
- 记录日志
- 可以部署统计
- 成功多少次
- 失败多少次
- 回滚多少次
- 多人同时执行脚本
防止多人操作导致重复上线失败,通过lock锁对文件进行控制。 - 串行,并行
机器少的情况串行感觉不出什么,如果机器过多则会很慢。
分组部署并行部署,以及分组测试
测试一个预生产环境,通过则继续部署,如果失败,退出部署操作 - 部署服务器双机
防止部署系统down机,部署代码丢失,误操作。 - 如何执行
- shell执行
- web界面点击(自定义或Jenkins)
- 如何实现正常回退,以及紧急回退(回滚的必要性)
通过软连接的方式来实现代码秒级回退
3.自动部署难点
在大公司推进自动化部署上线,是有许多的难点,根据个人公司的不同,来选择不同的方法进行推进。
自动化推进难点:
a.能力(个人及团队)
b.责任(责任能否承担,敢于承担责任)
c.公司流程,人员,组织架构
自动化部署实践
整个集群自动化部署流程设计如下:可根据如下思路,结合公司实际业务来编写shell脚本或者Python。
- 获取最新代码
- 编译(java需要,php则不用)
- 配置文件(软连接或者拷贝)
- 打包(tar,加速传输)
- 文件分发(scp rsync salt ansible)(不需要验证密码)
- 将目标服务器移除集群 #注释配置文件,现在大部分是云环境,那么则在云环境上操作,也可看看云环境是否提供了调用的api
- 解压
- 代码放置webroot站点目录
- scp差异文件(可能有一个节点配置文件不一样)
- 重启或重新加载web服务,看需求了。
- 测试
正常回退实践
- 列出回滚版本
- 目标服务器移除集群
- 执行回滚
- 重启并测试
- 加入集群
紧急回退版本
- 列出回滚版本(ls -l 或find查出对应的历史版本)
- 执行回滚操作(删除软连接,重建软连接)
- 重启对应的服务
自动部署采坑
自动化部署php环境或者java环境的过程中,那么你一定遇到了如下的问题。
- 如何应用到你的生产环境
- 会退到"上一个" "正常"版本
- 自动部署软连接的坑
a. php如果开启了opcache,需要重启php或者清理opcache
b. java Tomcat是必须要重启,最好每次都清理work,tmp缓存目录。
c. sesssion单独存储在redis或memecache中。