Elastic beanstalkでDjangoを使用して開発しています。Apache構成に2つの変更を加えたいです。
1. www.domain.comをdomain.comにリダイレクトします
2. http://domain.com を https://domain.com にリダイレクトします
私はApache構成の経験がありません。それをグーグルすることで、RewriteRulesを.htaccessファイルに置くべきだという考えが得られました。
例: ヘルスチェックに失敗せずにAmazon Elastic Beanstalkでhttpsを強制する方法
Elastic Beanstalk構成(.ebextensions)でそれを行う方法の説明が見つかりませんでした。ルートフォルダーに.htaccessファイルを配置してデプロイしようとしましたが、機能しませんでした。
エラスティックBeanstalkにRewriteRulesを追加する方法を知っている人はいますか?
これは簡単な解決策です
Wsgi.confのローカルバージョンを編集し、<VirtualHost> </ VirtualHost>タグ内に次のリダイレクトルールを追加します
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule !/status https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301]
“/status”をヘルスチェックとして使用しているページに変更しますページ。
ebextensionsディレクトリ内の<app> .confファイルを編集して、このバージョンのwsgi.confをAmazonのバージョンにコピーするコンテナコマンドを追加します
container_commands:
01_syncdb:
command: "Django-admin.py syncdb --noinput" leader_only: true
02_collectstatic:
command: "Django-admin.py collectstatic --noinput"
03_wsgireplace:
command: 'cp wsgi.conf /etc/httpd/conf.d/wsgi.conf'
...
コードをデプロイします。
それは動作するはずであり、ファイルはデプロイメントごとに適切に更新されます。注意すべき唯一のことは、Amazonが将来的にベースのwsgi.confファイルの内容を変更した場合、コピーが機能しなくなる可能性があることです。
出典: rickchristianson
www.example.com
をexample.com
に移動させることは、実際にリダイレクトであることを気にしない場合は、DNSのCNAMEで実行できます。リダイレクトが必要な場合は、以下のApache構成に追加できます。この回答の主なポイントは、Elastic BeanstalkでApache設定を変更する方法を詳しく説明することです(これを適切に行うのは簡単ではないため)。
この回答は、ロードバランサーセキュリティグループでhttpsをすでに有効にし、SSL証明書をロードバランサーに追加し、ロードバランサーによって転送されるポートに443を追加し、Route 53を使用してElastic Beanstalk環境でドメイン名をポイントしていることを前提としています(または同等のDNSサービス)。
あなたがする必要があるのは、あなたの プロジェクトの.conf
ディレクトリにある.ebextensions
ファイル に以下を追加することだけです:
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 configはこの問題の通常の解決策であり、Elastic BeanstalkはApacheを使用しているため、この方法を使用する必要があります。
サーバーへのSSHおよび...:これは、Elastic Beanstalkのポイントと完全に相反し、多くの問題があります。自動スケーリングによって作成された新しいインスタンスの構成は変更されません。クローン環境には構成がありません。環境変更の合理的なセットがいくつあっても、構成は消去されます。これはまさに悪い考えです。
Apache設定を新しいファイルで上書きします:これはソリューションの正しい領域に入りますが、Elastic Beanstalkがサーバーのセットアップ(非常によく実行される可能性があります)。次の項目の問題も参照してください。
Apache設定ファイルを動的に編集して、数行を追加します:これはまともなアイデアです。これに関する問題は、Elastic BeanstalkがデフォルトのApache構成ファイルの名前を変更した場合に機能しないことと、このファイルが予期しないときに上書きされる可能性があることです https://forums.aws.Amazon .com/thread.jspa?threadID = 163369
他の人への参照のために、 Zags 'solution を使用してwww以外をwwwにリダイレクトするには、これを.ebextensions/your_file.config
に追加します。
files:
"/etc/httpd/conf.d/www_rewrite.conf":
mode: "000644"
owner: root
group: root
content: |
RewriteEngine On
<If "'%{HTTP_Host}' !~ /^www\./">
RewriteRule ^(.*)$ http://www.%{HTTP_Host}%{REQUEST_URI} [R=301,L]
</If>