Amazon API Gateway にカスタムドメインを設定する

概要

Amazon API Gateway に独自ドメインを設定しアクセス可能にします。
SSL証明書は AWS Certificate Manager を利用します。

前提条件

この記事の内容を実践する為に必要な前提条件です。

  • 公開可能済のAPI Gatewayが存在している事
  • 利用可能なドメインを取得している事
  • AWS Certificate ManagerでSSL証明書が準備されている事

前提条件1 API Gatewayの準備

API Gatewayの準備ですが、Serverless Framework を使うと簡単に用意出来るのでオススメです。
以前、 Serverless Frameworkのインストールと初期設定 という記事を書きましたので参考になると幸いです。

前提条件2 利用可能なドメインを取得する

Route 53でドメインを購入すると全てがAWSのサービスで管理出来る事になるのでオススメです。
ドメインの購入方法等は下記の記事に載せてありますので参考にして頂けると幸いです。

前提条件3 AWS Certificate ManagerでSSL証明書を準備する

手順に関しては難しくありません、 AWSのサービスでドメインを取得しALBでSSLで接続出来るようにする に取得方法を記載してあります。

1点だけ注意点があります。それは証明書を配置する region は必ず us-east-1 米国東部(バージニア北部) にする事です。

2017-06-15 現在の時点では AWS Certificate Manager の証明書を利用する為には、証明書が us-east-1 米国東部(バージニア北部) に配置されている必要があります。

API Gatewayにカスタムドメインの設定を行う

マネジメントコンソール → Amazon API Gateway → +カスタムドメイン名の作成 より設定を行います。

以下の情報を入力します。

  • ドメイン名: 任意のドメイン名を入力します
  • ACM 証明書: 作成した証明書を選択します
  • ベースマッピング: 作成したどのAPI Gatewayにマッピングさせるかを選択します

custom-domain1.png

「保存」を押すと作成が開始されます。(かなり時間がかかります)

しばらくすると下記のような形になります。
この「ディストリビューションドメイン名」という箇所をコピーしましょう。

custom-domain2.png

ディストリビューションドメイン名をRoute 53に設定する

DNSレコードの設定を行っていきます。

私の場合はAPI Gatewayに設定したドメインは 元々持っていたドメインのサブドメインとして設定を行いました。

その為、元々のHosted zoneにAレコードとして登録を行います。

Name: 設定したドメイン名を入力
Alias Target: 先程コピーしたディストリビューションドメイン名

custom-domain3.png

このあたりの方法に関しては AWSのサービスでドメインを取得しALBでSSLで接続出来るようにする でも方法を紹介しています。

動作確認

最後に動作確認を行います。

自動で割り当てられるURLで接続
curl -v https://i99999999i.execute-api.ap-northeast-1.amazonaws.com/development/other
設定したカスタムドメインで接続
curl -v https://api-gateway.hoge.org/other

両方で同じ内容が返ってくれば成功になります。

以上になります。最後まで読んで頂きありがとうございました。

続きを読む

Mastodonインスタンス構築(鯖:AWS EC2、ドメイン:お名前.com、SSL:Let’s Encrypt)

まずは

QiitaはROM専(死語?)だったので初投稿。
こちらの記事に勇気付けられた。

「僕が書いたことはみんな書いている、ハマっていることは共有しなくてもいい」という考えも浮かぶと思うが…
・情報鮮度の観点で出す価値あり

http://qiita.com/hinom77/items/dfa9e0c734e47271edb7

たしかにググって記事がたくさん出てくると学んでて損はない技術なんだろうと思えてくる。
ビッグウェーブに乗りたいというのもある。
というわけで何番煎じかわからないがマストドンのインスタンス構築記録を書く。
見せ方、引用の仕方など作法があればご容赦。
Qiitaのマークダウンすらままならず…。

基本的な軸

基本的には↓↓を参考にさせていただきました。
私の環境で違ったところだけ横道に反れたりしながら追記してます。
基本は参考URLを見ていただき、たまにこっちに戻ってくるという感じがよいかと。
※以降【】でかこっている中項目は下記参考先の中項目タイトルに準じています。

■マストドンAWS構築チュートリアル完全版|初心者から大規模運用まで 5.お手軽な手順
http://webfood.info/mastodon-aws-tutorial/#section-5

【EC2インスタンスの作成】

インスタンススペックはt2.microを選択。
無料枠で選択できたので。

【Route53でHosted Zoneを作る】

丸々飛ばし。
DNSはお名前.comに任せる。

AWS EC2のインスタンスに固定グローバルIPを付与

AWSでは固定グローバルIP=Elastic IPと呼ばれている。
↓↓に書かれている通りに沿って進める。

■AWS EC2インスタンスにElastic IP(固定グローバルIPアドレス)を割り当てる
https://ac-5.net/aws/aws_elasticip_allocation

AWSのElastic IPを独自ドメインと関連付ける

DNSの設定。関連付ける、という言葉が正しいのかどうか。

■(お名前.com)ネームサーバーのAレコード設定
http://rensrv.com/domain/onamae-com/a_record-setting-onamae-com/

【SSHでログインする】

そのまま。

【Let’s EncryptでSSL証明書を取得する】

$ ./certbot-autoの箇所で途中、エラーで正常終了しなかった。

Requesting root privileges to run certbot...
/home/ubuntu/.local/share/letsencrypt/bin/letsencrypt
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Failed to find executable apache2ctl in PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
Certbot doesn't know how to automatically configure the web server on this system. However, it can still get a certificate for you. Please run "certbot-auto certonly" to do so. You'll need to manually configure your web server to use the resulting certificate.

apache2の起動コマンド(?)が見つからないようだ。
そもそもデフォルトでインストールされていないぽい。
↓↓
●対応:apache2インストール→再度実行

$ sudo apt-get update
$ sudo apt-get install apache2
$ ./certbot-auto

結果としてこれで成功したが、完了までにいろいろ聞かれたので参考までに記載。

●ドメイン名を入力してくれー
No names were found in your configuration files. Please enter in your domain
name(s) (comma and/or space separated) (Enter ‘c’ to cancel):

自前のドメイン名を入力して、エンター。

●HTTPSのみの接続にする?
Please choose whether HTTPS access is required or optional.
——————————————————————————-
1: Easy – Allow both HTTP and HTTPS access to these sites
2: Secure – Make all requests redirect to secure HTTPS access
——————————————————————————-
Select the appropriate number [1-2] then enter:

2の方が無難かと考え、2を入力してエンター。

●成功の確認
——————————————————————————-
Congratulations! You have successfully enabled https://(設定したドメイン)

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=(設定したドメイン)
——————————————————————————-

一応言われている通りにアクセスしたら、A評価(多少時間かかる)。

【ミドルウェアの設定】

t2.microなのでスワップ設定は飛ばし。

と思ったら後ほど出てくるdocker-composeでひっかかった。
処理が途中で止まってしまうのだが、どうやらメモリ不足が原因らしい…。

$docker-compose run --rm web rails assets:precompile

http://uyamazak.hatenablog.com/entry/2017/05/22/151210

たしかにスワップの設定後、再トライしたら処理が完了できた。

あと、念のためnginxの編集前の設定ファイルをコピーして残しておく。

cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.ort

【マストドンのセットアップ】

ここでだいぶ時間を食った…。

Docker動いてない?

ERROR: Couldn’t connect to Docker daemon at http+docker://localunixsocket – is it running?

●いろいろ対応:
・鯖再起動←たぶん関係ない。
・pip3のupgrade←アップグレードは成功したがたぶん関係ない。
 ただ、一応やったことなので残しておく。

$sudo pip3 install --upgrade pip

・インストール済かの確認

$pip3 list
docker-compose (1.13.0)

結局よくわからず↓↓を参考に入れ直す。

■今何かと話題のマストドン(mastodon)鯖を自分用に無料で立てる方法
【必要なものをインストールする】のセクション
http://jtwp470.hatenablog.jp/entry/2017/04/15/174036

その後、再度実行→成功!

$ sudo docker-compose build

以降、

$ sudo docker-compose run --rm web rake secret

から続行。
以降、assetsのdocker-composeで躓くも何とかAbout画面表示までこぎ着けた…。
まずは一旦の達成感。

【メールの設定】

今回はとりあえず自分のテスト用鯖なのでSESの制限は解除しない。
他はそのまま。

【cronの設定】

今回参照させていただいているところはマストドンのインストールディレクトリを指定しているのでcron内のパスを修正。
/home/ubuntu/mastodon→/home/ubuntu/live
他はそのまま。

ログインと管理画面

最後に、今回はとりあえず個人用インスタンスということにしているのでユーザ認証は手動で実行。
ということで↓↓を参考にさせていただきました。

■今何かと話題のマストドン(mastodon)鯖を自分用に無料で立てる方法
【初期登録と管理画面をだす方法】【管理画面の出し方】
http://jtwp470.hatenablog.jp/entry/2017/04/15/174036

なぜか手動認証のコマンドを打っても自前のgmailアカウントが見つからないと言われたので、適当な捨てアドを作り、登録し、管理画面から認証するという手順を踏みました。

さいごに

最初は探り探りだったので時間としては朝から晩までかかりました。
2回目はこの手順を残しておいたので2時間強くらいでできました。
1回目構築終わったあと、疲れなのか何なのかAWSのインスタンを消去してしまい、朝起きたときは絶望しましたが逆にこの手順が間違ってなかったことを自分で証明できてよかったよかった(?)
インスタンス構築にあたり最近の技術も勉強できたのでそれもよかった。
Dockerのことがまだはっきりと理解しきれていないので引き続き勉強ですね。

最後になりましたが、参考にさせていただいた先人たちには多大なる感謝を。
またこの記事がこれからの誰かの役に立てれば幸いです。

参考サイトまとめ

■マストドンAWS構築チュートリアル完全版|初心者から大規模運用まで
http://webfood.info/mastodon-aws-tutorial/
■AWS EC2インスタンスにElastic IP(固定グローバルIPアドレス)を割り当てる
https://ac-5.net/aws/aws_elasticip_allocation
■(お名前.com)ネームサーバーのAレコード設定
http://rensrv.com/domain/onamae-com/a_record-setting-onamae-com/
■今何かと話題のマストドン(mastodon)鯖を自分用に無料で立てる方法
http://jtwp470.hatenablog.jp/entry/2017/04/15/174036

続きを読む

AWS ALBはWebDAVを通してくれるのか?

長いので先に結論

結論を先に書くと、ALBはWebDAVを通してくれます。よかったですね。

素朴な疑問

AWSの新しいロードバランサ、Application Load Balancer(ALB)がリリースされました1
プロトコル面ではWebSocketやHTTP/2のサポートなどが目新しいところですけども、果たしてWebDAVは通るんだろうか?
と云うわけで調べてみたものの、意外にも類例が見つからなかったので試してみました。

やってみた

テスト構成

今回は以下の構成でテストを行いました。

構成図

セキュリティグループ、ターゲットグループ、ACM(SSL)の設定は割愛します。

EC2インスタンスの設定

下記構成のEC2インスタンスを2つ作成し、各サブネットに1つずつ配置しました。

EC2インスタンスのOSはAmazon Linux2を使用しました。
インストールしたパッケージはhttpd24のみです。
http24の設定ファイルには手を加えず、/etc/httpd/conf.d/webdav.confファイルを作成し下記内容を追加しています。

webdav.conf
DavLockDB /tmp/DavLock

Alias /dav/ /var/www/dav/

<Directory "/var/www/dav/">
    Dav on

    Options None
    AllowOverride None

    AuthType Basic
    AuthName WebDAVoverALBTest
    AuthUserFile /var/www/.htpasswd

    <RequireAll>
        Require valid-user
    </RequireAll>
</Directory>

WebDAVのローカルディレクトリは/var/www/dav/、HTTP上のディレクトリは/dav/になるよう設定しています。また/healthcheckでヘルスチェックできるようにしています。

ALBの設定

次にELBの作成に移ります。
まずはロードバランサタイプの選択から。もちろんここはALBを選びます。
ロードバランサタイプの選択

ロードバランサの設定は前述の構成通りに行います。
ステップ1

SSL証明書の設定。ここでは事前にACMで作成したものを使用しました。
ステップ2

セキュリティグループの設定。HTTPSが開いているだけのものを事前に作成してあります。
ステップ3

ルーティングの設定。
ステップ4

ターゲットの登録。EC2インスタンスは事前にターゲットグループへ登録済みです。
ステップ5

作成の確認。
ステップ6

ALBを作成しましたので、続いて「ルールの表示/編集」に移ります。
ロードバランサ一覧

ルールを追加し、/dev/fuga/へのアクセスは2つ目のターゲットグループへフォワードするよう設定します。
ルールの編集
ルール保存完了

手元の環境では、上記の設定でWebDAVの読み書きが2つのEC2インスタンスに振り分けられることを確認しました。

あとがき

今どきWebDAVを採用する機会は少ないでしょうし、ましてや同一ホスト名で複数サーバに振り分ける用途がどれだけあるかは分かりませんが、参考になれば幸いです。

注釈


  1. 「新しい」と云っても、すでに発表から10ヶ月(本稿執筆時点)経ちましたが‥‥‥ 

  2. 本稿執筆時点では2017.03 

続きを読む

AWSでSSL証明書の作成方法

SSL証明書をIAMにアップロードして利用していましたが、期限が近づいているという連絡が来ました。
AWSには無料で使えるACM(AWS Certificate Manager)があるので、証明書を作成し置き換えたいと思います。
これはその時のメモです。

手順

手順1

EC2 > ロードバランサー
から該当のロードバランサーを選択し、[リスナー]タブの「編集」ボタンを押します。
image.png

手順2

SSL証明書の「変更」ボタンを押します。
image.png

手順3

「AWS 証明書マネージャ (ACM) から、既存の証明書を選択する」を選択し、
「ACM から新しい証明書をリクエスト」のリンクを押します。
image.png

手順4

ドメイン名を入力後、「確認とリクエスト」ボタンを押します。
確認画面に遷移するのでもう一度ボタンを押してください。(スクリーンショットは省略)
image.png

手順5

リクエストを行うと下記画面が出ます。
リクエストを送信したメールアドレスもここに表示されます。
image.png

手順6

Amazonから届いたメールにリンクが貼ってあります。
そこから確認画面に遷移し、「I Approve」ボタンを押してください。
完了画面(スクリーンショットは省略)に遷移したら、あとは設定です。
image.png

手順7

手順3の画面を再ロードすると証明書が選択できるようになっています!
こちらを選択し、保存すれば完了です。
image.png

手順8

ブラウザからページを開き、証明書が正しいか確認してください。
※確認したので気付けましたが、ワイルドカードにし忘れるという、しょうもないミスを私はしました。。。

証明書の更新について

条件を満たしていれば自動更新されます。
http://docs.aws.amazon.com/ja_jp/acm/latest/userguide/configure-domain-for-automatic-validation.html

自動更新できない場合でも有効期限切れ45日前からメールで通知が来るようです。(手動更新)
http://docs.aws.amazon.com/ja_jp/acm/latest/userguide/managed-renewal.html#how-manual-domain-validation-works

まとめ

素早く、簡単にでました。
簡単なのにキャプチャしっかり取りすぎました。

続きを読む

AWS LambdaにSSL証明書の有効期限を確認して通知するSlackボットを作成した

はじめに

現在、私がプライベートで持っているサーバのSSL証明書は Let's Encrypt で設定します。
Let's Encrypt は証明書の期限についてはメールでお知らせしてくれますが、メールだと他のメールと埋もれて確認漏れが起こっていたりしていました。

自動で更新したらええやん! というようなご指摘はあるかと思いますが、今回はそれは無視で

環境

ローカル

  • Python 3.6
  • macOS Sierra 10.12.4

AWS

  • Lambda

    • Python 3.6
  • CloudWatch

リポジトリ

https://github.com/nnsnodnb/slackbot_ssl_expiration

準備

Apps & integrationsBots を設定しておいてください

Bots___ひやかしプロジェクト_Slack.png

ライブラリ

requirements.txt
appdirs==1.4.3
packaging==16.8
pyparsing==2.2.0
requests==2.13.0
six==1.10.0
slacker==0.9.42

サンプルソース

bot.py
from slacker import Slacker
import datetime
import socket
import ssl
import slack_settings # 同ディレクトリに slack_settings.py を配置


slack = Slacker(slack_settings.SLACK_API_TOKEN)


def ssl_valid_time_remaining(hostname):
    expires = ssl_expiry_datetime(hostname)
    return expires - datetime.datetime.utcnow()


def ssl_expires_in(hostname, buffer_days=7):  # 7日前で期限分岐
    remaining = ssl_valid_time_remaining(hostname)
    if remaining < datetime.timedelta(days=0):
        raise AlreadyExpired("Cert expired %s days ago" % remaining.days)
    elif remaining < datetime.timedelta(days=buffer_days):
        return True
    else:
        return False


def ssl_expiry_datetime(hostname):
    ssl_date_fmt = r'%b %d %H:%M:%S %Y %Z'
    context = ssl.create_default_context()

    conn = context.wrap_socket(
            socket.socket(socket.AF_INET),
            server_hostname=hostname,
    )

    conn.settimeout(3.0)
    conn.connect((hostname, 443))
    ssl_info = conn.getpeercert()
    return datetime.datetime.strptime(ssl_info['notAfter'], ssl_date_fmt)  # ssl_info['notAfter'] が証明書の期限


def post_slack(hostname):
    message = '@channel https://' + hostname + ' '
    if ssl_expires_in(hostname):
        message += 'そろそろヤバイ'
    else:
        message += 'はまだ期限内' 

    # ここら辺のメソッドはslackerパッケージを使用
    slack.chat.post_message(
            '#expiration',
            message,
            as_user=True,
            link_names=True
    )


def execute(event, context):
    post_slack('<YOUR DOMAIN>')
slack_setting.py
SLACK_API_TOKEN = ''

ローカルで実行

$ python bot.py

スクリーンショット_2017-06-07_17_21_48.png

今回もまた 渡辺曜 さんにお知らせ係を担当していただきました。

Lambdaの設定

Lambda_Management_Console.png

  1. トリガーの設定
    Lambda_Management_Console.png
    各自好きなように設定。自分は cron で月〜金のAM2時に通知される設定を選択しています。
  2. 関数の名前は適当に入力
  3. ランタイムPython 3.6 を選択
  4. ソースコードアップロードは下で説明
  5. ハンドラbot.execute を入力
  6. ロール等は各自設定

外部ライブラリの反映

ローカル環境では以下コマンド等でなんとかなりますが、

ローカル環境
$ pip install -r requirements.txt

AWS Lambda上ではライブラリが認識されないので外部ライブラリごとアップロードする必要があります。

外部ライブラリをプロジェクトディレクトリに保存
$ pip install <LIBRARY_NAME> -t .

という感じにやればプロジェクトディレクトリに保存されます。
しかし、1つ1つやるのが面倒なので私は以下でしました。

$ pip freeze > requirements.txt  # requirements.txt がなければ
$ pip install -r requirements.txt -t .

あとはzipに圧縮してアップロードする

$ zip -r bot.zip *  # bot.zip は好きな名前

プロジェクトディレクトリに bot.zip ができているので .ZIPファイルをアップロード を選択して bot.zip をアップロードする

スクリーンショット 2017-06-07 17.41.57.png

うまく設定できれいれば設定した時間にSlackに通知がくるはず!
私の環境では先述通り 月〜金 AM2時 に渡辺曜さんがお知らせしてくれます!!

続きを読む

Route53+S3+CloudFrontでhttpsのurlをリダイレクトさせる

概要

サイトのお引越しの時などに、Route53+S3でS3の静的Webサイトホスティング機能を使うと便利なのですが、
Httpsをリダイレクトしたい場合、S3単体ではSSL証明書を扱うことができないため、CloudFront経由で行います。
その方法とはまったところを紹介します。

手順

  • S3のバケットを作り、全てのリクエストをリダイレクトするように設定する
  • Certificate Managerで証明書を作る
  • CloudFrontのDistributionを新しく作りOriginをS3にし証明書を設定する
  • Route53にS3に向くようにRecordを追加する

S3のバケットを作り、全てのリクエストをリダイレクトするように設定する

S3のコンソールを開いてバケットを作り、「Static Website Hosting」を選んで

スクリーンショット 2017-06-05 8.07.46.png

リダイレクト先を設定します。
スクリーンショット 2017-06-05 8.08.14.png

エンドポイントのところをクリックして意図通りにリダイレクトされたらOKです。

Certificate Managerで証明書を作る

CloudFrontで使うようの証明書を作るのですが、必ずリージョンをバージニア北部(us-east-1)で作ってください。そうしないとCloudFrontの設定画面に出てきません。ここにはまって少し時間を使いました。

スクリーンショット 2017-06-05 8.15.45.png

CloudFrontのDistributionを新しく作りOriginをS3にし証明書を設定する

スクリーンショット 2017-06-05 8.19.24.png

CloudFrontの設定をするのですが、ここでOrigin Domain Nameにサジェストで出てくるバケットを指定してはいけません!!!

S3はストレージとして使う時とWebサイトとして使うときでエンドポイントが違います!

ではここで何を指定するかというと、先ほどのS3の設定の時に出てきた{バケット名}.s3-website-{リージョン名}.amazonaws.comを指定します。ここにめちゃくちゃはまって時間を無駄にしました。ツライ。

あとは証明書を設定してCNAMEに自分のリダイレクト元にしたいドメイン名を指定します。

スクリーンショット 2017-06-05 8.32.24.png

Route53にS3に向くようにRecordを追加する

スクリーンショット 2017-06-05 8.29.03.png

AレコードでCloudFrontに向けてALIAS貼ります

まとめ

最初はS3とRoute53だけでできるんだろうと呑気にやってたら色々やらなきゃいけず、結構はまってしまいました。
設定し終わると便利だなあという感じ。

続きを読む

AWS:無料でSSL証明書を取得する方法

概要

先日公開した自分のサービスをhttps接続できるようにしたいと思いました。

SSL証明書は、どこが安くて信頼できるか社内の上司で相談したところ、近くにいたインターン生が「AWSなら無料で発行できますよ。」とナイスなアドバイスをくれました。

さっそく調べて、SSL証明書を取得したのですが、ネット上には断片的な情報しかなく思ったよりも詰まったので、これから取得する方のために、わかりやすく画像で解説します。

前提

今回は、無料でSSL証明書が利用できるAWS Certificate Manager(ACM)を使います。

アジアパシフィック (東京)は、ELB(ロードバランサー)のみにACMを使用することができます。

なので、ELBを利用していないと、無料のSSL証明書を使うことができません。

ちなみに、ELBは有料で、デフォルトで月2000円くらい掛かります。

もし使用される方は以下に設定方法を紹介しています。

初心者向け:AWS(EC2)にRailsのWebアプリをデプロイする方法 ⑤

手順

AWSの設定

サービスをクリックします。

スクリーンショット 2017-06-01 21.33.48.png

Certificate Managerを選択します。

スクリーンショット 2017-06-01 21.34.03.png

「今すぐ始める」をクリックします。

スクリーンショット 2017-06-01 21.34.19.png

ドメイン名を入力します。

スクリーンショット 2017-06-01 21.34.41.png

スクリーンショット 2017-06-01 21.35.19.png

「確認とリクエスト」をクリックします。

スクリーンショット 2017-06-01 21.38.20.png

「確定とリクエスト」をクリックします。

スクリーンショット 2017-06-01 21.39.16.png

以下が表示され、メールが届きます。

※ Whois情報に登録されたメールアドレスに送信されます。

スクリーンショット 2017-06-01 21.40.16.png

メールを確認し、赤丸で囲んだ部分をクリックします。

35a9b599-f008-0336-84d3-da727f32f761.png

「I Approve」をクリックします。

スクリーンショット 2017-06-01 21.50.02.png

赤丸で囲んだ部分をクリックします。

スクリーンショット 2017-06-01 21.50.18.png

以下が表示され、証明書が発行されました。

スクリーンショット 2017-06-01 21.51.31.png

サービスをクリックします。

スクリーンショット 2017-06-01 21.51.31.png

EC2を選択します。

スクリーンショット 2017-06-01 22.06.02.png

ロードバランサーを選択します。

スクリーンショット 2017-06-01 22.08.55.png

リスナーをクリックします。

スクリーンショット 2017-06-01 22.10.02.png

「編集」をクリックします。

スクリーンショット 2017-06-01 22.10.48.png

HTTPをHTTPSに変更します。

スクリーンショット 2017-06-01 22.12.19.png

「変更」をクリックします。

スクリーンショット 2017-06-01 22.13.09.png

赤丸で囲んだ部分をクリックします。

スクリーンショット 2017-06-01 22.13.46.png

スクリーンショット 2017-06-01 22.14.55.png

「保存」をクリックします。

スクリーンショット 2017-06-01 22.16.13.png

「閉じる」をクリックします。

スクリーンショット 2017-06-01 22.17.42.png

サービスをクリックします。

スクリーンショット 2017-06-01 22.28.51.png

Route53を選択します。

スクリーンショット 2017-06-01 22.29.29.png

Hosted zonesをクリックします。

スクリーンショット 2017-06-01 22.30.12.png

対象のドメインをクリックします。

スクリーンショット 2017-06-01 22.30.49.png

「Go to Record Sets」をクリックします。

スクリーンショット 2017-06-01 22.31.58.png

Type: Aのドメインを選択します。

スクリーンショット 2017-06-01 22.33.23.png

AliasをYesに選択します。

スクリーンショット 2017-06-01 22.34.40.png

赤囲みの部分にELBを設定します。

スクリーンショット 2017-06-01 22.41.25.png

作成したELBを設定します。

スクリーンショット 2017-06-01 22.42.23.png

「Save Record Set」をクリックします。

スクリーンショット 2017-06-01 22.43.08.png

サーバとWebアプリの設定

  • ここからはサーバとWebアプリの設定をします。
  • 自分は、RailsとNginxを使っていまして、以下の設定をしています。

/etc/nginx/conf.d/christchurches-map.conf
upstream unicorn_server {
    server unix:/var/www/projects/christchurches-map/tmp/sockets/.unicorn.sock
    fail_timeout=0;
}

server {
    listen 80;
    client_max_body_size 4G;
    server_name 52.192.101.190;

    keepalive_timeout 5;

    # Location of our static files
    root /var/www/projects/christchurches-map/public;

    location ~ ^/assets/ {
        root /var/www/projects/christchurches-map/public;
    }

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;

        if (!-f $request_filename) {
            proxy_pass http://unicorn_server;
            break;
        }
    }

    error_page 500 502 503 504 /500.html;
    location = /500.html {
        root /var/www/projects/christchurches-map/public;
    }
}

Railsアプリに移動します。

$ cd /var/www/projects/christchurches-map/
$ vi config/environments/production.rb
#コメントアウトされていたものを外す
config.force_ssl = true

Unicornの起動を確認します。

$ ps -ef | grep unicorn | grep -v grep
501      29166     1  0 19:31 ?        00:00:01 unicorn_rails master -c /var/www/projects/christchurches-map/config/unicorn.conf.rb -D -E production
501      29169 29166  0 19:31 ?        00:00:00 unicorn_rails worker[0] -c /var/www/projects/christchurches-map/config/unicorn.conf.rb -D -E production
501      29171 29166  0 19:31 ?        00:00:00 unicorn_rails worker[1] -c /var/www/projects/christchurches-map/config/unicorn.conf.rb -D -E production

表示されたUnicornの番号をkillします。

$ kill 番号

$ kill 29166

Nginxを再起動します。

$ sudo service nginx restart

Unicornを再起動します。

$ bundle exec unicorn_rails -c /var/www/projects/christchurches-map/config/unicorn.conf.rb -D -E production

ブラウザから設定したドメインにアクセスします。

https://www.christchurches-map.com/

スクリーンショット 2017-06-01 23.00.26.png

以上で設定完了となります。

続きを読む