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