安裝 GitLab

本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。

本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。 鐵人賽原文網址：https://ithelp.ithome.com.tw/articles/10215241）

在第一天的文章中，我們簡單的認識了 GitLab，知道它是一項已廣為人知並受到大家喜愛的工具，它不僅能為團隊提供 Git 與 CI/CD 服務，也能滿足軟體開發專案 Workflow 中的多項需求。

在第一天我們也討論到應該要自行架設 GitLab Server 或使用 gitlab.com。在這裡就先做個聲明，在後續的文章內容，我們會使用到的功能主要會限制在 GitLab CE 之內，僅會以補充說明的方式提及 GitLab EE 的進階功能，因此各位毋須擔心，無論你打算選擇自架 GitLab Server 或使用 gitlab.com，皆可以順利跟著這 30 天的文章一起練習運用 GitLab。

安裝 gitlab

使用任何工具的第零步，當然是「安裝」啦！所以今天我們要先認識該如何自行架設 GitLab EE。這裡也再次說明，沒有註冊 license 的 GitLab EE 等同於 GitLab CE，因此建議可以直接架設 GitLab EE，畢竟難保也許未來的某一天你可能會想要從 CE 升級為 EE。

第一天有提及 GitLab 目前的 Requirements 已經比先前的版本來得調高一些，目前官方建議的 Requirements 如下：

  • Linux-based operating systems（常見的 Ubuntu、Debian、CentOS、openSUSE 與 Red Hat Enterprise Linux 皆可。）
  • Ruby 2.5（自 GitLab 版本 11.6 之後，僅支援 Ruby 2.5 以上。）
  • 1 ~ 2 cores CPU（根據使用人數是否超過百人。）
  • 4 GB RAM + 4GB swap（如使用人數超過百人，則建議 8 GB RAM。）
  • PostgreSQL 9.6（自 GitLab 版本 12.1 之後，不再支援使用 MySQL。）

【新增補充】GitLab 14.5 的 Requirements 已經變更如下：

  • 4 cores CPU，可以支撐至多約 500 位 User，8 cores CPU，可以支撐至多約 1000 位 User。官方文件更增加了 Available reference architectures 幫助你更詳細的依據預期的 User 數量來決定要用哪種等級的主機來架設 GitLab Server，舉例來說如果預期有 1000 位 User，那麼 AWS 可以選擇 c5.2xlarge 的 Ec2 主機。
  • GitLab 13.0 要求至少要 PostgreSQL 11，GitLab 14.0 則要求 PostgreSQL 12。
  • GitLab 13.0 要求 Redis 要 4.0 以上的版本。 但總之老樣子，其實你可以準備一台規格夠好的主機，剩下的問題都交給自動安裝包 Omnibus GitLab 處理。

【再次補充】GitLab 15.x 的 Requirements 又再次更新，還請自行確認原廠最新文件，查看目前最新的 Requirements。

相較於早期版本的安裝不易，目前 GitLab 官方已經提供了多樣的安裝方式與指南，讓架設 GitLab Server 的困難度下降許多。在官方網站 GitLab Installation 的頁面中，目前已列出針對多種不同環境的安裝方法，無論是 Ubuntu、CentOS、OpenSUSE、甚至是 Raspberry Pi 2 都能輕易的架設 GitLab。

【新增補充】Raspberry Pi 2 已經不夠力了，現在要用 Raspberry Pi 架設 GitLab，你需要 Raspberry Pi 4，同時如前述的至少 4GB RAM 才行。


（在官網已列出針對多種不同環境的 GitLab 安裝方法。）

除此之外，各家雲端供應商現在幾乎都有在 Marketplace 中提供現成方案，幫助使用者能一鍵架設 GitLab。


（例如：DigitalOcean 的 Marketplace。）


（例如：Google Cloud Platform。）

以 Package Management 的方案安裝 GitLab（以 Ubuntu 為例）

下面就以 Ubuntu 18.04 為例，GitLab EE 的安裝步驟如下：

# 先更新 Package Management
sudo apt-get update

# 安裝必要的 Package
sudo apt-get install -y curl openssh-server ca-certificates

# 取得 GitLab 官方事先準備好的 shell script，透過它自動添加 GitLab Package Repository。（如果要安裝 CE，下面的指令要換成 gitlab-ce）
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

# 設定你的 GitLab EE 要對應哪一個 Domain Name，並開始安裝 GitLab EE。（在安裝過程會自動設定 Domain Name。如果要安裝 CE，下面的指令要換成 gitlab-ce）
sudo EXTERNAL_URL="https://gitlab.example.com" apt-get install gitlab-ee

# 安裝完畢之後，即可立即透過瀏覽器以預設的 root 帳號登入。要注意一進入網站就會立刻要你設定新的 root 密碼，因此安裝完畢後，務必要盡快連上你架設好的 GitLab Server。

【新增補充】如果你輸入的 EXTERNAL_URL 是 https 開頭，那麼 Omnibus GitLab 還會自動幫你用 Let’s Encrypt 申請免費的 SSL 憑證。


（安裝完記得馬上連上網站設定 root 密碼。）

【新增補充】新版本的 Omnibus GitLab 也開始調整提供 root 預設密碼的方式，在 GitLab 12 與 13 的時代，還會出現如前述的狀況，在 GitLab 一架設完畢時，要盡快連上 GitLab Server 設定 root 密碼。在最新的 GitLab 14.5，Omnibus 會直接給予 root 一組預設的密碼， 並儲存在 /etc/gitlab/initial_root_password，記得在 GitLab Server 安裝完畢後前往查看。

實際按上述步驟安裝一遍，會發現過程非常的自動、順暢，甚至可以用「神奇」來形容，為何一行 apt-get install gitlab-ee，不但自動安裝了 GitLab EE，就連 GitLab EE 相依的其他 Packages 或 Services（例如：postgresql、redis、nginx⋯⋯）也都一並自動安裝完畢了。這背後其實是透過一個神奇的黑魔法達成的，因此在這裡我們必須要隆重的介紹 Omnibus GitLab 這個專案。

【新增補充】如果你不想要安裝最新版的 GitLab，那麼可以在前述安裝步驟要執行 apt-get install gitlab-ee 時，補上要安裝的版本號，例如 apt-get install gitlab-ee=13.12.15-ee.0。版本號的查詢，可以透過指令 apt-cache madison gitlab-ee 獲得。

Omnibus GitLab 幫你解決架設 GitLab 的大小事

Omnibus GitLab 是 GitLab 底下的一個子專案，其專案目標即是幫助使用者可以簡易、方便地安裝 GitLab，減輕安裝過程中的繁瑣設定，讓使用者無需煩惱該如何各別安裝、設定 GitLab 的相依 Services 及組態配置；只要像往常安裝其他軟體一樣，只要一行 Package Management 的安裝指令就搞定一切，甚至也不用擔心自己重複執行 apt-get install gitlab-ee，所有事情皆能夠自動（半自動）的完成。

介紹到這裡，你是否有聯想到其他類似的工具呢？只要一行指令就能完成多個軟體的安裝、環境與組態的配置，甚至不用擔心自己重複執行⋯⋯這不就是組態配置工具（Configuration Management Tools）的特色嗎？

而答案也正是如此，如果你仔細去追 Omnibus GitLab 專案內的程式碼或留意它的安裝過程，你會發現它一連串自動化操作的背後其實就是靠 Chef 這套知名的組態配置工具完成的。（由此前往查看 GitLab 的 Chef Cookbooks。）既然 GitLab 主要是以 Ruby 撰寫的，那麼選擇同樣也是以 Rudy 撰寫的 Chef 作為組態配置工具亦是合情合理。


(Omnibus GitLab 其實是幫你自動安裝並執行了 Chef Cookbooks！)

如果你不打算透過 Package Management 一個步驟一個步驟地敲指令安裝（雖然沒幾個指令），亦可使用 Docker 或自行選擇其他的組態配置工具（Ansible、Puppet、SaltStack）來協助架設 GitLab Server。

老實說，既然官方已經有現成的 Chef Cookbooks 可以使用，甚至都包裝成幾個常見 Linux OS Distribution 的 Package Management，對多數的使用者而言已足夠便利。但艦長身為 Ansible 的使用者，這邊當然要私心介紹一下 Ansible 界的大神 Jeff Geerling 從很早期就開始協助維護的 Ansible Role，如果是熟悉 Ansible 的朋友，應該對此不陌生，亦可考慮使用它來幫你架設 GitLab。但憑良心說，Jeff Geerling 的 Ansible Role 已經一段時間沒維護更新，以現在階段來說，使用該 Role 並非是自行架設 GitLab 的最佳方案。

如果你嫌上述兩種方式都太麻煩或不夠新穎，想要潮一點的使用 Container 來架設 GitLab，目前也能透過 Docker 快速地架設 GitLab。在前幾年 Docker 開始火熱的時候，GitLab 圈內就有大神 Sameer Naik 在早期貢獻維護了 GitLab 的 Docker image，讓大家可以透過 docker-compose 快速架設 GitLab；而官方後續也推出了官方 Docker image（該 image 背後也是仰賴於 Omnibus GitLab 這項專案。），所以要透過 Docker 架設 GitLab 已不是什麽難事。

【新增補充】官方持續在擁抱 Kubernetes，目前也有透過 Helm 將 GitLab 架設在 Kubernetes 上的安裝方法，這部分就留給各位 K8s 高手去研究了，請參閱官方文件 - Installing GitLab using Helm。

提醒：務必詳閱文件並設定 GitLab Configuration

如果你也是透過官方 Omnibus GitLab 的各種方式安裝 GitLab Server，那在首次執行完 install 動作之後，記得還要查看 GitLab 的 Configuration，裡面有很多重要的參數需要一一設定。

例如 SMTP 的相關參數，如果沒有設定正確有效的 SMTP，那你架設的 GitLab Server 可就沒辦法正常的讓使用者自行註冊帳號喔！（因為 GitLab Server 需要寄出註冊認證信。）針對 SMTP 再多提醒一點，因為聽說有些人想要為 GitLab Server 設定透過 Gmail 或其他免費的 SMTP 服務來寄信，但過程卻是一波三折。所以建議 SMTP 還是使用像是 AWS SES、Mailgun 之類 SMTP 服務會比較容易搞定喔！

【新增補充】其實沒有設置 SMTP 的 GitLab Server 依然是可以正常運作的，但就是會缺少了以 Email 傳遞資訊給 User 的管道，雖然無法讓使用者自行註冊，但管理者仍然可以在 GitLab Server 的 Admin area 中直接新增 User，並指定預設密碼。

小結

隨著 GitLab 功能越來越豐富，其架構也越來越複雜、肥大，這也導致自行架設的困難度。但從官方的 Omnibus GitLab 專案中，我們可以發現官方為了減輕 Gitlab 的安裝難度已投注了不少心力。

在比較了官方文件中條列的各種安裝方法，我個人認為採用 Omnibus GitLab 的方式安裝 GitLab，應該是目前最簡單省事的方式；但別忘記除了自行架設，選用 gitlab.com 仍是一個值得我們考慮的選項。

今天的內容就在此告一個段落，我們明天見～

參考資料

← 前言
Admin Area—維運 GitLab Server 的管理者後台 →