搬遷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環境中碰見的問題和解決方法是什么的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！