ウェブサイトを HTTPS + CloudFront + S3 の環境に移行したのでその振り返り
先日、Apacheで配信していたWebサイトをS3+CloudFrontの環境に移行しました。そのときにやったことを備忘録としてまとめました。
個人的にハマって悩んだところや大事だなと思ったところは太字にしています。
0. 前提条件一通り構成を組んだ後でのテストでは、キャッシュがしぶとくてコンテンツ更新後の状況が再現できないことがあるので、Invalidationしまくったり、ブラウザキャッシュを削除しまくったりする必要がある。適当なテストドメインを用意できると良い。たとえば、 www.example.com について構築しようとしているのであれば、 www2.example.com などをテスト用として確保するとよい。phpやrubyは動きません、Javascriptは動きます、Basic認証はできません、会員登録はできません(phpやrubyが必要なページは動かない)、などの制約事項があるので、非Techの関係者にネゴっとく必要がある。 1. S3の基本的な設定なんでもいいのでバケットを作る。バケット直で自分が持っているドメインを紐付けようと思うなら、ドメイン名と全く同じバケット名(www.example.comのサイトを作りたい場合は、バケット名をwww.example.comにする。ドットは入力できないとエンジニアの直感でなんとなく思いがちだけど、普通に入力できる…。)にする必要があるが、多分不要。(未検証、今回はドメインと同じバケット名にしました…。)静的ウェブサイトホスティングを有効にする。インデックスドキュメントはindex.html(他任意のファイル名でもOK)、エラードキュメントはerror.html(他任意ry)にする。バケットに、html, access-logs, cf-logs のディレクトリを作成する。htmlがコンテンツ置き場、access-logがS3が直接ロギングするログ置き場、cf-logsがCloudFrontがロギングするログ置き場にする。コンテンツを突っ込んでみて、静的ウェブサイトホスティング用のURLにアクセスして、コンテンツが表示されるかを確認する。 2. CloudFrontの基本的な設定基本的にはググって出てくるサイトを参考にしてよい。Alternate Domain Names には、テスト用に確保しておいたドメ…
個人的にハマって悩んだところや大事だなと思ったところは太字にしています。
0. 前提条件一通り構成を組んだ後でのテストでは、キャッシュがしぶとくてコンテンツ更新後の状況が再現できないことがあるので、Invalidationしまくったり、ブラウザキャッシュを削除しまくったりする必要がある。適当なテストドメインを用意できると良い。たとえば、 www.example.com について構築しようとしているのであれば、 www2.example.com などをテスト用として確保するとよい。phpやrubyは動きません、Javascriptは動きます、Basic認証はできません、会員登録はできません(phpやrubyが必要なページは動かない)、などの制約事項があるので、非Techの関係者にネゴっとく必要がある。 1. S3の基本的な設定なんでもいいのでバケットを作る。バケット直で自分が持っているドメインを紐付けようと思うなら、ドメイン名と全く同じバケット名(www.example.comのサイトを作りたい場合は、バケット名をwww.example.comにする。ドットは入力できないとエンジニアの直感でなんとなく思いがちだけど、普通に入力できる…。)にする必要があるが、多分不要。(未検証、今回はドメインと同じバケット名にしました…。)静的ウェブサイトホスティングを有効にする。インデックスドキュメントはindex.html(他任意のファイル名でもOK)、エラードキュメントはerror.html(他任意ry)にする。バケットに、html, access-logs, cf-logs のディレクトリを作成する。htmlがコンテンツ置き場、access-logがS3が直接ロギングするログ置き場、cf-logsがCloudFrontがロギングするログ置き場にする。コンテンツを突っ込んでみて、静的ウェブサイトホスティング用のURLにアクセスして、コンテンツが表示されるかを確認する。 2. CloudFrontの基本的な設定基本的にはググって出てくるサイトを参考にしてよい。Alternate Domain Names には、テスト用に確保しておいたドメ…