GitHub Actions Runner在Azure VNET中的连接问题分析与解决方案

问题背景

在使用GitHub Actions的自托管运行器时，当运行器部署在Azure容器应用(Container App)或容器实例(Container Instance)中且未连接Azure虚拟网络(VNET)时，运行器能够稳定运行数周，自动更新和连接GitHub都没有问题。然而，一旦将容器连接到Azure VNET，就会出现间歇性的连接问题，有时甚至会在作业执行过程中断开连接，自动更新功能也会失败。

问题表现

运行器在VNET环境中表现出以下症状：

1. 间歇性连接中断，错误信息显示"HTTP请求在2分钟后超时"
2. 自动更新功能失败
3. 长时间运行的作业可能会因连接中断而失败

根本原因分析

经过深入调查，这个问题与Azure的网络地址转换(SNAT)端口耗尽有关。当容器应用连接到VNET时，出站连接会使用SNAT端口进行转换。Azure对SNAT端口数量有限制，当并发连接数过多或连接保持时间过长时，会导致SNAT端口耗尽，从而引发间歇性连接问题。

解决方案

针对这个问题，可以采用以下几种解决方案：

1. 使用NAT网关：为容器子网配置NAT网关，这是最直接的解决方案。NAT网关提供可扩展的SNAT端口资源，能有效避免端口耗尽问题。

2. 优化连接管理：

   • 减少同时建立的连接数
   • 缩短连接保持时间
   • 实现连接池管理

3. 调整运行器配置：

   • 增加HTTP请求超时时间(虽然原问题中尝试增加到2分钟未解决问题)
   • 配置运行器更积极地释放闲置连接

实施建议

对于部署在Azure VNET中的GitHub Actions自托管运行器，强烈建议：

1. 为运行器所在的子网配置NAT网关，这是最可靠的解决方案
2. 监控SNAT端口使用情况，设置警报以便及时发现问题
3. 考虑将运行器部署在具有足够SNAT端口资源的专用子网中

结论

Azure VNET环境中的SNAT端口限制是导致GitHub Actions运行器间歇性连接问题的常见原因。通过正确配置网络基础设施，特别是使用NAT网关，可以显著提高运行器的稳定性和可靠性。对于关键业务场景中的自托管运行器，网络配置的优化应该是部署过程中的重要考虑因素。