この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
普段は、ご挨拶したい内容にマッチしたいらすとやのイラストを探す事が多いのですが、今回は逆に気になったいらすとやのイラストを紹介したいと思います。
▲ わざわざ紙のティンパニを用意するって、愛おしいですよね
こんにちは、AWS事業本部のShirotaです。こういう斬新な演奏方法に憧れを抱いています。推し銀河が 宇宙一低い音を出している と言われているので、いつかこういうものに取り込んでもらいたいな……という淡い野望も抱いています。
推し銀河については、話し出すと長くなるのでここでは割愛させて頂きます。
EC2でもバーチャルホスト環境が欲しい
Apacheのバーチャルホスト機能は、勿論EC2でも設定して使えます。
ここでバーチャルホストについてお話しておくと、Apacheの公式ドキュメントではバーチャルホストの定義を以下のように説明しています。
バーチャルホストという用語は、1 台のマシン上で (www.company1.com and www.company2.com のような) 二つ以上のウェブサイトを扱う運用方法のことを指します。
Apache バーチャルホスト説明書 - Apache HTTP サーバ バージョン 2.4
1台のマシンで複数ウェブサイトが運用できると何が嬉しいかと言うと、やはり コスト面が軽くなる事が嬉しい のではないでしょうか。
2つのウェブサイトを運用したいけど、そこまで重たいコンテンツを置く事が無い想定でEC2を2台立てるとコストが無駄になりそう……といった場合に助かります。
今回は、そんなバーチャルホスト環境をAWSで使えるもので構築してみた事をお話ししたいと思います。
用意してみた
今回、目指す環境は以下です。
▲ 用意するものとしては少なめ
やりたい事としては、
- https://test1.XXXXにアクセスすると/var/www/html/index.htmlが表示される
- https://test2.XXXXにアクセスすると/var/www/html/index2.htmlが表示される
といった事をやれる環境が作りたいなと思います。
今回の環境の前提条件
- EC2: Amazon Linux 2 (2020年1月30日現在最新のAMIを使用)
-
ACM: Amazonが発行するマネージドな証明書
-
Apache: 2.4.41(EC2のyumでインストール)
EC2の用意
CloudFormationで、最新のAMIからEC2を構築します。
AWSTemplateFormatVersion: "2010-09-09"
Description: Create EC2
Parameters:
AMIID:
Description: "Enter ami-id"
Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
Default: "/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2"Parameters部分で、/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 が入力されるようにしておいてCloudFormationを流します。
後でより楽に設定を行いたい場合は、ここでApacheをインストールするようにUserdataを記述しておくと楽かもしれません。
Apacheの設定
/etc/httpd/conf.d/ 下にXXXX.confファイルを作成して、バーチャルホストの設定を記述します。(ファイル名は任意)
<VirtualHost *:80>
DocumentRoot /var/www/html
DirectoryIndex index.html
ServerName test1.XXXX
</VirtualHost>
<VirtualHost *:80>
DocumentRoot /var/www/html
DirectoryIndex index2.html
ServerName test2.XXXX
</VirtualHost>記述後は、設定を読み込ませる為Apacheを再起動しましょう。
ACMの設定
今回は、test1.XXXXというドメインとtest2.XXXXというドメインを利用したいのでワイルドカード証明書を取得しました。
▲ 複数のサブドメインに対して1つで足りるので便利
余談ですが、更新時に生じる運用を楽にする為にDNS認証を利用すると楽です。(今回、以前検証用に取っていたワイルドカード証明書の期限が切れてました……)
以前書いたDNS検証に関するブログを参考までにご紹介させて頂きます。
ALBの設定
今回、HTTPS通信をEC2に送る為、以下のような443のリスナーを作成しました。
先ほど設定した、ワイルドカード証明書を設定しています。
▲ 今回はHTTPSのみ設定
また、今回はターゲットとなるEC2もEIPも一つなのでターゲットグループを設定する必要があまり無いのですが、どのターゲットグループを利用するのかを明示的に示したいので以下のように設定を行いました
ターゲットグループに関しては、次の項目で改めて設定内容をお話しします。
▲ 一応、各ターゲットグループに関して明示しました
ターゲットグループの設定
ヘルスチェックを行い、正常な場合だけルーティングを実施する為にターゲットグループの設定を行います。
今回、前述したバーチャルホストの設定ファイルに記載してあるファイルについてヘルスチェックを実施したいので、以下のようにターゲットグループを設定しました。
▲ test1.XXXXに関するヘルスチェック設定
▲ test2.XXXXに関するヘルスチェック設定
Route53の設定
今回利用したいサブドメイン2種類の設定を以下のように記述しました。
▲ これで、ALBと各サブドメインが結びつきました
Chrome上で確認してみる
さて、これで設定は完了しました。
各サブドメインに対して、Chromeからアクセスして確認して見ます。
それぞれのサブドメインに設定したディレクトリインデックスには、対応するサブドメイン名(test1かtest2)が記載されているので、それが表示されればバーチャルホストに依ってアクセスが振り分けられている事が示せるようになっています。
▲ こっちがtest1.XXXXにアクセスした時
▲ こっちがtest2.XXXXにアクセスした時
無事、振り分けされている事が確認できました！
HTTPSで接続しているのでACMで利用している証明書もついでに確認しておきます。
▲ とりたてほやほやのプライベート証明書
AWSをフルに使ってバーチャルホスト環境が用意できた！
今回は、HTTPSの通信のみでバーチャルホストの振り分けを実施するようにしました。
現在HTTPでアクセスされた場合には以下のようにエラーが発生してしまいますが、リダイレクトでHTTPSに飛ばす設定をALBのリスナーに設定しておくと、サイト利用者にとって親切な動きをしてくれるといったように、設定しておくと優しい設定も他にあるかと思います。
▲ このようにならないようにする
基本的に、バーチャルホストの設定は各ミドルウェアに依り(Apache、Nginx等)、それ以外に関してはバーチャルホストの利用有無関係無くEC2+ALB+ACMの環境を構築・設定するのと同じになります。
ですが、設定する箇所は結構多いと思うので、自動化できるとことは自動化し(CloudFormationやUserDataを活用する)手作業による作業ミスを減らせるように構築・設定する事を心掛けるとより捗るようになるかと思います。
このブログが、AWSでバーチャルホストを設定したい方の助けになれば幸いです。
1
