云构建代理是CI/CD中那些在一切顺利时几乎让人感觉神奇的功能之一。当队列繁忙时，你的TeamCity服务器可以扩展构建容量，当高峰过去后，再缩减回来。你恰好能在需要时获得额外算力，而无需让机器在其余时间闲置。

它们还让构建更加干净和可预测。每个云代理都从云镜像的全新虚拟机启动，因此每个构建都能获得隔离的环境，而不是继承前一个构建遗留下来的状态。可扩展、经济高效且可靠，云构建代理是真正稳健、精简的TeamCity配置的完美选择。

当然，云构建代理并非没有代价。最明显的一点是维护。代理从静态机器镜像启动，而一旦你的工具链发生变化或TeamCity服务器更新，该镜像就开始老化。突然之间，每个新代理都不得不花宝贵的时间追赶……或者你必须重复熟悉的循环：启动实例、安装更新、创建新快照、更新TeamCity云配置文件。

大型代码仓库则带来了另一个难题。由于每个云代理都从全新虚拟机启动，其检出目录也是空的。仓库越大，每个构建花在拉取源码上的时间就越多。一种解决方法是把仓库镜像连同工具一起烘焙到镜像中，这样代理只需拉取最新的提交。但这也是暂时的：随着变更累积，镜像会变得过时，又需要再次更新。

如果你在亚马逊云服务上运行基于AMI的云构建代理，有一种更好的处理方式——AWS Image Builder插件。它将镜像维护从手动、重复的杂务转变为常规的TeamCity构建配置。

前提条件

要自动化AMI更新，请从JetBrains Marketplace下载并安装AWS Image BuilderTeamCity插件。你可以直接在TeamCity中操作：导航至 管理 | 插件，然后点击 浏览插件仓库。安装后别忘了启用该插件。

你还需要在TeamCity中配置一个合适的 AWS连接。该连接的IAM主体需要具备EC2权限来启动实例、创建镜像以及读取VPC元数据。

创建构建配置

1. 安装并启用插件后，在可以访问上一节提到的AWS连接的项目下，创建一个新的构建配置。

2. 添加 Image Builder AWS AMI 构建步骤。

   [LOADING...]

3. 指定核心步骤设置：

   • AWS 连接 —— 选择TeamCity用于与AWS通信的连接。
   • 基础 AMI —— 选择该构建配置要重建的AMI。
   • 网络设置 —— 需要访问AWS资源。
   • 标签 —— 将分配给新构建AMI的name=value标签列表。如果你希望TeamCity自动更新其云配置文件，这一步很重要（见下文）。
   • 镜像访问 —— 输入账户ID、组织ARN或OU ARN，以指定哪些用户可以访问你新建的镜像。

4. 勾选 安装 TeamCity 代理，将构建代理烘焙进AMI。完整的代理分发版将直接从TeamCity实例获取，因此你的代理版本将始终与服务器版本匹配。在重大TeamCity更新后，运行此构建配置，为你的AMI提供相应的代理版本。

5. 指定在构建过程中运行的可选脚本（TeamCity首次运行脚本文件；内联脚本将最后执行）。你可以使用这些脚本安装运行时、SDK、代理插件，或执行任何否则会在每次代理启动时运行的环境设置。

6. 启用VCS镜像以加快构建检出阶段。插件将根据该配置所附的VCS根，用Git对象镜像预填充镜像。VCS根包含了所有必需的信息（连接详情、凭据、子模块检出策略等），因此非常适合这项工作。

要指定应烘焙哪些镜像：

• 保存构建步骤，返回构建配置设置。
• 导航至 版本控制 选项卡，点击 附加 VCS 根。
• 如果你的AMI构建配置与包含常规构建、测试和部署所需仓库的配置属于同一项目，则可以附加一个已有的VCS根。否则，请创建一个新的。
• 对于新建的Git VCS根，指定拉取URL和授权设置。
• 将根的 检出策略 切换为 使用镜像。

运行构建配置

填写完所有构建步骤和VCS根设置后，运行该配置并验证结果。

• 检查 teamcity.build.awsImageBuilder.amiId 构建参数的值，该参数存储了新镜像的AMI ID。

• 导航至 构件 选项卡，查看隐藏的 .teamcity/image_builder/ 构件。该目录存储了AWS Image Builder插件用于上传最终AMI的生成的 HashiCorp Packer模板。

• 登录AWS控制台，验证新AMI已发布并打上标签。

  [LOADING...]

更新 TeamCity 云配置文件

构建更新后的AMI只是自动化故事的一半。下一步是确保TeamCity在镜像准备好后立即开始使用它。

为此，请前往 项目设置 | 云配置文件，打开要更新的配置文件，并检查其中的每个云镜像。将 实例 开关设置为 通过标签选择 AMI，这样TeamCity就会根据标签而不是固定的AMI ID来选择镜像。使用你在镜像构建器构建步骤中配置的相同AMI标签。

随着时间推移，重复运行镜像构建器会产生多个具有相同标签的AMI，但这不会成为问题。当云镜像使用 通过标签选择 AMI 策略时，TeamCity会定期检查AWS中匹配的AMI，并选择创建日期最新的那个。这意味着你的云代理可以始终从最新的AMI启动，而无需手动更新配置文件。

Kotlin DSL

如果你更喜欢在 Kotlin DSL 中配置TeamCity工作流程，而非通过TeamCity UI，以下是代码中配置AMI构建器步骤的方法：

awsImageBuilderBuild {

    name = "Build Agent AMI"

    awsConnectionId = "AmazonWebServicesAws"

    baseAmi = "ami-0xxxxxxxxxxxxxxxxx"

    instanceType = "t3.medium"

    subnetId = "subnet-0xxxxxxxxxxxxxxxxx"

    tags = """

        role=teamcity-agent

        env=prod

    """.trimIndent()

    includeAgent = true

    inlineScript = "systemctl enable teamcity-agent"

}

告诉我们你的想法

我们热衷于构建能够解决日常DevOps挑战的功能。AWS Image Builder插件正是为此而生——它让云构建代理的维护变得简单得多，让你少花时间调整镜像，多花时间关注构建。

一如既往，您的反馈至关重要。如果您遇到问题，或者觉得缺少重要的自定义选项，请通过 JetBrains Marketplace插件页面 上的评论，或相应的 YouTrack工单 告诉我们。