GitLab搭建以及配置（一）

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