能否采用蓝绿部署方案升级AWS上的关键Artifactory实例？

核心结论 #

直接共用RDS的蓝绿部署方案不可行，会导致数据损坏、实例冲突等严重问题；EFS需要独立复制，S3需谨慎隔离，join.key也会引发启动或运行异常。

具体问题拆解 #

1. 共用RDS的风险 #

• Artifactory跨版本升级通常会修改数据库schema，旧版本实例读取被新版本修改后的schema会直接崩溃，或出现元数据读取异常。
• 两个实例并行读写同一RDS会触发数据竞争、锁冲突，导致元数据不一致、任务队列混乱，甚至永久性数据损坏。
• 必须为绿环境配置独立的RDS实例：备份旧RDS并恢复到新实例，让新版本Artifactory在独立数据库上完成schema迁移和测试，完全隔离蓝绿环境的数据操作。

2. EFS复制的注意事项 #

• 复制EFS是可行的，但必须创建独立的EFS实例：
  • 复制前需确保蓝环境Artifactory处于稳定状态（可临时停止写入或用EFS快照），避免复制不一致的文件。
  • 绿环境挂载独立的EFS副本，禁止与蓝环境共用同一EFS——否则两个实例同时读写文件系统会引发缓存不一致、文件锁冲突，导致服务异常。

3. S3共用的谨慎处理 #

• 如果S3用于存储二进制文件或远程缓存，理论上可共用，但需满足两个前提：
  • 确认新版本与旧版本的S3操作逻辑完全兼容，不会修改现有对象的结构或元数据。
  • 为绿环境配置独立的S3前缀，避免两个实例操作同一批对象时出现覆盖或读取异常。
• 跨大版本升级时，建议直接使用独立的S3存储，测试完成后再迁移数据，彻底避免兼容性风险。

4. join.key的冲突问题 #

• join.key是Artifactory用于节点认证的密钥，数据库中会存储当前实例的join.key：
  • 若两个实例共用同一RDS，其中一个实例启动时会覆盖数据库中的join.key，导致另一个实例因密钥不匹配无法启动或运行异常。
  • 即使复制EFS，新实例的join.key若与旧实例一致，Artifactory会识别为同一节点，引发集群冲突；若不一致，又会与数据库中存储的密钥不匹配，启动失败。
• 只有在蓝绿环境完全隔离数据库的前提下，各自生成独立的join.key，才能避免此类问题。

推荐的蓝绿部署流程 #

• 蓝环境（旧版本）：保留原ECS容器、EFS、RDS、S3，正常提供服务。
• 绿环境（新版本）：
  1. 基于旧EFS快照创建新的独立EFS实例。
  2. 备份旧RDS实例，恢复到新的独立RDS实例。
  3. 配置独立的S3存储（或独立前缀）。
  4. 部署新版本Artifactory镜像到ECS，挂载新EFS、连接新RDS和S3。
  5. 启动绿环境实例，完成自动schema迁移，开展功能、兼容性测试。
  6. 测试通过后，切换流量到绿环境，验证稳定后销毁蓝环境。

内容的提问来源于stack exchange，提问作者DenCowboy