除了 Jenkins 之外，個人排行第二感興趣的 CI Tool 是 GitLab（GitLab CI 在 GitLab 8.0 之後合併至 GitLab CE/EE）。個人目前被 GitLab 所吸引的地方是它的「單純與便捷」，如同有些人說 Jenkins 太囉唆了，Jenkins 在使用上可以設定的細節超級多（雖然你不一定每一項都會用到）；相較之下 GitLab 單純且便捷，彷彿只要在程式碼中多加一個 yaml 檔即可設定完所有 CI 流程與動作。
但，真的有這麼簡單嗎？
所以當然要實際架設來玩玩看，才能做出更多的判斷。
2016.11.4 補充，確實就是這麼簡單，GitLab 確實是目前熱門的 CI Tool，功能越趨完整，雖然難免開始肥大化，但是未來發展不容小覷。
另外此文已經有部分過期了，建議各位閱讀之餘，還要對照最新的文件，避免有誤！
用 Docker 架設 GitLab 現在 Docker 如此盛行，要架設服務最簡單的做法就是先上 Docker Hub 搜尋現成的 Docker Image。GitLab 這種熱門專案當然不意外，一定會有現成的 Image 可以直接取用。在社群朋友的推薦之下，即找到下面這個優質的 Docker Image。
印象中這個 Docker Image 的作者 sameersbn 是 Docker 圈內的大神之一，除了 GitLab 之外，他也做了其他很多優質的 image，大神出品，品質保證，選用他的 image 准沒錯！
大神做出來的 Docker Image 備有非常完整的使用說明，根據 Quick Start 的說明，可以直接使用作者貼心的準備的 docker-compose.yml 來快速啟動。
當你 docker-compose up 之後，會自動啟動三個 Container，分別是 Postgresql、Redis 及 GitLab。若順利啟動成功，即可透過瀏覽器訪問 10080 或 80 port 順利連上你所架設的 GitLab。
雖然可以直接 docker-compose up 快速啟動，不過我建議還是先檢閱一下 docker-compose.yml，將參數修改成自己所需的設定值，其中比較重要的有：
- GitLab 所需要的 postgresql 帳號密碼
- 掛載進 Postgresql、Redis 及 GitLab 的 volumes 路徑。
- image 的版本。（此作者更新速度快，一直都有跟上 GitLab 的新版本）
- GitLab 的 web 及 SSH port。 （包含 container 開通的 port 及 GitLab 程式內的 port 設定值）
- 是否開啟寄信功能，若要開啟記得填上 SMTP 或 IMAP 的資訊
順利連上 GitLab 之後，可以使用預設的 username = root、password = 5iveL!fe 登入。
（友善提醒，記得將預設的密碼修改成自己的密碼。）
Admin Area
登入後，你可以在 Admin Area 中管理 GitLab 的一些 default 設定值。
在 Admin Area ，你可以管理 GitLab 的許多重要設定值，像在 Users，即可讓你直接新增使用者，或你也可以在 Settings 裡的 Sign-in Restrictions 設定是否開放讓人 Sign-up。若要限制只有自己公司的員工才能 Sign-up，你可以考慮設定 Restricted domains for sign-ups，限制只有特定 domains 的 email 可以 Sign-up。
Admin Area 可以管理的項目很多，這裡就只快速地提及幾項：
Deploy Keys：如果你希望建立跨 Project 共用的 Deploy Key 即可設定於此。（每個 Project 可以設定自己的 Deploy Key。）Runners：即是 GitLab 的 CI 重點項目，Runner 是用來幫你執行 CI / CD 後續動作的機器人，有關 Runner 本文後面會有更多說明。Service templates：如果你有要串接 HipChat、Redmine 或 Slack 等其他服務，這裡可以設定 default 值。（一樣每個 Project 有自己單獨的設定值。）Settings：更多重要的設定值都在這裡，例如前面提到的 Sign-in Restrictions，或你也可以在 Spam and Anti-bot Protection 中開啟 google reCAPTCHA，提升一點安全性。
GitLab Runner
用 docker-compose 架設完 GitLab 之後，接著要來建立 Runner，如前面提過的 Runner 就像是機器人，你所規劃的 CI / CD 各項動作，即是由這些 Runner 來幫忙執行。
要建立 GitLab Runner 當然老樣子，在 Docker Hub 上尋找現成的 Docker Image。
GitLab Runner 目前支援多種 executor，包含 shell、parallels、docker、docker-ssh、virtualbox、ssh … 等，該如何選用 executor 可參考 GitLab 官方文件。
這裡說明兩種我們有使用過的 executor，分別是 shell 及 docker。
首先是 shell。
簡單來說就是 Runner 會在它自己本地端執行你所設定的 CI / CD 動作。
舉例說明：假設我的 Runner 架設在單獨的 VM 上，此 VM 的 hostname 名稱為 runner001。接著我在 .gitlab-ci.yml 中設定一個動作是執行 hostname 指令，則當 GitLab 執行 CI 的動作時，我所得到的結果即是
runner001
因為 Runner 是在它「本地端」執行你所設定的 CI / CD 動作。也因此在使用這種 executor 要特別注意，一個不小心你可能會將 Runner 本身的環境弄髒、弄壞，例如 CI / CD 跑完了，最後想要設定自動刪除檔案，但卻不小心設定了 rm -rf * 之類的動作。(笑)
第二種是 docker
即是 Runner 會先依據 .gitlab-ci.yml 中的設定 Docker Image 運行 Container，接著才在此 Container 上執行 CI / CD 的動作。
舉例說明：例如在 .gitlab-ci.yml 如下設定
image: bobey/docker-gitlab-ci-runner-php5.6
script:
- echo "Running PHPUnit Tests"
- php vendor/bin/phpunit --colors --debug --coverage-text
那麼 Runner 就會先用 Docker Image bobey/docker-gitlab-ci-runner-php5.6 運行一個 Container，接著在此 Container 上執行後續的 phpunit 指令。
故此，如果 Runner 是架設在 VM 上，那麼記得此 VM 上要安裝好 Docker，並且要開放 Docker 的權限給使用者 gitlab-runner。（因為 GitLab 再操控 Runner 時，會使用的 User 是 gitlab-runner。）
若是打算用 Container 架設 Runner 那麼你可以將 host 上的 docker.sock (docker service) 掛載進 Container 之中，讓 Runner 可以直接操控 host 上的 docker service。
（補充：若對於這種將 docker.sock 掛進 Container 的作法感興趣，建議可以延伸閱讀此篇文章《Using Docker-in-Docker for your CI or testing environment? Think twice》）
最後示範一下我們架設 GitLab Runner 所下的 Docker 指令：
docker run -d \
--name gitlab-runner-docker \
--restart always \
-v /run/docker.sock:/var/run/docker.sock \
-v /host/path/for/runner:/etc/gitlab-runner \
gitlab/gitlab-runner:v1.1.0
其中 -v /run/docker.sock:/var/run/docker.sock 就是將 host 的 docker.sock 掛載進 Container。
當 Runner 的 container 啟動之後，還要設定讓它向 GitLab 註冊。
docker exec -it gitlab-runner-docker gitlab-runner register
註冊的時候，GitLab 就會詢問此 Runner 的 executor 為何，並且會需要輸入 GitLab 在 Admin Area - Runners 或各 Project settings 中顯示的 Runner Registration token。
（Runner 可以跨 Project 共用，也可以設定只能專屬某個 Project，因此才會兩邊都能查看到 Token。）
當 Runner 註冊成功，你即可在 GitLab 的 Admin Area - Runners 查看它的狀態。
在 Synology NAS 上也能用 Docker 架設 GitLab 其實接續去年十一月的文章《在 Synology NAS 上用 Docker 運行 php-cli》之後，幾乎公司內部要使用的服務全都被我安裝在 Synology NAS 上。
作法也很簡單，因為 Synology NAS 有提供使用者可以直接 ssh 登入來操作 NAS。順利登入之後它其實與一般的 Linux Server 無異，所以你只要事先在 NAS 的 GUI 中安裝好 Docker，接著你就能在 Terminal 中用 ssh 登入，直接下達 docker 指令。
所以你只要將前面提到的 docker-compose.yml 轉換成一行一行的 docker run 指令，一樣能順利在 Synology NAS 上運行前面介紹的 sameersbn 所製作的 Docker Image - GitLab。
要用 Docker 架設 GitLab 真的不難，特別是已經有現成且優秀的 Docker Image 可以使用，難度直接下降超多，一定要再次讚美 sameersbn 做出來的 Docker Image，image 架構漂亮、使用起來方便、Readme 文件內容齊全、還幫使用者考慮了搬家與升級該如何處理的問題，超好心的！
話說才研究完 GitLab 結果聽說 Jenkins 事隔多年終於改版大躍進，唉，是不是要轉回去再研究一下呢？
本文就到此結束，下次再來多寫一點在 Synology NAS 上透過 Terminal 使用 Docker 的經驗及 GitLab 的相關使用經驗。
