0

有很多情况我们需要在 AWS beanstalk 环境中覆盖 nginx conf。

  • 设置最大文件附件
  • 强制 http 到 https
  • 为不同的静态资源设置不同的缓存过期时间
  • 设置 WebSocket
  • gzip 文件类型
  • 等等等等

AWS Support 建议使用 nginx.conf，它是 beanstalk 应用程序的副本，方法是查看实例中的 /etc/nginx/nginx.conf。这将用作基础，然后添加新的配置或块。然后在项目中使用 .ebextensions/nginx/nginx.conf 和这个内容。但是，最大的问题是，如果基础 nginx.conf 被 AWS 更改，那么可能很难首先知道它何时更改，然后重复复制它然后添加覆盖的步骤。像这样的东西

大多数网络搜索提供的其他选项是使用 container_commands 并在 appdeploy 或 configdeploy 中创建文件 在 container_commands 中，人们建议修改 /tmp/deployment/config/#etc#nginx#conf.d#00_elastic_beanstalk_proxy.conf 类似这样的东西

这种方法的问题在于它仅在部署应用程序时才有效，而不是在任何 beanstalk 配置发生更改时（例如更改 env var）。

我的问题是覆盖 nginx 配置的更好的推荐方式。

4

1 回答 1

1

为了帮助保持弹性 beanstalk 部署易于管理，请记住以下几点：

首先：AWS 不会直接更改 Elastic Beanstalk 生产环境中的任何配置。同样，您也不应该直接在生产弹性 beanstalk 环境中进行任何更改。

AWS 建议您更改开发环境中的配置，并在您希望更改生效时通过控制台或 Elastic Beanstalk 命令行界面 (CLI) 重新部署。这与容器化与否、负载平衡与否、弹性 beanstalk nginx 配置文件或覆盖选项无关。

第二：从您提供的第一个链接：您可以使用弹性 beanstalk 默认 nginx 配置或.ebextensions 中的覆盖配置。两者都没有。这应该有助于减少您的困惑。当您在开发环境中对其中任何一个进行更改时，此更改意味着您的应用程序的新版本，您需要将其部署到您的生产环境中才能生效。

第三：nginx 可以充当原始服务器的代理，并且原始服务器可能会指示资产的缓存过期。如果需要，有一些方法可以更改 nginx 配置上的配置以覆盖原始设置。来自NGINX 缓存指南：

默认情况下，NGINX 尊重来自源服务器的 Cache-Control 标头。它不会缓存将 Cache-Control 设置为 Private、No-Cache 或 No-Store 或在响应标头中使用 Set-Cookie 的响应。NGINX 只缓存 GET 和 HEAD 客户端请求。

我希望这有助于澄清问题。部署您的应用程序并牢记这些技术并继续部署。如果错误，请将其删除并重试。

如果您遇到困难，请询问有关您的应用程序和特定配置的更具体的问题。您为问题提供的详细信息越多，我们就能越好地帮助您。

于 2018-08-28T09:23:11.910 回答