GitLab.com settings

原文：https://docs.gitlab.com/ee/user/gitlab_com/

• SSH host keys fingerprints
• SSH known_hosts entries
• Mail configuration
• Backups
• Alternative SSH port
• GitLab Pages
• GitLab CI/CD
• Repository size limit
• IP range
• Maximum number of webhooks
• Shared Runners
  • Linux Shared Runners
    • Pre-clone script
    • config.toml
  • Windows Shared Runners (beta)
    • Configuration
    • Example
    • Limitations and known issues
• Sidekiq
• PostgreSQL
• Unicorn
• GitLab.com-specific rate limits
  • HAProxy API throttle
  • Rack Attack initializer
    • Protected paths throttle
    • Git and container registry failed authentication ban
  • Admin Area settings
  • Visibility settings
  • SSH maximum number of connections
  • Import/export
• GitLab.com Logging
• GitLab.com at scale
  • Elastic Cluster
  • Fluentd
  • Prometheus
  • Grafana
  • Sentry
  • Consul
  • HAProxy

GitLab.com settings

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

SSH host keys fingerprints

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

SSH known_hosts entries

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

gitlab.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf
gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsj2bNKTBSpIYDEGk9KxsGh3mySTRgMtXL583qmBpzeQ+jqCMRgBqB98u3z++J1sKlXHWfM9dyhSevkMwSbhoR8XIq/U0tCNyokEi/ueaBMCvbcTHhO7FcwzY92WK4Yt0aGROY5qX2UKSeOvuP4D6TPqKF1onrSzH9bx9XUf2lEdWT/ia1NEKjunUqu1xOB/StKDHMoX4/OKyIzuS0q/T1zOATthvasJFoPrAjkohTyaDUz2LN5JoH839hViyEG82yB+MjcFV5MU3N1l1QL3cVUCh93xSaua1N85qivl+siMkPGbO5xR/En4iEY6K2XPASUEMaieWVNTRCtJ4S8H+9
gitlab.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFSMqzJeV9rUzU4kWitGjeR4PWSa29SPqJ1fVkhtj3Hw9xjLVXVYrU9QlYWrOLXBpQ6KWjbjTDTdDkoohFzgbEY=

Mail configuration

GitLab.com 通过Mailgun从mg.gitlab.com域发送电子邮件，并拥有自己的专用 IP 地址（ 192.237.158.143 ）.

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

Backups

See our backup strategy.

Alternative SSH port

可以通过git+ssh的其他 SSH 端口访问 GitLab.com.

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

Host gitlab.com
  Hostname altssh.gitlab.com
  User git
  Port 443
  PreferredAuthentications publickey
  IdentityFile ~/.ssh/gitlab

GitLab Pages

以下是GitLab 页面的设置.

注意： Pages 站点的最大大小由GitLab CI / CD 中的工件最大大小决定.

GitLab CI/CD

以下是有关GitLab CI / CD的当前设置.

Repository size limit

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

如果您接近或超过存储库大小限制，则可以使用 Git 减小存储库大小 .

注意：每个请求通过 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 块（ IPv4和IPv6 ）.

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

Maximum number of webhooks

限制：

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

Shared Runners

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

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

Linux Shared Runners

Linux Shared Runners on GitLab.com run in autoscale mode 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 GitLab.com plans.

您的所有 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 小时后超时，无论项目中配置的超时时间如何. 检查问题4010和4070，以供参考.

以下是共享的”跑步者”设置.

Pre-clone script

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

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

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

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

config.toml

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

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

Google Cloud Platform

concurrent = X
check_interval = 1
metrics_server = "X"
sentry_dsn = "X"
[[runners]]
  name = "docker-auto-scale"
  request_concurrency = X
  url = "https://gitlab.com/"
  token = "SHARED_RUNNER_TOKEN"
  pre_clone_script = "eval \"$CI_PRE_CLONE_SCRIPT\""
  executor = "docker+machine"
  environment = [
    "DOCKER_DRIVER=overlay2",
    "DOCKER_TLS_CERTDIR="
  ]
  limit = X
  [runners.docker]
    image = "ruby:2.5"
    privileged = true
    volumes = [
      "/certs/client",
      "/dummy-sys-class-dmi-id:/sys/class/dmi/id:ro" # Make kaniko builds work on GCP.
    ]
  [runners.machine]
    IdleCount = 50
    IdleTime = 3600
    OffPeakPeriods = ["* * * * * sat,sun *"]
    OffPeakTimezone = "UTC"
    OffPeakIdleCount = 15
    OffPeakIdleTime = 3600
    MaxBuilds = 1 # For security reasons we delete the VM after job has finished so it's not reused.
    MachineName = "srm-%s"
    MachineDriver = "google"
    MachineOptions = [
      "google-project=PROJECT",
      "google-disk-size=25",
      "google-machine-type=n1-standard-1",
      "google-username=core",
      "google-tags=gitlab-com,srm",
      "google-use-internal-ip",
      "google-zone=us-east1-d",
      "engine-opt=mtu=1460", # Set MTU for container interface, for more information check https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3214#note_82892928
      "google-machine-image=PROJECT/global/images/IMAGE",
      "engine-opt=ipv6", # This will create IPv6 interfaces in the containers.
      "engine-opt=fixed-cidr-v6=fc00::/7",
      "google-operation-backoff-initial-interval=2" # Custom flag from forked docker-machine, for more information check https://github.com/docker/machine/pull/4600
    ]
  [runners.cache]
    Type = "gcs"
    Shared = true
    [runners.cache.gcs]
      CredentialsFile = "/path/to/file"
      BucketName = "bucket-name"

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

concurrent = X
check_interval = 3
[[runners]]
  name = "windows-runner"
  url = "https://gitlab.com/"
  token = "TOKEN"
  executor = "custom"
  builds_dir = "C:\\GitLab-Runner\\builds"
  cache_dir = "C:\\GitLab-Runner\\cache"
  shell  = "powershell"
  [runners.custom]
    config_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
    config_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "config"]
    prepare_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
    prepare_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "prepare"]
    run_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
    run_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "run"]
    cleanup_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
    cleanup_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "cleanup"]

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

Provider = "gcp"
Executor = "winrm"
OS = "windows"
LogLevel = "info"
LogFormat = "text"
LogFile = "C:\\GitLab-Runner\\autoscaler\\autoscaler.log"
VMTag = "windows"
[GCP]
  ServiceAccountFile = "PATH"
  Project = "some-project-df9323"
  Zone = "us-east1-c"
  MachineType = "n1-standard-2"
  Image = "IMAGE"
  DiskSize = 50
  DiskType = "pd-standard"
  Subnetwork = "default"
  Network = "default"
  Tags = ["TAGS"]
  Username = "gitlab_runner"
[WinRM]
  MaximumTimeout = 3600
  ExecutionMaxRetries = 0
[ProviderCache]
  Enabled = true
  Directory = "C:\\GitLab-Runner\\autoscaler\\machines"

Example

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

.shared_windows_runners:
  tags:
    - shared-windows
    - windows
    - windows-1809
stages:
  - build
  - test
before_script:
 - Set-Variable -Name "time" -Value (date -Format "%H:%m")
 - echo ${time}
 - echo "started by ${GITLAB_USER_NAME}"
build:
  extends:
    - .shared_windows_runners
  stage: build
  script:
    - echo "running scripts in the build job"
test:
  extends:
    - .shared_windows_runners
  stage: test
  script:
    - 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或services .
• 对于 Beta 版本，我们在基本 VM 映像中包含了一组软件包. 如果您的 CI 作业需要此列表中未包含的其他软件，那么您将需要在before_script或script添加安装命令以安装所需的软件. 请注意，每个作业都在新的 VM 实例上运行，因此需要为管道中的每个作业重复安装其他软件包.
• 作业在等待状态中的停留时间可能比 Linux 共享运行器更长.
• 我们有可能引入重大更改，这将需要更新使用 Windows Shared Runner 组件的管道.

Sidekiq

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

注意：在 Sidekiq 导入节点和 Sidekiq 导出节点上， SIDEKIQ_MEMORY_KILLER_MAX_RSS设置为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 特定设置（及其默认设置）的列表如下：

其中一些设置正在调整过程中. 例如， shared_buffers的值很高，因此我们正在考虑对其进行调整. 有关此特定更改的更多信息，请参见https://gitlab.com/gitlab-com/infrastructure/-/issues/1555 . 可以在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 地址将根据阻止类型自动释放，如下所述.

如果您对 GitLab.com 的所有请求均收到403 Forbidden错误，请检查是否有任何自动流程可能触发了阻止. 要获得帮助，请与GitLab 支持人员联系，以获取详细信息，例如受影响的 IP 地址.

HAProxy API throttle

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

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

RateLimit-Limit: 600
RateLimit-Observed: 6
RateLimit-Remaining: 594
RateLimit-Reset: 1563325137
RateLimit-ResetTime: Wed, 17 Jul 2019 00:58:57 GMT

Source:

• 在GitLab.com 的当前 HAProxy 设置中搜索rate_limit_http_rate_per_minute和rate_limit_sessions_per_second .

Rack Attack initializer

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

Protected paths throttle

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

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

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

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 速率限制设置.

Visibility settings

在 GitLab.com 上，自 GitLab 12.2（2019 年 7 月）起创建的项目，组和代码段在 GitLab.com 上禁用了内部可见性设置.

SSH maximum number of connections

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

Import/export

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

GitLab.com Logging

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

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

• A detailed list of what we’re logging
• Our current log retention policies
• A diagram of our logging infrastructure

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 作为我们的监控解决方案的一部分：

• gitlab-cookbooks / gitlab-elk · GitLab
• gitlab-cookbooks / gitlab_elasticsearch · GitLab

Fluentd

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

• gitlab-cookbooks / gitlab_fluentd · GitLab

Prometheus

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

• gitlab-cookbooks / gitlab-prometheus · GitLab

Grafana

为了可视化监视数据：

• gitlab-cookbooks / gitlab-grafana · GitLab

Sentry

开源错误跟踪：

• gitlab-cookbooks / gitlab-sentry · GitLab

Consul

服务发现：

• gitlab-cookbooks / gitlab_consul · GitLab

HAProxy

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

• gitlab-cookbooks / gitlab-haproxy · GitLab