之前在搭建基础设施环境时，考虑到部门内部协作及资源控制，所以代码管理这块是基于内部服务器搭建的一套流程。选取的自然是大家熟知的GitLab。
第一个坑：外网访问
在部分项目中，我们可以远程协作，所以需要外网访问gitlab，并提交代码。所以我们基于阿里云搭建了一个VPN。当然还有一个比较简单的办法，那就是通过外网服务器基于ssh反向代理及autossh实现内网穿透，也能达到此效果！基于SSH的代理方式，可以参考：https://www.jianshu.com/p/09fd97f8c43f
第二个坑：致命，机器频繁突然重启导致文件损坏或莫名的异常
如果服务器处在不太稳定的环境，例如突然停电(不得不吐槽，由于办公楼物业几个月就会停几次电，或者夏天动不动跳几次闸)、服务器内存不足等，gitlab偶尔会出现一些致命的错误，导致无法正常启动。
在这里分享下，一种常见的基于Docker容器(频繁重启)造成的gitlab无法启动的异常。
场景：
还在一口吃着早餐，一边排着任务清单，且准备着早会的资料。结果突然收到收件报警通知，原来隔壁办公室电源跳闸了，服务器异常发出了报警邮件。由于部分服务设置了开启启动，所以想着问题不大。到了10点后，同事告知，代码GItLab平台没起来。
尝试去看看服务，通过docker ps -f name=gitlab ，发现不断重启
gitlab
打开日志排查，docker logs -f gitlab （由于日志太多，所以上备份环境，构建gitlab_tmp环境进行模拟），定位到了异常
gitlab 异常日志处
这个问题看到后，很茫然。是啊，这个答案是蛮正确的，如果是直接安装可能没有问题吧，但问题就是，公司的Gitlab是安装在Docker里面的。容器都启动不了，咋去执行这个命令来重新配置呢！头疼
然后开始咨询和排查文件，首先是要定位到/opt/gitlab/embedded/nodes/3ac7f980d600.json. 这个文件，看看长啥样。哈哈，如果不了解docker的，估计这个文件是不知道在哪的。其实这个文件是在docker目录下的，通过 find /yuemia/data/repository/docker-repo/ -name '3ac7f980d600.json' 来查到这个文件（如果没有设置docker的目录，应该是find /var/lib/docker -name 'xxx.json'）。发现这个json文件里只有容器id，应该是文件破破坏了。所以备份这个文件，然后再删除。重新启动这个容器 docker restart gitlab 在监听日志，发现刚才的文件已经重新生成了，并且多了很多内容。然后这次启动比较慢，和重新构建容器一样耗时。
好了，大功告成，服务启动正常（当然，我没这么幸运，我是来回折腾了好几个小时，一个是本来就没备份，另一个是尝试几次还是没起来）。
写到这里，我得建议，备份还是挺重要的。
在这里准备一份备份脚本，然后设置是定时启动，这样基本也就可以放心一点了。
1、建立backup.sh脚本
#!/bin/bash
data=$(date "+%Y-%m-%d %H:%M:%S") # 时间戳来做文件名
gitlab_backup='/xxx/xxx/gitlab/backups' # gitlab的备份目录，见gitlab.rb文件的backup_path
delFile=`ls -l -crt $gitlab_backup/*.tar | awk '{print $9 }' | head -1` # 列出已经备份的文件
count=`ls -l -crt $gitlab_backup/*.tar | awk '{print $9 }' | wc -l` # 统计已经备份的文件数量
# 如果超过9个就清除，避免文件太多站空间
if [ $count -gt 9 ];then
rm $delFile
echo "$data -- delete $delFile" >> $gitlab_backup/del_log.txt
fi
# 这个是最重要的，
docker exec gitlab gitlab-rake gitlab:backup:create
# 记录执行结果
if [ $? -ne 0 ];then
echo "$data -- 脚本执行失败" >> $gitlab_backup/back_log.txt
fi
添加定时任务 crontab -e 选择3 ，然后添加 0 2 * * * sh /yuemia/evn/gitlab/backup.sh。每天凌晨2点会自动备份gitlab的数据
网友评论