Configuration options 参数配置
GitLab 的相关参数配置都存在 /etc/gitlab/gitlab.rb文件里。 浏览 查看安装包默认的参数。 浏览 查看所有可配置的项目。 自GitLab 7.6开始的新安装包, 已经默认将所有的参数写入到 /etc/gitlab/gitlab.rb 文件中.
Configuring the external URL for GitLab 配置域名访问
为使用户可以正确的获取到GitLab上显示的当前仓库的clone地址， GitLab需要你设置好哪个url才是用户可以访问到GitLab, 比如 http://gitlab.example.com。你需要编辑下面这个文件
/etc/gitlab/gitlab.rb:
external_url "http://gitlab.example.com" #替换为你自己的地址
运行 sudo gitlab-ctl reconfigure 使修改生效。
Configuring a relative URL for Gitlab 配置子路径访问(实验性)
注意: Relative URL(子路径)是在8.5版本被 Omnibus GitLab的, 该功能还处于测试阶段。 如果你使用源码安装的，这里有一篇独立介绍 的文档.
虽然我们建议GitLab使用二级域名访问, 但有时由于各种各样的原因， 我们想用子路径的方式访问GitLab。 出于这种需求，Gitlab 也可以安装到子路径, 如 https://example.com/gitlab.
需要注意的是，修改了这个URL后, 所有远程仓库地址要也做相应的修改, 所以你需要手动修改本地仓库中的remote url以使可以正常连接GitLab服务器。
Relative URL requirements 配置子路径访问的条件
自Omnibus 8.17 安装包开始,不再需要重新编译静态资源 Omnibus GitLab 一键包附带了预编译的资源(如CSS， JavaScript， fonts, 等等)。 如果你使用的是 8.17 之前的版本 并配置了GitLab使用relative URL， 这些资源文件就需要重新生成，而生成资源的过程需要消耗一部分CPU和内存资源。 为防止内存不足, 需要保证服务器至少有2GB的可用内存， 我们建议的服务器配置为4GB内存，4核或者8核CPU。
Enable relative URL in GitLab 启用子路径访问
请按照下面的步骤为GitLab启用relative URL:
-
(可选) 如果当前服务器可用资源不用，可用下面的命令暂时关闭 Unicorn 和 Sidekiq 释放一部分内存:
sudo gitlab-ctl stop unicornsudo gitlab-ctl stop sidekiq
-
修改
external_url，编辑/etc/gitlab/gitlab.rb:external_url "https://example.com/gitlab"
上面的例子将使GitLab的访问路径变成域名后面加
/gitlab，请将此处修改为你自己的地址。 -
Reconfigure GitLab 使修改生效:
sudo gitlab-ctl reconfigure
-
Restart the services so that Unicorn and Sidekiq picks up the changes
sudo gitlab-ctl restart
如上面的操作出现错误，请查阅章节。
Disable relative URL in GitLab 禁用子路径访问
禁用relative URL， 同样的也要修改 external_url ，改成不包含子路径的地址。 然后重启下Unicorn服务即可:
sudo gitlab-ctl restart unicorn
如上面的操作出现错误，请查阅章节。
Relative URL troubleshooting 使用子路径的故障排查
如果你配置子路径后,发现 gitlab 静态资源发生错误 (如图片丢失,资源响应长时间未响应), 请在的 issue 页面提交问题, 注意使用Frontend标签。
如你使用的是 8.17 之前的版本 并发现由于一些原因导致资源生成失败(比如服务器内存不足)， 你可以在解决这些问题后手动执行生成资源的任务(比如增加swap):
sudo NO_PRIVILEGE_DROP=true USE_DB=false gitlab-rake assets:clean assets:precompilesudo chown -R git:git /var/opt/gitlab/gitlab-rails/tmp/cache
上面的命令中的用户和组如果和你在gitlab.rb中设置的 user['username']， user['group'] ， gitlab_rails['dir'] 不一样， 执行该命令的时候注意修改chown 命令后面的git:git为配置文件里面的用户和组。
Loading external configuration file from non-root user 载入非超级用户的扩展配置
Omnibus-gitlab会加载 /etc/gitlab/gitlab.rb 文件中的所有配置项。 这个文件的属主为root，并且有严格的权限控制，这样做的原因是 执行 gitlab-ctl reconfigure的过程中要以root身份运行Ruby解析/etc/gitlab/gitlab.rb。 这就意味着拥有 /etc/gitlab/gitlab.rb写入权限的用户可以编辑配置项然后以root用户身份来执行解析。
在某些团队，可能会允许非root用户来修改gitlab的配置， 你可以在 /etc/gitlab/gitlab.rb 文件中引入外部扩展配置文件实现这个需求:
from_file "/home/admin/external_gitlab.rb"
使用from_file引入到 /etc/gitlab/gitlab.rb 的代码在sudo gitlab-ctl reconfigure的时候都会以 root 权限运行。 /etc/gitlab/gitlab.rb和from_file中重复的配置项，/etc/gitlab/gitlab.rb的优先级更高。
Storing Git data in an alternative directory 设置存储仓库数据的备用目录
默认情况下omnibus-gitlab 将仓库数据存储在 /var/opt/gitlab/git-data目录下，仓库存放在子目录 repositories里面。 以可以通过修改/etc/gitlab/gitlab.rb 的这一行来自定义 git-data 的父目录。
git_data_dirs({ "default" => { "path" => "/mnt/nas/git-data" } }) 自GitLab 8.10开始,可以通过在/etc/gitlab/gitlab.rb文件中添加下面的几行配置, 来增加多个git数据目录.
git_data_dirs({ "default" => { "path" => "/var/opt/gitlab/git-data" }, "alternative" => { "path" => "/mnt/nas/git-data" }}) 注意 目标路径和其子路径必须不能为软链接。
运行 sudo gitlab-ctl reconfigure 使修改生效。
如果 /var/opt/gitlab/git-data 目录已经存在Git仓库数据， 你可以用下面的命令把数据迁移到新的位置:
# 准备迁移之前要停止GitLab服务，防止用户写入数据。sudo gitlab-ctl stop# 注意 'repositories'后面不带斜杠，而# 'git-data'后面是有斜杠的。sudo rsync -av /var/opt/gitlab/git-data/repositories /mnt/nas/git-data/# 如果需要修复权限设置，# 可运行下面的命令进行修复。sudo gitlab-ctl reconfigure# 再次检查下 /mnt/nas/git-data的目录. 正常情况应该有下面这个子目录:# repositoriessudo ls /mnt/nas/git-data/# 完工! 启动GitLab，验证下是否能# 通过web访问Git仓库。sudo gitlab-ctl start
Changing the name of the Git user / group 修改默认的运行用户和组
默认情况下omnibus-gitLab使用git用户登陆Git gitlab-shell, Git data是属主也是git，网页上生成的SSH URL也是git用户。 同样的, git用户组也是Git data的属组。
我们不建议在已经安装好的gitlab上修改默认的user/group，因为这会产生无法预知的副作用。 如果你固执的想要修改默认的user/group，你可以在 /etc/gitlab/gitlab.rb文件中添加下面加行配置:
user['username'] = "gitlab"user['group'] = "gitlab"
运行 sudo gitlab-ctl reconfigure 使修改生效。
注意：如果你在已经安装好的GitLab中修改了user/group，reconfigure不会修改子目录的属主和属组，你需要手动修改， 并确认新用户可以读写 repositories 和 uploads 目录。
Specify numeric user and group identifiers 设置使用数字表示的用户和组
omnibus-gitlab 为GitLab, PostgreSQL, Redis 和 NGINX创建了运行用户。 你可以在 /etc/gitlab/gitlab.rb 文件中指定这些用户的uid和gid。
user['uid'] = 1234user['gid'] = 1234postgresql['uid'] = 1235postgresql['gid'] = 1235redis['uid'] = 1236redis['gid'] = 1236web_server['uid'] = 1237web_server['gid'] = 1237
运行 sudo gitlab-ctl reconfigure 使修改生效。
Disable user and group account management 禁用管理用户和组账户的功能
By default, omnibus-gitlab takes care of creating system user and group accounts as well as keeping the information updated. These system accounts run various components of the package. Most users do not need to change this behaviour. However, if your system accounts are managed by other software, eg. LDAP, you might need to disable account management done by the package.
为了禁用omnibus-gitlab管理用户和组账户，我们需要在/etc/gitlab/gitlab.rb中做如下设置：
manage_accounts['enable'] = false
警告 Omnibus-gitlab 建议在系统上保留omnibus-gitlab安装包创建的默认用户。
omnibus-gitlab 创建的默认用户如下：
# GitLab user (必需)git# Web server user (必需)gitlab-www# Redis user for GitLab (如使用内置的redis，该账号必需)gitlab-redis# Postgresql user (如使用内置的Postgresql，该账号必需)gitlab-psql# Prometheus user for prometheus monitoring and various exportersgitlab-prometheus# GitLab Mattermost user (only when using GitLab Mattermost)mattermost# GitLab Registry user (only when using GitLab Registry)registry
omnibus-gitlab 创建的默认组如下：
# GitLab group (必需)git# Web server group (必需)gitlab-www# Redis group for GitLab (如使用内置的Redis，该用户组必需)gitlab-redis# Postgresql group (如使用内置的Postgres，该用户组必需)gitlab-psql# Prometheus user for prometheus monitoring and various exportersgitlab-prometheus# GitLab Mattermost group (如使用内置的Mattermost，该用户组必需)mattermost# GitLab Registry group (only when using GitLab Registry)registry
你也可以自定义user/group ，但需要在/etc/gitlab/gitlab.rb配置文件中配置详细的user/group，如：
# 禁用管理user/group的功能manage_accounts['enable'] = false# GitLabuser['username'] = "custom-gitlab"user['group'] = "custom-gitlab"user['shell'] = "/bin/sh"user['home'] = "/var/opt/custom-gitlab"# Web serverweb_server['username'] = 'webserver-gitlab'web_server['group'] = 'webserver-gitlab'web_server['shell'] = '/bin/false'web_server['home'] = '/var/opt/gitlab/webserver'# Postgresql (如使用外部Postgresql，可忽略该配置)postgresql['username'] = "postgres-gitlab"postgresql['shell'] = "/bin/sh"postgresql['home'] = "/var/opt/postgres-gitlab"# Redis (如使用外部Redis，可忽略该配置)redis['username'] = "redis-gitlab"redis['shell'] = "/bin/false"redis['home'] = "/var/opt/redis-gitlab"# 以此类推,GitLab Mattermost 也需要指定详细的user/group
Disable storage directories management 禁用管理存储目录的功能
默认情况下，omnibus-gitlab负责创建所有必需的文件夹并赋予目录正确的所有权和权限， 并根据配置文件保持更新。
在某些大型组织架构中，随着项目代码和数量的增加，一些目录会存储大量的数据， 为扩展存储能力这些目录可能就需要挂载到NFS(或者其他共享存储)上。
挂载某些文件系统会拒绝root用户自动创建目录， 比如 NFS 需要启用 root_squash 。 要解决这个问题，omnibus-gitlab 会尝试使用该目录的属主用户来自动创建子目录。
如果你挂载了 /etc/gitlab 目录，你可以禁用omnibus-gitlab 对该目录的管理功能。
修改 /etc/gitlab/gitlab.rb :
manage_storage_directories['manage_etc'] = false
如果计划重新挂载GitLab所有存储目录到每个独立的挂载点上， 应该完全禁用omnibus-gitlab对各个存储目录的管理功能。
为禁止对所有存储目录的管理功能， 修改 /etc/gitlab/gitlab.rb :
manage_storage_directories['enable'] = false
Warning omnibus-gitlab 建议保留默认的目录。 如该选项已设置， 将有管理员创建目录并设置正确的权限。
启用此设置会阻止omnibus-gitlab创建如下目录：
| Default location | Permissions | Ownership | Purpose |
|---|---|---|---|
/var/opt/gitlab/git-data | 0700 | git:root | Holds repositories directory |
/var/opt/gitlab/git-data/repositories | 2770 | git:git | Holds git repositories |
/var/opt/gitlab/gitlab-rails/shared | 0751 | git:gitlab-www | Holds large object directories |
/var/opt/gitlab/gitlab-rails/shared/artifacts | 0700 | git:root | Holds CI artifacts |
/var/opt/gitlab/gitlab-rails/shared/lfs-objects | 0700 | git:root | Holds LFS objects |
/var/opt/gitlab/gitlab-rails/uploads | 0700 | git:root | Holds user attachments |
/var/opt/gitlab/gitlab-rails/shared/pages | 0750 | git:gitlab-www | Holds user pages |
/var/opt/gitlab/gitlab-ci/builds | 0700 | git:root | Holds CI build logs |
/var/opt/gitlab/.ssh | 0700 | git:git | Holds authorized keys |
Only start Omnibus-GitLab services after a given filesystem is mounted 设置延迟启动
为保证服务质量，我们可以设置让omnibus-gitlab的服务(Nginx, Redis, Unicorn等) 在指定的文件系统挂载成功后再启动，在/etc/gitlab/gitlab.rb 文件中添加如下内容：
# wait for /var/opt/gitlab to be mountedhigh_availability['mountpoint'] = '/var/opt/gitlab'
运行sudo gitlab-ctl reconfigure 使修改生效。
Configuring runtime directory 配置运行时目录
When Prometheus monitoring is enabled, GitLab-monitor will conduct measurements of each Unicorn process (Rails metrics). Every Unicorn process will need to write a metrics file to a temporary location for each controller request. Prometheus will then collect all these files and process their values.
In order to avoid creating disk I/O, the omnibus-gitlab package will use a runtime directory.
During reconfigure, package will check if /run is a tmpfs mount. If it is not, warning will be printed:
Runtime directory '/run' is not a tmpfs mount.
and Rails metrics will be disabled.
To enable Rails metrics again, create a tmpfs mount and specify it in /etc/gitlab/gitlab.rb:
runtime_dir '/path/to/tmpfs'
Please note that there is no = in the configuration.
Run sudo gitlab-ctl reconfigure for the settings to take effect.
Configuring Rack Attack 配置基础防护
为阻止恶意使用客户端破坏GitLab，我们使用了rack-attack gem包。 查阅 获取更多内容。
源码中的文件在omnibus-gitlab 中由/etc/gitlab/gitlab.rb管理。
Disabling automatic cache cleaning during installation 禁用安装过程中自动清理缓存
If you have large gitlab installation, you might not want to run rake cache:clean task. As it can take long time to finish. By default, cache clear task will run automatically during reconfigure.
Edit /etc/gitlab/gitlab.rb:
# This is advanced feature used by large gitlab deployments where loading# whole RAILS env takes a lot of time.gitlab_rails['rake_cache_clear'] = false
Don't forget to remove the # comment characters at the beginning of this line.
Enabling/Disabling Rack Attack and setting up basic auth throttling 启用禁用账户验证防护
修改下面的配置项控制Rack Attack:
gitlab_rails['rack_attack_git_basic_auth'] = { 'enabled' => true, # 启用/禁用 Rack Attack 'ip_whitelist' => ["127.0.0.1"], # 白名单地址，多个IP用","隔开 'maxretry' => 10, # 限制每个IP尝试登陆的次数为10次。 'findtime' => 60, # 60秒后重置每IP的授权计数器 'bantime' => 3600 # 对多次错误登陆的IP封禁1小时(3600秒)} Setting up paths to be protected by Rack Attack 设置访问路径防护
要修改默认的防护路径， 需在配置文件中设置gitlab_rails['rack_attack_protected_paths']区段。
Warning 此操作会覆盖 omnibus-gitlab 默认列表：
gitlab_rails['rack_attack_protected_paths'] = [ '/users/password', '/users/sign_in', '/api/#{API::API.version}/session.json', '/api/#{API::API.version}/session', '/users', '/users/confirmation', '/unsubscribes/', '/import/github/personal_access_token'] Note: 所有路径必须是 gitlab 的相对路径. 如启用了，上面的路径要做相应修改。
Warning 若要在路径中插入rails的变量， 如(#{API::API.version}),应避免用大括号和单引号字符串。 示例："/api/#\{API::API.version\}/session.json" 或者 '/api/#{API::API.version}/session.json'
Setting up throttling for 'paths to be protected' 设置路径防护的频率
用如下配置来控制频率和周期：
gitlab_rails['rate_limit_requests_per_period'] = 10 #限制每周期请求次数gitlab_rails['rate_limit_period'] = 60 #每周期的时长，60s
运行sudo gitlab-ctl reconfigure 使修改生效。
Setting up LDAP sign-in 配置使用LDAP登录
See .
Enable HTTPS 启用HTTPS
See .
Redirect HTTP requests to HTTPS. 强制 HTTP 跳转为 HTTPS
See .
Change the default port and the ssl certificate locations. 修改默认端口和SSL证书路径
See .
Use non-packaged web-server 使用外部 web-server
使用系统上已安装的Nginx, Passenger, or Apache webserver 请查阅 .
Using a non-packaged PostgreSQL database management server 使用外部的PostgreSQL数据库服务器
连接外部PostgreSQL or MySQL DBMS 请查阅 (Omnibus安装包只有Enterprise(企业版)支持Mysql).
Using a non-packaged Redis instance 使用外部 Redis 实例
See .
Adding ENV Vars to the GitLab Runtime Environment 添加系统变量到GitLab运行环境
See .
Changing GitLab.yml settings 自定义GitLab.yml设置
See .
Sending application email via SMTP 使用SMTP发送邮件
See .
Omniauth (Google, Twitter, GitHub login)
Omniauth configuration is documented in .
Adjusting Unicorn settings 调整 Unicorn 配置
See .
Setting the NGINX listen address or addresses 配置 NGINX 监听地址
See .
Inserting custom NGINX settings into the GitLab server block 在内置NGINX中插入自定义server块
See .
Inserting custom settings into the NGINX config 在内置NGINX中插入自定义设置
See .
Enable nginx_status 启用内置NGINX的nginx_status模块
See .