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-clientssudo systemctl enable sshdsudo systemctl start sshdsudo yum install postfixsudo systemctl enable postfixsudo systemctl start postfixsudo firewall-cmd --permanent --add-service=httpsudo systemctl reload firewalldcurl -LJO https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-XXX.rpmrpm -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 ......