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 时的常见错误以及任何可用的解决方法。

追踪 Helm 命令

将 CI/CD 变量 TRACE 设置为任意值，可以让 Helm 命令产生详细输出。您可以使用此输出来诊断 Auto DevOps 部署问题。

您可以通过更改高级 Auto DevOps 配置变量来解决一些 Auto DevOps 部署问题。阅读更多关于自定义 Auto DevOps CI/CD 变量的信息。

无法选择构建包

Auto Test 可能无法检测到您的语言或框架，并显示以下错误：

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

可能的原因如下：

您的应用可能缺少构建包正在查找的关键文件。 Ruby 应用需要 Gemfile 才能被正确检测，尽管没有 Gemfile 也可以编写 Ruby 应用。
可能不存在适用于您应用的构建包。尝试指定自定义构建包。

构建器弃用错误

由于此Heroku 更新，传统的 shimmed heroku/buildpacks:20 和 heroku/builder-classic:22 镜表现在会生成错误而不是警告。

要解决此问题，您应该迁移到 heroku/builder:* 构建器镜像。作为临时解决方案，您也可以设置环境变量来跳过错误。

迁移到 `heroku/builder:*`

在迁移之前，您应该阅读每个规范版本的发布说明，以确定潜在的破坏性更改。在这种情况下，相关的构建包 API 版本是 0.6 和 0.7。这些破坏性更改对构建包维护者尤为重要。

有关更多更改信息，您也可以比较规范本身的差异。

跳过错误

作为临时解决方案，您可以通过设置并转发 ALLOW_EOL_SHIMMED_BUILDER 环境变量来跳过错误：

  variables:
    ALLOW_EOL_SHIMMED_BUILDER: "1"
    AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES: ALLOW_EOL_SHIMMED_BUILDER

仅使用 / except 扩展 Auto DevOps 的流水线失败

如果您的流水线失败并显示以下消息：

Unable to create pipeline

  jobs:test config key may not be used with `rules`: only

当包含的作业的规则配置被 only 或 except 语法覆盖时，会出现此错误。要解决此问题，您必须：

将您的 only/except 语法转换为 rules。
（临时）将您的模板固定到基于 GitLab 12.10 的模板。

无法创建 Kubernetes 命名空间

如果 GitLab 无法为您的项目创建 Kubernetes 命名空间和服务账户，Auto Deploy 将失败。有关调试此问题的帮助，请参阅故障排除失败的部署作业。

检测到现有的 PostgreSQL 数据库

升级到 GitLab 13.0 后，在使用 Auto DevOps 部署时，您可能会遇到以下消息：

Detected an existing PostgreSQL database installed on the
deprecated channel 1, but the current channel is set to 2. The default
channel changed to 2 in GitLab 13.0.
[...]

默认情况下，Auto DevOps 会安装一个集群内 PostgreSQL 数据库与您的应用程序一起使用。默认安装方法在 GitLab 13.0 中发生了变化，升级现有数据库需要用户参与。两种安装方法是：

channel 1 (已弃用)：将数据库作为关联 Helm chart 的依赖项拉取。仅支持 Kubernetes 1.15 及更早版本。
channel 2 (当前)：将数据库作为独立的 Helm chart 安装。对于使用 Kubernetes 1.16 及更高版本的集群内数据库功能是必需的。

如果您收到此错误，可以执行以下操作之一：

您可以安全地忽略警告，并通过设置 AUTO_DEVOPS_POSTGRES_CHANNEL 为 1 并重新部署来继续使用 channel 1 PostgreSQL 数据库。
您可以通过设置 AUTO_DEVOPS_POSTGRES_DELETE_V1 为非空值并重新部署来删除 channel 1 PostgreSQL 数据库并安装一个全新的 channel 2 数据库。

删除 channel 1 PostgreSQL 数据库将永久删除现有的 channel 1 数据库及其所有数据。有关备份和升级数据库的更多信息，请参阅升级 PostgreSQL。
如果您没有使用集群内数据库，可以将 POSTGRES_ENABLED 设置为 false 并重新部署。此选项特别适用于没有集群内 PostgreSQL 依赖项的自定义图表用户。数据库自动检测基于您发布版本的 postgresql.enabled Helm 值。无论您的图表是否使用该变量，此值都会根据 POSTGRES_ENABLED CI/CD 变量设置并由 Helm 持久化。

将 POSTGRES_ENABLED 设置为 false 将永久删除您环境的任何现有 channel 1 数据库。

项目的 Auto DevOps 自动禁用

如果项目的 Auto DevOps 被自动禁用，可能是由于以下原因：

Auto DevOps 设置未在项目本身中明确启用。它仅在父级组或实例中启用。
项目没有成功的 Auto DevOps 流水线历史。
Auto DevOps 流水线失败。

要解决此问题：

在项目中启用 Auto DevOps 设置。
修复破坏流水线的错误，以便流水线重新运行。

`Error: unable to recognize "": no matches for kind "Deployment" in version "extensions/v1beta1"`

将您的 Kubernetes 集群升级到 v1.16+ 后，在使用 Auto DevOps 部署时，您可能会遇到以下消息：

UPGRADE FAILED
Error: failed decoding reader into objects: unable to recognize "": no matches for kind "Deployment" in version "extensions/v1beta1"

如果当前在环境命名空间上的部署是使用 Kubernetes v1.16+ 中不存在的已弃用/已删除 API 部署的，则可能发生这种情况。例如，如果您的集群内 PostgreSQL 是以传统方式安装的，资源是通过 extensions/v1beta1 API 创建的。然而，部署资源在 v1.16 中已移至 app/v1 API。

要恢复此类过时的资源，您必须通过将旧版 API 映射到新版 API 来转换当前的部署。有一个名为 mapkubeapis 的辅助工具可用于解决此问题。按照以下步骤在 Auto DevOps 中使用该工具：

修改您的 .gitlab-ci.yml：

include:
  - template: Auto-DevOps.gitlab-ci.yml
  - remote: https://gitlab.com/shinya.maeda/ci-templates/-/raw/master/map-deprecated-api.gitlab-ci.yml

variables:
  HELM_VERSION_FOR_MAPKUBEAPIS: "v2" # If you're using auto-depoy-image v2 or later, please specify "v3".

运行作业 <environment-name>:map-deprecated-api。在进入下一步之前，确保此作业成功。您应该看到如下输出：

2020/10/06 07:20:49 Found deprecated or removed Kubernetes API:
"apiVersion: extensions/v1beta1
kind: Deployment"
Supported API equivalent:
"apiVersion: apps/v1
kind: Deployment"

将您的 .gitlab-ci.yml 恢复到之前的版本。您不再需要包含补充模板 map-deprecated-api。
像往常一样继续部署。

`Error: not a valid chart repository or cannot be reached`

正如在官方 CNCF 博客文章中宣布的， stable Helm chart 仓库已于 2020 年 11 月 13 日被弃用并删除。在该日期之后，您可能会遇到此错误：

Error: error initializing: Looks like "https://kubernetes-charts.storage.googleapis.com"
is not a valid chart repository or cannot be reached

一些 GitLab 功能依赖于 stable chart。为了减轻影响，我们已将它们更改为使用新的官方仓库或由 GitLab 维护的 Helm Stable Archive 仓库。 Auto Deploy 包含一个示例修复。

在 Auto Deploy 中，auto-deploy-image 的 v1.0.6+ 版本不再将已弃用的 stable 存储库添加到 helm 命令中。如果您使用自定义 chart 并依赖于已弃用的 stable 存储库，请指定一个较旧的 auto-deploy-image，如下例所示：

include:
  - template: Auto-DevOps.gitlab-ci.yml

.auto-deploy:
  image: "registry.gitlab.com/gitlab-org/cluster-integration/auto-deploy-image:v1.0.5"

请注意，当 stable 存储库被删除时，此方法将停止工作，因此您最终必须修复您的自定义 chart。

要修复您的自定义 chart：

在您的 chart 目录中，将 requirements.yaml 文件中的 repository 值从：

repository: "https://kubernetes-charts.storage.googleapis.com/"

更改为：

repository: "https://charts.helm.sh/stable"

在您的 chart 目录中，使用与 Auto DevOps 相同的 Helm 主版本运行 helm dep update .。
提交对 requirements.yaml 文件的更改。
如果您之前有 requirements.lock 文件，请提交对该文件的更改。如果您的 chart 之前没有 requirements.lock 文件，则不需要提交新的文件。此文件是可选的，但存在时用于验证下载的依赖项的完整性。

您可以在问题 #263778，“从 stable Helm 仓库迁移 PostgreSQL”中找到更多信息。

`Error: release .... failed: timed out waiting for the condition`

刚开始使用 Auto DevOps 时，在首次部署应用程序时，您可能会遇到此错误：

INSTALL FAILED
PURGING CHART
Error: release staging failed: timed out waiting for the condition

这很可能是由部署过程中失败的存活（或就绪）探针尝试引起的。默认情况下，这些探针针对端口 5000 上部署的应用程序的根页面运行。如果您的应用程序未配置为在根页面提供任何内容，或配置为在端口 5000之外的特定端口上运行，则此检查将失败。

如果失败，您应该在相关 Kubernetes 命名空间的事件中看到这些失败。这些事件如下例所示：

LAST SEEN   TYPE      REASON                   OBJECT                                            MESSAGE
3m20s       Warning   Unhealthy                pod/staging-85db88dcb6-rxd6g                      Readiness probe failed: Get http://10.192.0.6:5000/: dial tcp 10.192.0.6:5000: connect: connection refused
3m32s       Warning   Unhealthy                pod/staging-85db88dcb6-rxd6g                      Liveness probe failed: Get http://10.192.0.6:5000/: dial tcp 10.192.0.6:5000: connect: connection refused

要更改用于存活检查的端口，请将自定义值传递给 Auto DevOps 使用的 Helm chart：

在您的仓库根目录创建一个名为 .gitlab/auto-deploy-values.yaml 的目录和文件。
用以下内容填充该文件，将端口值替换为您的应用程序实际配置使用的端口号：
```
service:
  internalPort: <port_value>
  externalPort: <port_value>
```
提交您的更改。

提交更改后，后续的探针应该使用新定义的端口。通过以相同方式覆盖 livenessProbe.path 和 readinessProbe.path 值（显示在默认 values.yaml文件中），也可以更改被探测的页面。