时间戳

首页 > 解决方案 > 在 AWS 中为（私有）ECS 服务设置简单的维护页面

amazon-web-services - 在 AWS 中为（私有）ECS 服务设置简单的维护页面

问题描述

我们当前的设置：企业网络通过 VPN 与 AWS 连接，Route53 条目指向 ELB，ELB 指向 ECS 服务（都在私有 VPC 子网内）。

=> 当您请求 URL（从公司网络内部）时，您会看到 Web 应用程序。✅</p>

现在，我们想要的是，当 ECS 服务没有运行时（维护，错误，...），我们希望直接为用户提供维护页面。此时您将看到默认的 AWS 503 错误页面。我们希望提供一个简单的静态 HTML 页面，其中包含一些维护信息。

到目前为止，我们尝试了什么：

  1. 将 Route53 与故障转移到 CloudFront 一起使用，使用 HTML 分发 S3 存储桶

    这确实有效，但是：

    1. Route53 不会很快地进行故障转移 => 在切换到 CloudFront 之前，用户仍将看到默认的 AWS 503 页面。
    2. 由于这是一个 DNS 故障转移，并且浏览器（以及代理、本地 dns 缓存......）一旦解析条目就会缓存，由于缓存，用户在 Route53 切换后仍会看到默认的 AWS 503 页面。只有在新的 IP 地址被解析后（可能需要几分钟或直到浏览器或操作系统重新启动），用户才会看到维护页面。
    3. 与之前的两者一样，但反过来：当服务重新运行时，用户将看到维护页面的时间比他们应该看到的要长。

    由于这不是我们想要的，我们接下来尝试：

  2. 使用具有两个源（我们的 ELB 和故障转移 S3 存储桶）的 CloudFront，并带有 503 的自定义错误页面。

    这不起作用，因为 CloudFront 需要公开可用的源，而我们的 ELB 位于私有 VPC 子网中❌</p>

    我们可以重新配置我们的完整网络环境，使其公开并限制对 CloudFront IP 的访问。虽然这可能会奏效，但我们看到以下缺点：

    1. 安全性降低：其他人可以将我们的 Web 应用程序作为目标设置 CloudFront 分配，并且可以在我们的公司网络之外对其进行完全访问。
    2. 为了克服这个安全问题，我们必须实现一个安全标头（将从 CloudFront 发送到应用程序），这导致我们的应用程序内部有安全代码 => 为什么我们的应用程序要处理这种安全性？如果代码有错误或任何东西怎么办？
    3. 我们当前的环境已经启动并运行。我们将不得不对一个总体安全性降低的错误页面进行大量更改！

  3. 使用第二个 ECS 服务（例如 HAProxy、nginx、apache 等），将我们的应用程序作为目标，并将错误文件用于我们的维护页面。

    虽然这会像预期的那样工作，但它也有一些缺点：

    1. 该服务是单点故障：当它关闭时，您无法访问 Web 应用程序。为了克服这个问题，你必须把它放在 ELB 后面，放在至少两个 AZ 中，并且（可选）使其水平扩展以处理更大的请求量。
    2. 服务要花钱！也许您只需要一个内存和 CPU 很少的小实例，但是当您有大量请求时，它（可能）必须与您的 Web 应用程序一起扩展！
    3. 感觉就像我们回到了 2000 年代，而不是在云环境中。

所以，长话短说：有没有其他方法来实现 af*****g 简单的维护页面，同时保持我们的 Web 应用程序的私密性和安全性？

标签： amazon-web-servicesamazon-cloudfrontamazon-route53amazon-elbmaintenance

解决方案

推荐阅读