AWS Image Builder Plugin for TeamCity
TL;DR · AI 摘要
TeamCity 现在支持通过 AWS Image Builder 插件自动更新 AMI 镜像，提升云构建代理的维护效率。
核心要点
- 使用 AWS Image Builder 插件可自动化 AMI 更新，减少手动维护工作。
- TeamCity 云构建代理从静态镜像启动，需定期更新以避免过时。
- 插件支持在 TeamCity 中配置 AWS 连接和网络设置，实现镜像构建自动化。
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- AWS Image Builder 插件
- 优势
- 自动化 AMI 更新
- 减少手动维护
- 使用场景
- TeamCity 云构建代理
- AWS 环境
- 配置步骤
- 安装插件
- 配置 AWS 连接
- 创建构建配置
金句 / Highlights
值得收藏与分享的关键句。
云构建代理从静态镜像启动，镜像一旦过时，所有新代理都需要花费时间更新。
AWS Image Builder 插件将镜像维护从手动任务转变为 TeamCity 的构建配置。
插件支持在 TeamCity 中配置 AWS 连接和网络设置，实现镜像构建自动化。
TeamCity 的 AWS Image Builder 插件 - JetBrains 博客
TeamCity
面向 DevOps 团队的强大 CI/CD 工具
关注
- 关注：
- X X
- YouTube YouTube
- RSS RSS
获取 TeamCity
TeamCity 的 AWS Image Builder 插件
Dmitrii Korovin
当一切运行良好时，云构建代理是 CI/CD 功能中几乎感觉像魔法一样的部分。当队列繁忙时，您的 TeamCity 服务器可以扩展构建能力，当高峰期结束时，又可以将其缩减回来。您在需要时获得额外的计算能力，而无需在其他时间让机器空闲。
它们还使构建更干净、更可预测。每个云代理都从云镜像启动一个全新的虚拟机，因此每个构建都获得一个隔离的环境，而不是继承前一个构建留下的状态。可扩展、成本高效且可靠，云构建代理是真正稳健且高效 TeamCity 设置的理想选择。
当然，云构建代理并非没有权衡之处。最明显的一个是维护。代理是从静态机器镜像启动的，而一旦您的工具发生变化或 TeamCity 服务器更新，该镜像就开始老化。突然之间，每个新的代理都需要花费宝贵的时间来追赶……或者您必须重复熟悉的循环：启动一个实例，安装更新，创建一个新的快照，并更新 TeamCity 的云配置。
大型仓库又增加了另一个复杂性。由于每个云代理都从一个全新的虚拟机启动，它也从一个空的检出目录开始。仓库越大，每个构建花费在拉取源代码上的时间就越多。一个变通方法是将仓库镜像与您的工具一起烘焙到镜像中，这样代理只需要获取最新的提交。但这也只是临时的：随着更改的积累，镜像会变得过时，镜像需要再次更新。
如果您在 Amazon Web Services 上运行基于 AMI 的云构建代理，处理这个问题有一个更好的方法——AWS Image Builder 插件。它将镜像维护从手动、重复的任务转变为 TeamCity 的常规构建配置。
先决条件
要自动化 AMI 更新，请从 JetBrains Marketplace 下载并安装 AWS Image Builder TeamCity 插件。您可以在 TeamCity 中直接完成此操作：导航到“管理” | “插件”，然后点击“浏览插件仓库”。安装后不要忘记启用此插件。
您还需要在 TeamCity 中配置合适的 AWS 连接。该连接的 IAM 主体需要 EC2 权限来启动实例、创建镜像和读取 VPC 元数据。
创建构建配置
- 一旦插件安装并启用，就在具有访问上一节中提到的 AWS 连接权限的项目下创建一个新的构建配置。
- 添加 Image Builder AWS AMI 构建步骤。
- 指定核心步骤设置：
- AWS 连接 – 选择 TeamCity 用于与 AWS 通信的连接。
- 基础 AMI – 选择此配置将重新构建的 AMI。
- 网络设置 – 用于访问 AWS 资源。
- 标签 – 将分配给新构建的 AMI 的 name=value 标签列表。如果您希望 TeamCity 自动更新其云配置（请参见下文），此步骤非常重要。
- 镜像访问 – 输入账户 ID、组织 ARN 或 OU ARN，以指定谁可以访问您新构建的镜像。
- 勾选安装 TeamCity agent，将构建代理集成到 AMI 中。代理的完整分发版本将直接从 TeamCity 实例获取，因此您的代理将始终与服务器版本保持一致。在 TeamCity 进行重大更新后，运行此构建配置，为 AMI 提供相应的代理版本。
- 指定构建过程中可选的脚本（TeamCity 的首次运行脚本文件；内联脚本将在最后执行）。您可以使用这些脚本来安装运行时、SDK、代理插件，或执行其他在每次代理启动时都会运行的环境设置。
- 启用 VCS 镜像以加快构建检出阶段的速度。该插件将根据与此配置关联的 VCS 根目录，预先填充 Git 对象镜像。这些根目录包含所有必要的信息（连接详细信息、凭据、子模块检出策略等），使它们成为完成此任务的完美工具。
要指定哪些镜像应集成到 AMI 中：
- 保存构建步骤，返回到构建配置设置。
- 导航到版本控制标签页，点击“附加 VCS 根”。
- 如果您的 AMI 构建器配置属于与拥有常规配置（用于构建、测试和部署所需仓库）的相同项目，可以附加一个现有的 VCS 根。否则，创建一个新的 VCS 根。
- 对于新创建的 Git VCS 根，指定获取 URL 和授权设置。
- 将根的检出策略更改为“使用镜像”。
运行构建器配置
在填写完所有构建步骤和 VCS 根设置后，运行该配置并验证结果。
- 检查 teamcity.build.awsImageBuilder.amiId 构建参数的值，该参数存储了新镜像的 AMI ID。
- 导航到“制品”标签页，查看隐藏的 .teamcity/image_builder/ 制品。该目录存储了一个生成的 HashiCorp Packer 模板，AWS Image Builder 插件使用它来上传最终的 AMI。
- 登录到 AWS 控制台，验证新的 AMI 是否已发布并打上标签。
更新 TeamCity 云配置文件
构建一个更新后的 AMI 仅仅是自动化故事的一半。下一步是确保 TeamCity 在 AMI 准备就绪后能自动使用它。
为此，请前往“项目设置” | “云配置文件”，打开您要更新的配置文件，并检查其中的每个云镜像。将“实例”切换设置为“通过标签选择 AMI”，使 TeamCity 通过标签而不是固定的 AMI ID 来选择镜像。使用与在镜像构建器构建步骤中配置的相同 AMI 标签。
随着时间的推移，重复的镜像构建器运行将生成多个带有相同标签的 AMI，但这不会成为问题。当云镜像使用“通过标签选择 AMI”策略时，TeamCity 会定期检查 AWS 中的匹配 AMI，并选择创建日期最新的那个。这意味着您的云代理可以持续从最新的 AMI 启动，而无需手动更新配置文件。
Kotlin DSL
如果您更喜欢使用 Kotlin DSL 而不是 TeamCity UI 来配置 TeamCity 的工作流，以下是如何在代码中配置 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 工单中告诉我们。
Amazon EC2
aws
cloud agent
plugin
- 分享
上一篇博客
Bamboo 生命周期结束：如何准备并选择合适的 CI/CD 替代方案