Help us learn about your current experience with the documentation. Take the survey.

Auto DevOps 的要求

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

在启用 Auto DevOps 之前，我们建议您为部署做好准备。如果不这样做，您可以使用它来构建和测试应用程序，然后再配置部署。

准备部署：

  1. 定义 部署策略。

  2. 准备 基础域名。

  3. 定义您要部署到的位置：

    1. Kubernetes。
    2. Amazon Elastic Container Service (ECS)。
    3. Amazon Elastic Kubernetes Service (EKS)。
    4. Amazon EC2。
    5. Google Kubernetes Engine。
    6. 裸机。

  4. 启用 Auto DevOps。

Auto DevOps 部署策略

使用 Auto DevOps 部署应用程序时，选择最适合您需求的 持续部署策略：

部署策略 设置 方法论
持续部署到生产环境 启用 Auto Deploy，默认分支持续部署到生产环境。 持续部署到生产环境。
使用定时增量部署持续部署到生产环境 将 INCREMENTAL_ROLLOUT_MODE 变量设置为 timed。 部署之间有 5 分钟延迟，持续部署到生产环境。
自动部署到暂存环境，手动部署到生产环境 将 STAGING_ENABLED 设置为 1，并将 INCREMENTAL_ROLLOUT_MODE 设置为 manual。 默认分支持续部署到暂存环境，并持续交付到生产环境。

您可以在启用 Auto DevOps 时或之后选择部署方法：

  1. 在左侧边栏，选择 搜索或跳转至 并找到您的项目。
  2. 选择 设置 > CI/CD。
  3. 展开 Auto DevOps。
  4. 选择部署策略。
  5. 选择 保存更改。

使用 蓝绿部署 技术 来最小化停机时间和风险。

Auto DevOps 基础域名

使用 Auto Review Apps 和 Auto Deploy 需要设置 Auto DevOps 基础域名。

要定义基础域名，可以通过以下方式：

  • 在项目、群组或实例级别：转到您的集群设置并在那里添加。
  • 在项目或群组级别：将其作为环境变量添加：KUBE_INGRESS_BASE_DOMAIN。
  • 在实例级别：转到 管理 区域，然后 设置 > CI/CD > 持续集成与交付 并在那里添加。

基础域名变量 KUBE_INGRESS_BASE_DOMAIN 遵循与其他环境变量相同的 优先级顺序。

如果您没有在项目和群组中指定基础域名，Auto DevOps 将使用实例范围的 Auto DevOps 域名。

Auto DevOps 需要与基础域名匹配的通配符 DNS A 记录。对于 example.com 这样的基础域名，您需要一个如下的 DNS 条目：

*.example.com   3600     A     10.0.2.2

在这种情况下，部署的应用程序从 example.com 提供服务，而 10.0.2.2 是您负载均衡器的 IP 地址，通常是 NGINX（查看要求）。 设置 DNS 记录超出了本文档的范围；请咨询您的 DNS 服务商获取信息。

或者，您可以使用像 nip.io 这样的免费公共服务， 它们提供无需配置的自动通配符 DNS。对于 nip.io， 将 Auto DevOps 基础域名设置为 10.0.2.2.nip.io。

完成设置后，所有请求都会到达负载均衡器，负载均衡器将请求路由到 运行您应用程序的 Kubernetes Pod。

Kubernetes 的 Auto DevOps 要求

要充分利用 Kubernetes 的 Auto DevOps，您需要：

要启用部署，您需要：

  1. 一个适用于您项目的 Kubernetes 1.12+ 集群。 对于 Kubernetes 1.16+ 集群，您必须为 Kubernetes 1.16+ 的 Auto Deploy 执行额外配置。

  2. 对于外部 HTTP 流量，需要 Ingress 控制器。对于常规 部署，任何 Ingress 控制器都可以工作，但从 GitLab 14.0 开始， 金丝雀部署 需要 NGINX Ingress。您可以通过 GitLab 集群管理项目模板 或手动使用 ingress-nginx Helm chart 将 NGINX Ingress 控制器部署到您的 Kubernetes 集群。

    当 使用自定义 chart 部署 时，您必须 添加注解， 以便 Prometheus 使用 prometheus.io/scrape: "true" 和 prometheus.io/port: "10254" 来抓取 Ingress manifest。

    如果您的集群安装在裸机上，请参阅 裸机的 Auto DevOps 要求。

  • 基础域名（用于 Auto Review Apps 和 Auto Deploy）

    您必须 指定 Auto DevOps 基础域名， 您所有的 Auto DevOps 应用程序都使用该域名。此域名必须配置 通配符 DNS。

  • GitLab Runner（用于所有阶段）

    您的 Runner 必须配置为运行 Docker，通常使用 Docker 或 Kubernetes 执行器， 并启用 特权模式。 Runner 不需要安装在 Kubernetes 集群中，但 Kubernetes 执行器易于使用并自动扩展。 您也可以使用 Docker Machine 配置基于 Docker 的 Runner 进行自动扩展。

    Runner 应注册为整个 GitLab 实例的 实例 Runner， 或分配给特定项目的 项目 Runner。

  • cert-manager（可选，用于 TLS/HTTPS）

    要为您的应用程序启用 HTTPS 端点，您可以 安装 cert-manager， 这是一个原生的 Kubernetes 证书管理控制器，有助于签发 证书。在您的集群上安装 cert-manager 会签发 Let’s Encrypt 证书，并确保 证书有效且是最新的。

如果您没有配置 Kubernetes 或 Prometheus，那么 Auto Review Apps 和 Auto Deploy 将被跳过。

满足所有要求后，您可以 启用 Auto DevOps。

裸机的 Auto DevOps 要求

根据 Kubernetes Ingress-NGINX 文档：

在传统的云环境中，网络负载均衡器可以按需获取， 一个 Kubernetes manifest 就足以向外部客户端提供 与 NGINX Ingress 控制器的单一联系点，并间接地与 集群内运行的任何应用程序建立联系。 裸机环境缺乏这种便利，需要稍微不同的设置来为 外部消费者提供相同类型的访问权限。

前面链接的文档解释了这个问题并提供了解决方案，例如：