1. 為什么選擇在 Ubuntu 上自建 GitLab1.1 自建代碼托管平臺的核心動機(jī)很多團(tuán)隊(duì)在起步階段會直接使用公有代碼托管服務(wù)省事、零維護(hù)這沒什么問題。但當(dāng)項(xiàng)目規(guī)模變大、代碼資產(chǎn)變多之后自建代碼托管平臺的需求就會逐漸浮現(xiàn)出來。我在幾個不同規(guī)模的團(tuán)隊(duì)里都經(jīng)歷過這個轉(zhuǎn)折點(diǎn)最常見的觸發(fā)因素有三個一是代碼資產(chǎn)的私密性要求提高某些項(xiàng)目不希望源碼存放在第三方平臺上二是需要和內(nèi)部系統(tǒng)做深度集成比如 CI/CD 流水線要直接訪問內(nèi)網(wǎng)服務(wù)、制品庫、測試環(huán)境三是成本考量當(dāng)團(tuán)隊(duì)人數(shù)增長到一定規(guī)模后按席位付費(fèi)的公有服務(wù)賬單會變得相當(dāng)可觀。GitLab 社區(qū)版CE是目前自建方案里功能最完整、生態(tài)最成熟的選擇之一。它不只是一個 Git 倉庫管理工具還集成了代碼審查Merge Request、議題跟蹤Issue、持續(xù)集成CI/CD、制品倉庫、容器鏡像倉庫等一整套研發(fā)協(xié)作能力。對于中小團(tuán)隊(duì)來說一套自建的 GitLab 基本可以替代三到四個獨(dú)立的工具。選擇 Ubuntu 作為宿主系統(tǒng)理由也很直接GitLab 官方對 Ubuntu 的支持最完善官方軟件倉庫直接提供 Ubuntu 的安裝包依賴關(guān)系處理得最干凈。相比之下在 CentOS 或其它發(fā)行版上安裝雖然也能跑起來但經(jīng)常會遇到依賴版本沖突、SELinux 策略攔截之類的問題排查起來很費(fèi)時間。1.2 本文適合哪些人參考這篇文章面向的是有一定 Linux 基礎(chǔ)、需要在 Ubuntu 服務(wù)器上快速部署 GitLab 的運(yùn)維人員或后端開發(fā)者。你不需要是 Linux 專家但至少要熟悉基本的命令行操作、會用apt管理軟件包、能看懂系統(tǒng)服務(wù)狀態(tài)。如果你之前從來沒接觸過 GitLab 的自建部署跟著這篇文章走一遍大概半小時到一小時內(nèi)能完成全部配置。我下面要講的方案核心思路是使用 GitLab 官方提供的軟件倉庫和安裝包而不是用 Docker 或者從源碼編譯。這三種方式我都試過Docker 方式靈活但網(wǎng)絡(luò)和存儲配置容易踩坑源碼編譯耗時太長且升級麻煩官方軟件包方式是最省心、最適合快速上線的路徑。當(dāng)然每種方式都有適用場景我會在后面的章節(jié)里對比說明。2. 部署前的整體方案設(shè)計(jì)與選型對比2.1 三種主流安裝方式的取舍在動手之前先把安裝方式選清楚這決定了后面所有步驟的走向。GitLab 在 Ubuntu 上的安裝方式主要有三種我把它們的核心差異整理成了一張表安裝方式部署速度升級維護(hù)資源占用適用場景官方軟件包Omnibus快一條命令簡單apt 升級較高內(nèi)置所有組件生產(chǎn)環(huán)境、快速上線Docker 容器中等需配置掛載中等需管理鏡像可控依賴宿主機(jī)測試環(huán)境、多實(shí)例源碼編譯慢數(shù)小時復(fù)雜需手動處理最低可裁剪特殊定制需求官方軟件包方式也叫 Omnibus 包把 GitLab 需要的所有組件——PostgreSQL、Redis、Nginx、Gitaly、Sidekiq 等等——全部打包在一起通過一個配置文件/etc/gitlab/gitlab.rb統(tǒng)一管理。這意味著你不需要單獨(dú)去裝數(shù)據(jù)庫、配反向代理安裝包會幫你搞定。代價是資源占用相對高一些但對現(xiàn)代服務(wù)器來說這點(diǎn)開銷完全可以接受。Docker 方式的好處是環(huán)境隔離干凈遷移方便但你需要自己處理數(shù)據(jù)卷掛載、端口映射、容器網(wǎng)絡(luò)而且 GitLab 容器對內(nèi)存的要求不低配置不當(dāng)容易出現(xiàn)服務(wù)起不來的情況。源碼編譯我一般只在有特殊定制需求時才考慮比如要修改某些核心邏輯否則純粹是浪費(fèi)時間。提示如果你的服務(wù)器內(nèi)存小于 4GB官方軟件包方式可能會在安裝過程中因?yàn)閮?nèi)存不足而失敗。GitLab 官方建議至少 4GB 內(nèi)存實(shí)際使用中 8GB 會更從容。2.2 服務(wù)器規(guī)格與系統(tǒng)要求在選好安裝方式之后下一步是確認(rèn)服務(wù)器規(guī)格。GitLab 對硬件的要求不算低尤其是內(nèi)存。我整理了一份實(shí)際部署中總結(jié)出來的配置建議CPU至少 2 核推薦 4 核。GitLab 的 Web 服務(wù)和后臺任務(wù)都比較吃 CPU核心數(shù)太少會導(dǎo)致頁面響應(yīng)慢。內(nèi)存最低 4GB推薦 8GB。內(nèi)存不足是安裝失敗和運(yùn)行卡頓的頭號原因。磁盤至少 20GB 可用空間推薦 50GB 以上。Git 倉庫、制品、日志都會持續(xù)增長。系統(tǒng)版本Ubuntu 20.04 LTS 或 22.04 LTS。LTS 版本穩(wěn)定性好官方支持周期長。關(guān)于系統(tǒng)版本我特別建議用 LTS長期支持版本而不是最新的非 LTS 版本。非 LTS 版本的生命周期短可能過幾個月就不再接收安全更新而 GitLab 的官方倉庫對非 LTS 版本的支持也可能滯后。我踩過一次坑在一臺 Ubuntu 非 LTS 的機(jī)器上裝 GitLab結(jié)果官方倉庫里沒有對應(yīng)版本的包最后只能降級系統(tǒng)重裝。2.3 網(wǎng)絡(luò)與域名規(guī)劃GitLab 部署好之后是要給團(tuán)隊(duì)成員訪問的所以網(wǎng)絡(luò)和域名需要提前規(guī)劃。這里涉及幾個關(guān)鍵點(diǎn)第一確定訪問地址。如果你有內(nèi)部 DNS可以給服務(wù)器分配一個內(nèi)部域名比如gitlab.internal.example。如果沒有 DNS直接用服務(wù)器 IP 也可以但后續(xù)如果 IP 變了所有倉庫的遠(yuǎn)程地址都要改比較麻煩。所以有條件的話盡量用域名。第二確定訪問協(xié)議。GitLab 默認(rèn)支持 HTTP 和 HTTPS。生產(chǎn)環(huán)境強(qiáng)烈建議上 HTTPS否則代碼推送時的憑據(jù)是明文傳輸?shù)摹TTPS 證書可以用內(nèi)部 CA 簽發(fā)也可以用公開的證書服務(wù)。如果只是內(nèi)網(wǎng)測試HTTP 也能湊合用但要清楚其中的風(fēng)險。第三確認(rèn)端口。GitLab 默認(rèn)的 Web 端口是 80 和 443SSH 端口默認(rèn)是 22。如果服務(wù)器上已經(jīng)有其它服務(wù)占用了這些端口需要在配置時改掉。我遇到過好幾次服務(wù)器上已經(jīng)跑了 Nginx 或者 SSH 服務(wù)的情況端口沖突導(dǎo)致 GitLab 起不來排查了半天才發(fā)現(xiàn)是端口被占。3. 下載程序包與快速安裝部署實(shí)操3.1 系統(tǒng)環(huán)境準(zhǔn)備與依賴檢查正式安裝之前先做幾項(xiàng)準(zhǔn)備工作。第一步是更新系統(tǒng)包索引并升級已有軟件sudo apt update sudo apt upgrade -y這一步看起來簡單但很重要。如果系統(tǒng)里有大量待更新的包不先處理掉后面安裝 GitLab 時可能會因?yàn)橐蕾嚢姹静黄ヅ涠鴪箦e。我有一次偷懶跳過了這步結(jié)果安裝過程中提示某個庫版本過低又回頭來升級反而多花了時間。第二步是安裝幾個基礎(chǔ)工具后面配置時會用到sudo apt install -y curl openssh-server ca-certificates tzdata perl這幾個包的作用分別是curl用于下載和測試網(wǎng)絡(luò)請求openssh-server提供 SSH 服務(wù)Git 通過 SSH 推送代碼時需要ca-certificates管理證書tzdata處理時區(qū)perl是 GitLab 某些腳本的依賴。第三步是配置時區(qū)。GitLab 的日志、提交時間、CI 任務(wù)調(diào)度都和時區(qū)有關(guān)如果時區(qū)不對排查問題時會很困惑。設(shè)置時區(qū)的命令是sudo timedatectl set-timezone Asia/Shanghai設(shè)置完可以用timedatectl確認(rèn)一下。我建議在安裝 GitLab 之前就把時區(qū)設(shè)好而不是裝完之后再改因?yàn)?GitLab 首次啟動時會讀取系統(tǒng)時區(qū)并寫入配置裝完再改需要重新配置。第四步是配置郵件服務(wù)。GitLab 需要發(fā)送通知郵件比如新用戶注冊、合并請求提醒如果不配置郵件這些功能會靜默失敗。最簡單的方案是用系統(tǒng)的 Postfix 來發(fā)郵件sudo apt install -y postfix安裝過程中會彈出一個配置界面選擇 Internet Site 即可。當(dāng)然如果你有企業(yè)郵箱或者第三方郵件服務(wù)也可以在 GitLab 配置里指定 SMTP 服務(wù)器這個后面會講。3.2 添加官方倉庫與下載安裝包準(zhǔn)備工作做完接下來就是核心步驟添加 GitLab 官方軟件倉庫然后安裝。GitLab 官方提供了一個腳本可以自動完成倉庫配置curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash這個腳本做的事情是檢測你的系統(tǒng)版本添加對應(yīng)的 GitLab 倉庫地址導(dǎo)入 GPG 簽名密鑰。執(zhí)行完之后可以用下面的命令確認(rèn)倉庫是否添加成功apt-cache policy gitlab-ce如果能看到候選版本信息說明倉庫配置正確。接下來就是安裝sudo EXTERNAL_URLhttp://gitlab.example.com apt install -y gitlab-ce這里的EXTERNAL_URL是 GitLab 的訪問地址安裝時會寫入初始配置。注意這個地址要和你實(shí)際訪問的地址一致否則后面生成的倉庫地址、郵件里的鏈接都會不對。如果你暫時沒有域名可以先用服務(wù)器 IP比如http://192.168.1.100。注意EXTERNAL_URL一旦設(shè)定后續(xù)修改需要重新運(yùn)行g(shù)itlab-ctl reconfigure而且已經(jīng)生成的倉庫地址不會自動更新。所以最好一開始就確定好。安裝過程會持續(xù)幾分鐘取決于服務(wù)器性能和網(wǎng)絡(luò)速度。安裝包大概有 1GB 左右下載加上解壓配置耐心等一會兒。安裝完成后終端會輸出一段提示告訴你 GitLab 已經(jīng)安裝成功并提示你運(yùn)行配置命令。3.3 首次配置與初始化安裝完成后需要運(yùn)行一次配置命令讓 GitLab 根據(jù)/etc/gitlab/gitlab.rb里的設(shè)置來初始化各個組件sudo gitlab-ctl reconfigure這個命令是 GitLab Omnibus 包的核心它會讀取配置文件然后依次配置 PostgreSQL、Redis、Nginx、Gitaly 等服務(wù)。第一次運(yùn)行時間比較長大概三到五分鐘期間會輸出大量日志。如果中間沒有報錯最后會顯示 gitlab Reconfigured!。配置完成后檢查一下各個服務(wù)的狀態(tài)sudo gitlab-ctl status正常情況下你應(yīng)該能看到run: nginx、run: postgresql、run: redis、run: gitaly等服務(wù)都是run狀態(tài)。如果有服務(wù)顯示down需要查看對應(yīng)日志排查。常見的起不來原因包括內(nèi)存不足、端口被占用、配置文件語法錯誤。接下來獲取初始管理員密碼。GitLab 首次安裝后會自動生成一個隨機(jī)密碼存放在/etc/gitlab/initial_root_password文件里sudo cat /etc/gitlab/initial_root_password這個文件在首次配置后 24 小時內(nèi)有效之后會被自動刪除。拿到密碼后用瀏覽器訪問你設(shè)置的EXTERNAL_URL用用戶名root和這個密碼登錄。登錄后第一件事就是修改 root 密碼并創(chuàng)建自己的管理員賬號。3.4 關(guān)鍵配置項(xiàng)調(diào)整默認(rèn)配置能跑起來但有幾個地方我建議根據(jù)實(shí)際情況調(diào)整。打開配置文件sudo vim /etc/gitlab/gitlab.rb第一個要關(guān)注的是外部訪問地址external_url http://gitlab.example.com如果你安裝時設(shè)的地址不對或者后來換了域名改這里然后重新reconfigure。第二個是 SSH 端口。如果服務(wù)器上 22 端口已經(jīng)被占用比如系統(tǒng)自帶的 SSH 服務(wù)需要給 GitLab 的 SSH 換個端口gitlab_rails[gitlab_shell_ssh_port] 2222同時要確保gitlab_rails[gitlab_shell_ssh_port]和實(shí)際監(jiān)聽的端口一致。改完之后用戶克隆倉庫時需要用ssh://githost:2222/group/project.git這種格式。第三個是郵件配置。如果你不用系統(tǒng) Postfix而是用第三方 SMTP配置大概是這樣gitlab_rails[smtp_enable] true gitlab_rails[smtp_address] smtp.example.com gitlab_rails[smtp_port] 587 gitlab_rails[smtp_user_name] gitlabexample.com gitlab_rails[smtp_password] your_password gitlab_rails[smtp_domain] example.com gitlab_rails[smtp_authentication] login gitlab_rails[smtp_enable_starttls_auto] true gitlab_rails[gitlab_email_from] gitlabexample.com第四個是備份和日志的保留策略。GitLab 默認(rèn)會保留一定時間的日志和備份如果磁盤空間緊張可以調(diào)整gitlab_rails[backup_keep_time] 604800這個值是秒數(shù)604800 秒等于 7 天。意思是超過 7 天的備份會被自動清理。每次修改配置文件后都要運(yùn)行sudo gitlab-ctl reconfigure讓改動生效。如果只改了某些組件的配置也可以只重啟對應(yīng)服務(wù)比如sudo gitlab-ctl restart nginx但為了保險起見我一般還是跑完整的 reconfigure。4. 安裝后的驗(yàn)證與常見問題排查4.1 功能驗(yàn)證清單安裝配置完成后不要急著交付給團(tuán)隊(duì)用先自己走一遍核心功能確認(rèn)沒有問題。我通常按下面的清單來驗(yàn)證Web 訪問瀏覽器打開EXTERNAL_URL能看到登錄頁面用 root 賬號能登錄。創(chuàng)建項(xiàng)目新建一個測試項(xiàng)目確認(rèn)能創(chuàng)建成功。SSH 克隆在本地用git clone通過 SSH 協(xié)議克隆測試項(xiàng)目確認(rèn) SSH 密鑰認(rèn)證正常。HTTP 克隆用 HTTP 協(xié)議克隆確認(rèn)憑據(jù)認(rèn)證正常。推送代碼往測試項(xiàng)目推一個提交確認(rèn)推送成功。合并請求創(chuàng)建一個合并請求確認(rèn)頁面能正常顯示 diff。郵件通知觸發(fā)一個會發(fā)郵件的操作比如新用戶注冊確認(rèn)郵件能收到。這幾項(xiàng)都過了基本可以確認(rèn) GitLab 的核心功能是正常的。如果某一項(xiàng)失敗根據(jù)失敗環(huán)節(jié)去查對應(yīng)日志。4.2 常見問題速查表下面這張表是我在實(shí)際部署中遇到過的典型問題以及對應(yīng)的排查思路和解決方法問題現(xiàn)象可能原因排查方法解決方法安裝時提示內(nèi)存不足服務(wù)器內(nèi)存小于 4GBfree -h查看內(nèi)存增加內(nèi)存或加 swap502 錯誤后端服務(wù)未啟動gitlab-ctl status查看日志重啟服務(wù)SSH 克隆失敗SSH 端口不對或被防火墻攔截ss -tlnp查看端口調(diào)整端口配置或防火墻規(guī)則郵件發(fā)不出去SMTP 配置錯誤gitlab-rails console測試檢查 SMTP 參數(shù)頁面加載慢內(nèi)存不足或 CPU 瓶頸top查看資源占用升級配置或優(yōu)化reconfigure 報錯配置文件語法錯誤查看報錯行號修正配置文件關(guān)于 502 錯誤這是最常見的問題。502 表示 Nginx 能收到請求但后端的 GitLab 應(yīng)用Puma 或 Unicorn沒有響應(yīng)。原因通常是后端服務(wù)還在啟動中或者因?yàn)閮?nèi)存不足被系統(tǒng)殺掉了。先等幾分鐘如果還是 502就去看/var/log/gitlab/gitlab-rails/production.log里的錯誤信息。關(guān)于 SSH 克隆失敗我踩過好幾次坑。最常見的原因是服務(wù)器防火墻沒放行 GitLab 的 SSH 端口。如果你用的是 UFW需要執(zhí)行sudo ufw allow 2222/tcp假設(shè)端口是 2222。另外如果服務(wù)器本身有 SSH 服務(wù)在 22 端口GitLab 的 SSH 會默認(rèn)用 22導(dǎo)致沖突這時候必須改端口。4.3 性能調(diào)優(yōu)與資源控制GitLab 默認(rèn)配置對資源的利用比較保守如果服務(wù)器配置較高可以適當(dāng)調(diào)優(yōu)。但如果服務(wù)器配置一般反而需要限制資源占用避免 GitLab 把整臺機(jī)器拖垮。對于內(nèi)存較小的服務(wù)器4GB 左右我建議做以下調(diào)整puma[worker_processes] 2 sidekiq[max_concurrency] 10 postgresql[shared_buffers] 256MB這幾個參數(shù)分別控制 Web 服務(wù)的 worker 數(shù)量、后臺任務(wù)并發(fā)數(shù)、數(shù)據(jù)庫共享緩沖區(qū)大小。調(diào)小這些值可以降低內(nèi)存占用代價是并發(fā)處理能力下降。對于小團(tuán)隊(duì)十幾個人來說這個配置夠用了。對于配置較好的服務(wù)器16GB 以上可以適當(dāng)調(diào)大puma[worker_processes] 4 sidekiq[max_concurrency] 25 postgresql[shared_buffers] 2GB另外GitLab 的日志會持續(xù)增長建議配置日志輪轉(zhuǎn)。Omnibus 包默認(rèn)已經(jīng)配置了 logrotate但你可以檢查一下/etc/gitlab/gitlab.rb里的logging相關(guān)配置確保日志不會把磁盤占滿。提示調(diào)整任何參數(shù)后都要運(yùn)行sudo gitlab-ctl reconfigure然后觀察一段時間確認(rèn)服務(wù)穩(wěn)定。不要一次性改太多參數(shù)否則出問題不好定位是哪個改動導(dǎo)致的。5. 日常維護(hù)與升級策略5.1 備份與恢復(fù)自建 GitLab 最重要的一件事就是備份。代碼資產(chǎn)丟了那是災(zāi)難性的。GitLab 提供了內(nèi)置的備份命令sudo gitlab-backup create這個命令會備份數(shù)據(jù)庫、倉庫、上傳文件等核心數(shù)據(jù)生成一個 tar 包放在/var/opt/gitlab/backups/目錄下。備份文件名里包含時間戳方便識別。但要注意這個命令不備份/etc/gitlab/gitlab.rb和/etc/gitlab/gitlab-secrets.json這兩個文件。前者是配置文件后者包含數(shù)據(jù)庫加密密鑰、CI 密鑰等敏感信息。這兩個文件必須單獨(dú)備份否則恢復(fù)時會出問題。我一般會把它們復(fù)制到一個安全的地方比如另一臺服務(wù)器的備份目錄。恢復(fù)的步驟稍微復(fù)雜一些大致流程是先停掉相關(guān)服務(wù)把備份文件放到指定目錄運(yùn)行恢復(fù)命令再重啟服務(wù)。具體命令是sudo gitlab-ctl stop puma sudo gitlab-ctl stop sidekiq sudo gitlab-backup restore BACKUP備份文件名 sudo gitlab-ctl reconfigure sudo gitlab-ctl restart恢復(fù)完成后一定要驗(yàn)證數(shù)據(jù)是否完整比如檢查倉庫數(shù)量、用戶數(shù)量、最近的提交記錄。5.2 版本升級的注意事項(xiàng)GitLab 的版本升級有講究不能隨便跨大版本升級。官方建議的升級路徑是先升級到當(dāng)前大版本的最新小版本再升級到下一個大版本的最新小版本逐步推進(jìn)。比如從 15.x 升到 17.x需要先升到 15 的最新版再升到 16 的最新版最后升到 17。升級命令本身很簡單sudo apt update sudo apt install -y gitlab-ce sudo gitlab-ctl reconfigure但升級前一定要做兩件事一是完整備份二是查看官方升級文檔里的注意事項(xiàng)。有些版本升級會涉及數(shù)據(jù)庫遷移如果中途失敗回滾會很麻煩。我一般會在升級前把服務(wù)器做個快照萬一出問題可以快速恢復(fù)。另外升級過程中服務(wù)會短暫中斷建議安排在業(yè)務(wù)低峰期進(jìn)行。如果團(tuán)隊(duì)對可用性要求高可以考慮搭建高可用架構(gòu)但那涉及多節(jié)點(diǎn)部署復(fù)雜度會高很多不在本文討論范圍內(nèi)。5.3 監(jiān)控與告警GitLab 跑起來之后需要持續(xù)監(jiān)控它的健康狀態(tài)。最簡單的監(jiān)控方式是定期檢查服務(wù)狀態(tài)和關(guān)鍵指標(biāo)。GitLab 自帶了一個健康檢查接口curl http://gitlab.example.com/-/health如果返回GitLab OK說明基本服務(wù)正常。還有更詳細(xì)的檢查接口比如/-/readiness和/-/liveness可以集成到監(jiān)控系統(tǒng)里。對于資源監(jiān)控我建議關(guān)注幾個核心指標(biāo)CPU 使用率、內(nèi)存使用率、磁盤使用率、磁盤 IO。這些指標(biāo)可以用系統(tǒng)自帶的工具如top、iostat查看也可以接入專業(yè)的監(jiān)控系統(tǒng)。磁盤使用率尤其要關(guān)注因?yàn)?GitLab 的倉庫和日志會持續(xù)增長磁盤滿了會導(dǎo)致服務(wù)不可用。告警方面至少要配置磁盤空間告警和內(nèi)存告警。磁盤使用率超過 80% 就應(yīng)該收到告警內(nèi)存使用率持續(xù)超過 90% 也要告警。這些告警能讓你在問題惡化之前介入處理。6. 我踩過的坑與實(shí)操心得6.1 內(nèi)存不足導(dǎo)致的安裝失敗我第一次在一臺 2GB 內(nèi)存的服務(wù)器上裝 GitLab安裝過程直接卡死最后報錯說內(nèi)存不足。當(dāng)時以為是安裝包的問題重試了好幾次后來才意識到是內(nèi)存不夠。GitLab 的 Omnibus 包在安裝和首次配置時會啟動多個服務(wù)內(nèi)存峰值可能超過 3GB。如果服務(wù)器內(nèi)存只有 2GB基本不可能裝成功。解決辦法有兩個一是加內(nèi)存二是加 swap。加 swap 是臨時方案性能會差一些但至少能裝起來。加 swap 的命令是sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile然后在/etc/fstab里加上一行讓 swap 開機(jī)自動掛載。不過我還是建議生產(chǎn)環(huán)境直接用足夠的內(nèi)存swap 只是應(yīng)急手段。6.2 端口沖突的排查過程有一次在一臺已經(jīng)跑了 Nginx 的服務(wù)器上裝 GitLab裝完之后訪問 502查了半天才發(fā)現(xiàn)是端口沖突。GitLab 自帶的 Nginx 想監(jiān)聽 80 端口但系統(tǒng)上已經(jīng)有一個 Nginx 占用了 80導(dǎo)致 GitLab 的 Nginx 起不來。排查方法是看端口占用sudo ss -tlnp | grep :80如果看到不是 GitLab 的進(jìn)程占用了 80就需要處理。要么停掉原來的服務(wù)要么改 GitLab 的端口。改端口的話在gitlab.rb里設(shè)置nginx[listen_port] 8080然后重新配置。但改端口之后訪問地址也要帶上端口號比如http://gitlab.example.com:8080。6.3 備份文件恢復(fù)的坑備份恢復(fù)看起來簡單但有幾個細(xì)節(jié)容易忽略。第一恢復(fù)時 GitLab 的版本必須和備份時的版本一致否則可能恢復(fù)失敗。第二恢復(fù)前要確保目標(biāo)服務(wù)器的/etc/gitlab/gitlab-secrets.json和備份時的一致否則數(shù)據(jù)庫里的加密數(shù)據(jù)無法解密。第三恢復(fù)過程中如果中斷可能導(dǎo)致數(shù)據(jù)不一致需要重新恢復(fù)。我有一次恢復(fù)備份忘了同步gitlab-secrets.json結(jié)果恢復(fù)完成后用戶能登錄但 CI 變量全部失效排查了很久才發(fā)現(xiàn)是密鑰文件不對。從那以后我每次備份都會把配置文件和密鑰文件一起打包恢復(fù)時一起還原。6.4 一些實(shí)用的小技巧最后分享幾個日常運(yùn)維中總結(jié)的小技巧。第一用gitlab-ctl tail可以實(shí)時查看所有服務(wù)的日志排查問題時很方便不用一個個去翻日志文件。第二gitlab-rails console可以進(jìn)入 Rails 控制臺執(zhí)行一些數(shù)據(jù)庫查詢或修復(fù)操作比如重置用戶密碼、清理卡住的任務(wù)。第三定期運(yùn)行g(shù)itlab-rake gitlab:check可以檢查系統(tǒng)狀態(tài)發(fā)現(xiàn)潛在問題。還有一個關(guān)于性能的小技巧如果團(tuán)隊(duì)規(guī)模不大可以把 GitLab 的 Prometheus 監(jiān)控組件關(guān)掉能省不少內(nèi)存。在gitlab.rb里設(shè)置prometheus_monitoring[enable] false關(guān)掉之后自帶的監(jiān)控面板就不能用了但如果你有自己的監(jiān)控系統(tǒng)這個組件確實(shí)沒必要開。我在幾個小團(tuán)隊(duì)的環(huán)境里都關(guān)掉了它內(nèi)存占用能降 500MB 左右效果挺明顯的。