GitHub Actions Runner镜像中Ubuntu 22/24版本的HTTPS连接稳定性问题分析

问题背景

在GitHub Actions的标准Runner环境中，使用Ubuntu 22.04和24.04镜像的用户报告了HTTPS连接不稳定的问题。这个问题表现为在进行大量并行HTTPS请求时，会出现连接重置(Connection reset)或读取超时(Read timeout)的错误，失败率约为20%。值得注意的是，同样的工作负载在Ubuntu 20.04环境中运行正常。

问题现象

用户通过最小化测试复现了这个问题：

• 使用curl进行150个并行HTTPS请求
• 测试目标是一个部署在AWS ELB(弹性负载均衡器)后端的服务
• 失败表现为两种形式：
  • OpenSSL SSL_connect: Connection reset by peer
  • Operation timed out after 30000 milliseconds

测试结果显示：

• Ubuntu 20.04：0次失败
• Ubuntu 22.04：33次失败
• Ubuntu 24.04：25次失败

根本原因分析

经过深入调查，发现问题与Ubuntu系统中systemd-resolved服务的DNS解析行为变更有关：

1. DNS解析行为变化：

   • 在Ubuntu 20.04中，systemd-resolved会从DNS返回的IP列表中选择一个IP并保持一段时间
   • 从Ubuntu 22.04开始，systemd-resolved会为每个请求随机返回列表中的一个IP（源于systemd的3f0a7b3a3224681fec0133fc5ef8d30f0f9b4fa5提交）

2. 问题触发条件：

   • 当目标域名解析到多个IP地址时（如AWS ELB场景）
   • 并行请求会使用不同的后端IP
   • 某些IP组合会导致连接不稳定

3. 环境特异性：

   • 问题仅在GitHub Actions环境中重现
   • 在普通AWS EC2实例上运行Ubuntu 22.04时无法复现
   • 说明问题可能与GitHub的网络环境配置有关

解决方案与临时缓解措施

临时解决方案

通过固定DNS解析结果可以解决此问题：

1. 手动解析并写入hosts文件：

   echo "$(dig +short stagingapi.dnanexus.com | head -n1) stagingapi.dnanexus.com" | sudo tee -a /etc/hosts
   

2. 定期更新解析（针对IP可能变化的场景）：

   while true; do
     echo "$(dig +short stagingapi.dnanexus.com | head -n1) stagingapi.dnanexus.com" | sudo tee /etc/hosts.new
     sudo mv /etc/hosts.new /etc/hosts
     sleep 300
   done
   

长期解决方案建议

1. 系统配置调整：

   • 修改systemd-resolved配置，启用DNS缓存
   • 调整glibc的DNS解析行为

2. 应用层解决方案：

   • 在应用程序中实现DNS缓存
   • 使用连接池管理HTTP连接

3. 网络层优化：

   • 考虑使用HTTP/2减少连接数
   • 实现重试机制处理偶发失败

技术细节深入

systemd-resolved行为分析

Ubuntu 22.04引入的systemd-resolved变更旨在提高负载均衡效果，但在特定网络环境下可能导致问题：

1. Round-Robin DNS：

   • 传统DNS轮询策略可能更适合稳定连接
   • 随机选择策略在复杂网络环境中可能引发问题

2. 连接复用影响：

   • 不同IP导致无法复用TCP连接
   • 增加TLS握手开销

AWS ELB特性影响

AWS负载均衡器的以下特性可能加剧此问题：

1. 多AZ部署：

   • 不同可用区的ELB节点可能有不同网络特性
   • 跨AZ通信可能引入额外延迟

2. 连接跟踪：

   • ELB对短时大量新建连接可能有特殊处理
   • 源IP分散可能导致ELB限流

最佳实践建议

对于在GitHub Actions中使用Ubuntu 22.04/24.04 Runner的用户：

1. 关键任务工作流：

   • 优先使用Ubuntu 20.04（在完全退役前）
   • 或实施上述hosts文件解决方案

2. 测试策略：

   • 增加测试重试机制
   • 监控网络错误率

3. 依赖服务访问：

   • 考虑使用单IP入口点
   • 评估使用VPC端点等AWS原生解决方案

结论

这个问题展示了底层系统组件变更对应用稳定性的潜在影响。虽然systemd-resolved的变更有其合理性，但在特定环境配置下可能引发兼容性问题。目前推荐的解决方案是通过固定DNS解析结果来规避问题，同时建议关注GitHub官方Runner镜像的后续更新。