如何同时更新多台相同服务器上的 Nginx 配置文件?

Bub*_*ubu 12 amazon-ec2 amazon-web-services

我们在 Amazon EC2 上有一组 Nginx 服务器,我们偶尔需要更新配置文件以实现新设置。

目前我们在自定义 AMI 中有配置,如果我们需要更新,我们必须重建 AMI,然后重建 EC2 实例。我们有一些帮助脚本,但要做到这一点仍然需要付出很多努力。有什么更好的方法吗?

MLu*_*MLu 26

您可以利用许多概念。

成功的关键是自动化

第一个选择是继续做你现在正在做的事情,即在每次配置更改时重建 EC2。只是以完全自动化的方式。

当您现在通过 AMI 进行配置更新时,您可以更进一步并创建一个管道,当某个存储库中的配置文件发生更改时,该管道将:

  1. 自动构建新的 AMI - 最流行的工具之一是Packer
  2. 自动重建您的 Nginx 队列- 您应该已经在一个Auto-Scaling 组中拥有所有 Nginx 服务器,并且前面有一个应用程序负载均衡器。如果您不这样做,您应该这样做,因为它会使更新变得像更新ASG 启动配置并等待从新 AMI 重新构建实例一样简单。

第二种选择是保留实例,只部署配置文件,而不重建它们。通常,您可以将配置文件视为代码,并以与部署代码版本相同的方式部署配置更改。AWS 有许多工具可以帮助解决这个问题。

  • AWS Elastic Beanstalk在内部使用Chef,您可以通过这种方式编写 Nginx 更新脚本。
  • AWS Code Deploy是一个完全可编写脚本的部署工具,可以与AWS Code Suite 的其他部分很好地集成:
    • 代码提交,您可以将 Nginx 配置文件保存在 Git 中。
    • 每当在 Code Commit 中更新配置文件时,都可以自动触发部署的代码管道
  • AnsiblePuppet是流行的非 AWS 工具,可以帮助您以相同的方式配置所有服务器。

一旦您对自动化这些 Nginx 配置更新感到满意,您可能希望将自动化扩展到基础架构的其余部分。


有一个很棒的白皮书AWS 上的部署选项概述,可以为您提供一个很好的概述。

我希望有帮助:)


Tim*_*Tim 5

将您的配置存储在 EFS 上,并将 EFS 挂载到 Nginx 配置需要的位置。或者将它们放在 Amazon S3 上并偶尔运行同步,或使用 s3fs(注意 s3fs 可能不足以用于生产用途)。

当您需要更改配置时,将自动缩放组所需的大小增加到使用新配置触发新实例所需的大小的两倍,然后返回到您需要的大小,这将删除旧实例。或者只是对服务器进行滚动重启。

另一种选择是使用基本的自动化工具(如 AWS 代码部署)将新配置推送到您的服务器。

上面的全自动选项在技术上更好、更简洁,但如果您很少更改配置并想要一个简单的解决方案,这可能会有所帮助。