一、系统环境
- 服务器：阿里云主机
- 操作系统：Centos7.0 64位
- 已装软件：Nginx（80端口）、Apache（8080端口）、PHP-FPM（9000端口）
二、安装版本
- GitLab分为社区版（GitLab Community Edition）和企业版（GitLab Enterprise Edition）。社区版免费，企业版收费，但是功能比社区版多。根据目前的需求，选择安装社区版（GitLab-CE）。
- 版本号：8.5.4
三、安装方式
以前试过源码安装，过程痛苦无比。此次选择官方提供的GitLab-CE Omnibus安装包。GitLab官网上有详细的安装说明，根据自己的操作系统选择相应的版本，按步骤操作即可。
https://about.gitlab.com/downloads
四、安装过程
由于国内阿里云主机无法连接国外的GitLab Yum源，所以只能从GitLab中文社区直接下载rpm包进行安装。
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中文社区：http://www.gitlab.cc
五、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会：
- 限制执行预定义好的Git命令（git push, git pull, git annex）
- 调用GitLab Rails API 检查权限
- 执行pre-receive钩子（在GitLab企业版中叫做Git钩子）
- 执行你请求的动作
- 处理GitLab的post-receive动作
- 处理自定义的post-receive动作
当通过http(s)访问GitLab Server时，工作流程取决于你是从Git仓库拉取(pull)代码还是向git仓库推送(push)代码。如果你是从Git仓库拉取(pull)代码，GitLab Rails应用会全权负责处理用户鉴权和执行Git命令的工作；如果你是向Git仓库推送(push)代码，GitLab Rails应用既不会进行用户鉴权也不会执行Git命令，它会把以下工作交由GitLab Shell进行处理：
- 调用GitLab Rails API 检查权限
- 执行pre-receive钩子（在GitLab企业版中叫做Git钩子）
- 执行你请求的动作
- 处理GitLab的post-receive动作
- 处理自定义的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 Shell这段话都是翻译官网的。链接在这里
https://gitlab.com/gitlab-org/gitlab-shell/blob/master/README.md
最后一段话有点拗口，我对此还是有一点问题的：既然你把
git push的逻辑都放在GitLab Shell里面了，为什么不把git pull的逻辑也都放在里面提供重用呢？
猜想：git pull这段逻辑无法重用，因为通过http(s)方式访问时，要读取仓库的数据并且把这些数据封装成http包返回给客户端；而通过ssh方式访问时，仓库代码数据是通过ssh数据包返回的。两种访问方式返回数据的封装方式不一样，所以也没有必要提供重用。但是我觉得读取仓库数据这段逻辑应该还是重用了的。
GitLab Workhorse
GitLab Workhorse是一个敏捷的反向代理。它会处理一些大的HTTP请求，比如文件上传、文件下载、Git push/pull和Git包下载。其它请求会反向代理到GitLab Rails应用，即反向代理给后端的unicorn。官网对GitLab Workhorse的介绍在这里：https://gitlab.com/gitlab-org/gitlab-workhorse/
六、GitLab工作流程
七、配置
配置考量
- 要求能通过子域名
git.zn2studio.com访问GitLab站点并且站点内的仓库地址也要用子域名显示。 - 要求使用腾讯企业邮箱的SMTP服务器发送邮件。
- 要求使用HTTP请求方式。
- 要求能使用SSH连接方式。
- 要求避免与已装软件的端口冲突
- 要求使用系统已安装的Nginx服务器
配置过程
- 修改GitLab配置文件，停用GitLab内置Nginx
nginx['enable'] = false - 使用系统已经安装的Nginx给gitlab-workhorse作反向代理
- 因为unicorn的默认端口是8080,与系统已存在的Apache端口冲突，修改Apache端口为8000（也可以修改unicorn的端口）
- 修改GitLab配置文件中的external_url
external_url 'http://git.zn2studio.com'
修改这个配置会影响GitLab里面显示的仓库链接 - 修改GitLab邮件服务配置，使用腾讯企业邮箱的SMTP服务器
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
八、关于GitLab-CI
GitLab-CE 8.0以上的版本已经将GitLab-CI集成进了GitLab里面，并且是默认开启的。所以不需要像以前一样再单独安装GitLab-CI并且为GitLab-CI开启单独的Server。如下图所示：
