Auto DevOps 要求

在启用 Auto DevOps 之前，我们建议您为部署做好准备。或者，您可以使用 Auto DevOps 来构建和测试您的应用，然后再配置部署。

要准备部署：

定义部署策略。
准备基础域名。
定义要将其部署到的位置：
1. Kubernetes.
2. Bare metal.

完成后：

启用 Auto DevOps。

Auto DevOps 部署策略

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

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

您可以在启用 Auto DevOps 或更高版本时选择部署方法：

在左侧边栏中，选择 搜索或转到 并找到您的项目。
在左侧边栏中，选择 设置 > CI/CD。
展开 Auto DevOps。
选择部署策略。
选择 保存修改。

使用蓝绿部署技术将停机时间和风险降至最低。

Auto DevOps 基础域名

Auto DevOps 基础域名需要使用 Auto Review Apps、Auto Deploy 和 Auto Monitoring。

要定义基础域名，可以：

在项目、群组或实例级别：转到您的集群设置并添加到那里。
在项目或群组级别：将其添加为环境变量：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     1.2.3.4

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

或者，您可以使用免费的公共服务，如 nip.io，无需任何配置即可提供自动通配符 DNS。对于 nip.io，将 Auto DevOps 基域设置为 1.2.3.4.nip.io。

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

Auto DevOps requirements for Kubernetes

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

Kubernetes（Auto Review Apps、Auto Deploy 和 Auto Monitoring）

要启用部署，您需要：
1. 用于您的项目的 Kubernetes 1.12+ 集群。对于 Kubernetes 1.16+ 集群，您必须对 Auto Deploy for Kubernetes 1.16+ 进行额外配置。
2. 对于外部 HTTP 流量，需要一个 Ingress 控制器。对于常规部署，任何 Ingress 控制器都应该可以工作，但从 14.0 版本开始，金丝雀部署需要 NGINX Ingress。您可以通过 GitLab 集群管理项目模板，或使用 ingress-nginx Helm chart。
  
  要在使用 Prometheus 集群集成时显示指标，您必须启用 Prometheus 指标。
  
  使用自定义 chart 进行部署时，您还必须使用 Prometheus 注释要被 Prometheus 抓取的 Ingress manifest，使用 prometheus.io/scrape: "true" 和prometheus.io/port: "10254"。
  
  如果您的集群安装在裸金属上，请参阅裸金属的 Auto DevOps 要求。
基础域名（Auto Review Apps、Auto Deploy 和 Auto Monitoring）

您必须指定 Auto DevOps 基础域名，您的所有 Auto DevOps 应用都使用它。此域名必须配置通配符 DNS。
GitLab Runner（所有 stages）

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

Runner 应注册为整个实例的共享 runner，或分配给特定项目的特定 runner。
Prometheus（Auto Monitoring）

要启用 Auto Monitoring，您需要在集群内部或外部安装 Prometheus，并配置为抓取您的 Kubernetes 集群。如果您已经配置了极狐GitLab 与 Kubernetes 的集成，则可以通过启用 Prometheus 集群集成来指示极狐GitLab 查询集群内 Prometheus。

必须为项目激活 Prometheus 集成，或者在群组或实例级别激活。

要获取响应指标（除了系统指标），您必须配置 Prometheus 监控 NGINX。
cert-manager（可选，用于 TLS/HTTPS）

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

如果您没有配置 Kubernetes 或 Prometheus，则 Auto Review Apps、Auto Deploy 和 Auto Monitoring 被跳过。

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

Auto DevOps requirements for bare metal

根据 Kubernetes Ingress-NGINX 文档：

在传统的云环境中，网络负载均衡器可按需使用，单个 Kubernetes manifest 足以为 NGINX Ingress 控制器与外部客户端提供单点联系，并间接与集群内运行的任何应用联系。裸金属环境缺乏这种资源，需要稍微不同的设置来为外部消费者提供相同类型的访问。

上面链接的文档解释了这个问题并提出了可能的解决方案，例如：

通过 MetalLB。
通过 PorterLB。