• 选择配置项
  • Secrets
  • 网络和 DNS
    • external-dns 动态 IP
    • 固定 IP
  • 持久化
  • TLS 证书
  • PostgreSQL
  • Redis
  • MinIO
  • Prometheus
    • 配置 Prometheus 抓取启用了 TLS 的端点
    • 导出器端点
  • 外发电子邮件
  • 接收电子邮件
  • 服务台电子邮件
  • RBAC
  • CPU and 内存资源需求
• 使用 Helm 部署
• 监控部署
• 首次登录

部署指导

在执行 helm install 之前，您需要就如何运行极狐GitLab 做出一些决定。使用 Helm 的 --set option.name=value 命令行选项可以指定选项值。参考完整的 命令行选项列表。本指南将涵盖所需的值和常用选项。

选择配置项

在每个部分中，将与 helm install 结合使用的配置项。

Secrets

一些 Secrets 需要被创建（例如 SSH keys）。默认情况下会自动生成，但是如果您想要对它们进行自定义配置，您可以遵循 secrets 指导。

网络和 DNS

默认情况下，chart 依赖于 Kubernetes 中具有 type: LoadBalancer 的Service 对象，使用配置了 Ingress 对象的基于名称的虚拟服务器，来对外暴露极狐GitLab 服务。您需要指定一个域名，包含将 gitlab、registry 和 minio（如果已启用）解析为 chart IP 的记录。

在您的 Helm 安装命令行中包含以下选项：

--set global.hosts.domain=example.com

举个例子：

启用自定义域名支持后，*.<pages domain> 子域，默认为 <pages domain>，变为 pages <global.hosts.domain>，需要解析到分配给 Pages 的外部 IP（通过 --set global.pages.externalHttp 或 --set global.pages.externalHttps）。要使用自定义域名，GitLab Pages 可以使用 CNAME 记录将自定义域名指向相应的 <namespace>.<pages domain> 域名。

external-dns 动态 IP

如果您计划使用自动 DNS 注册服务，例如 external-dns，您不需要对极狐GitLab 进行额外配置，但您需要在集群中部署。如果您选择了 external-dns，项目页面会为每个支持的提供商显示完整指导。

如果您使用仓库中的脚本配置了 GKE 集群，external-dns 已在您的集群中安装。

固定 IP

如果您计划手动配置 DNS 记录，他们应全部指向一个固定 IP。例如您拥有 example.com 和固定 IP 10.10.10.10，则 gitlab.example.com, registry.example.com 和 minio.example.com （如果使用 MinIO）应全部解析到 10.10.10.10。

如果您使用 GKE，配置固定 IP 和 DNS。在配置过程中，请查阅云提供商和 DNS 提供商的文档获取更多帮助。

在 Helm 安装命令行中包含以下选项：

--set global.hosts.externalIP=10.10.10.10

持久化

默认情况下，chart 将创建 Volume Claims，预期存在动态 provisioner 提供底层持久卷。如果您想自定义 storageClass 或手动创建挂载 volumes，请查看存储文档。

重要提示: 在首次安装后，更改存储设置需要手动编辑 Kubernetes 对象，所以最佳方式是在安装生产实例之前，预先做好计划以避免额外的存储迁移工作。

TLS 证书

您应该使用 https 并配置 TLS 证书来运行极狐GitLab。chart 默认安装并配置 cert-manager 获得免费 TLS 证书。 如果您拥有通配符证书，您已安装 cert-manager，或有其它获取 TLS 证书的方法，请查阅 TLS 选项文档。

对于默认配置，您必须指定 email 地址去注册您的 TLS 证书。

在 Helm 安装命令行中包含以下选项：

--set certmanager-issuer.email=me@example.com

PostgreSQL

chart 默认提供集群内建的 PostgreSQL 数据库，仅适用于试用目的。

说明：该配置不推荐在生产环境中使用。

• 由 bitnami/PostgreSQL 默认提供单个 StatefulSet。
• 对于 4.0.0 版本的 chart，副本在内部可用，但 未默认开启。该功能未在极狐GitLab 实例上测试过。

如果您已有准备好的外部 PostgreSQL 数据库，可以使用以下命令配置 chart 使用该数据库。

在 Helm 安装命令行中包含以下选项：

--set postgresql.install=false
--set global.psql.host=production.postgress.hostname.local
--set global.psql.password.secret=kubernetes_secret_name
--set global.psql.password.key=key_that_contains_postgres_password

Redis

所有 Redis 配置设置已移动且合并到 全局配置文档 页面。

说明：该配置不推荐在生产环境中使用。

• 由 bitnami/Redis 默认提供单个 StatefulSet。
• 对于 4.0.0 版本的 chart，副本在内部可用，但 未默认开启。该功能未在极狐GitLab 实例上测试过。

MinIO

该 chart 默认提供集群内建的 MinIO 实例，用于提供对象存储 API。

说明：该配置不推荐在生产环境中使用。

• MinIO fork 提供了一个单实例、非弹性部署的 Deployment。

Prometheus

我们使用上游 Prometheus chart，不要覆盖其它默认文件的值，除了自定义的 prometheus.yml 文件，该文件用于限制收集 Kubernetes API 的指标数据，以及由极狐GitLab chart 创建资源的指标数据。默认禁用 alertmanager，nodeExporter 和 pushgateway。

prometheus.yml 文件控制 Prometheus 从具有 gitlab.com/prometheus_scrape annotation 的资源中收集指标。此外，也可以使用 gitlab.com/prometheus_path 和 gitlab.com/prometheus_port annotations 配置指标的收集方式。每一个 annotation 与 prometheus.io/{scrape,path,port} annotation 相似。

对于正在或想要使用 Prometheus 监控极狐GitLab 应用的用户，原始的 prometheus.io/* annotation 仍添加到适当的 Pods 和 Services 中。这样允许已有用户持续收集指标，且可以提供在同一个 Kubernetes 集群中，同时抓取极狐GitLab 应用指标和其它应用指标的能力。

参考 Prometheus chart 文档，了解配置选项的详尽列表。prometheus 是我们使用的必需 chart，确保其中的配置项是 prometheus 的子项。

对于实例，持久存储的请求由以下配置内容控制：

prometheus:
  alertmanager:
    enabled: false
    persistentVolume:
      enabled: false
      size: 2Gi
  pushgateway:
    enabled: false
    persistentVolume:
      enabled: false
      size: 2Gi
  server:
    persistentVolume:
      enabled: true
      size: 8Gi

配置 Prometheus 抓取启用了 TLS 的端点

如果给定的导出器允许 TLS，并且 chart 配置公开了导出器端点的 TLS 配置，则可以将 Prometheus 配置为从启用了 TLS 的端点抓取指标。

使用 TLS 和 Kubernetes 服务发现用于 Prometheus 抓取配置时有一些注意事项：

• 使用 pod 和服务端点发现角色 - Prometheus 使用 Pod 的内部 IP 地址来设置抓取目标的地址。要验证 SSL 证书，Prometheus 需要配置为在为指标端点创建的证书中设置的通用名称 (CN)，或者配置为包含在主题备用名称 (SAN) 扩展中的名称。该名称不必解析，可以是任意字符串，即有效的 DNS 名称。
• 如果用于导出器端点的证书是自签名的，或不存在于 Prometheus 基础镜像中 - Prometheus pod 需要为证书颁发机构 (CA) 安装证书，该证书颁发机构 (CA) 签署了用于导出器端点的证书。Prometheus 在其基础镜像中使用 Debian 的 ca-bundle。
• Prometheus 支持使用应用于每个抓取配置的 tls_config 设置这两个项目。虽然 Prometheus 具有强大的 relabel_config 机制，用于根据 Pod annotations 和其他发现的属性设置 Prometheus 目标标签，但设置 tls_config. server_name 和 tls_config.ca_file 不能使用 relabel_config。查看 Prometheus 项目议题了解详情。

鉴于这些注意事项，最简单的配置是在用于导出器端点的所有证书中共享一个“名称”和 CA：

1. 为 tls_config.server_name 选择一个任意名称（例如，metrics.gitlab）。
2. 将该名称添加到用于对导出器端点进行 TLS 加密的每个证书的 SAN 列表中。
3. 从同一 CA 颁发所有证书：
   • 将 CA 证书添加为集群 secret。
   • 使用 Prometheus chart 的 extraSecretMounts: 配置，将该 secret 挂载到 Prometheus 服务器容器中。
   • 将其设置为 Prometheus scrape_config 的 tls_config.ca_file。

Prometheus TLS 值示例通过以下方式提供了此共享配置的示例：

1. 为 pod/endpoint scrape_config 角色设置 tls_config.server_name 为 metrics.gitlab。
2. 假设 metrics.gitlab 已添加到用于导出端点的每个证书的 SAN 列表中。
3. 假设 CA 证书已添加到名为 metrics.gitlab.tls-ca 的密钥中，密钥也名为 metrics.gitlab.tls-ca，在部署 Prometheus chart 的同一命名空间中创建（例如，kubectl create secret generic --namespace=gitlab metrics.gitlab.tls-ca --from-file=metrics.gitlab.tls-ca=./ca.pem）。
4. 使用 extraSecretMounts: 条目将 metrics.gitlab.tls-ca secret 挂载到 /etc/ssl/certs/metrics.gitlab.tls-ca。
5. 将 tls_config.ca_file 设置为 /etc/ssl/certs/metrics.gitlab.tls-ca。

导出器端点

并非 chart 中包含的所有指标端点都支持 TLS。 如果端点启用了 TLS，还将设置 gitlab.com/prometheus_scheme: "https" 注释，以及 prometheus.io/scheme: "https" 注释，其中任何一个都可以与 relabel_config 一起使用，来设置 Prometheus __scheme__ 目标标签。 Prometheus TLS 值示例包含一个针对 __scheme__ 的 relabel_config，使用 gitlab.com/prometheus_scheme: "https" 注释。

下表列出了应用了 gitlab.com/prometheus_scrape: true 注释的部署（或使用 Gitaly 和 Praefect 中的一个或两者时）和服务端点。

在下面的文档链接中，如果组件提到添加 SAN 条目，请确保您还添加了您决定用于 Prometheus tls_config.server_name 的 SAN。

对于 webservice pod，暴露的端口是 webservice 容器中的独立 webrick 导出器。Workhorse 容器端口不抓取。有关更多详细信息，请参阅 Webservice Metrics 文档。

外发电子邮件

Outgoing email 默认禁用。如果要启用，使用 global.smtp 和 global.email 设置提供您的 SMTP 服务器的详细信息。您可以在 命令行选项文档中查看相关信息。

如果您的 SMTP 服务器需要认证，确保阅读 secrets 文档 中关于提供密码的相关部分。您可以使用 --set global.smtp.authentication="" 禁用认证。

如果您的 Kubernetes 集群部署在 GKE，请注意 SMTP 端口 25 被关闭。

接收电子邮件

了解该配置请参考 mailroom chart 文档。

服务台电子邮件

了解该配置请参考 mailroom chart 文档。

RBAC

该 chart 默认创建和使用 RBAC。如果您的集群未启用 RBAC，您需要禁用以下设置：

--set certmanager.rbac.create=false
--set nginx-ingress.rbac.createRole=false
--set prometheus.rbac.create=false
--set gitlab-runner.rbac.create=false

CPU and 内存资源需求

Chart 中的资源请求和组件副本数量，默认设置为满足小型生产部署。适用于具有至少 8vCPU 和 30GB 内存的集群。如果您尝试部署非生产实例，您可以减小默认值以适用于更小的集群。

最小 GKE 示例值文件提供了调整资源的示例，以适应 3vCPU 12GB 内存的集群。

最小 Minikube 示例值文件提供了调整资源的示例，以适应 2vCPU 4GB 内存的 Minikube 实例。

使用 Helm 部署

一旦收集了所有配置选项，可以获取任何依赖项并运行 Helm。在示例中，我们将 Helm 版本命名为 gitlab，chart 版本为 5.6.2。

helm repo add gitlab-jh https://charts.gitlab.cn
helm repo update
helm upgrade --install gitlab gitlab-jh/gitlab \
  --version 5.6.2 \
  --timeout 600s \
  --set global.hosts.domain=example.com \
  --set global.hosts.externalIP=10.10.10.10 \
  --set certmanager-issuer.email=me@example.com 

说明如下：

• 所有 Helm 命令指定使用 Helm v3 语法。
• Helm v3 要求将发布名称指定为命令行上的位置参数，除非使用了 --generate-name 选项。
• Helm v3 要求指定一个数字作为持续时间，并在值后面附加一个单位（例如 120s = 2m and 210s = 3m30s）。--timeout 选项可处理为使用秒为单位，设置时可以_不_指定单位。
• --timeout 选项具有一定迷惑性，在应用了 --timeout 选项时，Helm 在安装或升级过程中部署多个组件。--timeout 的值单独应用于每个组件的安装，而不是所有组件的安装。因此，当使用 --timeout=3m 设置在 3 分钟后中止 Helm 安装时，仍可能导致 Helm 安装在 5 分钟后完成，因为所有已安装组件的安装时间都不超过 3 分钟。

如果您想要安装指定版本的实例，您也可以使用 --version <installation version> 选项。

了解 chart 和极狐GitLab 之间的版本对照，请查看文档。

监控部署

部署完成后将输出安装的资源列表，这可能需要 5-10 分钟。

运行 helm status gitlab 命令，可以检查部署的状态。部署进行时，您可以在另一个终端运行该命令。

首次登录

您可以通过访问安装时指定的域名，来访问极狐GitLab 实例。默认域名为 gitlab.example.com，除非更改了 全局 host 设置。如果您手动创建了初始 root 密码的 Secret，您可以使用它，以 root 用户身份登录。如果没有，极狐GitLab 将自动为 root 用户创建一个随机密码，您可以通过以下命令获取（用版本名称替换 <name>，如果您使用了以上案例中的命令，<name> 为 gitlab）。

kubectl get secret <name>-gitlab-initial-root-password -ojsonpath='{.data.password}' | base64 --decode ; echo