转载

一些搬迁GitLab环境中碰见的问题和解决

因为单位机房搬迁，涉及到之前为运维开发搭建的GitLab环境也需要做迁移。旧环境中安装的时候很顺畅基本没有碰见什么问题(参考：http://blog.itpub.net/7192724/viewspace-2124847/)，但这次新环境的安装着实费了一些功夫，碰见了一些棘手的问题，记录于此，对碰见这些问题的朋友们有所帮助。

注：以下问题和解决方案援引自我的同事兼同门师弟之手，版权归他:)

问题一：Gitlab安装碰见硬编码路径
首先是安装环境准备，需要装一些rpm包，
sudo yum install openssh-server
sudo yum install postfix
sudo yum install cronie
sudo service postfix start
sudo chkconfig postfix on
sudo lokkit -s http -s ssh

查看包内容
rpm -qp l gitlab-ce-8.17.0-ce.0.el7.x86_64.rpm > watch.txt

发现包内容如下：

/opt
/opt/gitlab
/opt/gitlab/LICENSE
/opt/gitlab/LICENSES
....

而在新服务器上/opt路径下空间很小，让用户使用的是/DATA路径。

查看安装包内容是否可重定向
rpm -qpi gitlab-ce-8.11.5-ce.0.el6.x86_64.rpm | grep Relocations
Name : gitlab-ce Relocations: /

可以看出目录/可重定向。

尝试一：重定向安装
sudo rpm -ivh --relocate /=/DATA/app gitlab-ce-8.11.5-ce.0.el6.x86_64.rpm

但是安装过程报错
cp: cannot stat `/opt/gitlab/etc/gitlab.rb.template': No such file or directory
sed: can't read /etc/gitlab/gitlab.rb: No such file or directory
...
/var/tmp/rpm-tmp.xPMDUv: line 10: /opt/gitlab/bin/gitlab-ctl: No such file or directory
warning: %posttrans(gitlab-ce-8.11.5-ce.0.el6.x86_64) scriptlet failed, exit status 127

然后执行：
sudo gitlab-ctl reconfigure

依旧报错，路径问题，查看gitlab-ctl文件，发现其中的路径都是写的/opt/gitlab类型的硬编码，尝试修改，可是涉及文件太多而且没有参照物，无果。

尝试二：使用软链接，重定向安装
在一次的尝试中，到饭点了，本不想吃饭，但波哥说没准睡个觉或吃个饭，就有思路了。。。于是乎。。。神奇的事情发生了，在去食堂的路上，我们想到既然是路径的问题，能否采用软链接，定向到要安装的目录。按照这个思路进行尝试，首先卸载已安装的程序。

查看已安装的程序

sudo rpm -qa | grep gitlab
gitlab-ce-8.11.5-ce.0.el6.x86_64

卸载程序
sudo rpm -e gitlab-ce-8.11.5-ce.0.el6.x86_64

创建软链接文件
sudo ln /opt/gitlab /DATA/app/opt/gitlab
再尝试重定向安装，无报错，安装成功。

问题二：Gitlab控制台网页无法访问
Gitlab安装成功后，修改/etc/gitlab/gitlab.rb
external_url 'http://xx.xx.xx.xx'(当前服务器IP)

修改完成后重新配置，在gitlab/bin目录下执行
sudo ./gitlab-ctl reconfigure

在本地访问Gitlab，发现无法访问，telnet IP 8080端口不通。

一些搬迁GitLab环境中碰见的问题和解决

偶然的机会，在服务器同网段机器wget IP:80发现是可以正常访问的，而且发现Gitlab默认的端口为80端口，而在服务器和本地之间80端口的策略没有开通，只开通有8080端口，所以这问题很有可能就是和GitLab默认端口有关了。

既然80端口未开通，就尝试使用8080端口，修改端口策略，按照Gitlab官方说明，修改/etc/gitlab/gitlab.rb
nginx['listen_addresses'] = ['*']
nginx['listen_port'] = 8080

修改后重新配置，在gitlab/bin目录下执行
sudo ./gitlab-ctl reconfigure

HTTP访问，提示502

一些搬迁GitLab环境中碰见的问题和解决

后再阅读http://blog.csdn.net/wangxicoding/article/details/43738137文章时想到，是否因为unicorn服务默认占用8080端口，将nginx端口修改为8080会造成影响？于是选择为unicorn重新配置端口，修改/etc/gitlab/gitlab.rb
unicorn['listen'] = '127.0.0.1'
unicorn['port'] = 8082

修改后重新配置，在gitlab/bin目录下执行
sudo ./gitlab-ctl reconfigure

修改后HTTP访问尝试，可以正常访问。
一些搬迁GitLab环境中碰见的问题和解决

问题三：Gitlab备份及恢复
旧环境中已经有了一些代码，迁移环境可以选择重新上传代码这种方式，可这么做实在是有些LOW，Gitlab其实为我们提供了一些备份恢复的手段和方法。

首先创建备份
sudo ./gitlab-rake gitlab:backup:create

使用以上命令会在/var/opt/gitlab/backups目录下创建一个名称类似为1448938055_gitlab_backup的压缩包, 这个压缩包就是Gitlab整个的完整部分, 其中开头的1448938055是备份创建的日期。修改备份文件默认目录，可以通过修改/etc/gitlab/gitlab.rb来修改默认存放备份文件的目录：
gitlab_rails['backup_path'] = '/mnt/backups'

Gitlab数据恢复
停止相关数据连接服务
sudo ./gitlab-ctl stop unicorn
sudo ./gitlab-ctl stop sidekiq

从1448938055编号备份中恢复
sudo ./gitlab-rake gitlab:backup:restore BACKUP=1448938055

启动Gitlab
sudo ./gitlab-ctl start

完成。

拓展知识：Unicorn是什么？
参考：https://about.gitlab.com/2015/06/05/how-gitlab-uses-unicorn-and-unicorn-worker-killer/
Gitlab使用Unicorn(预分叉的Ruby web服务)，来处理web请求(web浏览和Git Http Clients)

Understanding Unicorn and unicorn-worker-killer
Unicorn

GitLab uses Unicorn, a pre-forking Ruby web server, to handle web requests (web browsers and Git HTTP clients). Unicorn is a daemon written in Ruby and C that can load and run a Ruby on Rails application; in our case the Rails application is GitLab Community Edition or GitLab Enterprise Edition.

Unicorn has a multi-process architecture to make better use of available CPU cores (processes can run on different cores) and to have stronger fault tolerance (most failures stay isolated in only one process and cannot take down GitLab entirely). On startup, the Unicorn ‘master’ process loads a clean Ruby environment with the GitLab application code, and then spawns ‘workers’ which inherit this clean initial environment. The ‘master’ never handles any requests, that is left to the workers. The operating system network stack queues incoming requests and distributes them among the workers.

In a perfect world, the master would spawn its pool of workers once, and then the workers handle incoming web requests one after another until the end of time. In reality, worker processes can crash or time out: if the master notices that a worker takes too long to handle a request it will terminate the worker process with SIGKILL (‘kill -9’). No matter how the worker process ended, the master process will replace it with a new ‘clean’ process again. Unicorn is designed to be able to replace ‘crashed’ workers without dropping user requests

总结：
1.实在是很不理解为何gitlab-ce-8.17.0-ce.0.el7.x86_64.rpm定义了这么多硬编码路径，而不是支持变量替换，或许有其他方法可以更好地解决这个问题，还请指教。
2.软链接这个特性很小，但是确实很好用、很实用，尤其在这个安装过程中起到了至关重要的作用。
3.一个Gitlab的安装其实涉及了很多的技术知识，例如Redis、PG等，这个gitlab-ce-8.17.0-ce.0.el7.x86_64.rpm安装包做了统一的封装，否则就需要一个组件一个组件地安装配置。
4.碰见这种很难一时解决的问题，可以吃下饭、睡个觉，兴许新思路就涌现出来了:)

欢迎关注我的个人微信公众号：bisal的个人杂货铺
一些搬迁GitLab环境中碰见的问题和解决