搬迁GitLab环境中碰见的问题和解决方法是什么

搬迁gitLab环境中碰见的问题和解决方法是什么，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

....

而在新服务器上/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 _64) scriptlet failed, exit status 127

然后执行：'Http://xx.xx.xx.xx'(当前服务器IP)

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

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

偶然的机会，在服务器同网段机器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

后再阅读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备份及恢复
旧环境中已经有了一些代码，迁移环境可以选择重新上传代码这种方式，可这么做实在是有些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

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

看完上述内容，你们掌握搬迁GitLab环境中碰见的问题和解决方法是什么的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注编程网精选频道，感谢各位的阅读！