GCP帳號充值服務 GCP上建立個人代碼託管伺服器：GitLab私有化部署保姆級教程

谷歌雲GCP / 2026-07-13 21:40:04

前言：為什麼要在 GCP 私有化 GitLab

很多人用 GitHub 或公有 GitLab，起步很快，但當你的代碼牽涉公司資產、敏感專案、內部流程或法遵要求，就會開始在意「資料不出境」「權限要可控」「稽核要好做」「客戶端要能訪問穩定」。這時，把 GitLab 私有化部署到你自己掌握的雲上，就成了最實際的解。

GCP帳號充值服務 在 GCP 上部署 GitLab，優點很明顯：基礎設施省心、擴容方便、備援與監控工具成熟。缺點也要先說清：GitLab 不是一個輕量服務，資料庫、檔案、CI Runner 都可能堆在一起；如果一開始配置不對，後面會很痛。

下面這篇文章會以「保姆級教程」的方式寫：你不需要先懂全部概念，只要跟著做，并在遇到問題時知道該去哪裡看、怎麼判斷。目標不是把你訓練成 DevOps，而是讓你把服務穩穩地跑起來。

第一章：部署前的思考清單（少走彎路）

GCP帳號充值服務 1. 你要的是哪一種 GitLab？

GitLab 私有化通常有兩條路：

Omnibus（推薦給新手）：單機包裝，安裝、更新、日常維護都比較直觀。GitLab 將元件整合在一台或少數幾台主機上。
以 Docker/自建微服務：彈性更高，但你得自己管理多個元件與網路、持久化、版本相容，對新手不友善。

本文以Omnibus 部署為主路線。原因很簡單：你要的是「能用、好維護、容易排錯」。

2. 硬體規劃：先估算，再落地

GitLab 的資源消耗跟你使用方式強相關，尤其是 CI/CD、容器構建、以及大量大檔儲存。你可以用以下粗略估算（僅供起步參考）：

小型到中小型：2 vCPU、8GB RAM、~100GB 磁碟（含 OS 與初期 Git 存儲）。
中型：4 vCPU、16GB RAM、~300GB 磁碟。
大量 CI：磁碟與 Runner 會吃得更快；通常要配額外磁碟與更好的快取策略，必要時把 Runner 放到獨立機器。

如果你不確定，就先以「小型」起步，確保部署能穩定跑。真正的坑不在於你一開始給少了，而在於你沒有把資料磁碟規劃好可擴充。

3. 網路與網域：提前決定你的訪問方式

GitLab 典型會走兩種訪問：

HTTP/HTTPS：瀏覽器、Web API、Git 操作都在這裡。
SSH：例如你要用 git@ 域名方式 push/pull。

建議你直接準備一個網域（可以是子網域）。例如：gitlab.yourdomain.com。有網域的好處是 TLS 憑證可以更容易處理、也更像真正的內部服務。

如果你暫時沒有網域，也可以先用自簽憑證或臨時方式上線，但你後續一定要補齊。

第二章：在 GCP 建立主機與網路環境

1. 建立 Compute Engine 實例

登入 GCP Console，建立一台 Compute Engine VM。建議做法：

系統：建議使用 Ubuntu 22.04 LTS 或 20.04 LTS。
區域/機型：先以標準機型起步。
磁碟：一定要把 GitLab 的資料放到「可持久化、可擴充」的磁碟上。

你可以選用一個 VM 並附加一顆額外的持久磁碟（例如 200GB）。後續若資料增加，只擴充磁碟即可。

2. 防火牆規則：把該開的開好

GitLab 主要會用到以下埠：

80：HTTP（若你只用 HTTPS，可不開，但常有人用到重導）
443：HTTPS（必開）
22：SSH（Git 透過 SSH 時必開）
1022/一些自定義：可依你設定 Runner 或其他服務

你可以在 VPC 防火牆中建立入站規則。原則是：能限制來源就限制來源。例如只允許你公司 IP 網段存取。

3. 固定 IP 與 DNS

如果你使用網域，強烈建議 VM 使用靜態外部 IP。因為 GitLab 的對外服務會依賴你的網域解析到正確 IP。

完成後，在你的 DNS 管理後台加上 A 記錄：

GCP帳號充值服務 主機名：gitlab
類型：A
值：你的靜態 IP

等待 DNS 生效即可。

第三章：選擇部署方法並開始安裝 GitLab

1. 先更新系統與準備相依套件

登入你的 VM 後，先做系統更新與基礎工具準備。你可以按下列思路操作：

更新套件索引與升級
安裝 Git、curl、必要的編譯/網路工具（取決於你的版本）

Omnibus 通常會處理大部分依賴，但你仍要確保系統是乾淨且版本一致。

GCP帳號充值服務 2. 設定 GitLab 外部 URL（最重要的一步之一）

GitLab 安裝時你要告訴它對外服務的網址。例如：

把 external_url 設為你的網域：

external_url 'https://gitlab.yourdomain.com'

這一步做錯後面會出現重導、連結錯誤、Webhook 回呼失敗等問題。你應該在安裝前就確認。

3. Docker 與 Omnibus 的取捨（快速決策）

如果你只想把 GitLab 快速落地，建議堅持用 Omnibus。你不用自己把資料庫、redis、nginx、workhorse 分散管理。

只有在你有以下需求時才考慮 Docker 或分離式部署：

你要做多主機 HA（高可用）
你要精細拆分資源與容器網路
你已經有成熟 DevOps 流程

否則，Omnibus 是最能降低不必要複雜度的選擇。

第四章：以 Omnibus 部署 GitLab（核心流程）

GCP帳號充值服務 1. 開始安裝（官方安裝路徑）

在 VM 上依照 Omnibus 的安裝方式進行。一般流程是：

加入 GitLab 的軟體源（或使用官方方式獲取安裝包）
GCP帳號充值服務 設定 gitlab.rb（含 external_url、證書、SSH 設定等）
執行安裝指令讓 GitLab 初始化

你要注意：不同版本的安裝方式可能略有差異，但「設 external_url → 配置 → 執行安裝」的骨架是一致的。

2. 配置 TLS 憑證：讓瀏覽器與 Git 走安全通道

GitLab 強烈建議使用 HTTPS。你可以使用兩種方式：

自建憑證：上傳你自己的憑證與私鑰。
Let’s Encrypt：自動簽發（通常需要你的網域可對外解析並能完成 HTTP-01 或 DNS-01 挑戰）。

若你是內網環境且沒有公開網域，可能得使用自建 CA 或內網憑證。若是一般公開網域，Let’s Encrypt 會省掉很多麻煩。

不管你用哪種方式，都要記得：配置完成後要讓 GitLab 的 Nginx 正常載入憑證。可以用狀態檢查或檢視服務日志確認。

3. SSH 佈署：讓你可以用 git@ push

GitLab 內部通常會配置 SSH，讓你能在用戶端透過 SSH push/pull。要確認：

GitLab 對外 SSH 域名或 IP
入站 22 埠已打通
若你使用自簽憑證或特定網路，客户端需信任

如果你只是想先用 HTTPS 操作，也可以先不急著把 SSH 做到位。但很多团队後面會要求 SSH，所以早點驗證會更省時間。

4. 初始化完成後登入：root 密碼與首次設定

安裝完成後，通常會生成或顯示 root 初始密碼（或你需要從檔案中讀取）。你登入後應立刻做幾件事：

更新密碼（root 勿久放初始值）
設定站點 URL、時區
檢查郵件通知（SMTP）是否可用（若你要做通知、忘記密碼等）
檢查使用者註冊策略（是否允許外部註冊、是否封鎖 sign-up）

如果你沒有 SMTP 或不想處理郵件，也要確保系統不會在登入或操作時因郵件失敗而造成卡頓。

第五章：磁碟與資料持久化策略（最常被忽略）

1. 為什麼磁碟規劃是成敗關鍵

GitLab 依賴大量持久化資料，包括：

Git 倉庫本體
上傳的檔案（包括 LFS）
CI 產出的 artifacts
系統日誌與快取

如果你把資料都放在系統盤，未來擴容要重來；如果你忘了設定磁碟掛載，更新或重啟後會出現資料丟失或服務啟不來。

2. 建議的做法：獨立掛載並確保可擴充

建議你做一個額外的持久磁碟（例如 /mnt/gitlab-data），再把 GitLab 的資料目錄映射到這個掛載點。

GCP帳號充值服務 不同安裝方式會影響目錄位置，但你要抓住的是：把 GitLab 需要的主要資料放到外掛磁碟。

GCP帳號充值服務 此外，當你擴充磁碟時，不只要在 GCP 側做擴容，還要在 VM 裡面讓檔案系統辨識新容量。

3. 快照與備份：別等事故才想起來

備份至少要包含兩層：

磁碟快照：能快速回滾，但不是即時檢索級別的備份。
GitLab 內建備份：通常包含資料庫與必要的檔案，恢復更精準。

如果你是個人站或小團隊，至少做到：

GCP帳號充值服務 每天或每隔幾小時備份資料
至少每週做一次更完整的快照
定期做「備份可用」測試（這點最容易被跳過）

備份不是只產出就算完成。你要知道如果真的要恢復，你能不能恢復。

第六章：建立 CI/CD 與 Runner（讓你的 GitLab 活起來）

1. 先搞清楚 Runner 的角色

GitLab 的 CI/CD 執行需要 Runner。你可以把 Runner 跑在同一台 GitLab 主機上（初期簡單），也可以把 Runner 放到獨立 VM（更安全、也更容易擴充）。

起步階段建議同機 Runner，等流程成熟再拆。

2. 用最小配置先通過第一個 Pipeline

你應該用一個最簡單的 .gitlab-ci.yml 驗證：

runner 是否能註冊
pipeline 能否上傳 artifact（若你設定）
快取是否能正常運作（可選）

不要一開始就導入複雜的 Docker-in-Docker、Kubernetes executor 等設計。先把基本流程打通，確保你有「可靠的基礎」，再談最佳化。

3. 資安與資源限制：Runner 不能無限制

CI pipeline 可能執行任意腳本。你要把最基本的控制做好：

限制使用的 image（如果可能）
避免 runner 以過高權限運行
為磁碟與 CPU 設上限，避免爆掉整台機器

尤其是在多人使用或你允許外部提交 pipeline 時，安全設計更不能省。

第七章：TLS、反向代理與 URL 正確性檢查（上線前必做）

1. 你要確保：外部 URL 與實際訪問一致

GitLab 在前端連結、Webhook 回呼、以及某些跳轉上都會依賴 external_url。因此你需要確認：

瀏覽器能正常打開 GitLab
連結、登入後導向正確
Webhook 發送目標是你預期的網址

2. 讓 Git 操作走 HTTPS（可選）

你可以把 Git 操作方式調整到一致，減少團隊成員的困惑。若你使用 HTTPS，就要確保憑證鏈完整。

如果團隊遇到憑證警告，會導致他們不願意使用或被迫繞過安全檢查。這類問題在上線後最傷。

3. 檢查日誌：排錯時先看哪裡

當 GitLab 的狀態不正常，你應該知道優先檢查的方向：

Web 服務（Nginx/rails 等）是否啟動
資料庫連線是否正常
磁碟是否滿了（這是最常見的根因之一）
DNS 或憑證是否導致服務啟動失敗

你的直覺是「先看最直接影響外部的服務」，而不是從所有元件開始猜。

第八章：上線與日常維護（你會用得上）

1. 更新策略：先測，再升級

GitLab 升級會帶來變更。你應該採取：

升級前先做完整備份
先在維護窗口做升級
更新後檢查 pipeline 與日常功能

如果你是小團隊，最好設定固定的維護週期，例如每月或每兩週檢查一次。

2. 監控與告警：別讓你自己變成監控器

至少做以下幾件事：

CPU、RAM、磁碟使用量監控
服務狀態（HTTP 連通性）
備份是否成功的告警

GCP 上你可以使用內建監控工具配合簡單告警。你要的是讓問題在用戶抱怨之前被你看到。

3. 使用者與權限管理：建立制度比修修補補重要

GCP帳號充值服務 私有化不是把服務裝起來就結束。你還要確保：

誰能建立專案、誰能管理群組
誰能在 CI 中使用敏感變數（如 API Key）
分支保護策略（例如 main 不允許直接 push）

這些設定會在你團隊規模變大後立刻影響風險。

GCP帳號充值服務第九章：常見錯誤與排查路線（把坑填平）

1. GitLab 無法打開或一直重導

最常見原因：

external_url 設錯
憑證無效或缺少鏈
防火牆未開 443

排查順序建議：

先確認你實際訪問的 URL 是否與設置一致
用浏览器查看憑證錯誤
檢查服務是否啟動、日誌是否報 TLS 或路由錯誤

2. 安裝卡住或服務起不來

常見原因：

磁碟空間不足
持久化目錄權限錯誤
DNS 或 URL 設定導致自動檢測失敗

建議你先看系統磁碟是否滿了，然後看安裝/服務的日志。不要反覆改設定直到方向不明。

3. Pipeline 跑不起來