内网后台同步到线上（番外篇）

内网后台同步到线上（番外篇）

　　今天做另一个后台同步到线上的时候发现一些问题，还有一些优化，特意记录下来。此篇文章基于：【内网后台同步到线上】https://www.cnblogs.com/windysai/p/14782818.html

　　前文有说过同步传输线路真实是这样的路线，其中我提到实现思路：内网服务器是复制一份后台代码目录文件，然后对其进行git提交测试的（就是这个图！）因为怕影响到原正式版的后台，如果测试有误，整个后台就会被我搞坏了（今天还真的遇到）

　　

　　实际上整个解决问题的流程图是这样的：

 　   从安全方面考虑，这样做挺好；但从维护管理，及方便性，要考虑周全。

　　第一个系统的后台同步就是下图的线路，因为是第一次做试验，就本着在保证安全的基础上实现需求，然后再考虑优化。

　　所以不管是内网后台代码目录，还是线上静态资源目录，都是拷贝复制进行测试的。测通之后就想着就这样解决需求吧~~~才发现登录后台之后，点最近几天的文章，页面报错不存在，如下图。原因是图上的线上静态资源B1没有及时从B里同步最新的过来，只有截至到拷贝那天的新闻数据。

　　　

 　　于是，我就在后台代码目录线上同步的脚本，加了每次同步完之后，从静态资源B拷贝到B1，用到cp（因为当时rsync还没调清楚，权宜之计。。。）

#增量更新（该条有点问题，后面说到）
rsync -alzvPu -t --delete  --exclude '/home/用户/data/html/静态资源目录/.git' /home/用户/data/html/静态资源目录/*  /home/用户/data/html/静态资源目录_20210517/

#这条貌似也有问题
cp -rp `ls /home/用户/data/html/静态资源目录/* | grep -v "/home/用户/data/html/静态资源目录/.git" | xargs` /home/用户/data/html/静态资源目录_20210517/

 　　虽然报的没有文件或目录的错，但静态资源目录倒是更新过来了的（容许我还没调整这条命令过来，先放下）

　　但是内网后台的rsync增量更新同步，倒是通过几次试错成本搞出来了（把内网复制的后台代码目录A1搞崩了，如下图）

rsync的delete参数是为了保持目的目录跟源目录一致同步的，可以理解为目的目录A1不可能自己私藏A没有的文件或目录。我就以为跟cp一样复制的命令：

rsync -alzvP --delete --exclude "index.html" --exclude=/u --exclude=/html --exclude=/r /home/用户/data/后台源目录A/* /home/用户/data/后台目的目录A1/

这命令的意思就是排除静态资源目录（exclude），然后进行A和A1一致同步的增量拷贝。【本来我是使用“exclude-from”的，我当时把要排除同步的资源目录以绝对路径的方式，每个目录为一行地，写到一个exclude.list，发现不行，所以我最终一个个写上去了

rsync -alzvP --delete --exclude-from='/home/用户/script/exclude.list'  】

 

我发现加了*是不能实现一致同步的，最终看到这文档：https://www.cnblogs.com/kevingrace/p/5766139.html，然后把红星“*”去掉，整个git push到gitalb上坏掉了，无论运行多少次git pull都不行

终极解决大法（一个歪果仁链接：https://rakeshjain-devops.medium.com/fix-to-tip-of-your-current-branch-is-behind-its-remote-counterpart-git-error-eb75f719c2d5）：

git reset --hard origin/master

 

 看着是警告这命令是有点风险的，鉴于做测试就算了，还窃喜幸好不是对后台代码正式版A动的操作。。。而是A1，吓坏。

这条rsync命令最阔怕一点就是，把A1上的 .git 目录全部干掉了！！！所以搞坏了git，调整后的rsync命令如下，

rsync -alzvP --delete --exclude=/.git --exclude "index.html" --exclude=/u --exclude=/html --exclude=/r /home/用户/data/后台源目录A/ /home/用户/data/后台源目录A1/

　　这条命令亲测暂时没有什么大问题，所以线上的静态资源目录增量更新也可以这样用，聪明的读者肯定知道怎么依葫芦画瓢的~~~

　　最后一个反思：

　　其实对于静态资源目录增量更新其实可以不用额外做，线上直接软连接到正式版的静态资源目录上就好了。我觉得风险其实不大，因为正式版的静态资源目录是通过内网——》gitlab更新过来的，意味着即使搞坏了，假设有黑客登上服务器，改了这目录下的文件，过一会儿又会被更新成正确的。

 　　这样直接软连接到正式版资源目录还有一个好处，假如真的停电了，因为用户正常情况下，访问网站的静态资源目录是B。复制更新的静态资源目录B1在停电时才要充当为正式版的角色，B1因后台发文章临时取代了B，B此时因为停电已经无法做gitlab内网同步，当恢复供电时候，B1新发的文章还要重新同步回B，想想是不是颇麻烦。

　　总的来说，优化后是这样的，内网后台需要另外复制一个作为gitlab新项目（安全保险起见），而线上同步过去的后台软连接到静态资源目录，资源目录建议直接链接到正式环境的，不要额外复制资源目录。