为了复习 AWS 联网概念,我完成了一个项目,该项目涉及使用 AWS 服务创建 Virtual Private Cloud (VPC),重点是弹性和安全性。这用作我的项目的文档,包括项目实施步骤、背后的原因和故障排除。

项目概况

VPC 架构图

该项目的主要目标是在 AWS 上创建一个 Virtual Private Cloud (VPC),旨在托管在生产中具有弹性、高可用性和安全性的服务器。以下是我旨在实现的目标以及我是如何实现的详细说明:

  1. 已创建 VPC

  2. 设置 Auto Scaling 组

  3. 设置 Bastion

  4. 部署 Application Load Balancer

  5. 设置我的应用程序服务器

  6. 测试基础设施

1. 创建 VPC

什么是 VPC?

Virtual Private Cloud (VPC) 是专用于您的 AWS 账户的虚拟网络。这就像将数据中心放在云中一样,您可以在其中控制网络设置,例如 IP 地址范围、子网、路由表和网络网关。

为什么使用 VPC?

使用 VPC 可为您的资源提供隔离和安全性,确保只有您允许的实体才能访问这些资源。这对于创建安全且架构良好的基础设施至关重要。

实现:

我使用了 AWS“VPC and more”(VPC 及更多)向导,这是一个快速设置工具,可简化包含所有必要组件的 VPC 的创建过程:

我的 VPC 资源图

高可用性可确保您的应用程序即使在发生故障或高流量负载的情况下也能保持运行。为此,我创建了两个不同的可用区,并将我的服务器部署在其中。通过将服务器分布在两个可用区中,我确保即使一个区域因中断或维护而宕机,另一个区域中的服务器也可以继续处理请求。此设置提供了冗余并提高了应用程序的正常运行时间。us-east-1aus-east-1b

在 AWS 中设计弹性、安全且高性能的网络架构,创建两个公有子网和两个私有子网是关键部分。这种设置不仅可以通过利用多个可用区来确保高可用性和容错能力,还可以根据资源对 Internet 访问的需求提供明确的资源分离。

AZ1:

  • 公有子网 1:此子网用于需要从 Internet 访问的资源,例如 Application Load Balancer (ALB) 和其中一个 NAT 网关。

  • 私有子网 1:此子网用于不需要直接 Internet 访问且需要额外安全层的资源,例如托管应用程序服务器的 EC2 实例。

AZ2:

  • 公有子网 2:类似于 AZ1 中的公有子网。

  • 私有子网 2:类似于 AZ1 中的私有子网。

网络地址转换 (NAT) 网关允许私有子网中的实例连接到 Internet 以进行更新和补丁,而不会将其暴露给入站 Internet 流量。使用 NAT 网关可确保您的服务器可以安全地访问 Internet,同时保持其私有子网状态。

我在两个可用区中都部署了 NAT 网关,以确保高可用性。此设置允许私有子网中的实例将出站流量发送到 Internet,但不会接收未经请求的入站流量。

2. 设置 Auto Scaling 组

什么是 Auto Scaling 组?

Auto Scaling 组 (ASG) 可确保您有正确数量的 EC2 实例可用于处理应用程序的负载。它可以根据需求自动增加或减少实例的数量。

为什么使用 ASG?

使用 ASG 可以提高应用程序的可用性和成本效益。在高峰时段,ASG 可以增加实例数量以处理额外的负载,在非高峰时段,它可以减少实例数量以节省成本。

实现:

我设置了一个 Auto Scaling 组 (ASG),以确保应用程序服务器可以根据需求自动预置和扩展:

我的启动模板

我使用启动模板来定义 ASG 将启动的 EC2 实例的实例设置:

  • AMI 映像:Ubuntu 22.04

  • Instance Type: — 我的实例的硬件规格。我选择此配置是因为它的免费层可用性和应用程序的低流量要求。t2 micro

  • 我指定了私有子网的子网 ID,以便我的应用程序服务器在私有子网中预置,无法访问 Internet。

  • 我修改了 VPC 向导创建的默认安全组,以允许来自可信 IP 地址的 SSH(端口 22)流量,允许来自我稍后将配置的 ALB 的源 IP 地址的 HTTP(端口 80)流量,并允许所有出站流量流向任何目标。

然后,我配置了 Auto-scaling 组大小:

  • 所需容量是 ASG 始终尝试维护的 EC2 实例数。我将所需的容量设置为 2。将所需容量设置为 2 意味着 ASG 将确保始终有 2 个实例在运行。这提供了基准级别的可用性和冗余,确保如果一个实例发生故障,至少还有一个实例正在运行来处理负载。

  • 最小容量是 ASG 将维护的最小实例数。我将最小容量设置为 2。通过将最小容量设置为 2,我确保 ASG 永远不会缩减到 2 个实例以下,从而提供基本级别的容错和可用性。

  • 最大容量是 ASG 可以扩展到的最大实例数。我将最大容量设置为 4。 将最大容量设置为 4 允许 ASG 在流量高峰期扩展到 4 个实例。这可确保应用程序可以处理增加的负载而不会降低性能。

运作方式:

  • 正常操作:如果所需最小容量为 2,则 ASG 将维护 2 个实例。如果一个实例失败,ASG 会自动启动一个新实例来替换它。

  • 增加的流量:在高峰时段,如果负载增加,ASG 可以横向扩展并添加最多 2 个额外实例(达到最大容量 4)来处理流量。

  • 减少流量:当流量减少时,ASG 会缩减,但会根据最小容量设置保持至少 2 个实例。

使用 ASG 的好处

  1. 高可用性:确保应用程序保持可用,并且可以处理不同级别的流量,而无需人工干预。

  2. Fault Tolerance:自动替换运行状况不佳的实例,保持所需的容量并确保应用程序保持运行。

  3. 冗余:将实例分布在多个可用区中,从而提供冗余并增强应用程序对单个可用区中故障的弹性。

设置好 ASG 后,我检查了我的 EC2 实例是否已设置和正确配置。一切都检查了。

3. 设置堡垒主机

我还设置了一个堡垒主机,以安全地访问 Virtual Private Cloud (VPC) 的私有子网中的实例。

堡垒机的用途:

堡垒主机,也称为跳板服务器或网关主机,是一种专门配置的服务器,充当 Internet 和 VPC 中的私有实例之间的中介。它为管理员提供了一个安全网关,用于远程访问私有子网中的实例。

实现:

  1. 我在 VPC 内的公有子网中启动了一个新的 EC2 实例,以用作堡垒主机:

  • 我配置了一个与堡垒主机关联的安全组,以仅允许来自我信任的 IP 地址的入站 SSH(端口 22)访问,并允许出站 SSH 流量连接到我的私有实例。此受限访问可确保只有授权用户才能连接到堡垒主机。

  • SSH 密钥对:我使用 SSH 密钥对安全地进行身份验证并连接到堡垒主机。此密钥对可确保我的本地计算机与堡垒主机之间的安全通信。

2. 连接到 Bastion 主机:

  • 为了连接到堡垒主机,我使用了带有适当 SSH 密钥对和堡垒主机的公有 IP 地址的 SSH。

scp -i /home/ntando_mv/.ssh/aws-login.pem /home/ntando_mv/.ssh/aws-login.pem ubuntu@50.19.174.253:/home/ubuntu/
aws-login.pem

3. 通过堡垒主机访问私有实例:

  • 连接到堡垒主机后,我使用 SSH 端口转发或类似方法建立了到 VPC 中私有实例的安全隧道。

服务器 1:

scp -i /home/ubuntu/serverkey.pem /home/ubuntu/serverkey.pem ubuntu@10.0136.42:/home/ubuntu

  • 同样,我使用相同的命令建立与 server2 的 SSH 连接。

  • 建立隧道后,我可以安全地访问和管理私有实例,就像使用命令直接连接到它们一样。ssh

使用堡垒机的好处:

  • 通过限制对堡垒主机的 SSH 访问并使用 SSH 密钥对进行身份验证,我确保了对私有实例的访问受到限制且安全。

  • 堡垒主机提供了一个集中式访问点,用于管理私有子网中的实例,从而简化了远程管理任务。

  • 审计跟踪:到私有实例的所有 SSH 会话都通过堡垒主机路由,从而为安全性和合规性目的提供管理活动的审计跟踪。

4. 设置 Application Server

通过堡垒安全地连接到我的服务器后,我就设置了我的应用程序服务器。

实现:

为了简单起见和演示目的,我使用了 Python 的内置 HTTP 服务器来为应用程序服务器提供基本文件。此文件用作 Web 内容的占位符。index.html

在每个 EC2 实例上,我放置了一个文件并使用以下内容对其进行编辑:index.html

服务器 1:

<!DOCTYPE html>
<html>
<body>

<h1>This is a project documenting apps in private subnets.</h1>


</body>
</html>

服务器 2:

<!DOCTYPE html>
<html>
<body>

<h1>This is project is complete.</h1>


</body>
</html>

然后,我使用以下命令运行 Python HTTP 服务器:

python3 -m http.server 8000

此命令在端口 8000 上启动一个简单的 Web 服务器,允许将流量路由到这些实例。

5. 部署 Application Load Balancer

什么是 Application Load Balancer?

Application Load Balancer (ALB) 在多个可用区中的多个目标(例如 EC2 实例)之间分配传入的应用程序流量。它在应用程序层 (HTTP/HTTPS) 运行。

为什么使用 ALB?

ALB 提高了容错能力,并提供对应用程序的单点访问,从而在多个实例之间高效分配流量。

实现:

我在公有子网中设置了一个 ALB,它将传入的 HTTP 请求路由到私有子网中的实例。此设置可确保服务器本身对直接 Internet 访问保持隐藏状态。

我通过创建应用程序负载均衡器、侦听端口 80 并瞄准 ASG 创建的 2 个应用程序服务器来配置负载均衡器。我确保将 ALB 放置在公有子网中,以便 Internet 可以访问它。

问题描述:
在设置 Application Load Balancer 期间,我注意到我的实例在运行状况检查下被列为“unhealthy”。最初,这些实例在 ALB 看来运行状况不佳,即使应用程序在实例上正常运行也是如此。

采取的故障排除步骤:

1. 确定问题:
— 检查我的目标组的配置,并注意到它被配置为侦听端口 80。

2. 更新了目标组配置:
— 更新了与 ALB 关联的目标组,以侦听端口 8000 而不是端口 80,以匹配运行我的应用程序的端口。

3. 更新安全组规则:
— 修改了与实例关联的安全组,以允许端口 8000 上来自 ALB 源 IP 地址的入站流量,以及来自负载均衡器的端口 80 上的入站流量。

我还为 ALB 创建了另一个安全组,以与这些设置保持一致:

SG-ELB 公司:

  • 入站:HTTP:TCP 80 from (或特定 IP 范围)0.0.0.0/0

  • 出站:自定义 TCP:TCP 8000 到 SG-Backend

通过遵循此设置,我确保您的 ALB 和后端服务器具有适当的安全性和功能,同时保持通过堡垒主机的安全访问。

4. 运行状况检查配置:
— 确保目标组的运行状况检查配置已设置为检查端口 8000 上实例的运行状况。

5. 实例配置:
— 验证我的应用程序是否正在运行并侦听端口 8000 上的传入请求。

6. ALB 侦听器配置:
— 确认 ALB 侦听器配置为将传入请求从实例上的端口 80 转发到端口 8000。

分辨率:

运行状况良好的实例的 ALB Resource Map

在更新目标组端口配置和安全组规则以允许端口 8000 上的流量,并确保应用程序在该端口上正确运行后,实例在 ALB 中显示为运行状况良好。传入请求已成功从 ALB 路由到在端口 8000 上运行我的应用程序的实例,问题已得到解决。

6. 测试基础设施

为了测试部署在 ALB 后面的应用程序,我使用了 ALB 的域名。以下是我执行测试的方式:

1. 访问应用程序:
— 打开 Web 浏览器并在地址栏中输入 ALB 的域名。

2. 对应用程序进行压力测试:

— 通过快速刷新浏览器或打开多个选项卡/窗口来持续加载应用程序。
— 观察到请求在 ALB 后面的两台服务器之间均匀分布。

3. 监控服务器响应:
— 监控来自两台服务器的响应,以确保每台服务器都成功为请求提供服务,没有错误或问题。
— 确保两台服务器都提供响应,而不会过载或停机。

从 server1 提供的内容

server2 上提供的内容

结果:
- 通过使用 ALB 的域名通过生成高流量负载来对应用程序进行测试和压力测试,我验证了应用程序是否具有弹性并能够处理并发用户请求。
- ALB 背后的两台服务器都有效地为应用程序提供服务,展示了 ALB 的负载均衡功能以及基础设施的可靠性和可扩展性。

结论

这个项目不仅教会了我 AWS 联网服务,还给了我构建弹性和安全基础设施的实践经验。通过使用 VPC、私有子网、Auto Scaling 组、Application Load Balancer、堡垒和 NAT 网关,我创建了一个适合生产工作负载的强大环境。