安裝 GitLab

本文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw,同時修正部分內容。

在第一天的文章中,我們簡單的認識了 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 官方已經提供了多樣的安裝方式與指南,讓架設 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_URLhttps 開頭,那麼 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 仍是一個值得我們考慮的選項。

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

參考資料