CMS同步控制

一、需求引入

  这是我刚入职公司没多久的需求,都两年多的东西了,周五时候无意中看到,发现还是有点意思的。昨晚特意理了下思路。

  需求是这样的:公司内网服务器搭了个CMS的发布后台,其中有a、b、c、d 的目录需要上传到线上服务器上,但是有不同需求,a、b目录需要每5分钟传到线上,而所有目录a、b、c、d则要人为意志控制才能发布。为什么要这么搞?因为美工时不时、有需要的时候才会动c、d目录的东西,意味着c、d目录里文件有更改,需要同步到线上看,貌似是样式、动态资源的东西。a、b目录主要是静态资源比如文章。

 

二、问题解决

  当时领导给我说了好几次需求,怕我理解错意思。。。估计怕我做不出来,那时候试用期都没过。。。这个解决思路是公司一个懂运维的开发给我参考的。他叫我用脚本结合传参进行控制。

  解决流程图如下:

CMS同步控制_服务器

说明:

CMS目录:tomcat跑的项目目录,浏览器能访问CMS后台发布地址,美工运营用来发文章就是改动CMS这个目录下的文件。

Website目录:实际传到gitlab的项目目录,用于同步到线上,nginx代理该目录,让用户访问。

Website和CMS的目录不相同

CMS同步控制_内网_02

1、公司内网有个同步到gitlab的脚本:主要是把CMS目录a、b、c、d拷贝到Website相应的目录:a、b、c、d, 每3分钟定时推送到gitlab仓库,这样做的原因是防止美工不定时利用CMS后台发布东西,干脆有杀错无放过~~~

2、内网jenkins发布平台,主要做的任务是进行CMS发布。git项目实际对应Website。

(1)maven构建Webiste项目,形成war包;

(2)调用1 的同步脚本,将CMS的a、b、c、d目录拷贝到Website,并push到gitlab上;

(3)停掉tomcat跑的CMS,,并进行a、b、c、d目录备份

(4)把(1)构建后的war包,解压进行Website包发布,并将第(3)步备份过的a、b、c、d目录还原

(5)起tomcat跑的CMS

 

上面流程图说了,我是通过参数来控制不同目录发布的。

线上也有个jenkins发布,给美工他们开了发布权限。事先线上服务器编写有脚本:pull_CMS.sh

(1)放到计划任务里:    

*/5 * * * * /bin/bash pull_CMS.sh 1

(2)美工实际发布的jenkins任务,实际运行脚本

/bin/bash pull_CMS.sh 2

 

pull_CMS.sh 判断参数来发布不同的目录

(ps:这个脚本其实就是把gitlab上Website的目录a、b、c、d根据参数:1、2,去判断是发布所有目录到CMS,还是只是只发布a、b目录。实际上就是复制)

 1 #!/bin/bash
 2 
 3 。。。。。从gitlab上同步Website项目到线上服务器
 4 
 5 ### judge para to transfer 
 6 transfer_choice=$1
 7 
 8 if [ ${transfer_choice} -eq 1 ]; then
 9   #  echo "only the dir(a、b) to deploy" 
10     cp -rp ${Website}/u ${CMS}/
11     cp -rp ${Website}/html ${CMS}/
12 
13 elif [ ${transfer_choice} -eq 2 ]; then
14  #  echo "all the dir(a、b、c、d)"
15     cp -rp ${Website}/* ${CMS}/
16 fi