AWS Route 53 - 域名路由到应用程序负载均衡器的不同端口 [英] AWS Route 53 - Domain name route to different ports of an Application load balancer

问题描述

我们正在 AWS 中实施微服务架构.我们有几个 EC2 实例，它们在不同的端口上部署了微服务.我们还有一个面向互联网的 Application Load Balancer，它根据端口路由到不同的服务.

We are implementing a micro-services architecture in AWS. We have several EC2 instances which has the micro-services deployed on different ports. We also have an internet facing Application Load Balancer, which routes to different services based on the port.

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 号路线的资源都使用别名，它执行以下操作:

We need to have a domain name instead of the ELB, the port should not be exposed through the domain name as well. Almost all the resources I found regarding route 53, use alias which does the following:

xx.xxxx.co.id -> xxxx-xx.xx.elb.amazonaws.com or
xx.xxxx.co.id -> 111.111.111.11 (static ip)

1) 每个微服务都需要单独的域吗?

1) Do we need separate domains for each micro service?

2) 如何使用别名将域指向 ELB 的特定端口?

2) How to use alias to point domains to a specific port of the ELB?

3) 如果域来自除 AWS 之外的其他提供商，是否可以使用此设置.

3) Is it possible to use this setup if the domains are from another provider other than AWS.

推荐答案

重要更新

由于这个答案最初是写的，Application Load Balancer 引入了 ALB 的功能，可以根据传入请求的 Host 标头 将请求路由到特定目标组.

Since this answer was originally written, 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.

传入的主机标头现在可用于将请求路由到特定实例和端口.

The incoming host header can now be used to route requests to specific instances and ports.

此外，ALB 引入了 SNI 支持，允许您将多个 TLS (SSL) 证书与单个平衡器相关联，并且在协商 TLS 时将根据客户端提供的 SNI 自动选择正确的证书.来自 Amazon Certificate Manager 的多域和通配符证书也适用于 ALB.

Additionally, ALB introduced SNI support, allowing you to associate multiple TLS (SSL) certificates with a single balancer, and the correct certificate will be automatically selected based on the SNI presented by the client when TLS is negotiated. Multi-domain and wildcard certs from Amazon Certificate Manager also work with ALB.

基于这些因素，不需要单独的端口或不同的侦听器——只需为每个服务分配主机名和/或路径前缀，并将这些模式映射到适当的目标实例组.

Based on these factors, no separate ports or different listeners are needed -- simply assign hostnames and/or path prefixes for each service, and map those patterns to the appropriate target group of instances.

原始答案不再准确，但包含在下面.

The original answer is no longer accurate, but is included below.

1.) 每个微服务都需要单独的域吗?

1.) Do we need separate domains for each micro service?

不，这对您没有帮助.ALB 不会解释附加到传入请求的主机名.

No, this won't help you. ALB does not interpret the hostname attached to the incoming request.

同一域中的不同主机名也不会直接实现您的目标.

Separate hostnames in the same domain won't directly accomplish your objective, either.

2.) 如何使用别名将域指向 ELB 的特定端口?

2.) How to use alias to point domains to a specific port of the ELB?

域不指向端口.主机名不指向端口.DNS 仅用于地址解析.互联网上的任何地方都是如此.

Domains do not point to ports. Hostnames do not point to ports. DNS is only used for address resolution. This is true everywhere on the Internet.

3.) 如果域来自除 AWS 之外的其他提供商，是否可以使用此设置.

3.) Is it possible to use this setup if the domains are from another provider other than AWS.

这不是 AWS 的限制.DNS 根本就不能这样工作.

This is not a limitation of AWS. DNS simply does not work this way.

服务端点不知道指向它的 DNS 记录.DNS 条目本身严格用于发现可用于访问端点的 IP 地址.之后，端点实际上对 DNS 一无所知，也无法通过 DNS 告诉浏览器使用不同的端口.

A service endpoint is unaware of the DNS records that point to it. The DNS entry itself is strictly used for discovering an IP address that can be used to access the endpoint. After that, the endpoint does not actually know anything about the DNS, and there is no way to tell the browser, via DNS, to use a different port.

对于 HTTP，隐式端口是 80.对于 HTTPS，它是 443.除非在 URL 中提供端口，否则这些是唯一可用的端口.

For HTTP, the implicit port is 80. For HTTPS, it is 443. Unless a port is provided in the URL, these are the only usable ports.

然而，在 HTTP 和 HTTPS 中，每个请求都伴随着一个 Host: 标头，由 Web 浏览器随每个请求发送.这是地址栏中的主机名.

However, in HTTP and HTTPS, each request is accompanied by a Host: header, sent by the web browser with each request. This is the hostname in the address bar.

为了区分到达设备(例如 ELB/ALB)的不同主机名的请求，端点的设备必须解释传入的主机标头并将请求路由到提供该服务的后端系统.

To differentiate between requests for different hostnames arriving at a device (such as ELB/ALB), the device at the endpoint must interpret the incoming host header and route the request to an back-end system providing that service.

ALB 目前不支持此功能.

ALB does not currently support this capability.

但是，ALB 确实支持根据路径前缀选择端点.所以 microservices.example.com/api/foo 可以路由到一组服务，而 microservices.example.com/api/bar 可以路由到另一组.

ALB does, however, support choosing endpoints based on a path prefix. So microservices.example.com/api/foo could route to one set of services, while microservices.example.com/api/bar could route to another.

但是 ALB 不直接支持通过主机头进行路由.

But ALB does not directly support routing by host header.

在我的基础架构中，我们使用 ELB 或 ALB 的组合，但负载均衡器背后的实例不是应用程序.相反，它们是运行 HAProxy 负载平衡器软件并将请求路由到后端的实例.

In my infrastructure, we use a combination of ELB or ALB, but the instances behind the load balancer are not the applications. Instead, they are instances that run HAProxy load balancer software, and route the requests to the backend.

重要配置元素的简要示例如下所示:

A brief example of the important configuration elements looks like this:

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 和应用程序之间的一个薄层，它通过检查主机头或请求的任何其他特征来处理请求路由.

The ELB terminates the SSL and selects a proxy at random and the proxy checks the Host: header and selects a backend (a group of 1 or more instances) to which the request will be routed. It is a thin layer between the ELB and the application, which handles the request routing by examining the host header or any other characteristic of the request.

这是一种解决方案，但是是一种有点高级的配置，这取决于您的专业知识.

This is one solution, but is a somewhat advanced configuration, depending on your expertise.

如果您正在寻找开箱即用、无服务器、以 AWS 为中心的解决方案，那么实际上可以在 CloudFront 中找到答案.是的，它是一个 CDN，但它还有其他几个应用程序，包括作为反向代理.

If you are looking for an out-of-the-box, serverless, AWS-centric solution, then the answer is actually found in CloudFront. Yes, it's a CDN, but it has several other applications, including as a reverse proxy.

• 对于每项服务，从您的域中选择一个主机名以分配给该服务，foo.api.example.com 或 bar.api.example.com.

• For each service, choose a hostname from your domain to assign to that service, foo.api.example.com or bar.api.example.com.

为每个服务创建一个 CloudFront 分配.

For each service, create a CloudFront distribution.

配置每个分发的备用域名以使用该服务分配的主机名.

Configure the Alternate Domain Name of each distribution to use that service's assigned hostname.

将源域名设置为 ELB 主机名.

Set the Origin Domain Name to the ELB hostname.

设置 源 HTTP 端口到 ALB 上服务的特定端口，例如8090.

Set the Origin HTTP Port to the service's specific port on the ALB, e.g. 8090.

配置默认缓存行为以转发您需要的任何标头.如果您不需要 CloudFront 的缓存功能，请选择转发所有标头.如果需要，还可以转发查询字符串和 Cookie.

Configure the default Cache Behavior to forward any headers you need. If you don't need the caching capability of CloudFront, choose Forward All Headers. Also enable forwarding of Query Strings and Cookies if needed.

在 Route 53 中，创建 foo.api.example.com 作为该特定 CloudFront 分配的主机名的别名，例如dxxxexample.cloudfront.net.

In Route 53, create foo.api.example.com as an Alias to that specific CloudFront distribution's hostname, e.g. dxxxexample.cloudfront.net.

您的问题已解决.

你看到我在那里做了什么吗?

You see what I did there?

对于您配置的每个主机名，专用的 CloudFront 分配会在标准端口 (80/443) 上接收请求，并且——基于主机标头匹配的分配——CloudFront 将请求路由到相同strong> ELB/ALB 主机名，但一个自定义端口号.

For each hostname you configure, a dedicated CloudFront distribution receives the request on the standard ports (80/443) and -- based on which distribution the host header matches -- CloudFront routes the requests to the same ELB/ALB hostname but a custom port number.

这篇关于AWS Route 53 - 域名路由到应用程序负载均衡器的不同端口的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！