假设您已在负载平衡器安全组中启用https,将SSL证书添加到负载平衡器,将443添加到负载平衡器转发的端口,并使用Route 53将您的域名指向Elastic Beanstalk环境(或等效DNS服务)。它还假定您没有使用基于docker的部署
所有你需要做的是将以下内容添加到您的一个.config
files in the .ebextensions
directory of your project:
files:
"/etc/httpd/conf.d/ssl_rewrite.conf":
mode: "000644"
owner: root
group: root
content: |
RewriteEngine On
<If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</If>
这在Elastic Beanstalk外是适度直接的。通常会添加一个Apache重写规则,如下所示:
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
或者,如果在负载均衡器后面,就像我们在这种情况下:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
然而,这些配置仅在< VirtualHost>块。将RewriteCond改变为< If>块允许它在< VirtualHost>块,允许我们放入一个独立的Apache配置文件。请注意,CentOS上的标准Apache设置(包括ElasticBeanstalk上的设置)包括所有匹配/etc/httpd/conf.d/*.conf的文件,这与我们存储此文件的文件路径相匹配。
条件的-n’%{HTTP:X-Forwarded-Proto}’部分阻止它重定向,如果您不在负载平衡器后面,允许您在生产环境与负载平衡器和https之间共享配置,一个临时环境是单实例,没有https。如果您在所有环境中使用负载平衡器和https,这不是必需的,但它不会受到伤害。
我见过的坏解决方案
我看到了很多坏的解决方案,这个问题,值得通过他们来了解为什么这个解决方案是必要的。
>使用Cloudfront:有些人建议在Elastic Beanstalk之前使用非缓存的Cloudfront设置来执行HTTP到HTTPS重定向。这增加了一个不完全合适的全新服务(因此增加了复杂性)(Cloudfront是一个CDN;它不是对继承动态内容强制使用HTTPS的正确工具)。 Apache配置是这个问题的正常解决方案,Elastic Beanstalk使用Apache,所以这是我们应该去的方式。
> SSH到服务器和…:这是完全对立的Elastic Beanstalk的点,并有这么多的问题。通过自动扩展创建的任何新实例将不具有修改的配置。任何克隆的环境将不具有配置。任何数量的合理设置的环境更改都将擦除配置。这只是一个坏主意。
>用一个新文件覆盖Apache配置:这是进入正确的解决方案领域,但如果Elastic Beanstalk改变了服务器设置的方面(他们很可能做的),那么会给你带来维护噩梦。也看到下一个项目中的问题。
>动态编辑Apache配置文件以添加几行:这是一个不错的想法。这样做的问题是,如果Elastic Beanstalk更改其默认Apache配置文件的名称,并且该文件可以被覆盖,当你最不期望的时候它不会工作:https://forums.aws.amazon.com/thread.jspa?threadID=163369
原文:https://codeday.me/bug/20171210/105195.html