はじめに

当記事は、【ECS準備編】【ECS起動編】からの続編です。

まだ、お読みでない方は先にそちらからご覧ください。

使用技術

ECS/Fargate(blue/greenデプロイメント)
ELB(ALB)
Rails6

作業内容

ドメインの取得
ACMの取得
ロードバランサーの編集
Railsのproduction.rbの編集
Route53の設定
ECSサービスの更新

1. ドメインの取得

現状は、AWS側で自動生成されたDNS名でアクセスできます。

ALB名-ランダムな数字.リージョン名.サービス名.amazonaws.com

提供しているサービスとは関係のない名称なので
自分でドメインを作成していきましょう。

例）
xxxshop.com
foodccc.jp

こういったドメイン名は、レジストラという事業者から購入できます。

お名前.comが有名ですが、AWSのRoute53からも購入できますので
当記事ではRoute53を利用します。

それでは、AWSサービス一覧からRoute53を検索して移動します。

ドメイン画面に移動してドメインの登録を押します。

まずは、入力フォームに任意のドメイン名を入れます。
その隣にプルダウンメニューで.comや.jpなどが選べます。
選択後、チェックを押して他ドメインとの重複がないか調べてもらいます。

ステータスが使用可能となれば購入できますので
アクション下のカートに入れるをクリックします。

すると、右側にショッピングカートが出てきますので、
使用する年数を決めます。

最後に続行ボタンを押します。

次のページは、個人情報の入力画面となります。

メールアドレスなどに間違えがないように入力してください。

もし、存在しないメールアドレスだと以下のような忠告がAWSから出されます。

最終確認画面で、AWS規約にチェックを入れて、注文を完了を押したら購入できます。

2. ACMの取得

続いて、AWS版の証明書となるACMを取得します。

接続先への通信をSSLで暗号化するには、
接続先に秘密鍵と証明書が必要です。

証明書は、本来は第三者機関の認証局が発行します。
ですが、AWSではACMという機能で無料で作れます。

今回はコンテナへの仲介役としてALBが存在しますので
同ALBに証明書を持たせる形になります。

それでは、まずACMを取得していきましょう。

AWSサービス一覧からacmを選択します。

リクエストを押します。

パブリック証明書をリクエストで次に進みます。

完全修飾ドメイン名は、先ほど取得したドメインを入力します。

検証方法はDNS検証を選択します。

最後にリクエストを押します。

ステータスが発行済みになったら完了です。

3. ロードバランサーの編集

現在、blue/greenデプロイメントの設計上で、ALBのリスナーには
・　HTTPポート(80)
・　カスタムポート(10080)
の２つが設定されています。

そこにHTTPSポート(443)を追加します。

更に、HTTPポート(80)にはルールを指定して
HTTPSポート(443)にリダイレクトする設定を行います。

では、実装を始めましょう。

まずは、EC2画面から
サイドバーのロードバランサー　→ 対象ALBをチェック　→ リスナーのタブ　→
リスナーの追加をクリックします。

リスナー追加画面に移動したら、
HTTPSプロトコルの443ポートとして、
blueターゲットグループを指定します。

SSL証明書は、先ほどACMで作成したものを設定しましょう。

最後にリスナーの追加をクリックします。

これで、HTTPS(443)のリスナーがALBに新しく登録されました。

続いて、既存のHTTP（80）のリスナーに個別ルールを指定します。

まず、対象ALBのリスナータブに戻って、
ルールの表示/編集をクリックします。

そこで新しく個別ルールの挿入していきましょう。

条件は、パスが/*と一致するなら　→ HTTPS（443）にリダイレクトする　というものです。

*(ワイルドカード)は全てのパスとなるので、必然的にHTTP(80)にアクセスしたユーザーは
無条件でHTTPS（443）にリダイレクトされる意味になります。

4. Railsのproduction.rbの編集

続いて、Rails側のコード変更です。

ここでは、config.force_ssl = trueをコメントインしています。
これにより、Railsが強制的にHTTPS通信を求める設定になります。

ただし、このままではALBのヘルスチェックはHTTP（80）としているので、
上手くパスしてくれません。

そのため、追加コードとして、ELB(ALB)のヘルスチェックに限っては例外的にSSLを強制するコードは適用しないとする設定を行っています。

これは、下記記事を参考にさせて頂きました。
(私のコードはrubocopで自動修正したものです。)

config/environments/production.rb

require 'active_support/core_ext/integer/time'

Rails.application.configure do

--省略--

  # Force all access to the app over SSL, use Strict-Transport-Security, and use secure cookies.
  config.force_ssl = true
  # ELBヘルスチェックは例外として80->443のリダイレクトはしない設定
  config.ssl_options = { redirect: { exclude: ->(request) { request.env['HTTP_USER_AGENT'].include?('ELB-HealthChecker') } } }

--省略--

end

5. Route53の設定

続いて、AWS版のDNSサーバーであるRoute53の設定です。

ここでは、Aレコードのエイリアス機能を使用します。

それによって、ドメイン名でアクセスしてきたユーザーを
ALBに向けることができ、最終的に閲覧してほしいRailsコンテナに行き着きます。

以前インフラの補足：参考まで
私の前インフラ環境では、
EC2は、インスタンス起動時に変動してしまうパブリックアドレスを
ElasticIPで固定化し、Route53に名前解決を担ってもらっていました。

ECSでは、コンテナ生成時にIPアドレスが割り振られますので
固定化はできていませんが、Route53はAレコードのエイリアスを用いて
ALBに向けているので、内部で上手く処理してくれる…と推測しています。

では、実装していきましょう。

まず、Route53画面のホストゾーンを押します。

Route53でドメイン取得していれば、デフォルトでホストゾーンが存在するはずです。
もし他のレジストラでドメインを取得した場合などは、ホストゾーンを自分で作りましょう。

取得したドメインをクリックします。

レコードを作成をクリックします。

各種ルーティングポリシーの中から、シンプルルーティングを選択します。

シンプルなレコードを定義をクリックします。

レコード名は、無記入でも良いです。
必要であれば、ホスト名を追加してください。

レコードタイプは、Aレコードを選択します。

ルーティング先は、ALB（エイリアス）を選択して
リージョンは東京とした上で
自分のALBを選択してください。

最後にシンプルなレコードを定義を押します。

元の画面に戻りますので、レコードを作成をクリックして
レコードを完成させましょう。

6. ECSサービスの更新

これで、最後の作業です。

現在、ECSと連携しているALBは
・プロダクションリスナー：　HTTP(80)
・テストリスナー：　カスタムTCP(10080)
としています。

そこを
・プロダクションリスナー：　HTTPS（443）
・テストリスナー：カスタムTCP（10080）
に変更します。

しかし、ECSと連携しているALBのリスナー設定は
サービスの更新では対応できないようなので
新しく別のサービスを起動して対応します。

新しいサービスが正常に起動できたことを確認後、
古い方のサービスを削除します。

注意すべき点は、新しいサービスを起動する前に
ALBのプロダクションリスナーとテストリスナーのデフォルト設定を
blueとgreenに正しく分けておく工夫が必要です。

では、実装していきましょう。

まず、EC2の画面から
サイドバーのロードバランサー　→ 対象ALBのチェック　→ リスナーのタブ　から
現況を確認します。

ルールの列にある転送先に注目すると、
HTTPS:443とHTTP:10080のターゲットグループがgreenで同じになっていますので
このケースでは正しくありません。

blue/greenデプロイメントで何度かサービスの更新をしていると
デフォルトの転送先が意図しないものに切り替わってしまっている可能性がありますので
もし同じ現象になっている方は手動で変更します。

今回のケースでは、HTTPS：443がblueではなくgreenとなってしまっているので
ここをblueに変更していきます。
(HTTP:10080がblueとなっていても同じやり方でgreenに直せます。)

それでは、対象リスナーをチェックして、編集をクリックします。

リスナー編集画面に移動したら、現在設定されている転送先を
ゴミ箱のアイコンを押して削除します。

その後、アクションの追加を押して
転送先を選択します。

続いて、blueターゲットグループをプルダウンで選択して
更新を押します。

これで、リスナーを
・HTTPS：443 は　blueターゲットグループ
・HTTP：10080 は　greenターゲットグループ
と整備ができました。

ここからECSサービスを新規作成します。
更新ではなく、作成を押します。

設定内容は、ECS起動編で入力したものと同じです。

ここも設定内容は、ECS起動編で入力したものと同じです。

ここだけ違いますので、注意します。

プロダクションリスナーはHTTPS：443とします。
（前回はHTTP：80としていました。）

テストリスナーはHTTP：10080です。

ターゲットグループは、blue-tg, green-tgの順に登録します。

ここも設定内容は、ECS起動編で入力したものと同じです。

ここも設定内容は、ECS起動編で入力したものと同じです。

サービスの作成を押して、タスクの起動を待ちましょう。

前回と同様に、ECSサービスのイベントタブより
has reached a steady state.
が確認できれば、成功しています。

これで新しいサービスからタスクを生成できました。

現状は古いサービスも残っているかと思いますので、
無駄に料金コストがかからないように削除しましょう。

続編

終わりに

ふと、疑問に思ったけどterraformって、GUIで作成したもの全てを
コードから構築できるんだろうか？

細かい部分だけ、部分的にGUIでしないといけなかったら
整理するの大変に感じそう…

今回も長い記事になってしまいましたが、最後までお読みいただき、
ありがとうございました！