自动化部署系统设计

这里所说的自动化部署系统，其实是一种半自动的代码部署，不同于jenkins的持续集成，也不同于puppet,ansible的自动部署。根据公司实际情况，而定制的一种自动化部署方案:

背景介绍

公司项目发布过程如下：

1. 开发人员上传war包至svn目录，并发邮件告知运维其svn目录；

2. 运维人员从svn地址下载war包至本地；

3. 运维人员ssh2登陆远程服务器：

   • 备份服务war包
   • 停止服务
   • 上传新war至相应的目录
   • 启动服务
   • 查看log

方案设计

为了解决线下的手动部署，主要提供如下功能：

1. 开发人员部署申请

   关于svn文件的上传，暂时仍沿用，后期可以更换成web上传功能进行替换。

2. 服务部署管理

   运维人员管理每个服务部署的情况，即哪个服务部署在哪台服务器的哪个目录上；

3. 服务器管理

   服务器的管理，即每台服务的ip地址，及ssh登陆所需用户名、密码;

4. 部署申请审核
   运维人员审核开发人员的部署申请，是否允许上线。

5. 自动化部署

   如何进行自动化部署，这是个难点？采用什么技术，也是因人而异.比如ansible就采用python,而java web提代的自动化部署也有ant,tomcat deploy等。在这里选择通过ssh2登陆远程服务器，执行服务脚本完成自动部署的操作。
   自动部署功能通过监听部署申请审核通过的消息，进行自动化部署，主要进行如下操作:

   • 获取部署申请信息；
   • 根据服务的部署申请信息，获取服务的部署信息；
   • 根据服务的部署信息，获取服务的物理服务器信息；
   • 根据部署申请信息，从远程svn地址下载war包至本服务器的临时目录;
   • 通过ssh2登陆远程服务器，执行如下操作;
   • 备份服务war包;
   • 停止服务;
   • 上传新war包;
   • 启动服务;
   • 关闭远程连接;
   • 删除本地war包;

   因为我们后端的服务框架采用dubbox,所有服务都是多节点部署，所以显示的停止服务在低谷请求是允许的。具体的项目代码请参见auto-deploy
   目前只完成自动化部署的核心功能，后续功能会慢慢补上。