溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

搬遷GitLab環(huán)境中碰見的問題和解決方法是什么

發(fā)布時間:2021-12-08 09:53:29 來源:億速云 閱讀:159 作者:柒染 欄目:互聯(lián)網(wǎng)科技

搬遷GitLab環(huán)境中碰見的問題和解決方法是什么,相信很多沒有經(jīng)驗的人對此束手無策,為此本文總結(jié)了問題出現(xiàn)的原因和解決方法,通過這篇文章希望你能解決這個問題。

....

而在新服務(wù)器上/opt路徑下空間很小,讓用戶使用的是/DATA路徑。

查看安裝包內(nèi)容是否可重定向
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


然后執(zhí)行:'http://xx.xx.xx.xx'(當(dāng)前服務(wù)器IP)

修改完成后重新配置,在gitlab/bin目錄下執(zhí)行
sudo ./gitlab-ctl  reconfigure

在本地訪問Gitlab,發(fā)現(xiàn)無法訪問,telnet IP 8080端口不通。

搬遷GitLab環(huán)境中碰見的問題和解決方法是什么  



偶然的機會,在服務(wù)器同網(wǎng)段機器wget IP:80發(fā)現(xiàn)是可以正常訪問的,而且發(fā)現(xiàn)Gitlab默認的端口為80端口,而在服務(wù)器和本地之間80端口的策略沒有開通,只開通有8080端口,所以這問題很有可能就是和GitLab默認端口有關(guān)了。

既然80端口未開通,就嘗試使用8080端口,修改端口策略,按照Gitlab官方說明,修改/etc/gitlab/gitlab.rb
nginx['listen_addresses'] = ['*']
nginx['listen_port'] = 8080

修改后重新配置,在gitlab/bin目錄下執(zhí)行
sudo ./gitlab-ctl  reconfigure

HTTP訪問,提示502

搬遷GitLab環(huán)境中碰見的問題和解決方法是什么

后再閱讀http://blog.csdn.net/wangxicoding/article/details/43738137文章時想到,是否因為unicorn服務(wù)默認占用8080端口,將nginx端口修改為8080會造成影響?于是選擇為unicorn重新配置端口,修改/etc/gitlab/gitlab.rb
unicorn['listen'] = '127.0.0.1'
unicorn['port'] = 8082


修改后重新配置,在gitlab/bin目錄下執(zhí)行
sudo ./gitlab-ctl  reconfigure


修改后HTTP訪問嘗試,可以正常訪問。
搬遷GitLab環(huán)境中碰見的問題和解決方法是什么



問題三:Gitlab備份及恢復(fù)
舊環(huán)境中已經(jīng)有了一些代碼,遷移環(huán)境可以選擇重新上傳代碼這種方式,可這么做實在是有些LOW,Gitlab其實為我們提供了一些備份恢復(fù)的手段和方法。

首先創(chuàng)建備份
sudo ./gitlab-rake gitlab:backup:create

使用以上命令會在/var/opt/gitlab/backups目錄下創(chuàng)建一個名稱類似為1448938055_gitlab_backup的壓縮包, 這個壓縮包就是Gitlab整個的完整部分, 其中開頭的1448938055是備份創(chuàng)建的日期。修改備份文件默認目錄,可以通過修改/etc/gitlab/gitlab.rb來修改默認存放備份文件的目錄:
gitlab_rails['backup_path'] = '/mnt/backups'

Gitlab數(shù)據(jù)恢復(fù)
停止相關(guān)數(shù)據(jù)連接服務(wù)
sudo ./gitlab-ctl stop unicorn
sudo ./gitlab-ctl stop sidekiq


從1448938055編號備份中恢復(fù)
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(預(yù)分叉的Ruby web服務(wù)),來處理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定義了這么多硬編碼路徑,而不是支持變量替換,或許有其他方法可以更好地解決這個問題,還請指教。
軟鏈接這個特性很小,但是確實很好用、很實用,尤其在這個安裝過程中起到了至關(guān)重要的作用。
一個Gitlab的安裝其實涉及了很多的技術(shù)知識,例如Redis、PG等,這個gitlab-ce-8.17.0-ce.0.el7.x86_64.rpm安裝包做了統(tǒng)一的封裝,否則就需要一個組件一個組件地安裝配置。

看完上述內(nèi)容,你們掌握搬遷GitLab環(huán)境中碰見的問題和解決方法是什么的方法了嗎?如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容,歡迎關(guān)注億速云行業(yè)資訊頻道,感謝各位的閱讀!

向AI問一下細節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI