随着项目的发展和用户群的扩大,扩展计算资源变得至关重要。在此博客中,我将探讨在不导致停机的情况下调整 AWS EC2 实例大小的过程,并讨论确保无缝过渡的一些注意事项。
真实世界演练
在扩展基础架构时,定期评估当前实例大小是否满足项目需求非常重要。考虑 CPU 利用率和用户增长等因素来确定何时需要调整大小。
我一直在做一个最近上线的项目,在过去的几个月里,它的用户群一直在不断增长。当 CPU 利用率达到一定水平时,我有自动扩展策略来扩展——但是,当你意识到你需要扩展你的实例而不是不断地扩展时,会有一个点。
我已经将 Terraform 作为代码用于我所有的 AWS 基础设施——所以这是我定义我的 EC2 配置的地方。我设置了配置,以便始终至少有一个健康的实例。
<span style="color:var(--syntax-text-color)"><span style="color:var(--syntax-text-color)"><code>resource "aws_autoscaling_group" "example_ec2_asg" {
name = "example-asg"
vpc_zone_identifier = [aws_subnet.private_subnet_1.id, aws_subnet.private_subnet_2.id]
launch_configuration = aws_launch_configuration.ecs_launch_config.name
force_delete = true
health_check_grace_period = 10
desired_capacity = 2
min_size = 1
max_size = var.max_size
lifecycle {
create_before_destroy = true
}
}
# EC2 launch configuration
resource "aws_launch_configuration" "example_ecs_launch_config" {
name_prefix = "ecs_launch_config-"
image_id = data.aws_ami.example_ami.id
iam_instance_profile = aws_iam_instance_profile.ecs_agent.name
security_groups = [aws_security_group.ecs_tasks_sg.id]
instance_type = var.ec2_instance_type // passing in as var
associate_public_ip_address = false
user_data = <<EOF
#!/bin/bash
echo ECS_CLUSTER=${aws_ecs_cluster.main.name} >> /etc/ecs/ecs.config
EOF
depends_on = [aws_ecs_cluster.main]
lifecycle {
create_before_destroy = true
}
}
</code></span></span>
在上面的代码片段中,您可以看到我的 EC2 实例的启动配置。您会注意到我将实例类型作为变量传入——这是因为我根据部署环境(例如 QA、测试、生产)使用不同的实例大小。
你可以看到我设置了一个生命周期事件,它指定在一个实例被销毁之前总是创建一个新实例。我还有一个随时运行的 2 个实例的所需容量集。
目标
我的 EC2 实例当前是t2.small,我想将它们更新为t2.medium
忧虑
对于代码部署,我将其设置为进行滚动部署,但我担心这种变化不仅仅是代码更新,它正在更新运行代码的实际计算。
我担心如果我更新我的 terraform 配置并运行它,它可能会尝试一次更新所有实例并导致停机。
我决定在测试 AWS 环境中测试此更新,然后再尝试 QA 或生产,这样我就不会在尝试了解此过程时给开发团队或最终客户造成任何问题。
计划
我将 terraform 的环境变量更新为at2.medium并运行一个 terraform 计划来查看未决的更改:

在屏幕截图中,您可以看到 Terraform 计划显示将有一个force replacementEC2 实例来更新类型。
为了测试并查看它是否会导致停机,我在我的测试环境中确认了部署。terraform 计划完成后,我进入 EC2 控制台,我可以看到我的实例的大小仍然是 t2.small。
我想当部署完成时,它会触发每个实例开始更新到新的大小。然而,情况并非如此——因为我已经更新了启动配置中的 EC2 大小,它只会在您启动新实例时触发。
考试
我有两个实例在运行,所以我想我会尝试停止一个实例来测试我的理论,看看会发生什么。在 AWS 控制台中(再次在我的测试环境中),我选择了我的一个实例并选择停止它。

当我单击它时,我开始访问我的 API 健康端点,以验证流量仍在路由到正在运行的实例,当我在控制台中重新检查时,我可以自动创建一个新的中型实例。
我又点击了几次运行状况端点,以验证在创建新实例时一切仍在按预期运行,而且确实如此!
一旦新的中型实例处于就绪状态并且我可以在 ECS 中看到该服务已启动并正在运行,我便停止了第二个小实例。再次停止后,我可以看到一个新的介质实例正在其位置创建并在 ECS 中注册。
我现在有信心,我可以在 QA 和生产环境中进行此升级,而无需任何最终用户停机。
注意事项
-
利用基础架构即代码工具来帮助跟踪配置更新。
-
实施滚动部署以确保一个部署成功,然后再开始另一个部署。
-
确保您的所需实例数高于一个实例,以启用滚动更新策略,并在您的一个实例变得不健康时提供帮助。
-
确保您有一个健康端点,设置为允许您在基础设施更新期间轻松测试服务,以确保流量按预期路由。
-
如果在更新过程中出现问题,请制定回滚策略
结论
在不导致停机的情况下调整 EC2 实例的大小是管理不断增长的项目的一个重要方面。通过遵循上述最佳实践,您可以无缝调整实例大小以满足应用程序不断变化的需求,并自信地扩展基础架构,同时提供流畅的用户体验。
本文介绍了如何在不中断服务的情况下调整AWSEC2实例大小,通过使用Terraform进行自动化配置更新,实现滚动部署,确保在扩展计算资源时保持应用的无缝运行。作者强调了监控CPU利用率、设置健康检查和使用生命周期策略的重要性。
515

被折叠的 条评论
为什么被折叠?



