我的服務器上部署的代碼、配置文件等內(nèi)容大多是使用 Git 進行版本控制。為了能夠使用、配置起來更方便，通常使用一整套系統(tǒng)去管理。很顯然，在一些代碼和配置文件里會有一些機密的內(nèi)容，如一些密鑰什么的，所以必須不能公開。GitHub.com 雖然提供了 Private 存放處功能，但是由于此功能是付費的，而且對于 Organization 的 Plan 還是極貴，并不十分劃算；就算能有免費的 Private 存放處，把自己的很多重要的密鑰放在第三方服務器上還是很不安全，所以能夠 Host 在自己的主機上的，并且能夠替代 GitHub.com 的軟件/服務就是不錯的選擇。
本文將講一下我在自己服務器上安裝 GitLab 遇到的坑，進階使用，包括使用 .gitlab-ci.yml 文件實現(xiàn)自動 Build，實時同步鏡像到 GitHub。
能夠 Host 在自己的服務器上的軟件/服務其實有很多，比如 GitHub Enterprise，Bitbucket Server。不過再此還是推薦完全開源、免費、由社區(qū)維護的 GitLab Community Edition，沒有任何限制，只是相比 Enterprise Edition 少了些本來也用不著的功能。
安裝及遇到的坑
具體安裝方法見文檔，目前官方推薦的系統(tǒng)環(huán)境是 Ubuntu 16.04 LTS，安裝起來非常簡便，整個 Web 環(huán)境都會配置好。安裝后的更多配置請參見文檔。如果你的主機上跑了不只一個 Web 程序，那就需要對現(xiàn)有的 Web 軟件做修改，具體可參見我的代碼（Nginx）或者官方的文檔。我的代碼中使用了 sub_filter 來實現(xiàn)替換默認的標題，實現(xiàn)更好的 SEO，更加品牌化。
然后為了能達到更好的使用效果，還應該配置 SMTP 發(fā)件服務器，我使用的是 AWS SES；然后還需要一個支持 IMAP 的收件服務器實現(xiàn) Reply by email，我使用的是 Gmail，收郵件的限制總比發(fā)郵件的限制少吧～這些的具體設置方法官方文檔里都有。
安裝后默認是允許注冊的，如果你不想讓外人注冊，你需要直接去 Web 后臺禁用。如果你想要開放注冊，那么最好先想好新注冊用戶能干什么，比如和我一樣：只允許新用戶創(chuàng)建 Issues 和 Snippets，那就在 Web 后臺將 Default projects limit 設置為 0，然后編輯后臺的配置文件，禁止新用戶創(chuàng)建 Group。同時建議在 Web 后臺啟用 reCAPTCHA 和 Akismet，防止惡意注冊和惡意發(fā) Issues。既然允許注冊，那么也建議使用 OmniAuth 來支持第三方 OAuth 的方式登陸。
GitLab Runner
GitLab Runner 十分強大，但是并不是內(nèi)置的，它可以極其方便的實現(xiàn)自動部署等非常有用的功能。安裝配置好 Runner 后，在項目根目錄下添加一個名為 .gitlab-ci.yml 的文件，以 master 分支為例，為了實現(xiàn)每次 commit 到 master 都將文件部署到 /var/gitlab/myapp ，那么文件內(nèi)容應該是這樣的：
pages:
stage: deploy
script:
- mkdir -p /var/gitlab/myapp
- git --work-tree=/var/gitlab/myapp checkout -f
only:
- master
注意，你需要先創(chuàng)建 /var/gitlab 文件夾，并設置這個文件夾的用戶組為 gitlab-runner:gitlab-runner
sudo chown -R gitlab-runner:gitlab-runner /var/gitlab
.gitlab-ci.yml 核心的部分就是 script: ，這里的腳本都是由用戶 gitlab-runner 執(zhí)行的，你可以根據(jù)需要修改，后文中也給了幾種范例。
然后 commit，去設置頁面里里激活這個項目的 Runner。建議在設置里設置 Builds 為 git clone 而不是 git fetch ，因為后者常常出現(xiàn)奇奇怪怪的問題，前者的速度瓶頸主要在于網(wǎng)絡傳輸。
部署 Runner 在同一個主機上，Or not？
官方的文檔里強烈不推薦把 Runner 部署在同一個主機上，其實這種說法并不正確。官方不推薦這樣做是因為一些 build 會花費很長時間，占用很多的 CPU 和內(nèi)存資源。但是如果你執(zhí)行的 build 腳本并不會這樣，那么安裝在同一個主機上也未嘗不可。
常見的部署范例
這幾種部署是我比較常用的，大家可以當作范例，具體根據(jù)自己的需要弄各種不同的部署。
以下幾種 Web 的部署方式所消耗的系統(tǒng)資源都不多，而且由于使用了 nice ，并不會阻塞其他任務，可以部署在同一臺主機上。
Jekyll
修改之前那個 .gitlab-ci.yml 文件的 git checkout 一行，替換為：
nice jekyll build --incremental -d /var/gitlab/myapp
檢查 PHP 的編譯錯誤
也是添加以下代碼到 .gitlab-ci.yml 即可自動檢查所有 PHP 文件的編譯錯誤，編譯通過的文件不會顯示，只會顯示編譯錯誤的：
if find . -type f -name "*.php" -exec nice php -l {} \; | grep -v "No syntax errors"; then false; else echo "No syntax errors"; fi
自動與 GitHub 同步
以下過程需要 root 權限登陸到主機，或者在每行命令前添加 sudo。
首先，需要先給 gitlab-runner 用戶一個單獨的 SSH Key：
ssh-keygen -f /home/gitlab-runner/.ssh/id_rsa
然后，創(chuàng)建 /home/gitlab-runner/.ssh/known_hosts ，內(nèi)容是：
github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
之后，獲取 /home/gitlab-runner/.ssh/id_rsa.pub 文件內(nèi)容，在 GitHub 上添加這個 SSH Key。
由于是使用 root 賬號，弄完了之后不要忘了修改用戶組：
sudo chown -R gitlab-runner:gitlab-runner /home/gitlab-runner/.ssh
然后，同樣是通過 .gitlab-ci.yml 實現(xiàn)自動同步：
git push --force --mirror git@github.com:[Organization]/[Project].git
修改 [Organization] 和 [Project] 為你自己的名稱即可。
談談安裝在自己服務器上的 GitLab 的好處
文件都存儲在自己的服務器里，安全性比較有保障，自己有最高權限，不會遇到項目被刪的情況。部署時延遲極低，可靠性也高，不會遇到自己服務器沒問題但是第三方服務宕機導致無法部署的窘?jīng)r。
可以根據(jù)情況部署到離自己最近的服務器，或者是內(nèi)部服務器，像 GitHub 的服務器就在美國東岸，亞洲這邊連接并不快，國內(nèi)也不穩(wěn)定。
最關鍵的是，如果你本來就有個 VPS 什么的，也有很大的空閑，那么相當于你可以免費獲得私有存放處，但是要注意性能需求，沒有足夠的空閑還是不要啟用。
由于能夠配置好實時同步鏡像到 GitHub，GitLab 還有那么多 GitHub 沒有的功能，其實已經(jīng)可以完全使用 GitLab 作為主要的版本控制工具，GitHub 只是存一份鏡像備用。
最后
歡迎大家訪問我的 gitTLO（git.tlo.xyz） 體驗效果，使用的正是 GitLab。
