Auto DevOps 要求

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

要准备部署:

  1. 定义部署策略
  2. 准备基础域名
  3. 定义要将其部署到的位置:

    1. Kubernetes.
    2. Bare metal.

完成后:

  1. 启用 Auto DevOps

Auto DevOps 部署策略

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

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

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

  1. 在顶部栏中,选择 主菜单 > 项目 并找到您的项目。
  2. 在左侧边栏,选择 设置 > CI/CD
  3. 展开 Auto DevOps
  4. 选择部署策略。
  5. 选择 保存修改
note使用蓝绿部署技术将停机时间和风险降至最低。

Auto DevOps 基础域名

Auto DevOps 基础域名需要使用 Auto Review AppsAuto DeployAuto 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,您需要:

  • KubernetesAuto Review AppsAuto DeployAuto 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。

      note要在使用 Prometheus 集群集成时显示指标,您必须启用 Prometheus 指标

      使用自定义 chart 进行部署时,您还必须使用 Prometheus 注释要被 Prometheus 抓取的 Ingress manifest,使用 prometheus.io/scrape: "true"prometheus.io/port: "10254"

      note如果您的集群安装在裸金属上,请参阅裸金属的 Auto DevOps 要求
  • 基础域名Auto Review AppsAuto DeployAuto 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。

  • PrometheusAuto 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 AppsAuto DeployAuto Monitoring 被跳过。

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

Auto DevOps requirements for bare metal

根据 Kubernetes Ingress-NGINX 文档

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

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