从零开始搭建Gitlab服务器

从零开始搭建Gitlab服务器

Gitlab简介

最近感觉就是在不断的搭建/迁移版本服务器，而现在市面上关于版本服务器搭建的指南都流于表面，真正深入骨骼的少之又少，往往以偏概全很多关键点并未提及。而版本服务器的搭建往往是一个初创型或中小型公司迫切需要解决的问题。

目前市用户量和口碑较好的Git服务提供商，屈指可数。国外的话 GitHub，BitBucket 都是不错的选择，但国际形势变幻莫测，需要随时备好梯子。国内的话**Coding用户体验就做的很不错，很切合码农们的审美， 开源中国的码云**也有对应的代码托管服务，不过自从他们家Maven仓库镜像下架事件后已不推荐再用，不久后被阿里收购不是没有可能。

各个版本管理软件各有优劣，大多数的企业和团队为了隐私性的需要，选择了目前市面上功能和体验都十分给力的**Gitlab**作为非开源的代码管理平台。

Gitlab目前有两种不同的版本，社区/个人版和企业版
GitLab社区版是完全免费的，不但能建立免费的私有仓库而且没有数量上限，参与人员也没有数量限制，还能设置成员的权限，甚至细致到具体某条分支的权限，以及强大的工作流等等。完全满足我们日常开发、投产所需要的版本控制功能。
Gitlab企业版支持LDAP架构和对应功能，以达到更高的处理性能和存储效率，并提供其他更多模块和服务支持

参考链接：Gitlab社区版/企业版对比

安装前的准备

目前来说，Gitlab的发行版本并不是支持所有Linux/Unix内核版本，以下几种可能还是需要广大同学们通过其开源源码进行编译安装 。

• Arch Linux
• Fedora
• FreeBSD
• Gentoo
• macOS

除此之外，存储/CPU/内存分别影响到Gitlab所能运行的效率和能支持到的性能指标，为了不让开发童靴们在协作办公中怒砸键盘，官方给出的硬件建议可以结合公司和团队规模作为版本服务器硬件选型的重要参考。

CPU

按照CPU核心数量，官方建议大致有如下划分：

• 单核： 可以支持100个左右的用户并发，但是可能会有些许卡顿，毕竟所有的前后台处理都需要这个苦逼的核心一人包办。
• 双核： 约500并发用户，这也是官方给出的建议最低配置
• 4核： 约2,000并发用户
• 8核/16核： 约5,000/10,000并发用户
• 32核/64核： 官方给出数据中，核心数和用户数基本成线性增长了，但是实际使用中，发现其对CPU和内存占用明显过大，能维持在官方1/10的性能指标已经是不错的情况了，所以其应该存在一定的内存泄露

内存

官方建议的内存是最好不要低于4G，不然每次push和commit都会让你痛不欲生。8G内存就能很稳的支持1,000个并发数，所以至少选择8G以上的内存来搭建你的版本服务器。

Gitlab安装

基本构成

我们以CentOs 7.4举例，CentOs 7.x在防火墙等一系列组件上的安装配置和6.x稍微差异，请灵活搬砖。总的来说，完全正确的把Gitlab弄起来，大概包含以下操作和模块支持，跳过其中某几步安装成功并不代表操作步骤就完全正确；但是如果安装出现问题，可以回头详细来看看此处的描述，检查是否遗漏了某个基础模块/组件支持或者忘记了某些配置项。

• 基础操作系统(CentOs 7.4)和对应的包/依赖项
• Ruby
• Go
• 系统用户或分配用户(建议单独分配)
• 数据库(目前是postgresql)
• Redis
• Gitlab
• Web服务
• 防火墙安装、配置

不同的安装模式

1.傻瓜模式/Omnibus自动挡

GitLab官方提供了Omnibus安装包来安装，整合了大部分的套件（Nginx、ruby on rails、git、redis、postgresql等），让使用者不用额外安装这些软件，减轻了绝大部分安装量。
我们一般采用这种方式来安装，但自动挡所带来的隐患和冲突也会较多。特别是如果之前的服务器本来就不单纯，单独安装了nginx、redis之类的组件，再通过这种模式安装会产生一系列的冲突和配置问题，比如反向代理配置异常、服务访问不到等等，这个我们以后有时间再具体说。

参考链接：Gitlab Omnibus安装包

2.组件依赖模式/手动挡

2.1 安装依赖包并配置postfix邮件服务

 yum install curl openssh-server openssh-clients postfix > cronie
 service postfix start
 chkconfig postfix on

centos7使用systemctl命令

2.2 安装指定版本发行包

*下载并安装gitlab的yum源*

curl -sS http://packages.gitlab.cc/install/gitlab-ce/script.rpm.sh | sudo bash

 *自动安装最新版本*

yum install gitlab-ce

 *安装指定版本*

gitlab-ce-11.2.3-ce.0.el7.x86_64

3.纯手动模式/原始挡

当然，你也可以手动来安装Gitlab所需要的各类组件，结合其源码安装来达到同样的目的。当然，目前官方已经不再建议使用这种模式安装，身为Geek可以尝试一番刷刷成就感。这一步骤比较繁琐复杂，稍有不慎就可能会烧脑。
如果你打算使用这样的方式来安装的话，你可能需要做好多次失败重来的准备

参考链接：Gitlab源码编译安装

Gitlab常用命令

以上主要是详细描述了Gitlab从选型、安装都基本配置的过程，基本能满足一个项目团队协作平台的基础任务，以下为整理后的gitlab常用命令，能更有效的帮助运维人员来进行gitlab服务器的管理。

1.运维管理

查看版本

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

实时查看日志

 gitlab-ctl tail

数据库关系升级

 gitlab-rake db:migrate

清理redis缓存

gitlab-rake cache:clear

升级GitLab-ce 版本

yum update gitlab-ce

升级PostgreSQL最新版本

 gitlab-ctl pg-upgrade

2.服务控制命令

启动/停止/重启所有 gitlab 组件：

gitlab-ctl start/stop/restart

启动指定模块组件：

 gitlab-ctl start redis/postgresql/gitlab-workhorse/logrotate/nginx/sidekiq/unicorn

停止指定模块组件：

gitlab-ctl stop 模块名

查看服务状态

gitlab-ctl status

生成配置并启动服务

 gitlab-ctl reconfigure

3.日志相关

实时查看所有日志

 gitlab-ctl tail

实时各个模块日志

gitlab-ctl tail redis/postgresql/gitlab-workhorse/logrotate/nginx/sidekiq/unicorn

Gitlab配置

不管是通过上述三种方式之中的哪种安装，在Gitlab安装完成之后，我们是可以直接通过gitlab-ctl命令来启动gitlab服务的。

Gitlab服务构成

GitLab由主要由以下服务构成，他们共同承担了Gitlab的运作需要

nginx: 静态web服务器
gitlab-shell: 用于处理Git命令和修改authorized keys列表
gitlab-workhorse: 轻量级的反向代理服务器
logrotate：日志文件管理工具
postgresql：数据库
redis：缓存数据库
sidekiq：用于在后台执行队列任务（异步执行）
unicorn：HTTP服务，GitLab Rails应用是托管在这个服务器上面的。

主要配置文件目录

如果不是通过纯手工的方式安装，一般来说Gitlab的各个模块配置文件存放目录是固定的，手动编译安装出来的所有配置文件理论上会存放与手动置顶的编译安装目录。在日常的配置中，我们可以通过修改以下配置文件之中的参数来调节Gitlab的功能

主配置文件: /etc/gitlab/gitlab.rb
文档根目录: /opt/gitlab
默认存储库位置: /var/opt/gitlab/git-data/repositories
Nginx配置文件: /var/opt/gitlab/nginx/conf/gitlab-http.conf
Postgresql数据目录: /var/opt/gitlab/postgresql/data

一般来说我们的常规配置都可以通过修改/etc/gitlab/gitlab.rb这一配置文件来达到目的

基础配置/常见问题

1.默认管理员和密码

我们可以使用默认的管理员root来登录控制台，管理员首次登录时会要求我们重置登录密码。进入控制台之后，你可以重新修改密码。但这时你会发现GitLab管理员账号，缺省邮箱admin@example.com是个根本不存在的地址，所以无法通过邮箱重置密码。
这时，我们可以通过Gitlab服务器控制台命令来重新设置管理员或指定账户的登录密码。
切换到root用户，执行

gitlab-rails console production

等待控制台执行完毕，刷出等待输入界面之后，执行

[root@mail .ssh]# gitlab-rails console production
-------------------------------------------------------------------------------------
 GitLab:       11.2.3 (06cbee3)
 GitLab Shell: 8.1.1
 postgresql:   9.6.8
-------------------------------------------------------------------------------------
Loading production environment (Rails 4.2.10)
irb(main):001:0> user = User.where(id: 1).first
=> #<User id:1 @root>
irb(main):002:0>  user.password = '88888888'
=> "88888888"
irb(main):003:0> user.password_confirmation = '88888888'
=> "88888888"
irb(main):004:0> user.save!
Enqueued ActionMailer::DeliveryJob (Job ID: 56cdcd6c-0af6-43c5-9b04-642d7f94cd3d) to Sidekiq(mailers) with arguments: "DeviseMailer", "password_change", "deliver_now", gid://gitlab/User/1
=> true
irb(main):005:0> exit

这样我们就成功重置了管理员的登录密码，不过请慎用哦！

2.绑定域名/IP

在Gitlab启动之后，在不修改主配置的情况下，我们可以通过访问http://ip来通过浏览器访问Gitlab管理平台。一般来说我们直接通过这种方式已经能满足我们日常的版本管理需要，并不需要强制绑定域名。
但是在使用中，如果我们使用默认的配置来创建了一个项目，那么Gitlab会使用默认配置作为.git文件的版本地址，导致我们通过客户端clone时无法访问到对应的域名和真实的IP地址。

如我们暂时没有域名也不想解析，而单纯想使用服务器IP地址来作为git索引路径，那么我们可以修改配置文件/etc/gitlab/gitlab.rb之中的绑定域名

external_url '[http://gitlab.bjwf125.com'](http://gitlab.bjwf125.com')

这一行修改为服务器的对应IP地址(内网示例)

 external_url 'http://192.168.1.10'

再重新加载配置文件

 gitlab-ctl reconfigure

我们就可以看到项目中的地址已经变成了IP地址的索引，并且能被我们客户端正常访问了

3.使用SMTP来发送邮件通知

如果你不想用Gitlab服务器自带的postfix服务来发邮件，可以改用SMTP服务。同样是修改/etc/gitlab/gitlab.rb中的邮件服务配置，使用SMTP服务器来作为邮件通知的发送方

 gitlab_rails['smtp_address'] = "smtp.yourdomain.com"
 gitlab_rails['smtp_port'] = 25
 gitlab_rails['smtp_user_name'] = "xxx"
 gitlab_rails['smtp_password'] = "xxx"
 gitlab_rails['smtp_domain'] = "smtp.yourdomain.com" 
 gitlab_rails['smtp_authentication'] = 'plain'
 gitlab_rails['smtp_enable_starttls_auto'] = true

4.配置Gitlab访问方式为HTTPS

Gitlab安装后，默认是使用HTTP方式访问，若我们想使用更为安全的HTTPS方式，需要进行一些额外的设置

4.1 创建SSL证书存放目录

mkdir -p /etc/gitlab/ssl
chmod 0700 /etc/gitlab/ssl

通过Sftp等方式上传证书gitlab.xxx.com.crt，修改对应证书访问权限

 chmod 600 /etc/gitlab/ssl/gitlab.xxx.com.crt

4.2 修改主配置，支持SSL访问

仍然是修改/etc/gitlab/gitlab.rb主配置文件

 external_url "[https://gitlab.bjwf125.com](https://gitlab.bjwf125.com)"
nginx['redirect_http_to_https'] = true
 nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.xxx.com.crt"
 nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.xxx.com.key"

通过修改主配置并且gitlab-ctl reconfigure后，nginx服务的配置文件/var/opt/gitlab/nginx/conf/gitlab-http.conf会被自动修改为

 server {
 listen *:80;
 server_name gitlab.bjwf125.com;
 server_tokens off; ## Don't show the nginx version number, a security best practice
 return 301 [https://gitlab.xxx.com:443$request_uri](https://gitlab.bjwf125.com:443%24request_uri);
 access_log /var/log/gitlab/nginx/gitlab_access.log gitlab_access;
 error_log /var/log/gitlab/nginx/gitlab_error.log;
 }

已经支持了HTTPS的访问和解析

4.3 开启防火墙

接下来，我们需要开启服务器的443端口，以允许HTTPS访问。

centos 7.x

 firewall-cmd --zone=public --add-port=443/tcp --permanent

至此，我们的Gitlab已经支持了HTTPS方式的访问

备份/恢复

1.备份

gitLab备份的默认目录是/var/opt/gitlab/backups，若想要主动执行备份操作，可以通过

 gitlab-rake gitlab:backup:create

命令会在备份目录下创建一个以时间戳开头的xxxxxxxx_gitlab_backup.tar的压缩包，这个压缩包包括整个完整的gitlab。

若需要修改默认的备份目录，可以通过修改/etc/gitlab/gitlab.rb主配置文件来设置

 gitlab_rails['backup_path'] = '/data/backups'

2.恢复

指定恢复文件，gitlab会自动去查找备份目录。
指定文件名的格式类似：1535861590_2018_09_02_11.2.3，文件名后缀_gitlab_backup.tar不需要添加”

gitlab-rake gitlab:backup:restore BACKUP=1535861590_2018_09_02_11.2.3