一、系統(tǒng)環(huán)境
- 服務(wù)器：阿里云主機(jī)
- 操作系統(tǒng)：Centos7.0 64位
- 已裝軟件：Nginx（80端口）、Apache（8080端口）、PHP-FPM（9000端口）
二、安裝版本
- GitLab分為社區(qū)版（GitLab Community Edition）和企業(yè)版（GitLab Enterprise Edition）。社區(qū)版免費(fèi)，企業(yè)版收費(fèi)，但是功能比社區(qū)版多。根據(jù)目前的需求，選擇安裝社區(qū)版（GitLab-CE）。
- 版本號：8.5.4
三、安裝方式
以前試過源碼安裝，過程痛苦無比。此次選擇官方提供的GitLab-CE Omnibus安裝包。GitLab官網(wǎng)上有詳細(xì)的安裝說明，根據(jù)自己的操作系統(tǒng)選擇相應(yīng)的版本，按步驟操作即可。
https://about.gitlab.com/downloads
四、安裝過程
由于國內(nèi)阿里云主機(jī)無法連接國外的GitLab Yum源，所以只能從GitLab中文社區(qū)直接下載rpm包進(jìn)行安裝。
curl -LJO https://mirror.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-8.5.4-ce.0.el7.x86_64.rpm
rpm -i gitlab-ce-8.5.4-ce.0.el7.x86_64.rpm
GitLab中文社區(qū)：http://www.gitlab.cc
五、GitLab服務(wù)構(gòu)成
GitLab由以下服務(wù)構(gòu)成：
-
nginx：靜態(tài)Web服務(wù)器 -
gitlab-shell：用于處理Git命令和修改authorized keys列表 -
gitlab-workhorse:輕量級的反向代理服務(wù)器 -
logrotate：日志文件管理工具 -
postgresql：數(shù)據(jù)庫 -
redis：緩存數(shù)據(jù)庫 -
sidekiq：用于在后臺執(zhí)行隊列任務(wù)（異步執(zhí)行） -
unicorn：An HTTP server for Rack applications，GitLab Rails應(yīng)用是托管在這個服務(wù)器上面的。
重點(diǎn)講一下gitlab-shell和gitlab-workhorse。
Gitlab Shell
GitLab Shell有兩個作用：為GitLab處理Git命令、修改authorized keys列表。
當(dāng)通過SSH訪問GitLab Server時，GitLab Shell會：
- 限制執(zhí)行預(yù)定義好的Git命令（git push, git pull, git annex）
- 調(diào)用GitLab Rails API 檢查權(quán)限
- 執(zhí)行pre-receive鉤子（在GitLab企業(yè)版中叫做Git鉤子）
- 執(zhí)行你請求的動作
- 處理GitLab的post-receive動作
- 處理自定義的post-receive動作
當(dāng)通過http(s)訪問GitLab Server時，工作流程取決于你是從Git倉庫拉取(pull)代碼還是向git倉庫推送(push)代碼。如果你是從Git倉庫拉取(pull)代碼，GitLab Rails應(yīng)用會全權(quán)負(fù)責(zé)處理用戶鑒權(quán)和執(zhí)行Git命令的工作；如果你是向Git倉庫推送(push)代碼，GitLab Rails應(yīng)用既不會進(jìn)行用戶鑒權(quán)也不會執(zhí)行Git命令，它會把以下工作交由GitLab Shell進(jìn)行處理：
- 調(diào)用GitLab Rails API 檢查權(quán)限
- 執(zhí)行pre-receive鉤子（在GitLab企業(yè)版中叫做Git鉤子）
- 執(zhí)行你請求的動作
- 處理GitLab的post-receive動作
- 處理自定義的post-receive動作
也許你會奇怪在通過http(s)推送(push)代碼的情況下，GitLab Rails應(yīng)用為什么不在GitLab Shell之前進(jìn)行鑒權(quán)。這是因為GitLab Rails應(yīng)用沒有解析git push命令的邏輯。好的方法是將這些解析代碼放在一個地方，這個地方就是GitLab Shell，這樣我們就可以在通過SSH進(jìn)行訪問時重用這段代碼。實際上，GitLabShell在執(zhí)行git push命令時根本不會進(jìn)行權(quán)限檢查，它是依賴于pre-receive鉤子進(jìn)行權(quán)限檢查的。而當(dāng)你執(zhí)行git pull命令時，權(quán)限檢查是在命令執(zhí)行之前的。對git pull命令的權(quán)限檢查要簡單得多，因為你只需要檢查一個用戶是否可以訪問這個倉庫就可以了（不需要檢查分支權(quán)限）。
好吧，GitLab Shell這段話都是翻譯官網(wǎng)的。鏈接在這里
https://gitlab.com/gitlab-org/gitlab-shell/blob/master/README.md
最后一段話有點(diǎn)拗口，我對此還是有一點(diǎn)問題的：既然你把
git push的邏輯都放在GitLab Shell里面了，為什么不把git pull的邏輯也都放在里面提供重用呢？
猜想：git pull這段邏輯無法重用，因為通過http(s)方式訪問時，要讀取倉庫的數(shù)據(jù)并且把這些數(shù)據(jù)封裝成http包返回給客戶端；而通過ssh方式訪問時，倉庫代碼數(shù)據(jù)是通過ssh數(shù)據(jù)包返回的。兩種訪問方式返回數(shù)據(jù)的封裝方式不一樣，所以也沒有必要提供重用。但是我覺得讀取倉庫數(shù)據(jù)這段邏輯應(yīng)該還是重用了的。
GitLab Workhorse
GitLab Workhorse是一個敏捷的反向代理。它會處理一些大的HTTP請求，比如文件上傳、文件下載、Git push/pull和Git包下載。其它請求會反向代理到GitLab Rails應(yīng)用，即反向代理給后端的unicorn。官網(wǎng)對GitLab Workhorse的介紹在這里：https://gitlab.com/gitlab-org/gitlab-workhorse/
六、GitLab工作流程
七、配置
配置考量
- 要求能通過子域名
git.zn2studio.com訪問GitLab站點(diǎn)并且站點(diǎn)內(nèi)的倉庫地址也要用子域名顯示。 - 要求使用騰訊企業(yè)郵箱的SMTP服務(wù)器發(fā)送郵件。
- 要求使用HTTP請求方式。
- 要求能使用SSH連接方式。
- 要求避免與已裝軟件的端口沖突
- 要求使用系統(tǒng)已安裝的Nginx服務(wù)器
配置過程
- 修改GitLab配置文件，停用GitLab內(nèi)置Nginx
nginx['enable'] = false - 使用系統(tǒng)已經(jīng)安裝的Nginx給gitlab-workhorse作反向代理
- 因為unicorn的默認(rèn)端口是8080,與系統(tǒng)已存在的Apache端口沖突，修改Apache端口為8000（也可以修改unicorn的端口）
- 修改GitLab配置文件中的external_url
external_url 'http://git.zn2studio.com'
修改這個配置會影響GitLab里面顯示的倉庫鏈接 - 修改GitLab郵件服務(wù)配置，使用騰訊企業(yè)郵箱的SMTP服務(wù)器
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.exmail.qq.com"
gitlab_rails['smtp_port'] = 25
gitlab_rails['smtp_user_name'] = "xxx"
gitlab_rails['smtp_password'] = "xxx"
gitlab_rails['smtp_domain'] = "smtp.qq.com"
gitlab_rails['smtp_authentication'] = 'plain'
gitlab_rails['smtp_enable_starttls_auto'] = true
八、關(guān)于GitLab-CI
GitLab-CE 8.0以上的版本已經(jīng)將GitLab-CI集成進(jìn)了GitLab里面，并且是默認(rèn)開啟的。所以不需要像以前一樣再單獨(dú)安裝GitLab-CI并且為GitLab-CI開啟單獨(dú)的Server。如下圖所示：
