AWS Route 53 - 到应用程序负载均衡器不同端口的域名路由
Posted
技术标签:
【中文标题】AWS Route 53 - 到应用程序负载均衡器不同端口的域名路由【英文标题】:AWS Route 53 - Domain name route to different ports of an Application load balancer 【发布时间】:2017-06-08 20:34:43 【问题描述】:我们正在 AWS 中实施微服务架构。我们有几个 EC2 实例,它们将微服务部署在不同的端口上。我们还有一个面向 Internet 的应用程序负载均衡器,它根据端口路由到不同的服务。
eg:
xxxx-xx.xx.elb.amazonaws.com:8080/ go to microservice 1
xxxx-xx.xx.elb.amazonaws.com:8090/ go to microservice 2
我们需要一个域名而不是ELB,端口也不应该通过域名暴露出来。我发现的几乎所有关于 53 号路线的资源都使用 alias ,它执行以下操作:
xx.xxxx.co.id -> xxxx-xx.xx.elb.amazonaws.com or
xx.xxxx.co.id -> 111.111.111.11 (static ip)
1) 每个微服务是否需要单独的域?
2) 如何使用别名将域指向 ELB 的特定端口?
3) 如果域来自 AWS 以外的其他提供商,是否可以使用此设置。
【问题讨论】:
【参考方案1】:重要更新
由于最初编写此答案,Application Load Balancer introduced the capability for ALB to route requests to a specific target group based on the Host
header of the incoming request。
传入的主机标头现在可用于将请求路由到特定实例和端口。
另外,ALB introduced SNI support,允许您将多个 TLS (SSL) 证书与单个平衡器相关联,并且在协商 TLS 时,将根据客户端提供的 SNI 自动选择正确的证书。来自 Amazon Certificate Manager 的多域和通配符证书也适用于 ALB。
基于这些因素,不需要单独的端口或不同的侦听器——只需为每个服务分配主机名和/或路径前缀,并将这些模式映射到适当的目标实例组。
原来的答案不再准确,但包含在下面。
1.) 每个微服务是否需要单独的域?
不,这对你没有帮助。 ALB 不会解释附加到传入请求的主机名。
同一域中的不同主机名也不会直接实现您的目标。
2.) 如何使用别名将域指向 ELB 的特定端口?
域不指向端口。主机名不指向端口。 DNS 仅用于地址解析。这在互联网上无处不在。
3.) 如果域来自 AWS 以外的其他提供商,是否可以使用此设置。
这不是 AWS 的限制。 DNS 根本无法以这种方式工作。
服务端点不知道指向它的 DNS 记录。 DNS 条目本身严格用于发现可用于访问端点的 IP 地址。之后,端点实际上并不知道任何关于 DNS 的信息,并且无法通过 DNS 告诉浏览器使用不同的端口。
对于 HTTP,隐式端口是 80。对于 HTTPS,它是 443。除非在 URL 中提供端口,否则这些是唯一可用的端口。
但是,在 HTTP 和 HTTPS 中,每个请求都伴随有一个 Host:
标头,由 Web 浏览器随每个请求一起发送。这是地址栏中的主机名。
为了区分到达设备(例如 ELB/ALB)的不同主机名的请求,端点的设备必须解释传入的主机标头并将请求路由到提供该服务的后端系统。
ALB 当前不支持此功能。
但是,ALB 确实支持基于路径前缀选择端点。所以 microservices.example.com/api/foo 可以路由到一组服务,而 microservices.example.com/api/bar 可以路由到另一组。
但是 ALB 不直接支持按主机头路由。
在我的基础架构中,我们使用 ELB 或 ALB 的组合,但负载均衡器背后的实例不是应用程序。相反,它们是运行 HAProxy 负载平衡器软件并将请求路由到后端的实例。
重要配置元素的简要示例如下所示:
frontend main
use_backend svc1 if hdr(Host) -i foo.example.com
use_backend svc2 if hdr(Host) -i bar.example.com
backend svc1
server foo-a 192.168.2.24:8080
server foo-b 192.168.12.18:8080
backend svc2
....
ELB 终止 SSL 并随机选择一个代理,代理检查 Host:
标头并选择将请求路由到的后端(一组 1 个或多个实例)。它是 ELB 和应用程序之间的一个薄层,它通过检查主机标头或请求的任何其他特征来处理请求路由。
这是一种解决方案,但它是一种高级配置,具体取决于您的专业知识。
如果您正在寻找开箱即用、无服务器、以 AWS 为中心的解决方案,那么实际上可以在 CloudFront 中找到答案。是的,它是一个 CDN,但它还有其他几个应用程序,包括作为反向代理。
对于每个服务,从您的域中选择一个主机名以分配给该服务,foo.api.example.com 或 bar.api.example.com。
为每项服务创建一个 CloudFront 分配。
配置每个分发的备用域名以使用该服务的分配主机名。
将源域名设置为 ELB 主机名。
将 Origin HTTP Port 设置为 ALB 上服务的特定端口,例如8090.
配置默认缓存行为以转发您需要的任何标头。如果您不需要 CloudFront 的缓存功能,请选择 Forward All Headers。如果需要,还可以启用查询字符串和 Cookie 的转发。
在 Route 53 中,创建 foo.api.example.com 作为该特定 CloudFront 分配的主机名的别名,例如dxxxexample.cloudfront.net.
你的问题解决了。
你看到我在那里做了什么吗?
对于您配置的每个主机名,专用 CloudFront 分配会在标准端口 (80/443) 上接收请求,并且 -- 基于主机标头匹配的分配 -- CloudFront 将请求路由到相同 ELB/ALB 主机名,但自定义端口号。
【讨论】:
谢谢。这真是一个很好的解释。不幸的是,我们将无法继续使用 CloudFront,因为我们已经使用 elb 设置了微服务。并且它目前处于测试阶段。因此,我们将不得不采用您提到的其他解决方案。我是 AWS 基础设施的新手,您能否使用 HAProxy 为我指明正确的方向 我不确定我是否清楚,或者您是否完全理解我的回答,基于您的评论 “我们已经用 elb 设置了微服务。” ELB 保持不变。 CloudFront 可以让您将多个主机名指向 ELB 的不同端口,而无需 URL 中的端口。与使用 HAProxy 相比,这应该是一个更少破坏性的更改。 我的印象是我们不得不放弃使用 Cloudfront。感谢您为我澄清这一点。我是 AWS 的新手,非常感谢您的评论。我将研究云端。如果这对你来说不是问题,你能给出任何指示吗? 查看上面的项目符号列表中的步骤。您应该能够在 CloudFront 和 Route 53 中浏览这些内容,而无需更改您当前的设置——这将成为我所说的“覆盖”——这是访问服务的“替代”方式,它不会现在,不要阻止他们按照他们已经工作的方式工作。一旦你有这个工作,旧方法(http://elb-host:8090
)在技术上仍然有效,你不需要使用它。另外,如果您需要我的联系信息,请单击我的姓名以查看我的个人资料。【参考方案2】:
我认为他有可能构建他所描述的内容。我在同一条船上有一段时间了,这里有一些选择供您考虑:
在 R53 中创建一个托管区域 - 并将您的域指向它。 可选步骤:创建别名记录。您可以为每个子域执行此操作或 应用程序。如果使用根域,请将 ALIAS 字段留空。 使用 SLA 选项创建记录集,该选项是端口的服务查找 重定向。尝试将其指向您的 LB 端口 80,为子域设置别名。 更改负载平衡器的侦听器,以侦听端口 80 - 然后根据您的应用端口设置重定向应用流量。我没有使用过 SLA,但这肯定会为您指明方向。
【讨论】:
以上是关于AWS Route 53 - 到应用程序负载均衡器不同端口的域名路由的主要内容,如果未能解决你的问题,请参考以下文章
尝试创建 aws_route53_record 以指向负载均衡器,但使用 terraform 不断出现错误