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 ......