GitLab.com settings

GitLab.com settings

在此页面中,您将找到有关GitLab.com上使用的设置的信息.

以下是 GitLab.com 的 SSH 主机密钥的指纹. 首次连接到 GitLab.com 存储库时,您将在输出中看到这些键之一.

SSH known_hosts entries

将以下内容添加到.ssh/known_hosts以跳过 SSH 中的手动指纹确认:

Mail configuration

GitLab.com 通过从mg.gitlab.com域发送电子邮件,并拥有自己的专用 IP 地址( 192.237.158.143 ).

注意: mg.gitlab.com的 IP 地址可能随时更改.

Backups

.

Alternative SSH port

可以通过git+ssh的访问 GitLab.com.

Setting Value
Hostname altssh.gitlab.com
Port 443

以下是~/.ssh/config的示例:

  1. Host gitlab.com
  2. Hostname altssh.gitlab.com
  3. User git
  4. Port 443
  5. PreferredAuthentications publickey
  6. IdentityFile ~/.ssh/gitlab

以下是GitLab 页面的设置.

注意: Pages 站点的最大大小由的工件最大大小决定.

GitLab CI/CD

以下是有关的当前设置.

Setting GitLab.com Default
工件最大尺寸(未压缩) 1G 100M
Artifacts expiry time 从 2020 年 6 月 22 日开始,除非另有说明,否则在 30 天后删除(该日期之前创建的工件没有过期). 除非另有说明,否则 30 天后删除
预定管道计划 */5 * * * * 19 * * * *
免费套餐为500 ,否则为无限制 Unlimited
Max pipeline schedules in projects 免费套餐10 50 ,所有付费套餐50 Unlimited
25 25
Scheduled Job Archival 3 个月 Never

Repository size limit

GitLab.com 已启用以下帐户限制 . 如果未列出设置,则将其设置为默认值.

如果您接近或超过存储库大小限制,则可以 .

注意:每个请求通过 Cloudflare 的git push和 GitLab 项目导入限制为 5 GB. Git LFS 和文件上传以外的导入不受此限制的影响.

IP range

GitLab.com 将 IP 范围34.74.90.64/28用于其 Web / API 34.74.90.64/28的流量. 这整个范围仅分配给 GitLab. 您可以期望来自 Webhooks 或存储库镜像的连接来自这些 IP 并允许它们.

GitLab.com 由 Cloudflare 领导. 对于与 GitLab.com 的传入连接,您可能需要允许 Cloudflare 的 CIDR 块( 和IPv6 ).

对于 CI / CD 运行程序的传出连接,我们不提供静态 IP 地址. 我们所有的运行程序都已部署到 Google Cloud Platform(GCP)中-通过查找所有IP 地址范围或 CIDR 块,可以配置任何基于 IP 的防火墙.

Maximum number of webhooks

限制:

  • 100 个 webhooks 适用于项目.
  • 50 个 webhooks 适用于组.

GitLab 提供在 GitLab.com 上托管的 Linux 和 Windows 共享运行程序,用于执行管道.

注意: GitLab 提供的共享运行器不可配置. 如果您有特定的配置需求,请考虑安装自己的 Runner .

Linux Shared Runners on GitLab.com run in and are powered by Google Cloud Platform. Autoscaling means reduced waiting times to spin up CI/CD jobs, and isolated VMs for each project, thus maximizing security. They’re free to use for public open source projects and limited to 2000 CI minutes per month per group for private projects. More minutes can be purchased, if needed. Read about all .

您的所有 CI / CD 作业都在具有 3.75GB RAM,CoreOS 和最新 Docker Engine 的n1-standard-1 实例上运行. 实例提供 1 个 vCPU 和 25GB 的 HDD 磁盘空间. VM 的默认区域是 US East1. 每个实例仅用于一项作业,这确保了其他人无法访问其 CI 作业访问系统上剩余的任何敏感数据.

gitlab-shared-runners-manager-X.gitlab.com专用于 GitLab 项目以及它们的社区分支. 它们使用稍大的计算机类型(n1-standard-2),并且具有更大的 SSD 磁盘大小. 它们将不会运行未加标签的作业,并且与共享赛跑者的一般团队不同,这些实例最多可重复使用 40 次.

由 GitLab.com( shared-runners-manager-X.gitlab.com )上的共享 Runner 处理的作业将在 3 小时后超时,无论项目中配置的超时时间如何. 检查问题和4070,以供参考.

Setting GitLab.com Default
Runner versions dashboard -
Executor docker+machine -
默认 Docker 映像 ruby:2.5 -
privileged (run ) true false

Pre-clone script

在 Runner 尝试运行git initgit fetch下载 GitLab 存储库之前,GitLab.com 上的 Linux Shared Runner 提供了一种在 CI 作业中运行命令的方法. 可用于:

  • 用存储库数据播种构建目录
  • 向服务器发送请求
  • 从 CDN 下载资产
  • git init之前必须运行的任何其他命令

要使用此功能,请定义一个包含 bash 脚本的CI / CD 变量 CI_PRE_CLONE_SCRIPT .

演示了如何使用预克隆步骤为构建目录添加种子.

config.toml

我们的config.toml的完整内容是:

注意:非公开的设置显示为X

Google Cloud Platform

Windows Shared Runners (beta)

Windows Shared Runners 当前处于beta 中 ,不应用于生产工作负载.

在测试版期间, 将以与 Linux Runners 相同的方式应用于组和项目. 如本相关问题所述 ,当 beta 时期结束时,这可能会改变.

通过在 Google Cloud Platform 上启动虚拟机,GitLab.com 上的 Windows Shared Runners 可以自动自动缩放. 此解决方案使用 GitLab 为 程序开发的新 . Windows 共享运行程序在具有 2 个 vCPU 和 7.5GB RAM 的n1-standard-2实例上执行 CI / CD 作业. 您可以在软件包文档中找到可用的 Windows 软件包的完整列表.

我们希望不断进行迭代,以使 Windows Shared Runners 处于稳定状态并 . 您可以在相关的史诗中按照我们的工作朝着这个目标迈进.

Configuration

The full contents of our config.toml are:

注意:非公开的设置显示为X

  1. concurrent = X
  2. check_interval = 3
  3. [[runners]]
  4. url = "https://gitlab.com/"
  5. token = "TOKEN"
  6. executor = "custom"
  7. builds_dir = "C:\\GitLab-Runner\\builds"
  8. cache_dir = "C:\\GitLab-Runner\\cache"
  9. shell = "powershell"
  10. [runners.custom]
  11. config_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
  12. config_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "config"]
  13. prepare_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
  14. prepare_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "prepare"]
  15. run_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
  16. run_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "run"]
  17. cleanup_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
  18. cleanup_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "cleanup"]

我们的autoscaler/config.toml的完整内容是:

Example

下面是一个简单的.gitlab-ci.yml文件,以显示如何开始使用 Windows Shared Runners:

  1. tags:
  2. - shared-windows
  3. - windows
  4. - windows-1809
  5. stages:
  6. - build
  7. - test
  8. before_script:
  9. - Set-Variable -Name "time" -Value (date -Format "%H:%m")
  10. - echo ${time}
  11. - echo "started by ${GITLAB_USER_NAME}"
  12. build:
  13. extends:
  14. - .shared_windows_runners
  15. stage: build
  16. script:
  17. - echo "running scripts in the build job"
  18. test:
  19. extends:
  20. - .shared_windows_runners
  21. stage: test
  22. script:
  23. - echo "running scripts in the test job"

Limitations and known issues

  • Beta 定义中提到的所有限制.
  • 新 Windows VM 的平均配置时间为 5 分钟. 这意味着在测试期间,您可能会注意到 Windows Shared Runner 机群上的构建开始时间变慢. 在将来的版本中,我们将更新自动缩放器以启用虚拟机的预配置. 这将大大减少在 Windows 机群上配置 VM 所花费的时间. 您可以按照 .
  • Windows Shared Runner 舰队可能偶尔不可用进行维护或更新.
  • Windows Shared Runner 虚拟机实例不使用 GitLab Docker 执行器. 这意味着您将无法在管道配置中指定image或 .
  • 对于 Beta 版本,我们在基本 VM 映像中包含了一组软件包. 如果您的 CI 作业需要此列表中未包含的其他软件,那么您将需要在before_script或添加安装命令以安装所需的软件. 请注意,每个作业都在新的 VM 实例上运行,因此需要为管道中的每个作业重复安装其他软件包.
  • 作业在等待状态中的停留时间可能比 Linux 共享运行器更长.
  • 我们有可能引入重大更改,这将需要更新使用 Windows Shared Runner 组件的管道.

Sidekiq

GitLab.com 使用参数--timeout=4 --concurrency=4和以下环境变量运行 :

注意:在 Sidekiq 导入节点和 Sidekiq 导出节点上, 设置为16000000 .

PostgreSQL

GitLab.com being a fairly large installation of GitLab means we have changed various PostgreSQL settings to better suit our needs. For example, we use streaming replication and servers in hot-standby mode to balance queries across different database servers.

GitLab.com 特定设置(及其默认设置)的列表如下:

Setting GitLab.com Default
archive_command /usr/bin/envdir /etc/wal-e.d/env /opt/wal-e/bin/wal-e wal-push %p empty
archive_mode on off
autovacuum_analyze_scale_factor 0.01 0.01
autovacuum_max_workers 6 3
autovacuum_vacuum_cost_limit 1000 -1
autovacuum_vacuum_scale_factor 0.01 0.02
checkpoint_completion_target 0.7 0.9
checkpoint_segments 32 10
effective_cache_size 338688MB 基于可用内存量
hot_standby on off
hot_standby_feedback on off
log_autovacuum_min_duration 0 -1
log_checkpoints on off
log_line_prefix %t [%p]: [%l-1] empty
log_min_duration_statement 1000 -1
log_temp_files 0 -1
maintenance_work_mem 2048MB 16 兆字节
max_replication_slots 5 0
max_wal_senders 32 0
max_wal_size 5GB 1GB
shared_buffers 112896MB 基于可用内存量
shared_preload_libraries pg_stat_statements empty
shmall 30146560 基于服务器的功能
shmmax 123480309760 基于服务器的功能
wal_buffers 16MB -1
wal_keep_segments 512 10
wal_level replica minimal
statement_timeout 15s 60s
idle_in_transaction_session_timeout 60s 60s

其中一些设置正在调整过程中. 例如, shared_buffers的值很高,因此我们正在考虑对其进行调整. 有关此特定更改的更多信息,请参见 . 可以在https://gitlab.com/gitlab-com/infrastructure/-/issues?scope=all&utf8=✓&state=opened&label_name[]=database&label_name[]=change找到最新的建议更改列表.

Unicorn

GitLab.com 调整了独角兽杀手级宝石的内存限制.

基本默认值:

  • memory_limit_min = 750MiB
  • memory_limit_max = 1024MiB

Web 前端:

  • memory_limit_min = 1024MiB
  • memory_limit_max = 1280MiB

GitLab.com-specific rate limits

注意:有关管理员文档,请参阅速率限制 .

当 GitLab.com 从单个 IP 地址接收到异常流量时,通常会发生 IP 阻止,系统根据速率限制设置将其视为潜在恶意软件. 在异常流量停止后,IP 地址将根据阻止类型自动释放,如下所述.

HAProxy API throttle

对于每个 IP 地址每秒超过 10 个请求的 API 请求,GitLab.com 会以 HTTP 状态代码429进行响应.

所有 API 请求均包含以下示例标头:

Source:

Rack Attack initializer

机架攻击实施的速率限制的详细信息.

Protected paths throttle

GitLab.com 以 HTTP 状态代码429响应在每个 IP 地址每分钟超过 10 个请求的受保护路径上的 POST 请求.

请参阅下面的源,了解哪些路径受保护. 这包括用户创建,用户确认,用户登录和密码重置.

此标头包含在对阻止的请求的响应中:

  1. Retry-After: 60

有关更多详细信息,请参见受保护的路径 .

Git and container registry failed authentication ban

如果在 3 分钟内从一个 IP 地址收到 30 个失败的身份验证请求,则 GitLab.com 会以 HTTP 状态代码403响应 1 小时.

这仅适用于 Git 请求和容器注册表( /jwt/auth )请求(组合).

此限制:

  • 由成功认证的请求重置. 例如,29 个失败的身份验证请求后跟 1 个成功的请求,然后再有 29 个失败的身份验证请求不会触发禁止.
  • 不适用于gitlab-ci-token认证的 JWT 请求.

没有提供响应头.

Admin Area settings

GitLab.com:

  • 设置为默认值.
  • 没有启用用户和 IP 速率限制设置.

在 GitLab.com 上,自 GitLab 12.2(2019 年 7 月)起创建的项目,组和代码段在 GitLab.com 上禁用了设置.

SSH maximum number of connections

GitLab.com 通过使用来定义并发,未经身份验证的 SSH 连接的最大数量. 如果同时发生的连接数超过了允许的最大连接数,则会将其丢弃,并且用户会收到 .

Import/export

为了避免滥用,对项目和组的导入,导出和导出下载进行了速率限制. 有关详细信息,请参见和组导入/导出速率限制 .

我们使用解析日志. Fluentd 将我们的日志发送到 Stackdriver Logging和 . Stackdriver 用于将日志长期存储在 Google Cold Storage(GCS)中. Cloud Pub / Sub 用于使用pubsubbeat将日志转发到 .

您可以在我们的运行手册中查看更多信息,例如:

GitLab.com at scale

In addition to the GitLab Enterprise Edition Omnibus install, GitLab.com uses the following applications and settings to achieve scale. All settings are publicly available at chef cookbooks.

Elastic Cluster

我们使用 Elasticsearch 和 Kibana 作为我们的监控解决方案的一部分:

Fluentd

我们使用 Fluentd 统一我们的 GitLab 日志:

Prometheus 完成了我们的监视堆栈:

Grafana

为了可视化监视数据:

Sentry

开源错误跟踪:

Consul

HAProxy

高性能 TCP / HTTP 负载均衡器: