自动化运维——自动化部署系统构建及演变
一、早期手动部署代码
纯手动scp上传代码。
纯手动登陆，git pull 或者svn update。
纯手动xftp上传代码。
开发发送压缩包,rz上传，解压部署代码。
缺点
全程运维参与,占用大量时间。
如果节点多,上线速度慢。
人为失误多,目录管理混乱。
回滚不及时,或者难以回退。
二、设计自动部署代码
流程设计，确定目标。
自动部署环境
开发环境
开发者本地有自己的环境，运维配置公共开发环境，大家可共用的服务。例如:开发数据库MySQL,redis,Memcached等
测试环境
功能测试以及性能测试。
预生产环境
生产环境集群中的某一个节点,并且连接生产库。(不对外，不做破坏型操作。)
预生产环境由来
数据库不一致,测试环境和生产环境数据库是不一样的。
使用生产环境的联调接口;例如:支付接口。(电商业务)
灰度环境
根据不同的区域进行划分分。(生产环境)
生产环境
对用户提供服务的环境。
自动部署规划
前提
已经有一个可以上线的代码在git仓库。
我们现在要做10个集群节点的一键部署,秒级回滚。
所有的web服务，都应该使用普通用户。(强烈建议)
所有的web服务都不应该监听80端口，除了负载均衡。
那我们如何设计一套生产自动化部署系统。
规划
实现
总结和扩展(PDCA方法论)
生产环境应用
实现思路
代码放置位置
Git(首先)、Svn
获取最新代码
获取最新分支
获取版本号
获取tag包
差异解决
各个节点之间差异
代码仓库和实际的差异。配置文件是否放在代码仓库中。(配置单独进行存放，config.example)短信接口，支付，等敏感信息不让所有开发知道
统一的集群有10个节点。(Job节点 crontab.xml 配置文件不一样)
项目名称如何设计
项目名称_环境名称_版本_分支_时间_某开发提交
测试: rainbow_test_v1.1.1_dev_2016-08-11_12:12_xuliangwei
生产: rainbow_pro_v1.1.1_master_2016-08-11_11:11_xuliangwei
如何更新
php,tomcat需要重启，重新软链接。
如何测试
测试(关键的页面，API，后台等)
测试一个预生产环境，通过则继续部署，如果失败，退出部署操作。
记录日志
可以部署统计
成功多少次
失败多少次
回滚多少次
多人同时执行脚本
防止多人操作导致重复上线失败。通过lock锁对文件进行控制。
串行，并行
机器少的情况串行感觉不出什么。如果机器过多则会很慢。
分组部署并行部署，以及分组测试。
测试一个预生产环境，通过则继续部署，如果失败，退出部署操作。
部署服务器双机
防止部署系统down机，部署机代码丢失，误操作。
如何执行
shell执行
web界面点击(自定义或jenkins)
如何实现正常回退，以及紧急回退(回滚的必要性)
通过软链接的方式来实现代码秒级别回退。
自动部署难点
在大公司推进自动化部署上线，是有许多的难点，根据个人公司的不同，来选择不同的方法来进行推进。
自动化推进难点
能力(个人能力，团队能力)
责任(责任能否承担，敢于承担责任)
公司流程、人员、组织架构。
可通过如下方法推进
目标化沟通
责任划分
ITIL
项目管理：PMBOOK
三、自动部署实践
整个集群自动化部署流程设计如下
可根据如下思路，结合公司实际业务来编写shell脚本或者Python。
获取最新代码
编译（可选）
配置文件(软连接或者拷贝)。
打包(tar,加速传输)
文件分发（Scp Rsync Salt）(不需要密码验证)
将目标服务器移除集群(注释配置文件)
解压
防止webroot站点目录
scp差异文件(可能有一个节点配置文件不一样)
重启Web服务
测试
四、正常回退实践
列出回滚版本
目标服务器移除集群
执行回滚
重启并测试
加入集群
五、紧急回退实践
列出回滚版本(ls -l或find查出对应的历史版本)。
执行回滚操作(删除软链接，重建软链接)。
重启对应服务。
六、自动部署采坑
自动化部署php环境或者java环境的过程中，那么你一定遇到了如下的问题。
如何应用到你的生产环境。
回退到“上一个正常”版本。
自动部署软连接的坑。
PHP如果开启Opcache,需要重启PHP,或者清理opcache
Java Tomcat是必须要重启，最好每次清理work,tmp缓存目录。
来源：徐亮伟架构师之路
原文：http://t.cn/RtOtIgm
版权：本文版权归原作者所有