🔥码云GVP开源项目 12k star Uniapp+ElementUI 功能强大 支持多语言、二开方便! 广告
# Auto DevOps > 原文:[https://docs.gitlab.com/ee/topics/autodevops/](https://docs.gitlab.com/ee/topics/autodevops/) * [Overview](#overview) * [Enabled by default](#enabled-by-default) * [Quick start](#quick-start) * [Comparison to application platforms and PaaS](#comparison-to-application-platforms-and-paas) * [Features](#features) * [Auto DevOps base domain](#auto-devops-base-domain) * [Enabling/Disabling Auto DevOps](#enablingdisabling-auto-devops) * [At the project level](#at-the-project-level) * [At the group level](#at-the-group-level) * [At the instance level (Administrators only)](#at-the-instance-level-administrators-only) * [Deployment strategy](#deployment-strategy) * [Using multiple Kubernetes clusters](#using-multiple-kubernetes-clusters-premium) * [Limitations](#limitations) * [Private registry support](#private-registry-support) * [Installing Helm behind a proxy](#installing-helm-behind-a-proxy) * [Troubleshooting](#troubleshooting) * [Unable to select a buildpack](#unable-to-select-a-buildpack) * [Pipeline that extends Auto DevOps with only / except fails](#pipeline-that-extends-auto-devops-with-only--except-fails) * [Failure to create a Kubernetes namespace](#failure-to-create-a-kubernetes-namespace) * [Detected an existing PostgreSQL database](#detected-an-existing-postgresql-database) * [Development guides](#development-guides) # Auto DevOps[](#auto-devops "Permalink") 版本历史 * 在 GitLab 10.0 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37115) . * 通常在 GitLab 11.0 上可用. Auto DevOps provides pre-defined CI/CD configuration allowing you to automatically detect, build, test, deploy, and monitor your applications. Leveraging CI/CD best practices and tools, Auto DevOps aims to simplify the setup and execution of a mature and modern software development lifecycle. ## Overview[](#overview "Permalink") 您可以花费大量精力来设置构建,部署和监视项目所需的工作流和流程. 当您的公司要维护数百个(甚至数千个)项目时,情况会变得更糟. 随着新项目的不断启动,整个软件开发过程变得难以管理. Auto DevOps 通过自动检测以最小的配置测试,构建,打包,部署和监视每个项目所需的所有依赖关系和语言技术,为您提供了无缝的软件开发过程. 自动化可确保项目之间的一致性,流程的无缝管理以及更快地创建新项目:推送代码,而 GitLab 则完成其余工作,从而提高了生产率和效率. 有关 Auto DevOps 的介绍, [请在 GitLab 11.0 中](https://youtu.be/0Tc0YYBxqi4)观看[AutoDevOps](https://youtu.be/0Tc0YYBxqi4) . 有关要求,请参阅[Auto DevOps 要求以](requirements.html)获取更多信息. ## Enabled by default[](#enabled-by-default "Permalink") 在 GitLab 11.3 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41729) . 默认情况下,所有项目都会启用 Auto DevOps,并尝试在每个项目的所有管道中运行. 实例管理员可以在[Auto DevOps 设置中](../../user/admin_area/settings/continuous_integration.html#auto-devops-core-only)启用或禁用此默认[设置](../../user/admin_area/settings/continuous_integration.html#auto-devops-core-only) . 如果尚未为项目显式启用,Auto DevOps 会在各个项目的第一个管道故障时自动将其禁用. 从[GitLab 12.7 开始](https://gitlab.com/gitlab-org/gitlab/-/issues/26655) ,仅当存在[`Dockerfile`或匹配的 buildpack](stages.html#auto-build)时,Auto DevOps 才会在管道上自动运行. 如果项目中存在[CI / CD 配置文件](../../ci/yaml/README.html) ,则无论是否启用了 Auto DevOps,它都将继续使用. ## Quick start[](#quick-start "Permalink") 如果您使用的是 GitLab.com,请参阅[快速入门指南](quick_start_guide.html) ,以使用 GitLab.com 和 Google Kubernetes Engine(GKE)上的 Kubernetes 集群设置 Auto DevOps. 如果使用 GitLab 的自我管理实例,则必须先配置[Google OAuth2 OmniAuth Provider,](../../integration/google.html)然后才能在 GKE 上配置集群. 配置提供程序后,您可以按照[快速入门指南中](quick_start_guide.html)的步骤进行入门. In [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/208132) and later, it is possible to leverage Auto DevOps to deploy to [AWS ECS](requirements.html#auto-devops-requirements-for-amazon-ecs). ## Comparison to application platforms and PaaS[](#comparison-to-application-platforms-and-paas "Permalink") Auto DevOps provides features often included in an application platform or a Platform as a Service (PaaS). It takes inspiration from the innovative work done by [Heroku](https://www.heroku.com/) and goes beyond it in multiple ways: * Auto DevOps 可与任何 Kubernetes 集群一起使用; 您不仅限于在 GitLab 的基础架构上运行. (请注意,许多功能在没有 Kubernetes 的情况下也可以使用). * 没有额外的费用(基础设施费用没有加价),您可以在任何公共云(例如[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) )上使用托管的 Kubernetes 群集或容器即服务. * Auto DevOps 具有更多功能,包括安全测试,性能测试和代码质量测试. * Auto DevOps 提供增量的毕业路径. 如果需要高级自定义,则可以开始修改模板,而无需在完全不同的平台上重新开始. 查看[定制](customize.html)文档以获取更多信息. ## Features[](#features "Permalink") Auto DevOps 由一组[阶段组成](stages.html) ,以简单,自动的方式为您的项目带来了这些最佳实践: 1. [Auto Build](stages.html#auto-build) 2. [Auto Test](stages.html#auto-test) 3. [Auto Code Quality](stages.html#auto-code-quality-starter) 4. [Auto SAST (Static Application Security Testing)](stages.html#auto-sast-ultimate) 5. [Auto Secret Detection](stages.html#auto-secret-detection-ultimate) 6. [Auto Dependency Scanning](stages.html#auto-dependency-scanning-ultimate) 7. [Auto License Compliance](stages.html#auto-license-compliance-ultimate) 8. [Auto Container Scanning](stages.html#auto-container-scanning-ultimate) 9. [Auto Review Apps](stages.html#auto-review-apps) 10. [Auto DAST (Dynamic Application Security Testing)](stages.html#auto-dast-ultimate) 11. [Auto Deploy](stages.html#auto-deploy) 12. [Auto Browser Performance Testing](stages.html#auto-browser-performance-testing-premium) 13. [Auto Monitoring](stages.html#auto-monitoring) 由于 Auto DevOps 依赖于许多不同的组件,因此您应该具有以下基本知识: * [Kubernetes](https://kubernetes.io/docs/home/) * [Helm](https://helm.sh/docs/) * [Docker](https://s0docs0docker0com.icopy.site) * [GitLab Runner](https://docs.gitlab.com/runner/) * [Prometheus](https://s0prometheus0io.icopy.site/docs/introduction/overview/) Auto DevOps 为所有阶段提供了出色的默认设置. 但是,您可以[根据](customize.html)需要[自定义](customize.html)几乎所有内容. 有关创建 Auto DevOps 的概述,请阅读[本博客文章中的](https://about.gitlab.com/blog/2017/06/29/whats-next-for-gitlab-ci/)更多[信息](https://about.gitlab.com/blog/2017/06/29/whats-next-for-gitlab-ci/) . **注意** Kubernetes 集群可以[在没有](../../user/project/clusters/index.html) Auto DevOps 的[情况下使用](../../user/project/clusters/index.html) . ## Auto DevOps base domain[](#auto-devops-base-domain "Permalink") 必须使用 Auto DevOps 基本域才能使用[Auto Review Apps](stages.html#auto-review-apps) , [Auto Deploy](stages.html#auto-deploy)和[Auto Monitoring](stages.html#auto-monitoring) . 您可以在以下任意位置定义基本域: * 在集群的设置下(对于实例, [项目](../../user/project/clusters/index.html#base-domain)还是[组)](../../user/group/clusters/index.html#base-domain) * 或在项目级别作为变量: `KUBE_INGRESS_BASE_DOMAIN` * 或在组级别作为变量: `KUBE_INGRESS_BASE_DOMAIN` * 或作为实例范围的后备 **持续集成和交付**部分下的**管理区域>设置** 基本域变量`KUBE_INGRESS_BASE_DOMAIN`与其他环境[变量](../../ci/variables/README.html#priority-of-environment-variables)遵循相同的优先级顺序. 如果未设置 CI / CD 变量,并且群集设置为空,则在设置实例范围的**Auto DevOps 域**设置时将使用该设置. **提示:**如果您将[GitLab 托管应用程序用于 Ingress](../../user/clusters/applications.html#ingress) ,则应自动为您配置 URL 端点. 您所要做的就是将其值用于`KUBE_INGRESS_BASE_DOMAIN`变量.**注:** `AUTO_DEVOPS_DOMAIN`被[弃用 GitLab 11.8](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52363) ,取而代之的`KUBE_INGRESS_BASE_DOMAIN` ,并在除去[GitLab 12.0](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/56959) . Auto DevOps 需要与基础域匹配的通配符 DNS A 记录. 对于`example.com`的基本域,您需要一个 DNS 条目,例如: ``` *.example.com 3600 A 1.2.3.4 ``` 在这种情况下,已部署的应用程序是从`example.com` ,而`1.2.3.4`是负载均衡器的 IP 地址. 通常为 NGINX( [请参阅要求](#requirements) ). 设置 DNS 记录不在本文档的讨论范围内. 请与您的 DNS 提供商联系以获取信息. 另外,您可以使用免费的公共服务,例如[nip.io](https://nip.io) ,无需任何配置即可提供自动通配符 DNS. 对于[nip.io](https://nip.io) ,将 Auto DevOps 基本域设置为`1.2.3.4.nip.io` 完成设置后,所有请求都将到达负载均衡器,该负载均衡器会将请求路由到运行您的应用程序的 Kubernetes Pod. ## Enabling/Disabling Auto DevOps[](#enablingdisabling-auto-devops "Permalink") 首次使用 Auto DevOps 时,请查看[要求,](#requirements)以确保可以充分利用 Auto DevOps 的所有必需组件. 初学者应遵循[快速入门指南](quick_start_guide.html) . GitLab.com 用户只能在项目级别启用或禁用 Auto DevOps. 自我管理的用户可以在项目,组或实例级别启用或禁用 Auto DevOps. ### At the project level[](#at-the-project-level "Permalink") 如果启用,请检查您的项目是否没有`.gitlab-ci.yml` ,或者如果存在,请将其删除. 1. 转到项目的 **设置> CI / CD>自动 DevOps** . 2. 选中**默认为 Auto DevOps 管道**复选框以启用它. 3. (可选,但建议使用)启用后,您可以在 Auto DevOps 用于[部署应用程序](stages.html#auto-deploy)的[基本域中](#auto-devops-base-domain)添加,并选择[部署策略](#deployment-strategy) . 4. 单击**保存更改**以使更改生效. 启用该功能后,将在默认分支上触发 Auto DevOps 管道. ### At the group level[](#at-the-group-level "Permalink") 在 GitLab 11.10 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52447) . 仅管理员和组所有者可以在组级别启用或禁用自动 DevOps. 在组级别启用或禁用 Auto DevOps 时,除非在子组或项目上专门启用或禁用了 Auto DevOps,否则组配置将隐式用于该组内的子组和项目. 要在组级别启用或禁用自动 DevOps: 1. 前往您小组的 **设置> CI / CD>自动 DevOps**页面. 2. 选中**默认为 Auto DevOps 管道**复选框以启用它. 3. 单击**保存更改**以使更改生效. ### At the instance level (Administrators only)[](#at-the-instance-level-administrators-only "Permalink") 即使在实例级别被禁用,组所有者和项目维护者仍可以分别在组和项目级别启用 Auto DevOps. 1. 去 **管理区域>设置>持续集成和部署** . 2. **为所有项目**选择" **默认为自动 DevOps 管道"**以启用它. 3. (可选)您可以设置 Auto DevOps [基本域](#auto-devops-base-domain) ,以供 Auto Deploy 和 Auto Review Apps 使用. 4. 单击**保存更改**以使更改生效. ### Deployment strategy[](#deployment-strategy "Permalink") 在 GitLab 11.0 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38542) . 您可以转到项目的目录,更改 Auto DevOps 使用的部署策略. **设置> CI / CD>自动 DevOps** . 提供以下选项: * **持续部署到生产中** :启用将`master`分支直接部署到生产中的[自动部署](stages.html#auto-deploy) . * **使用定时增量部署连续部署到生产中** :将[`INCREMENTAL_ROLLOUT_MODE`](customize.html#timed-incremental-rollout-to-production-premium)变量设置为`timed` . 生产部署在每次部署增量之间有 5 分钟的延迟执行. * **自动部署到登台,手动部署到生产** :将[`STAGING_ENABLED`](customize.html#deploy-policy-for-staging-and-production-environments)和[`INCREMENTAL_ROLLOUT_MODE`](customize.html#incremental-rollout-to-production-premium)变量设置为`1`并`manual` . 这表示: * `master`分支直接部署到登台. * 提供了手动操作以逐步推广到生产中. **提示:**使用[蓝绿色部署](../../ci/environments/incremental_rollouts.html#blue-green-deployment)技术可最大程度地减少停机时间和风险. ## Using multiple Kubernetes clusters[](#using-multiple-kubernetes-clusters-premium "Permalink") 使用 Auto DevOps 时,由于[它们之间存在](../../user/project/clusters/index.html#multiple-kubernetes-clusters-premium) 1:1 连接,因此可以将不同的环境部署到不同的 Kubernetes 集群. Auto DevOps 使用的" [部署作业"模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml)当前定义了 3 个环境名称: * `review/` (从`review/`开始的所有环境`review/` ) * `staging` * `production` 这些环境使用[Auto Deploy](stages.html#auto-deploy)与作业绑定,因此,除了环境范围外,它们必须具有不同的部署域. 您必须[根据环境](../../ci/variables/README.html#limit-the-environment-scopes-of-environment-variables)为上述每个项定义一个单独的`KUBE_INGRESS_BASE_DOMAIN`变量. 下表是如何配置三个不同群集的示例: | 集群名称 | 集群环境范围 | `KUBE_INGRESS_BASE_DOMAIN`变量值 | 可变环境范围 | Notes | | --- | --- | --- | --- | --- | | review | `review/*` | `review.example.com` | `review/*` | 运行所有[Review Apps](../../ci/review_apps/index.html)的评论集群. `*`是一个通配符,每个环境名称都以`review/`开头使用. | | staging | `staging` | `staging.example.com` | `staging` | (可选)运行临时环境的部署的临时集群. 您必须先[启用它](customize.html#deploy-policy-for-staging-and-production-environments) . | | production | `production` | `example.com` | `production` | 运行生产环境部署的生产集群. 您可以使用[增量卷展栏](customize.html#incremental-rollout-to-production-premium) . | 为每个环境添加不同的集群: 1. 导航到您项目的 **运营> Kubernetes** . 2. 如上表所述,使用各自的环境范围创建 Kubernetes 集群. 3. 创建集群后,导航至每个集群并安装 Helm Tiller 和 Ingress. 等待分配入口 IP 地址. 4. 确保已使用指定的 Auto DevOps 域[配置 DNS](#auto-devops-base-domain) . 5. 导航到每个集群的页面,方法是 **操作> Kubernetes** ,然后根据其入口 IP 地址添加域. 完成配置后,您可以通过创建合并请求并验证您的应用程序是否已作为具有 Review `review/*`环境范围的 Kubernetes 集群中的 Review App 部署来测试设置. 同样,您可以检查其他环境. ## Limitations[](#limitations "Permalink") 以下限制适用. ### Private registry support[](#private-registry-support "Permalink") 没有记录的将私有容器注册表与 Auto DevOps 结合使用的方式. 我们强烈建议将 GitLab 容器注册表与 Auto DevOps 结合使用,以简化配置并防止任何不可预见的问题. ### Installing Helm behind a proxy[](#installing-helm-behind-a-proxy "Permalink") 当在代理后面时,GitLab 不支持将[Helm 作为 GitLab 管理的应用程序](../../user/clusters/applications.html#helm)安装. 想要这样做的用户必须在运行时将其代理设置注入到安装 Pod 中,例如使用[`PodPreset`](https://kubernetes.io/docs/concepts/workloads/pods/podpreset/) : ``` apiVersion: settings.k8s.io/v1alpha1 kind: PodPreset metadata: name: gitlab-managed-apps-default-proxy namespace: gitlab-managed-apps spec: env: - name: http_proxy value: "PUT_YOUR_HTTP_PROXY_HERE" - name: https_proxy value: "PUT_YOUR_HTTPS_PROXY_HERE" ``` ## Troubleshooting[](#troubleshooting "Permalink") ### Unable to select a buildpack[](#unable-to-select-a-buildpack "Permalink") 自动构建和自动测试可能无法检测到您的语言或框架,并出现以下错误: ``` Step 5/11 : RUN /bin/herokuish buildpack build ---> Running in eb468cd46085 -----> Unable to select a buildpack The command '/bin/sh -c /bin/herokuish buildpack build' returned a non-zero code: 1 ``` 以下是可能的原因: * 您的应用程序可能缺少 buildpack 寻找的关键文件. Ruby 应用程序需要正确检测`Gemfile` ,即使编写不带`Gemfile`的 Ruby 应用程序也是`Gemfile` . * 您的应用程序可能不存在 buildpack. 尝试指定[自定义 buildpack](customize.html#custom-buildpacks) . ### Pipeline that extends Auto DevOps with only / except fails[](#pipeline-that-extends-auto-devops-with-only--except-fails "Permalink") 如果您的管道失败并显示以下消息: ``` Found errors in your .gitlab-ci.yml: jobs:test config key may not be used with `rules`: only ``` 当包含作业的规则配置已被`only`或`except`语法覆盖时,将出现此错误. 要解决此问题,您必须: * 将您的`only/except`语法转换为规则. * (临时)将模板固定到[基于 GitLab 12.10 的模板](https://gitlab.com/gitlab-org/auto-devops-v12-10) . ### Failure to create a Kubernetes namespace[](#failure-to-create-a-kubernetes-namespace "Permalink") 如果 GitLab 无法为您的项目创建 Kubernetes 命名空间和服务帐户,则 Auto Deploy 将失败. 有关调试此问题的帮助,请参阅[对失败的部署作业进行故障排除](../../user/project/clusters/index.html#troubleshooting) . ### Detected an existing PostgreSQL database[](#detected-an-existing-postgresql-database "Permalink") 升级到 GitLab 13.0 后,使用 Auto DevOps 部署时可能会遇到以下消息: > 检测到已安装在不赞成使用的通道 1 上的现有 PostgreSQL 数据库,但当前通道设置为 2.在 GitLab 13.0 中,默认通道更改为 2\. […] 默认情况下,Auto DevOps 会在应用程序旁边安装集群内 PostgreSQL 数据库. 在 GitLab 13.0 中更改了默认安装方法,并且升级现有数据库需要用户参与. 两种安装方法是: * **通道 1(不建议使用):**作为关联的 Helm 图表的依赖项拉入数据库. 只支持 Kubernetes 版本 1.15 之前的版本. * **通道 2(当前):**将数据库安装为独立的 Helm 图表. 将集群内数据库功能与 Kubernetes 1.16 及更高版本一起使用时是必需的. 如果收到此错误,则可以执行以下操作之一: * 通过将`AUTO_DEVOPS_POSTGRES_CHANNEL`设置为`1`并重新部署,可以*放心地*忽略该警告并继续使用通道 1 PostgreSQL 数据库. * 通过将`AUTO_DEVOPS_POSTGRES_DELETE_V1`设置为非空值并重新部署,可以删除通道 1 PostgreSQL 数据库并安装新的通道 2 数据库. **危险:**删除通道 1 PostgreSQL 数据库将永久删除现有的通道 1 数据库及其所有数据. 有关备份和升级数据库的更多信息,请参见[升级 PostgreSQL](upgrading_postgresql.html) . * 如果不使用集群内数据库,则可以将`POSTGRES_ENABLED`设置为`false`并重新部署. 此选项与*没有图表内 PostgreSQL 依赖项*的*自定义图表的*用户特别相关. 数据库自动检测基于您的发行版的`postgresql.enabled` Helm 值. 该值是基于`POSTGRES_ENABLED` CI 变量设置的,并且由 Helm 保留,无论您的图表是否使用该变量. **危险:**将`POSTGRES_ENABLED`设置为`false`永久删除您环境中的任何现有通道 1 数据库. ## Development guides[](#development-guides "Permalink") [Development guide for Auto DevOps](../../development/auto_devops.html)