Requirements

原文：https://docs.gitlab.com/ee/install/requirements.html

Requirements

该页面包含有关受支持的操作系统以及安装和使用 GitLab 所需的硬件要求的有用信息.

Operating Systems

Supported Linux distributions

  • Ubuntu（16.04 / 18.04）
  • Debian（8/9/10）
  • CentOS 的（6/7/8）
  • openSUSE（Leap 15.1 / Enterprise Server 12.2）
  • 红帽企业版 Linux（请使用 CentOS 软件包和说明）
  • 科学版 Linux（请使用 CentOS 软件包和说明）
  • Oracle Linux（请使用 CentOS 软件包和说明）

有关安装选项，请参见主要安装页面 .

Unsupported Linux distributions and Unix-like operating systems

  • Arch Linux
  • Fedora
  • FreeBSD
  • Gentoo
  • macOS

可以在这些操作系统上安装 GitLab，但不支持. 请参阅源安装指南和安装指南以获取更多信息.

Microsoft Windows

GitLab 是针对基于 Linux 的操作系统开发的. 它不能在 Microsoft Windows 上运行，并且我们没有计划在不久的将来支持它. 有关最新的开发状态，请查看此问题 . 请考虑使用虚拟机运行 GitLab.

Software requirements

Ruby versions

GitLab 需要 Ruby（MRI）2.6. 从 GitLab 12.2 开始，我们不再支持 Ruby 2.5 及更低版本.

您必须使用 Ruby 的标准 MRI 实现. 我们喜欢JRuby和Rubinius ，但是 GitLab 需要几个具有本机扩展的 Gems.

Go versions

所需的最低 Go 版本为 1.13.

Git versions

从 GitLab 13.1：

  • 需要 Git 2.25.x 及更高版本.
  • 建议使用 Git 2.27.x 及更高版本.

Node.js versions

从 GitLab 12.9 开始，我们仅支持 node.js 10.13.0 或更高版本，并且我们放弃了对 node.js 8 的支持.（在 GitLab 11.8 中取消了对 node.js 6 的支持）.

我们建议使用 Node 12.x，因为它速度更快.

GitLab 使用Webpack编译前端资产，这需要最低版本的 Node.js 10.13.0.

您可以使用node -v检查您正在运行哪个版本. 如果您运行的版本低于v10.13.0 ，则需要将其更新为较新的版本. 您可以在Node.js 网站上找到从社区维护的软件包安装或从源代码进行编译的说明 .

Redis versions

GitLab 需要 Redis 5.0+. 从 GitLab 13.0 开始，不支持较低版本.

Hardware requirements

Storage

所需的硬盘空间在很大程度上取决于要存储在 GitLab 中的存储库的大小，但是根据经验，您应该至少具有与所有存储库加起来一样大的可用空间.

如果您将来想灵活地增加硬盘驱动器空间，请考虑使用逻辑卷管理（LVM）进行安装，以便在需要时可以添加更多硬盘驱动器.

除本地硬盘驱动器外，您还可以安装支持网络文件系统（NFS）协议的卷. 该卷可能位于文件服务器，网络连接存储（NAS）设备，存储区域网络（SAN）或 Amazon Web Services（AWS）弹性块存储（EBS）卷上.

如果您有足够的 RAM 和最新的 CPU，则 GitLab 的速度主要受硬盘搜索时间限制. 具有快速驱动器（7200 RPM 及更高版本）或固态驱动器（SSD）将提高 GitLab 的响应速度.

注意：由于文件系统性能可能会影响 GitLab 的整体性能，因此我们不建议使用 AWS EFS 进行存储 .

CPU

CPU 需求取决于用户数量和预期的工作量. 您的确切需求可能更多，具体取决于您的工作量. 您的工作负载受以下因素影响，这些因素包括但不限于：用户的活跃程度，使用的自动化程度，镜像和回购/更改大小.

以下是一些示例 GitLab 用户库大小的建议最低 CPU 硬件指南.

  • 4 芯是核心的推荐最小数目和多达 500 个用户支持
  • 8 个内核最多支持 1000 个用户
  • 更多用户？ 查阅参考架构页面

Memory

内存需求取决于用户数量和预期的工作量. 您的确切需求可能更多，具体取决于您的工作量. 您的工作负载受以下因素影响，这些因素包括但不限于：用户的活跃程度，使用的自动化程度，镜像和回购/更改大小.

以下是一些示例 GitLab 用户库大小的建议最低内存硬件指南.

  • 4GB RAM是必需的最小内存大小，最多可支持 500 个用户
  • 8GB RAM 最多支持 1000 个用户
  • 更多用户？ 查阅参考架构页面

除上述之外，即使您当前有足够的可用 RAM，我们通常也建议在服务器上至少有 2GB 的交换空间. 如果您的可用内存发生更改，那么进行交换将有助于减少发生错误的机会. 我们还建议将内核的 swappiness 设置配置为较低的值（例如10以充分利用您的 RAM，同时在需要时仍可使用交换功能.

Database

PostgreSQL 是唯一受支持的数据库，与 Omnibus GitLab 软件包捆绑在一起. 您也可以使用外部 PostgreSQL 数据库 . 在 GitLab 12.1 中删除了对 MySQL 的支持. 建议在 MySQL / MariaDB 上使用 GitLab 的现有用户在升级之前迁移到 PostgreSQL .

PostgreSQL Requirements

运行 PostgreSQL 的服务器应至少有 5-10 GB 的可用存储空间，尽管确切的要求取决于用户数量 .

我们强烈建议用户使用下面指定的最低 PostgreSQL 版本，因为这些是用于开发和测试的版本.

GitLab 版本 最低 PostgreSQL 版本
10.0 9.6
12.10 11
13.0 11

您还必须确保将pg_trgm扩展加载到每个 GitLab 数据库中. 可以使用 PostgreSQL 超级用户启用此扩展.

在某些系统上，您可能需要安装一个附加软件包（例如postgresql-contrib ），此扩展才可以使用.

注意： 在 GitLab 13.0 中已删除了对PostgreSQL 9.6 和 10 的支持，因此 GitLab 可以从 PostgreSQL 11 的改进（例如分区）中受益. 有关过渡到 PostgreSQL 12 的时间表，请参阅相关的 epic .

Additional requirements for GitLab Geo

如果您使用的是GitLab Geo ：

  • 我们强烈建议您在积极开发和测试的情况下运行由 Omnibus 管理的实例. 我们的目标是与大多数外部数据库（不由 Omnibus 管理）兼容（例如， AWS Relational Database Service（RDS） ），但我们不保证兼容性.
  • 您还必须确保将postgres_fdw扩展加载到每个 GitLab 数据库中. 可以使用 PostgreSQL 超级用户启用此扩展.

Puma settings

建议的 Puma 设置取决于运行它的基础结构. Omnibus GitLab 默认为建议的 Puma 设置. 无论安装方法如何，都可以调整 Puma 设置.

如果您使用的是 Omnibus GitLab，请参阅Puma 设置以获取有关更改 Puma 设置的说明. 如果您使用的是 GitLab Helm 图表，请参阅Webservice 图表 .

Puma workers

推荐的工人人数是根据以下最高者计算得出的：

  • 2
  • CPU 核心数-1

例如，一个具有 4 个核心的节点应配置 3 个 Puma Worker.

如果可以提供足够的 CPU 和内存容量，则可以增加 Puma worker 的数量. 数量更多的 Puma 工作人员通常将有助于减少应用程序的响应时间并提高处理并行请求的能力. 您必须执行测试以验证基础架构的最佳设置.

Puma threads

推荐的线程数取决于几个因素，包括总内存和传统 Rugged 代码的使用 .

  • 如果操作系统最多具有 2 GB 的内存，则建议的线程数为1 . 较高的值将导致过多的交换，并降低性能.
  • If legacy Rugged code is in use, the recommended number of threads is 1.
  • 在所有其他情况下，建议的线程数为4 . 由于Ruby MRI 多线程的工作方式，我们不建议设置更高的值.

Unicorn Workers

对于大多数情况，我们建议使用：（CPU 内核* 1.5）+ 1 = Unicorn worker. 例如，一个具有 4 个核心的节点将有 7 个 Unicorn worker.

对于所有 2GB 以上的计算机，我们建议至少三名 Unicorn 工人. 如果您有一台 1GB 的计算机，我们建议仅配置两个 Unicorn worker，以防止过度交换.

只要您有足够的可用 CPU 和内存容量，就可以增加 Unicorn worker 的数量，这通常将有助于减少应用程序的响应时间并提高处理并行请求的能力.

要在拥有 Omnibus 软件包（默认为上述建议）时更改 Unicorn worker，请参阅Omnibus GitLab 文档中的 Unicorn 设置 .

Redis and Sidekiq

Redis 存储所有用户会话和后台任务队列. Redis 的存储要求极低，每个用户大约 25kB. Sidekiq 使用多线程进程来处理后台作业. 此过程从整个 Rails 堆栈（200MB +）开始，但是由于内存泄漏，它可能随着时间的推移而增长. 在非常活跃的服务器（10,000 个活跃用户）上，Sidekiq 进程可以使用 1GB +的内存.

Prometheus and its exporters

从 Omnibus GitLab 9.0 起，默认启用Prometheus及其相关出口商，以实现对 GitLab 的轻松和深度监控. 使用默认设置，这些进程将消耗大约 200MB 的内存.

如果您想禁用 Prometheus 及其出口商或阅读有关它的更多信息，请查阅Prometheus 文档 .

GitLab Runner

强烈建议不要在打算安装 GitLab 的同一台计算机上安装 GitLab Runner. 根据您决定配置 GitLab Runner 的方式以及用于在 CI 环境中运行应用程序的工具的不同，GitLab Runner 会消耗大量可用内存.

如果您决定在同一台计算机上运行 GitLab Runner 和 GitLab Rails 应用程序，则上面提供的内存消耗计算将无效.

由于安全原因 ，将所有内容都安装在一台机器上也不安全，尤其是当您计划将 Shell executor 与 GitLab Runner 一起使用时.

如果您打算使用 CI 功能，我们建议为每个 GitLab Runner 使用单独的机器. GitLab Runner 服务器要求取决于：

  • 您在 GitLab Runner 上配置的执行程序的类型.
  • 运行构建作业所需的资源.
  • 作业并发设置.

由于作业的性质因每个用例而异，因此您将需要通过调整作业并发来进行实验以获得最佳设置.

作为参考，对 GitLab.com 的自动缩放共享运行器进行了配置，以便单个作业将在单个实例中运行，并具有：

  • 1vCPU.
  • 3.75GB 的 RAM.

Supported web browsers

警告：在 GitLab 13.0（2020 年 5 月）中，我们删除了对 Internet Explorer 11 的官方支持.在 GitLab 13.4 发行版（2020 年 9 月）中，我们将删除了所有支持 Internet Explorer 11 的代码.您可以提供有关此问题的反馈，也可以通过通常的支持渠道.

GitLab supports the following web browsers:

对于列出的 Web 浏览器，GitLab 支持：

  • 当前和以前的主要浏览器版本（Internet Explorer 除外）.
  • 受支持的主要版本的当前次要版本.

注意：我们不支持在浏览器中禁用 JavaScript 的情况下运行 GitLab，并且将来也没有支持该计划的计划，因为我们具有诸如 Issue Boards 之类的功能，这些功能广泛需要 JavaScript.