在许多情况下，我们需要在AWS beantalk环境中覆盖nginx conf。
AWS支持建议通过查看实例中的/etc/nginx/nginx.conf，使用nginx.conf（它是beantalk应用程序的副本）。这将用作基础，然后添加新的配置或块。 然后在项目中将.ebextensions / nginx / nginx.conf与该内容一起使用。 但是，最大的问题是，如果AWS更改了基本的nginx.conf，则可能很难先知道它何时已更改，然后重复复制它的步骤，然后添加覆盖。像this
大多数网络搜索提供的其他选项是使用container_commands以及在appdeploy或configdeploy中创建文件 在container_commands中，人们建议修改/tmp/deployment/config/#etc#nginx#conf.d#00_elastic_beanstalk_proxy.conf 像this
这种方法的问题在于它仅在部署应用程序时有效，而在任何beantalk配置已更改（例如更改env var）时无效。
我的问题是重写nginx配置的更好的推荐方法。
答案 0 :(得分：1)
为使弹性beantalk部署易于管理，请记住以下几点：
第一：AWS不会直接更改您的Elastic Beanstalk生产环境中的任何配置。同样，您也不应直接在生产弹性beantalk环境中进行任何更改。
AWS建议您在开发环境中更改配置，并在需要进行更改时redeploy via the console or via the Elastic Beanstalk Command Line Interface (CLI)进行更改。这与弹性beanstalk nginx配置文件或override选项无关，无论是否进行容器化或负载平衡。
第二：从您提供的第一个链接开始：您可以使用.ebextensions中的弹性beantalk默认nginx配置 OR 。两者没有混合。这应该有助于减轻您的困惑。当您在开发环境中进行任何更改时，此更改都意味着您的应用程序是新版本，因此您需要将其部署到生产中才能生效。
第三：nginx可以充当原始服务器的代理，并且原始服务器可能指示资产的缓存过期。如果需要，可以通过多种方法更改nginx配置上的配置以覆盖原始设置。来自NGINX caching guide：
默认情况下，NGINX从源头开始尊重Cache-Control标头 服务器。它不缓存将Cache-Control设置为的响应 响应中包含私有，无缓存或无存储或带有Set-Cookie 标头。 NGINX仅缓存GET和HEAD客户端请求。
我希望这有助于清理问题。部署您的应用程序，并牢记这些技术，然后再进行部署。如果错误，将其删除，然后重试。
如果遇到问题，请询问有关您的应用程序和特定配置的更具体的问题。您为问题提供的详细信息越多，我们越能为您提供帮助。