我刚刚回答了一个类似的问题,所以我也决定在这里插话。
@Codebeef 给出了一个很好的答案,但在大多数现代浏览器都必须使用 HTTPS 的世界中,这将不再适用。
这是如何为您的应用处理自定义域的全貌。
如果您的客户只是 CNAME 到您的域或为您的 IP 创建 A 记录,并且您不处理这些自定义域的 TLS 终止,您的应用将不支持 HTTPS,没有它,您的应用将无法运行这些自定义域上的现代浏览器。
您需要在您的网络服务器前设置一个 TLS 终止反向代理。此代理可以在单独的机器上运行,但您可以在与网络服务器相同的机器上运行它。
CNAME vs A 记录
如果您的客户希望将您的应用放在他们的子域中,例如app.customer.com 他们可以创建一个 CNAME app.customer.com 指向您的代理。
如果他们想将您的应用放在他们的根域上,例如customer.com 然后他们必须在 customer.com 上创建一个指向您代理 IP 的 A 记录。确保此 IP 永远不会改变!
如何处理 TLS 终止?
要使 TLS 终止工作,您必须为这些自定义域颁发 TLS 证书。您可以为此使用 Let's Encrypt。您的代理将看到传入请求的 Host 标头,例如app.customer1.com 或 customer2.com 等,然后它会通过检查 SNI 来决定使用哪个 TLS 证书。
代理可以设置为自动为这些自定义域颁发和更新证书。在来自新自定义域的第一个请求中,代理会发现它没有适当的证书。它会要求 Let's Encrypt 提供新证书。 Let's Encrypt 将首先发出挑战以查看您是否管理域,并且由于客户已经创建了指向您的代理的 CNAME 或 A 记录,这告诉 Let's Encrypt 您确实管理了域,它会让您为它。
要自动颁发和更新证书,我建议使用 Caddyserver、greenlock.js、OpenResty (Nginx)。
tl;dr 关于这里发生的事情;
Caddyserver 监听 443 和 80,它自动接收请求、颁发和更新证书,代理到您的后端的流量。
如何在我的后端处理它
您的代理正在终止 TLS 并将请求代理到您的后端。但是,您的后端不知道请求背后的原始客户是谁。这就是为什么您需要告诉您的代理在代理请求中包含其他标头以识别客户的原因。只需添加 X-Serve-For: app.customer.com 或 X-Serve-For: customer2.com 或 Host 标头的原始请求即可。
现在,当您在后端收到代理请求时,您可以阅读此自定义标头,并且您知道谁是请求背后的客户。您可以基于此实现您的逻辑,显示属于该客户的数据等。
更多
在您的代理队列前面放置一个负载平衡器,以提高可用性。您还必须为证书和 Let's Encrypt 挑战使用分布式存储。如果出现故障,请使用 AWS ECS 或 EBS 进行自动恢复,否则,您可能会在半夜醒来重启机器,或者手动重启您的代理。
如果您需要更多详细信息,可以在 Twitter @dragocrnjac 上私信我