CMS同步控制

CMS同步控制

一、需求引入

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

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

 

二、问题解决

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

　　解决流程图如下：

说明：

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

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

Website和CMS的目录不相同

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目录。实际上就是复制）

#!/bin/bash

。。。。。从gitlab上同步Website项目到线上服务器

### judge para to transfer 
transfer_choice=$1

if [ ${transfer_choice} -eq 1 ]; then
  #  echo "only the dir(a、b) to deploy" 
    cp -rp ${Website}/u ${CMS}/
    cp -rp ${Website}/html ${CMS}/

elif [ ${transfer_choice} -eq 2 ]; then
 #  echo "all the dir(a、b、c、d）"
    cp -rp ${Website}/* ${CMS}/
fi