0.名詞解釋
git 是一種版本控制系統，是一個命令，是一種工具
gitlib 是用於實現git功能的開發庫
github 是一個基於git實現的在線代碼託管倉庫，包含一個網站界面，向互聯網開放
gitlab 是一個基於git實現的在線代碼倉庫託管軟件，你可以用gitlab自己搭建一個類似於github一樣的系統，一般用於在企業、學校等內部網絡搭建git私服
1.硬件需求
1.1 存儲
存儲空間的大小主要取決於你將存儲的Git倉庫的大小。但根據 rule of thumb(經驗法則) 你應該考慮多留一些空間用來存儲Git倉庫的備份。
如果你想使用彈性的存儲空間，你可以考慮在分配分區的時候使用LVM架構，這樣可以在後期需要的清空下添加硬盤在增加存儲空間。
除此之外你還可以掛在一個支持NFS的分卷，比如NAS、 SAN、AWS、EBS。
如果你的服務器有足夠大的內存和CPU處理性能，GitLab的響應速度主要受限於硬盤的尋道時間。 使用更快的硬盤(7200轉)或者SSD硬盤會很大程度的提升GitLab的響應速度。
1.2 CPU
1 核心CPU最多支持100個用戶，所有的workers和後臺任務都在同一個核心工作這將導致GitLab服務響應會有點緩慢。
2核心 支持500用戶，這也是官方推薦的最低標準。
4 核心支持2,000用戶。
8 核心支持5,000用戶。
16 核心支持10,000用戶。
32 核心支持20,000用戶。
64 核心支持40,000用戶。
1.3 Memory
安裝使用GitLab需要至少4GB可用內存(RAM + Swap)! 由於操作系統和其他正在運行的應用也會使用內存, 所以安裝GitLab前一定要注意當前服務器至少有4GB的可用內存. 少於4GB內存會導致在reconfigure的時候出現各種詭異的問題, 而且在使用過程中也經常會出現500錯誤.
1GB 物理內存 + 3GB 交換分區 是最低的要求，但我們 強烈反對 使用這樣的配置。
2GB 物理內存 + 2GB 交換分區 支持100用戶，但服務響應會很慢。
4GB 物理內存 支持100用戶，也是 官方推薦 的配置。
8GB 物理內存 支持 1,000 用戶。
16GB 物理內存 支持 2,000 用戶。
32GB 物理內存 支持 4,000 用戶。
64GB 物理內存 支持 8,000 用戶。
128GB 物理內存 支持 16,000 用戶。
256GB 物理內存 支持 32,000 用戶。
即使你服務器有足夠多的RAM， 也要給服務器至少分配2GB的交換分區。 因爲使用交換分區可以在你的可用內存波動的時候降低GitLab出錯的機率。
注意: Sidekiq的25個workers在查看進程(top或者htop)的時候會發現它會單獨顯示每個worker，但是它們是共享內存分配的，這是因爲Sidekiq是一個多線程的程序。
2. 安裝並配置必要的依賴關係
如果你想使用 Postfix 發送郵件，請在安裝過程中根據提示選擇 'Internet Site'。 你也可以用 Sendmail 或者配置一個自定義的 SMTP服務, 並把它作爲一個 SMTP 服務器。
在 CentOS 系統上，下面的命令將會打開系統防火牆 HTTP 和 SSH 的訪問。
sudo yum install curl policycoreutils openssh-server openssh-clients sudo systemctl enable sshd sudo systemctl start sshd sudo yum install postfix sudo systemctl enable postfix sudo systemctl start postfix sudo firewall-cmd --permanent --add-service=http sudo systemctl reload firewalld curl -LJO https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-XXX.rpm rpm -i gitlab-ce-XXX.rpm
3. 配置並啓動GitLab
gitlab-ctl reconfigure
4. GitLab服務構成
GitLab由以下服務構成：
nginx：靜態Web服務器
gitlab-shell：用於處理Git命令和修改authorized keys列表
gitlab-workhorse:輕量級的反向代理服務器
logrotate：日誌文件管理工具
postgresql：數據庫
redis：緩存數據庫
sidekiq：用於在後臺執行隊列任務（異步執行）
unicorn：An HTTP server for Rack applications，GitLab Rails應用是託管在這個服務器上面的。
主要介紹gitlab-shell和gitlab-workhorse兩項：
gitlab-shell：
GitLab Shell有兩個作用：爲GitLab處理Git命令、修改authorized keys列表。
當通過SSH訪問GitLab Server時，GitLab Shell會：
1.限制執行預定義好的Git命令（git push, git pull, git annex）
2.調用GitLab Rails API 檢查權限
3.執行pre-receive鉤子（在GitLab企業版中叫做Git鉤子）
4.執行你請求的動作
5.處理GitLab的post-receive動作
6.處理自定義的post-receive動作
當通過http(s)訪問GitLab Server時，工作流程取決於你是從Git倉庫拉取(pull)代碼還是向git倉庫推送(push)代碼。如果你是從Git倉庫拉取(pull)代碼，GitLab Rails應用會全權負責處理用戶鑑權和執行Git命令的工作；如果你是向Git倉庫推送(push)代碼，GitLab Rails應用既不會進行用戶鑑權也不會執行Git命令，它會把以下工作交由GitLab Shell進行處理：
1.調用GitLab Rails API 檢查權限
2.執行pre-receive鉤子（在GitLab企業版中叫做Git鉤子）
3.執行你請求的動作
4.處理GitLab的post-receive動作
5.處理自定義的post-receive動作
也許你會奇怪在通過http(s)推送(push)代碼的情況下，GitLab Rails應用爲什麼不在GitLab Shell之前進行鑑權。這是因爲GitLab Rails應用沒有解析git push命令的邏輯。好的方法是將這些解析代碼放在一個地方，這個地方就是GitLab Shell，這樣我們就可以在通過SSH進行訪問時重用這段代碼。實際上，GitLabShell在執行git push命令時根本不會進行權限檢查，它是依賴於pre-receive鉤子進行權限檢查的。而當你執行git pull命令時，權限檢查是在命令執行之前的。對git pull命令的權限檢查要簡單得多，因爲你只需要檢查一個用戶是否可以訪問這個倉庫就可以了（不需要檢查分支權限）
gitlab-workhorse：
GitLab Workhorse是一個敏捷的反向代理。它會處理一些大的HTTP請求，比如文件上傳、文件下載、Git push/pull和Git包下載。其它請求會反向代理到GitLab Rails應用，即反向代理給後端的unicorn。官網對GitLab Workhorse的介紹在這裏：https://gitlab.com/gitlab-org/gitlab-workhorse/
5、說明
缺點：這種方式雖然說簡單方便，但是定製型很差，默認只能使用postgre和nginx
主配置文件：/etc/gitlab/gitlab.rb //可以自定義一些郵件服務等
日誌地址：/var/log/gitlab/ // 對應各服務
服務地址：/var/opt/gitlab/ // 對應各服務的主目錄
倉庫地址：/var/opt/gitlab/git-data //記錄項目倉庫等提交信息
重置配置：gitlab-ctl reconfigure //不要亂用，會重置爲最原始的配置的
重啓服務：gitlab-ctl stop/start/restart //啓動命令
默認安裝：postgres、nginx、redis、unicorn ......