CodePipeline 故障排除 - AWS CodePipeline
管道错误：使用 AWS Elastic Beanstalk 配置的管道返回错误消息：“部署失败。提供的角色没有足够的权限：Service:AmazonElasticLoadBalancing”部署错误：如果缺少“DescribeEvents”权限，则配置了 AWS Elastic Beanstalk 部署操作的管道会挂起，而不是失败管道错误：源操作返回权限不足消息：“无法访问 CodeCommit 存储库 repository-name。确保管道 IAM 角色具有足够的权限来访问存储库。”管道错误：Jenkins 生成或测试操作运行很长时间后由于缺少凭证或权限而失败管道错误：在一个 AWS 区域中使用在另一个 AWS 区域中创建的存储桶创建的管道返回“InternalError”，代码为“JobFailed”部署错误：包含 WAR 文件的 ZIP 文件已成功部署到 AWS Elastic Beanstalk，但应用程序 URL 报告 404 Not Found 错误管道构件文件夹名称似乎被截断添加 CodeBuild GitClone 权限以连接到 Bitbucket、GitHub、GitHub Enterprise Server 或 GitLab.com为 CodeCommit 源操作添加 CodeBuild GitClone 权限管道错误：使用 CodeDeployToECS 操作的部署返回错误消息：“Exception while trying to read the task definition artifact file from: <source artifact name> (尝试从 <源构件名称> 读取任务定义构件时发生异常)”GitHub 版本 1 源操作：存储库列表显示不同的存储库GitHub 版本 2 源代码操作：无法完成存储库连接Amazon S3 错误：CodePipeline 服务角色 <ARN> 正在拒绝 S3 访问 S3 桶 <BucketName>包含 Amazon S3、Amazon ECR 或 CodeCommit 源的管道不再自动启动连接到 GitHub 时出现连接错误：“出现问题，请确保在浏览器中启用 Cookie” 或“组织拥有者必须安装 GitHub 应用程序”执行模式更改为 QUEUED 或 PARALLEL 模式的管道在达到运行限制时失败如果将 PARALLEL 模式下的管道编辑为 QUEUED 或 SUPERSEDED 模式，则管道定义会过时从 PARALLEL 模式更改的管道将显示之前的执行模式具有使用文件路径触发筛选的连接的管道可能不会在创建分支时启动当达到文件限制时，具有使用文件路径触发筛选的连接的管道可能无法启动PARALLEL 模式下的 CodeCommit 或 S3 源修订可能与 EventBridge 事件不匹配 需要有关其他问题的帮助？

CodePipeline 故障排除

以下信息可帮助您处理 AWS CodePipeline 中的常见问题。

主题

管道错误：使用 AWS Elastic Beanstalk 配置的管道返回错误消息：“部署失败。提供的角色没有足够的权限：Service:AmazonElasticLoadBalancing”

问题：CodePipeline 的服务角色对 AWS Elastic Beanstalk 不具有足够的权限，包括但不限于 Elastic Load Balancing 中的一些操作。2015 年 8 月 6 日已更新 CodePipeline 的服务角色来解决此问题。在此日期之前创建其服务角色的客户必须修改其服务角色的策略语句以添加所需的权限。

可能的修复措施：最简单的解决方案是编辑服务角色的策略声明，详情请参见向 CodePipeline 服务角色添加权限。

应用编辑过的策略后，按照手动启动管道中的步骤手动重新运行使用 Elastic Beanstalk 的任何管道。

根据您的安全需求，您也可以通过其他方式修改权限。

部署错误：如果缺少“DescribeEvents”权限，则配置了 AWS Elastic Beanstalk 部署操作的管道会挂起，而不是失败

问题：对于使用 AWS Elastic Beanstalk 的任何管道，CodePipeline 的服务角色必须包含 "elasticbeanstalk:DescribeEvents" 操作。没有此权限，AWS Elastic Beanstalk 部署操作会挂起但不会失败或指示错误。如果您的服务角色缺少此操作，则 CodePipeline 将无权代表您在 AWS Elastic Beanstalk 中运行管道部署阶段。

可能的修复措施：检查您的 CodePipeline 服务角色。如果缺少 "elasticbeanstalk:DescribeEvents" 操作，请使用向 CodePipeline 服务角色添加权限中的步骤在 IAM 控制台中使用编辑策略功能添加它。

应用编辑过的策略后，按照手动启动管道中的步骤手动重新运行使用 Elastic Beanstalk 的任何管道。

管道错误：源操作返回权限不足消息：“无法访问 CodeCommit 存储库 repository-name。确保管道 IAM 角色具有足够的权限来访问存储库。”

问题：CodePipeline 的服务角色不具有对 CodeCommit 的足够权限，可能是在 2016 年 4 月 18 日添加对使用 CodeCommit 存储库的支持之前创建的。在此日期之前创建其服务角色的客户必须修改其服务角色的策略语句以添加所需的权限。

可能的修复措施：将 CodeCommit 所需的权限添加到 CodePipeline 服务角色的策略中。有关更多信息，请参阅 向 CodePipeline 服务角色添加权限。

管道错误：Jenkins 生成或测试操作运行很长时间后由于缺少凭证或权限而失败

问题：如果 Jenkins 服务器安装在 Amazon EC2 实例上，则该实例可能不是使用具有 CodePipeline 所需权限的实例角色创建的。如果您在 Jenkins 服务器、本地实例或不是使用所需 IAM 角色创建的 Amazon EC2 实例上使用 IAM 用户，则 IAM 用户将不具有所需权限，或者 Jenkins 服务器将无法通过服务器上配置的配置文件访问这些凭证。

可能的修复措施：确保为 Amazon EC2 实例角色或 IAM 用户配置 AWSCodePipelineCustomActionAccess 托管策略或等效权限。有关更多信息，请参阅 适用于 AWS CodePipeline 的 AWS 托管式策略。

如果您正在使用 IAM 用户，请确保实例上配置的 AWS 配置文件使用配置了正确权限的 IAM 用户。您可能必须直接在 Jenkins UI 中提供您配置的用于在 Jenkins 和 CodePipeline 之间进行集成的 IAM 用户凭证。这不是推荐的最佳实践。如果必须这样做，请确保 Jenkins 服务器是安全的，并且使用 HTTPS 而不是 HTTP。

管道错误：在一个 AWS 区域中使用在另一个 AWS 区域中创建的存储桶创建的管道返回“InternalError”，代码为“JobFailed”

问题：如果管道和 Amazon S3 桶是在不同的 AWS 区域中创建的，那么下载存储在该桶中的构件会失败。

可能的解决方法：确保存储构件的 Amazon S3 桶与您创建的管道位于同一 AWS 区域中。

部署错误：包含 WAR 文件的 ZIP 文件已成功部署到 AWS Elastic Beanstalk，但应用程序 URL 报告 404 Not Found 错误

问题：WAR 文件已成功部署到 AWS Elastic Beanstalk 环境，但应用程序 URL 返回 404 Not Found 错误。

可能的修复措施：AWS Elastic Beanstalk 可以解压缩 ZIP 文件，但不能解压缩包含在 ZIP 文件中的 WAR 文件。不要在 buildspec.yml 文件中指定 WAR 文件，而是指定一个包含要部署的内容的文件夹。例如：

version: 0.2

phases:
  post_build:
    commands:
      - mvn package
      - mv target/my-web-app ./
artifacts:
  files:
    - my-web-app/**/*
 discard-paths: yes

有关示例，请参阅适用于 CodeBuild 的 AWS Elastic Beanstalk 示例。

管道构件文件夹名称似乎被截断

问题：在 CodePipeline 中查看管道构件名称时，名称似乎被截断。这可能会使名称看似或似乎不再包含整个管道名称。

解释：CodePipeline 会截断构件名称，以确保在 CodePipeline 为任务工作者生成临时凭证时，完整的 Amazon S3 路径不超过策略大小限制。

即使构件名称似乎被截断，CodePipeline 也会映射到构件桶，而不受具有截断名称的构件影响。管道可以正常工作。这不是文件夹或构件的问题。管道名称不能超过 100 个字符。尽管构件文件夹名称似乎已缩短，但它对您的管道来说仍然是唯一的。

添加 CodeBuild GitClone 权限以连接到 Bitbucket、GitHub、GitHub Enterprise Server 或 GitLab.com

当您在源操作和 CodeBuild 操作中使用 AWS CodeStar 连接时，可以通过两种方式将输入构件传递到生成包：

  • 默认方式：源操作生成一个 zip 文件，其中包含 CodeBuild 下载的代码。

  • Git 克隆：源代码可以直接下载到构建环境中。

    Git 克隆模式允许您将源代码作为工作 Git 存储库进行交互。要使用此模式，您必须授予 CodeBuild 环境使用连接的权限。

要向 CodeBuild 服务角色策略添加权限，请创建附加到 CodeBuild 服务角色的客户管理型策略。以下步骤会创建一个策略，其中 UseConnection 权限在 action 字段中指定，而连接 ARN 在 Resource 字段中指定。

使用控制台添加 UseConnection 权限

  1. 要查找管道的连接 ARN，请打开管道，然后在源操作中点击 (i) 图标。您将连接 ARN 添加到您的 CodeBuild 服务角色策略。

    连接 ARN 的示例是：

    arn:aws:codeconnections:eu-central-1:123456789123:connection/sample-1908-4932-9ecc-2ddacee15095

  2. 要查找 CodeBuild 服务角色，请打开管道中使用的构建项目，然后导航到 Build details (构建详细信息) 选项卡。

  3. 选择服务角色链接。此时将打开 IAM 控制台，您可以在其中添加新策略，以授予对连接的访问权限。

  4. 在 IAM 控制台中，选择 Attach policies (附加策略)，然后选择 Create policy (创建策略)。

    使用以下示例策略模板。将您的连接 ARN 添加到 Resource 字段，如此示例中所示：

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "codestar-connections:UseConnection",
            "Resource": "insert connection ARN here"
        }
    ]
}

    在存储库的 JSON 选项卡上，粘贴您的策略。

  5. 选择查看策略。为策略输入名称（例如 connection-permissions），然后选择 Create policy (创建策略)。

  6. 返回到附加权限的页面上，刷新策略列表，然后选择您刚才创建的策略。选择附加策略。

    该图显示了在控制台中附加策略的选项

为 CodeCommit 源操作添加 CodeBuild GitClone 权限

当您的管道有一个 CodeCommit 源操作时，可以通过两种方式将输入构件传递到构建包：

  • 默认方式 – 源操作生成一个 zip 文件，其中包含 CodeBuild 下载的代码。

  • 完整克隆 – 源代码可以直接下载到构建环境中。

    完整克隆选项允许您将源代码作为工作 Git 存储库进行交互。要使用此模式，您必须授予 CodeBuild 环境从存储库提取的权限。

要向 CodeBuild 服务角色策略添加权限，请创建附加到 CodeBuild 服务角色的客户管理型策略。以下步骤将创建一个在 action 字段中指定 codecommit:GitPull 权限的策略。

使用控制台添加 GitPull 权限

  1. 要查找 CodeBuild 服务角色，请打开管道中使用的构建项目，然后导航到 Build details (构建详细信息) 选项卡。

  2. 选择服务角色链接。此时将打开 IAM 控制台，您可以在其中添加新策略，以授予对存储库的访问权限。

  3. 在 IAM 控制台中，选择 Attach policies (附加策略)，然后选择 Create policy (创建策略)。

  4. 在 JSON 选项卡上，粘贴以下示例策略。

    {
    "Action": [
        "codecommit:GitPull"
    ],
    "Resource": "*",
    "Effect": "Allow"
},

  5. 选择查看策略。为策略输入名称（例如 codecommit-gitpull），然后选择 Create policy (创建策略)。

  6. 返回到附加权限的页面上，刷新策略列表，然后选择您刚才创建的策略。选择附加策略。

管道错误：使用 CodeDeployToECS 操作的部署返回错误消息：“Exception while trying to read the task definition artifact file from: <source artifact name> (尝试从 <源构件名称> 读取任务定义构件时发生异常)”

问题：

任务定义文件是 CodePipeline 通过 CodeDeploy 向 Amazon ECS 执行部署操作（CodeDeployToECS 操作）的必需构件。CodeDeployToECS 部署操作中的构件 ZIP 大小上限为 3 MB。如果找不到文件或构件大小超过 3 MB，则会返回以下错误消息：

尝试从以下位置读取任务定义构件文件时出现异常：<source artifact name>

可能的修复措施：确保包含任务定义文件构件。如果文件已经存在，请确保压缩后的大小小于 3 MB。

GitHub 版本 1 源操作：存储库列表显示不同的存储库

问题：

在 CodePipeline 控制台中成功授权 GitHub 版本 1 操作后，您可以从 GitHub 存储库列表中进行选择。如果列表中不包括您期望看到的存储库，则可以对用于授权的账户进行故障排除。

可能的修复措施：CodePipeline 控制台中提供的存储库列表基于授权账户所属的 GitHub 组织。确认您用于授权 GitHub 操作的账户是否为创建存储库的 GitHub 组织的关联账户。

GitHub 版本 2 源代码操作：无法完成存储库连接

问题：

由于到 GitHub 存储库的连接使用 AWS Connector for GitHub，因此您需要组织所有者权限或存储库的管理员权限才能创建连接。

可能的修复措施：有关 GitHub 存储库的权限级别的信息，请参阅 https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-organizations-and-teams/permission-levels-for-an-organization。

Amazon S3 错误：CodePipeline 服务角色 <ARN> 正在拒绝 S3 访问 S3 桶 <BucketName>

问题：

在进行的过程中，CodePipeline 中的 CodeCommit 操作会检查管道构件桶是否存在。如果操作无权检查，则 Amazon S3 中会出现 AccessDenied 错误，并且 CodePipeline 中会显示以下错误消息：

CodePipeline 服务角色“arn:aws:iam::AccountID:role/service-role/RoleID”正在拒绝 S3 访问 S3 桶“桶名称”

该操作的 CloudTrail 日志也会记录 AccessDenied 错误。

可能的修复措施：执行以下操作：

  • 对于附加到 CodePipeline 服务角色的策略，将 s3:ListBucket 添加到策略中的操作列表中。有关查看您的服务角色策略的说明，请参阅查看管道 ARN 和服务角色 ARN（控制台）。编辑您的服务角色的策略声明，详情请参见向 CodePipeline 服务角色添加权限。

  • 对于附加到管道的 Amazon S3 构件桶的基于资源的策略（也称为构件桶策略），请添加一个语句以允许 CodePipeline 服务角色使用 s3:ListBucket 权限。

    将您的策略添加到构件桶

    1. 按照查看管道 ARN 和服务角色 ARN（控制台）中的步骤在管道设置页面上选择您的构件桶，然后在 Amazon S3 控制台中进行查看。

    2. 选择权限。

    3. 在 Bucket policy (存储桶策略) 下，请选择 Edit (编辑)。

    4. 在策略文本字段中，输入新的桶策略，或编辑现有策略，如以下示例所示。桶策略是一个 JSON 文件，因此您必须输入有效的 JSON。

      以下示例显示了构件桶的桶策略声明，其中服务角色的示例角色 ID 为 AROAEXAMPLEID。

      {
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::BucketName",
    "Condition": {
        "StringLike": {
            "aws:userid": "AROAEXAMPLEID:*"
        }
    }
}

      以下示例显示了添加权限后的相同桶策略声明。

      {
    "Version": "2012-10-17",
    "Id": "SSEAndSSLPolicy",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890",
            "Condition": {
                "StringLike": {
                    "aws:userid": "AROAEXAMPLEID:*"
                }
            }
        },
        {
            "Sid": "DenyUnEncryptedObjectUploads",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890/*",
            "Condition": {
                "StringNotEquals": {
                    "s3:x-amz-server-side-encryption": "aws:kms"
                }
            }
        },
        {
            "Sid": "DenyInsecureConnections",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890/*",
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": false
                }
            }
        }
    ]
}

      有关更多信息，请参阅https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/ 中的步骤。

    5. 选择保存。

应用编辑过的策略后，按照手动启动管道中的步骤手动重新运行管道。

包含 Amazon S3、Amazon ECR 或 CodeCommit 源的管道不再自动启动

问题：

更改使用事件规则（EventBridge 或 CloudWatch Events）进行更改检测的操作的配置设置后，如果源触发器标识符相似且初始字符相同，控制台可能无法检测到更改。由于新的事件规则不是由控制台创建的，因此管道不再自动启动。

在 CodeCommit 的参数名称末尾稍作更改的一个例子是将 CodeCommit 分支名称 MyTestBranch-1 更改为 MyTestBranch-2。由于更改位于分支名称的末尾，因此源操作的事件规则可能不会为新的源设置更新或创建规则。

这适用于使用 CWE 事件进行更改检测的源操作，如下所示：

源操作 参数/触发器标识符（控制台）
Amazon ECR

存储库名称

映像标签
Amazon S3

存储桶

S3 对象键
CodeCommit

存储库名称

分支名称

可能的修复措施：

请执行以下操作之一：

  • 更改 CodeCommit/S3/ECR 配置设置，以便对参数值的起始部分进行更改。

    示例：将分支名称 release-branch 更改为 2nd-release-branch。避免在名称末尾进行更改，例如 release-branch-2。

  • 更改每个管道的 CodeCommit/S3/ECR 配置设置。

    示例：将分支名称 myRepo/myBranch 更改为 myDeployRepo/myDeployBranch。避免在名称末尾进行更改，例如 myRepo/myBranch2。

  • 不使用控制台，而是使用 CLI 或 AWS CloudFormation 创建和更新更改检测事件规则。有关为 S3 源操作创建事件规则的说明，请参阅连接到使用 EventBridge 和 AWS CloudTrail 的 Amazon S3 源操作。有关为 Amazon ECR 操作创建事件规则的说明，请参阅 Amazon ECR 源操作和 EventBridge 资源。有关为 CodeCommit 操作创建事件规则的说明，请参阅 CodeCommit 源操作和 EventBridge。

在控制台中编辑操作配置后，接受控制台创建的已更新的更改检测资源。

连接到 GitHub 时出现连接错误：“出现问题，请确保在浏览器中启用 Cookie” 或“组织拥有者必须安装 GitHub 应用程序”

问题：

要为 CodePipeline 中的 GitHub 源操作创建连接，您必须是 GitHub 组织的拥有者。对于不属于组织的存储库，您必须是存储库拥有者。当连接由非组织拥有者的其他用户创建时，将针对组织拥有者创建请求，并显示以下错误之一：

出现问题，请确保在浏览器中启用 Cookie

或

组织拥有者必须安装 GitHub 应用程序

可能的修复：对于 GitHub 组织中的存储库，组织拥有者必须创建与 GitHub 存储库的连接。对于不属于组织的存储库，您必须是存储库拥有者。

执行模式更改为 QUEUED 或 PARALLEL 模式的管道在达到运行限制时失败

问题：在 QUEUED 模式下，管道的最大并发执行数为 50 个。当达到此限制时，管道会失败，但不显示状态消息。

可能的修复：为执行模式编辑管道定义时，请与其它编辑操作分开进行。

有关 QUEUED 或 PARALLEL 执行模式的更多信息，请参阅 CodePipeline 概念。

如果将 PARALLEL 模式下的管道编辑为 QUEUED 或 SUPERSEDED 模式，则管道定义会过时

问题：对于 PARALLEL 模式下的管道，将管道执行模式编辑为 QUEUED 或 SUPERSEDED 时，不会更新 PARALLEL 模式的管道定义。更新 PARALLEL 模式时更新的管道定义不会在 SUPERSEDED 或 QUEUED 模式中使用

可能的修复：对于 PARALLEL 模式下的管道，在将管道执行模式编辑为 QUEUED 或 SUPERSEDED 时，应避免同时更新管道定义。

有关 QUEUED 或 PARALLEL 执行模式的更多信息，请参阅 CodePipeline 概念。

从 PARALLEL 模式更改的管道将显示之前的执行模式

问题：对于 PARALLEL 模式下的管道，将管道执行模式编辑为 QUEUED 或 SUPERSEDED 时，管道状态不会将更新的状态显示为 PARALLEL。如果管道从 PARALLEL 变成 QUEUED 或 SUPERSEDED，则管道在 SUPERSEDED 或 QUEUED 模式下的状态将是这两种模式下的最后已知状态。如果管道从未在该模式下运行过，则状态为空。

可能的修复：对于 PARALLEL 模式下的管道，将管道执行模式编辑为 QUEUED 或 SUPERSEDED 时，注意执行模式显示将不显示 PARALLEL 状态。

有关 QUEUED 或 PARALLEL 执行模式的更多信息，请参阅 CodePipeline 概念。

具有使用文件路径触发筛选的连接的管道可能不会在创建分支时启动

描述：对于具有使用连接的源操作（如 BitBucket 源操作）的管道，可以通过 Git 配置设置一个触发器，允许您根据文件路径筛选来启动管道。在某些情况下，对于带有根据文件路径筛选的触发器的管道，当首次创建带有文件路径筛选条件的分支时，管道可能无法启动，因为这不允许 CodeConnections 连接解析已更改的文件。当触发器的 Git 配置设置为根据文件路径筛选时，源存储库中刚刚创建了带有筛选条件的分支，管道就不会启动。有关根据文件路径筛选的更多信息，请参阅筛选代码推送或拉取请求的触发器。

结果：例如，当创建分支“B”时，CodePipeline 中对分支“B”有文件路径筛选条件的管道将不会被触发。如果没有文件路径筛选条件，管道仍将启动。

当达到文件限制时，具有使用文件路径触发筛选的连接的管道可能无法启动

描述：对于具有使用连接的源操作（如 BitBucket 源操作）的管道，可以通过 Git 配置设置一个触发器，允许您根据文件路径筛选来启动管道。CodePipeline 最多检索前 100 个文件；因此，当触发器的 Git 配置设置为根据文件路径筛选时，如果文件超过 100 个，管道可能无法启动。有关根据文件路径筛选的更多信息，请参阅筛选代码推送或拉取请求的触发器。

结果：例如，如果差异包含 150 个文件，CodePipeline 会查看前 100 个文件（不按特定顺序），并根据指定的文件路径筛选条件进行检查。如果与文件路径筛选条件匹配的文件不在 CodePipeline 检索的 100 个文件中，管道将不会被调用。

PARALLEL 模式下的 CodeCommit 或 S3 源修订可能与 EventBridge 事件不匹配

描述：对于 PARALLEL 模式下的管道执行，执行可能会从最新的更改（如 CodeCommit 存储库的提交）开始，而最新的更改可能与 EventBridge 事件的更改不同。在某些情况下，启动管道的提交或图像标签之间可能会有一瞬间的间隔，当 CodePipeline 接收到事件并开始执行时，另一个提交或图像标签已被推送，CodePipeline（例如 CodeCommit 操作）将克隆此时的 HEAD 提交。

结果：对于使用 CodeCommit 或 S3 源的 PARALLEL 模式管道，无论触发管道执行的更改是什么，源操作都会在启动时克隆 HEAD。例如，对于 PARALLEL 模式下的管道，推送一次提交，启动管道执行 1，管道执行 2 使用第二次提交。

需要有关其他问题的帮助？

尝试其他资源：