Kamal 2在Digital Ocean与CDN环境下的负载均衡实践

在基于Kamal 2部署Rails应用时，结合Digital Ocean（DO）负载均衡器（LB）和CDN的架构会遇到一些典型挑战。本文将深入分析问题本质并提供专业解决方案。

核心问题分析

当采用CDN -> DO LB -> Kamal-proxy的架构时，DO负载均衡器的健康检查机制会失效。根本原因在于：

1. Kamal-proxy默认要求请求必须匹配deploy.yml中配置的特定主机名才会响应
2. DO LB的健康检查请求不携带主机头信息
3. 导致健康检查始终失败，后端服务器被标记为不可用

技术背景解析

Kamal 2的代理层设计初衷是为单服务器部署提供SSL终止和主机路由功能。其工作流程包括：

• 验证请求Host头是否匹配配置
• 执行TLS终止（如启用SSL）
• 将请求路由到对应容器

这种设计在加入中间层负载均衡器时会产生兼容性问题。

专业解决方案

方案一：简化架构（推荐）

1. 在Kamal配置中设置：

proxy: false
assume_ssl: true

2. 直接在CDN启用负载均衡功能
3. 将CDN LB的HTTPS流量直连应用服务器

优势：

• 完全避免DO LB的健康检查问题
• 保持DNS管理在CDN
• 简化网络拓扑

方案二：修改健康检查配置

如需坚持使用DO LB：

1. 为Kamal-proxy配置默认后端路由
2. 修改Nginx模板增加无Host头请求的处理
3. 确保/up端点可被匿名访问

实现要点：

• 定制Kamal的Nginx配置模板
• 添加默认server块处理无Host请求
• 保持现有路由逻辑不变

架构选择建议

对于中小规模部署，推荐采用方案一的CDN LB直连架构，因为：

1. 减少中间跳数，降低延迟
2. 避免多层TLS加解密开销
3. 利用CDN的全球网络
4. 简化证书管理（仅需CDN证书）

对于需要混合云或特定区域流量的场景，才需要考虑方案二的DO LB集成方案。

最佳实践总结

1. 明确各层的职责边界：

   • CDN：DNS、全局负载、安全防护
   • Kamal：应用部署和容器编排
   • 避免功能重叠

2. 监控指标：

   • 健康检查成功率
   • 端到端延迟
   • TLS握手时间

3. 安全配置：

   • 确保CDN到源站的通信安全
   • 合理设置安全规则
   • 定期轮换证书

通过理解Kamal的工作原理和云服务商的特性，可以构建出既高效又可靠的部署架构。