{{< details >}}

  • Tier: 基础版, 专业版, 旗舰版
  • Offering: JihuLab.com, 私有化部署

{{< /details >}}

本文档页面中的信息描述了使用 Auto DevOps 时常见的错误以及任何可用的解决方法。

跟踪 Helm 命令

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

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

无法选择 buildpack

自动测试可能无法检测到您的语言或框架，并出现以下错误：

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

可能的原因如下：

  1. 您的应用程序可能缺少 buildpack 所需的关键文件。Ruby 应用程序需要一个 Gemfile 来正确检测，即使可以在没有 Gemfile 的情况下编写 Ruby 应用程序。
  2. 您的应用程序可能没有相应的 buildpack。尝试指定一个自定义 buildpack。

构建器结束错误

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

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

迁移到 heroku/builder:*

在迁移之前，您应阅读每个规范版本的发行说明，以确定潜在的重大变化。在这种情况下，相关的 buildpack API 版本是 0.6 和 0.7。这些重大变化对 buildpack 维护者尤为重要。

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

跳过错误

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

  variables:
    ALLOW_EOL_SHIMMED_BUILDER: "1"
    AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES: ALLOW_EOL_SHIMMED_BUILDER

扩展 Auto DevOps 的仅 / 除外流水线失败

如果您的流水线失败并出现以下消息：

Unable to create pipeline

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

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

  1. 将 only/except 语法转换为规则。
  2. （临时）将您的模板固定到基于极狐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 及更高版本一起使用集群内数据库功能。

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

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

{{< alert type=”warning” >}}

删除 channel 1 PostgreSQL 数据库将永久删除现有的 channel 1 数据库及其所有数据。有关备份和升级数据库的更多信息，请参阅升级 PostgreSQL。

{{< /alert >}}

  1. 如果您未使用集群内数据库，可以将 POSTGRES_ENABLED 设置为 false 并重新部署。此选项特别适用于没有 chart 内 PostgreSQL 依赖项的自定义 chart的用户。数据库自动检测基于您的发布的 postgresql.enabled Helm 值。无论您的 chart 是否使用变量，此值都根据 POSTGRES_ENABLED CI/CD 变量设置并由 Helm 持久化。

{{< alert type=”warning” >}}

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

{{< /alert >}}

项目的 Auto DevOps 被自动禁用

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

  1. Auto DevOps 设置未在项目本身中明确启用。仅在父群组或其实例中启用(../../administration/settings/continuous_integration.md#auto-devops)。
  2. 项目没有成功的 Auto DevOps 流水线历史记录。
  3. Auto DevOps 流水线失败。

要解决此问题：

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

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 中使用该工具：

  1. 修改您的 .gitlab-ci.yml 文件：

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

variables:
  HELM_VERSION_FOR_MAPKUBEAPIS: "v2" # 如果您使用 auto-deploy-image v2 或更高版本，请指定 "v3"。

  2. 运行作业 <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"

  3. 恢复您的 .gitlab-ci.yml 到先前版本。您不再需要包含补充模板 map-deprecated-api。

  4. 按照惯例继续部署。

Error: not a valid chart repository or cannot be reached

正如官方 CNCF 博客文章中宣布的，稳定的 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 功能依赖于稳定的 chart。为减轻影响，我们将其更改为使用新的官方仓库或极狐GitLab 维护的 Helm 稳定存档仓库。

在 Auto Deploy 中，auto-deploy-image 的 v1.0.6+ 不再将已弃用的稳定仓库添加到 helm 命令中。如果您使用自定义 chart 并依赖于已弃用的稳定仓库，请指定较旧的 auto-deploy-image，例如：

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

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

请记住，当稳定仓库被删除时，此方法将停止工作，因此您最终必须修复您的自定义 chart。

要修复您的自定义 chart：

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

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

    更新为：

    repository: "https://charts.helm.sh/stable"
  2. 在您的 chart 目录中，使用与 Auto DevOps 相同的 Helm 主版本运行 helm dep update .。
  3. 提交 requirements.yaml 文件的更改。
  4. 如果您之前有 requirements.lock 文件，请提交该文件的更改。如果您的 chart 中以前没有 requirements.lock 文件，则无需提交新的文件。此文件是可选的，但如果存在，它用于验证下载的依赖项的完整性。

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：

  1. 在您的存储库根目录创建一个名为 .gitlab/auto-deploy-values.yaml 的目录和文件。

  2. 用以下内容填充文件，将端口值替换为您的应用程序配置使用的实际端口号：

    service:
  internalPort: <port_value>
  externalPort: <port_value>

  3. 提交您的更改。

提交更改后，后续探测应使用新定义的端口。探测的页面也可以通过覆盖 livenessProbe.path 和 readinessProbe.path 值以相同方式进行更改。