Open in app

Sign in

Write

Sign in

[2章]Play Framework(Scala)をAWS(EC2)にデプロイしてWelcome to Play!を表示させる

takahiko tominaga
nextbeat-engineering
Published in
32 min readApr 23, 2021

はじめに

お久しぶりです。ネクストビートの富永です。
今回も、引き続きAWSに関する内容となっております。

前回の1章では、ネットワーク(セキュリティー)レイヤーの構築を行いました。
本ブログは1章の続きであり、アプリケーションレイヤーの構築を行っていきます。
1章をまだ読んでいない方は、先に読むことをおすすめします。

[1章]Play Framework(Scala)をAWS(EC2)にデプロイしてWelcome to Play!を表示させる

今回は、AWSに関する内容となっており、1章、2章の2部構成になっております。 2つの章を通してタイトルの通り、Play Framework(Scala)をAWS(EC2)にデプロイして、「Welcome to…

medium.com

本ブログのアプリケーションレイヤーの構築では、以下のような構成を完成させます。

構成図

本ブログでは、以下の2項目を行います。

  1. EC2インスタンスの設定
  2. ELBの設定
  3. AWS Systems Managerの設定
  4. Play Frameworkの環境構築
  5. Nginxの設定

1. Elastic Compute Cloud(以降EC2)インスタンスの設定

EC2の設定では、下記を行います。

EC2とは

EC2とは、公式で下記のように記載されています。

安全でサイズ変更可能なコンピューティング性能をクラウド内で提供するウェブサービスです。ウェブスケールのクラウドコンピューティングを開発者が簡単に利用できるよう設計されています。Amazon EC2 のシンプルなウェブサービスインターフェイスによって、手間をかけず、必要な機能を取得および設定できます。お客様のコンピューティングリソースに対して、高機能なコントロールが提供され、Amazon の実績あるインフラストラクチャ上で実行できます。[4]

簡単にいうと、仮想サーバーのことです。

仮想サーバーとは

仮想サーバーとは、1台のサーバー上で複数のオペレーションシステム(OS)を動かし、複数のサーバーとして運用する仕組みのことです。

仮想サーバーには、「ホストOS型」「ハイパーバイザー型」の2種類があるようです。

ホストOS型

ホストOS型とは、WindowsやMacなどのホストOSに仮想化ソフトウェアをインストールし、LinuxなどのゲストOSを動かす仕組みです。
ソフトウェアを土台とするため、すでに使っているOSにアプリケーションを導入する感覚で、手軽にサーバーを仮想化できます。
しかし、仮想サーバーへのアクセスにホストOSを経由するため、複数のOSを運用すると処理速度が出にくくなります。

ハイパーバイザー型

ハイパーバイザー型とは、ハイパーバイザーと呼ばれる専用ソフトウェアをサーバーへ直接インストールし、ホストOSを経由せずにゲストOSやアプリケーションを動かす仕組みです。ハイパーバイザーを土台にして、ゲストOSを直接制御するため、ホストOS型よりも処理速度が出ます。
ただし、既存のハードウェアによっては、ハイパーバイザー型に対応していないケースがあります。[1]

AWSはこの「ハイパーバイザー型」というものであり、KVMというものを使用しているそうです。

ここら辺の説明は、筆者の知識が乏しいので、URLのみ貼っておきます。

【初心者向け】仮想サーバーとは？メリット・デメリットを解説[1]
KVM とは

EC2の作成

まず、マネジメントコンソールからEC2を選択して、ナビゲーションペインからインスタンスを選択しましょう。

下記画像左上の「インスタンスの作成」を選択します。
(※インスタンスの一覧が表示されていますが、初めての場合何も表示されていません)

続いて、Amazon Machine Image(以降AMI)の選択です。

AMIとは、ソフトウェア構成 (オペレーティングシステム、アプリケーションサーバー、アプリケーションなど) を記録したテンプレートのことです。

AMIからインスタンスを起動することで、ウェブサーバーが起動し、アプリケーションをリクエスト受け付け可能な状態にすることができます。

今回は、無料枠であるAmazon Linux 2を選択します。

お次は、インスタンスの選択です

インスタンスが、仮想サーバーのことです。インスタンスの選択は、パソコンでいうとメモリやCPUのスペックを選択するようなものです。

ここも無料枠である、「t2.micro」を選択します。

選択したら、右下のボタンから「次のステップ:インスタンスの詳細の設定」に進みましょう。

先ほど選択した、インスタンスの詳細設定を行っていきます。

・インスタンス数: 作成するインスタンスの数
複数作成することも可能です。
アプリケーションサーバーとデータベースサーバーを分けたりできます

・購入のオプション: スポットインスタンスのリクエスト
チェックを入れると、AWS クラウド内の使用されていない EC2 キャパシティーを活用できます。

・ネットワーク: VPCの選択
どのVPCを使用するかを選択します(先ほど作成したものを使用)

・サブネット: サブネットの選択
どのサブネットを使用するかを選択します
NATゲートウェイを紐づけたPrivateサブネットを選択します

・自動割り当てパブリックIP: パブリックIPを付与するかどうかを決めます

・配置グループ: インスタンスのグループ化
ネットワークパフォーマンスの向上や物理サーバ障害時の影響範囲を限定させるために、インスタンスをグループ化します

・キャパシティーの予約: AZごとにリソースの確保
AWSではAZごとにリソースの上限が決まっており、それを超えるとEC2インスタンスの起動ができなくなります。
キャパシティ予約をしていると、事前にリソースを確保してくれるので、そういった問題を回避できます。

・IAMロール: AWSのサービスや他のアカウントに対して操作権限を付与するための仕組みです
【AWS IAMとは？】初心者にもわかりやすく解説がわかりやすかったです

・シャットダウン操作: EC2をシャットダウンした際に、削除するのか、それとも停止させるだけなのかを選択します

・終了保護の有効化: インスタンス終了に伴う復元不可防止の設定です

・モニタリング: CloudWatch を使用したインスタンスのモニタリング
Amazon EC2 から未加工データを収集し、リアルタイムに近い読み取り可能なメトリクスに加工することができます。

・テナンシー: ハードウェアを占有するか、それとも他の利用者と共有するかを選択します

次は、タグの追加を行います。

今回は、キーを「Name」にして、値を「EC2 Sample」にしました。
※タグはなしでも大丈夫です。

インスタンスに、defaultで設定されているセキュリティグループを設定します。

今まで選択した内容が表示されていますので、問題がなければ右下の「起動」を選択します。

キーペアを作成する画面が表示されます。

今回は、AWS Systems Managerを使用してEC2にアクセスを行いますので、キーペアの作成は行わなくても大丈夫です。

インスタンスの作成には、少し時間がかかりますが、下記画像のように表示されていれば、EC2の作成は完了です。

2. ELBの設定

ELBとは

ELBとは、ALB、CLB、NLBという3種類の魅力的なロードバランサーを持つAWSのロードバランシングサービスの総称のことです。[1]

Webサーバやアプリケーションサーバが複数あった場合に、通信負荷が均一になるように、トラフィックを分散する機能として使用します。

ALB(Application Load Balancer)

最新で最も高機能なロードバランサーです。HTTPトラフィックおよびHTTPSトラフィックの負荷分散、柔軟なアプリケーション管理が必要な場合に向いています。リクエストレベル(レイヤー7)で動作しており、マイクロサービスやコンテナなど、最新のアプリケーションアーキテクチャにも対応しています。

NLB(Network Load Balancer)

毎秒数百万のリクエスト処理が可能で、高度なパフォーマンスが必要な場合に適しています。突発的なトラフィックや、急激に変化するトラフィックにも対応可能です。接続レベル(レイヤー4)で動作しており、TCP/UDP/TLSのトラフィック負荷分散にも向いています。

CLB(Classic Load Balancer)

複数のAmazon EC2インスタンスにおける負荷分散を行う基本的なロードバランサーです。EC2 Classicネットワーク内で構築された既存のアプリケーションがある場合は、CLBの使用が必須となっています。リクエストレベル(レイヤー7)と接続レベル(レイヤー4)の両方で動作しています。

ELBは、Webサーバやアプリケーションサーバが、複数あった場合に使用するような感じで、説明を行いましたが、サーバーが1台しかなくても、AWS ELBを使用することができます。
サーバー1台で使用したとしても、AWS ELBの利用にはいくつものメリットがあります。

メリット

  1. インスタンスの差し替えが容易
  2. サーバーのヘルスチェックが可能
  3. 無料のSSL証明書が利用可能

ELBの作成

まず、AWSのELBを設定するページへいきます。

次に画像左上の「ロードバランサーの作成」を選択します。

先ほど説明したELBの３種類が表示されています。

今回は、1番左の「Application Load Balancer」を選択します。

ALBの設定

名前: ロードバランサーの名前です(わかりやすい名前を設定)

スキーム: クライアントからインターネット経由でリクエストをターゲットにルーティングします。内部ロードバランサーは、プライベート IP アドレスを使用してターゲットにリクエストをルーティングします。

IPアドレスタイプ: クライアントがロードバランサーとの通信に IPv4 アドレスを使用する場合は [ipv4] を、クライアントがロードバランサーとの通信に IPv4 アドレスと IPv6 アドレスの両方を使用する場合は [デュアルスタック] を選択します。ロードバランサが内部ロードバランサーの場合は、[ipv4] を選択する必要があります。

リスナー: ポート 80 で HTTP トラフィックを受け付けるリスナーです。

アベイラビリティーゾーン(AZ): 有効にするサブネットをゾーンごとに 1 つ選択します。

1章で作成したVPCを選択します。
サブネットは、各AZごとにPublicとPrivateをしました。
ALBに紐付けるのは、Publicのサブネットを紐付けます。

アドオンサービス: ロードバランサーをアクセラレーターに関連付けます
(よくわからない+なくても良さそうなので、スルー)

ロードバランサーにセキュリティグループを設定します。

1章で作成したものと、defaultの設定を紐付けます。

ターゲットグループ:リクエストをターゲットグループに転送するデフォルトのリスナールールです。

ターゲットを登録します。

EC2を選択して、「登録ずみに追加」を選択します。

登録済みのターゲットに追加できたのを確認します。

最後に設定の確認を行い、問題なければ「作成」を選択します。

以下画像のように作成が完了したら、ALBの設定は完了です。

3. AWS Systems Manager(以降ASM)の設定

AWSをコンソール上で使用できるよう設定

下記コマンドで、PythonとAWS-CLIをインストールします。

$brew install python
$brew install awscli

下記画像のように、まずはPythonインストールします。

次に、AWS-CLIをインストールします。

ASMの設定

ASMの設定に関しては、以下2つの記事が非常にわかりやすくまとまっていたので、2つの記事を参照します。

まずは、「【AWS Systems Manager】Privateサブネット内のEC2インスタンスにSSM経由でアクセスしてみた」の記事で、以下を行ってください。

  • 事前準備
    ※Privateサブネットは、すでに作成済みですので飛ばして大丈夫です
  • 手順1~4

【AWS Systems Manager】Privateサブネット内のEC2インスタンスにSSM経由でアクセスしてみた - Qiita

AWS Systems Managerにて、セッションマネージャ経由でのSSH接続がリリースされ、従来の煩わしいSSH管理から開放される未来が見えてきました・・・！…

qiita.com

上記設定が完了したら、「【AWS Systems Manager】AWS CLIを用いてSSM経由でEC2インスタンスにアクセスしてみた」の記事を参考にAWS CLIで同様にEC2にアクセスしていきます。

【AWS Systems Manager】AWS CLIを用いてSSM経由でEC2インスタンスにアクセスしてみた - Qiita

本記事は、事前に以下設定がされていることを前提とします。 (a) IAMユーザーの設定（プログラムアクセスキー情報取得、MFA認証設定、各種IAMポリシー付与） (b) AWS Systems…

qiita.com

全ての準備が完了して、コンソールで以下のように表示されていればSSMの設定は完了です。

sh-4.2$

4. Play Frameworkの環境構築

SSMでEC2にアクセスできたので、早速Play Frameworkの環境構築をEC2上で行っていきます。

環境構築では、下記を行います。

  1. Javaのインストール
  2. Scalaのインストール
  3. sbtのインストール
  4. Node.jsのインストール
  5. GitHubとの連携
  6. gitのインストール
  7. アプリのクローン

Java8.0系をインストール

PlayFramework2.5.x以降はJava8以上が必須なので、Java8.0系をインストールします。

下記コマンドで、Javaがインストールされているか確認します。
インストールされていなければ、インストールを行います。
今回は、Amazon Corretto 8を使用します。

sh-4.2$ java -version
sh-4.2$ sudo yum install java-1.8.0-amazon-corretto-devel

インストールが完了したら、再度バージョンを確認し、Java8.0系がインストールされていれば完了です。
上手くインストールできない場合は、以下の公式手順を参照してください。

Amazon Linux 2 に Amazon Corretto 8 をインストールする手順

sh-4.2$ java -version
openjdk version "1.8.0_265"
OpenJDK Runtime Environment Corretto-8.232.09.1 (build 1.8.0_265-b01)
OpenJDK 64-Bit Server VM Corretto-8.232.09.1 (build 25.265-b01, mixed mode)

sh-4.2$ javac -version
javac 1.8.0_265

Scalaインストール

Play FrameworkをScalaで使用するので、Scalaもインストールしておきます。

まず下記コマンドで、インストールを行います。

sh-4.2$ wget https://downloads.lightbend.com/scala/2.13.1/scala-2.13.1.tgz

次に、インストールした、ファイルを解凍して展開します。

sh-4.2$ tar xvzf ./scala-2.13.1.tgz

bashrcファイルを編集します

sh-4.2$ vi .bashrc

bashrcファイルに下記を追加します。

export SCALA_HOME=./scala-2.13.1
export PATH=$PATH:$SCALA_HOME/bin

Scalaのバージョンを確認して、インストールしたバージョンが表示されていれば、成功です。

sh-4.2$ scala -version
Scala code runner version 2.13.1 -- Copyright 2002-2019, LAMP/EPFL and Lightbend, Inc.

sbtをインストール

続いてsbtのインストールです。
下記コマンドでインストールを行います。

sh-4.2$ curl https://bintray.com/sbt/rpm/rpm | sudo tee /etc/yum.repos.d/bintray-sbt-rpm.reposudo yum install sbt

Node.jsをインストール

sh-4.2$ sudo amazon-linux-extras install epel
sh-4.2$ sudo yum install nodejs npm --enablerepo=epel

GitHubとの連携

GitHubとの連携を行います。

下記コマンドで、GitHubの設定を行う.gitconfigファイルを編集していきます。

sh-4.2$ vi .gitconfig

.gitconfigファイルに、下記を追加します。

[user]
  name = git_user_name (#gitに登録した自分の名前)
  email = git@git.com (#git登録時の自分のメアド)[color] (#色付け)
  ui = true# GitHubの場合
[url "github:"] (#pull、pushのための設定)
    InsteadOf = https://github.com/
    InsteadOf = git@github.com:

完了したら、保存して閉じます。

次に、クローンしたアプリを置いておくディレクトリを作成していきます。

EC2の/ディレクトリに移動します。

lsコマンドで、ファイルを確認すると複数のファイルが存在しています。

この一覧にあるvarディレクトリにアプリをクローンして置いておくディレクトリを作成していきます。

sh-4.2$ cd /
sh-4.2$ ls
bin  boot  dev  etc  home  lib  lib64  local  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

※実装とは関係ありませんが、sh-4.2$のままだとどこの階層にいるのかわかりづらいので、source ~/.bashrcコマンドで.bashrcの設定を反映させることもできます。

実行すると以下のように表示されます。
筆者は、予め設定を行っています。どこの階層にいるかわかりやすいので、.bashrcの設定を反映させた状態で進行を進めます。

[ssm-user@ip-10-0-0-231 ~]$ cd /
[ssm-user@ip-10-0-0-231 /]$ ls
bin  boot  dev  etc  home  lib  lib64  local  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

varディレクトに移動して、下記コマンドでwwwディレクトリを作成します。

[ssm-user@ip-10-0-0-231 /]$ cd var
[ssm-user@ip-10-0-0-231 var]$ sudo mkdir www

wwwディレクトに移動して、scalaというディレクトリを作成し、所有者も変更します。

このscalaディレクトリにクローンしたアプリを置いておきます。

[ssm-user@ip-10-0-0-231 var]$ cd www
[ssm-user@ip-10-0-0-231 www]$ sudo mkdir scala

続いて、下記コマンドで、GitHubと連携を行う用の鍵を生成します。

[ssm-user@ip-10-0-0-231 ~]$ chmod 700 .ssh
[ssm-user@ip-10-0-0-231 ~]$ cd .ssh
[ssm-user@ip-10-0-0-231 .ssh]$ ssh-keygen -t rsa

コマンドを実行するとキーの命名と生成を行います。

Generating public/private rsa key pair.
Enter file in which to save the key (/home/ssm-user/.ssh/id_rsa): aws_git_rsa <- キーの名前を入力
Enter passphrase (empty for no passphrase): <- 何も押さずにEnter
Enter same passphrase again: <- 何も押さずにEnter
Your identification has been saved in aws_git_rsa.
Your public key has been saved in aws_git_rsa.pub.
The key fingerprint is:
SHA256:ok4VP+5umvDpaxI/+zzIjvId6pWUugXjP2sQ10lVULU ssm-user@ip-10-0-0-231.ap-northeast-1.compute.internal
The key's randomart image is:
+---[RSA 2048]----+
|         .o+o..  |
|        .      . |
|      .o .    E  |
|    . .+o        |
|    oo= S        |
|   .oB + .       |
|    *==..        |
|  .o.@O*o        |
|   +B*&@=.       |
+----[SHA256]-----+

lsコマンドで、キーが生成されているかを確認します。下記のように2つキーが生成されていれば、成功です。

[ssm-user@ip-10-0-0-231 .ssh]$ ls
aws_git_rsa  aws_git_rsa.pub

configファイルに、GitHubの設定を記載します。

[ssm-user@ip-10-0-0-231 .ssh]$ vi config
Host github
  Hostname github.com
  User git
  IdentityFile ~/.ssh/aws_git_rsa <- ここは任意のキー名

もう1つのキーをコピーしておきます。

コピーしたキーをGitHubに登録します。

[ssm-user@ip-10-0-0-231 .ssh]$ cat aws_git_rsa.pub

GitHubのsettingから、「SSH and GPG keys」を選択します。

下記画像の「new SSH key」を選択します。

SSHの名前と、先ほどコピーしたキーを貼り付けたら「Add SSH key」を選択します。

これで、GitHubでの設定は完了です。

configファイルに、600番で定義されたアクセス権を付与します。

[ssm-user@ip-10-0-0-231 .ssh]$ chmod 600 config

ssh -T githubコマンドで、GitHubへの接続を確認します。

「You’ve successfully authenticated, but GitHub does not provide shell access.」と表示されれば成功です。

[ssm-user@ip-10-0-0-231 .ssh]$ ssh -T github
The authenticity of host 'github.com (52.69.186.44)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
RSA key fingerprint is MD5:16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Are you sure you want to continue connecting (yes/no)?
Warning: Permanently added 'github.com,52.69.186.44' (RSA) to the list of known hosts.
Hi takapi327! You've successfully authenticated, but GitHub does not provide shell access.

GitHubとの接続も出来たので、アプリをクローンします。

[ssm-user@ip-10-0-0-231 scala]$ git clone git@github.com:~~~
-bash: git: command not found

なぬ？

GitHubのインストールを忘れていたので、インストールします。

gitのインストール

バージョンを確認して、表示されたらgitのインストールは完了です。

[ssm-user@ip-10-0-0-231 ~]$ sudo yum install git
[ssm-user@ip-10-0-0-231 ~]$ git version
git version 2.23.3

アプリのクローン

最後にアプリのクローンを行います。

先ほど行ったgit のcloneコマンドで、アプリをクローンします。

[ssm-user@ip-10-0-0-231 scala]$ git clone git@github.com: ~~~
Cloning into 'アプリ名'...
remote: Enumerating objects: 39, done.
remote: Counting objects: 100% (39/39), done.
remote: Compressing objects: 100% (27/27), done.
remote: Total 39 (delta 1), reused 39 (delta 1), pack-reused 0
Receiving objects: 100% (39/39), 6.75 KiB | 3.38 MiB/s, done.
Resolving deltas: 100% (1/1), done.

lsコマンドで、アプリがクローンされているか確認します。

表示されていれば完了です。

[ssm-user@ip-10-0-0-231 scala]$ ls
アプリ名

これで、Play Frameworkの環境構築は完了です。

5. Nginxの設定

次は、Nginxを使用したWebサーバーの設定を行います。

Nginxの設定では、下記を行います。

  1. Nginxのインストール
  2. Nginxの設定ファイルを変更

Webサーバーとは、クライアントからのリクエストを解釈し、サーバー上に用意された該当ファイルを返す仕組みを行うものです。

このやり取りの流れは、 HTTPという決まりごとの上で動いているため、この決まりを処理できるプログラムがWebサーバーと言われます。

Nginxとは、オープンソースなWebサーバーのひとつで、並行処理性能の高さ、比較的メモリ消費が少ないなどの特徴を持っています。
他には、ApacheというWebサーバーもあります。

ApacheとNginxについて比較 ← 違いが説明されています。

Nginxのインストール

早速、Nginxを下記コマンドで、インストールします。

[ssm-user@ip-10-0-0-231 scala]$ cd ~
[ssm-user@ip-10-0-0-231 ~]$ sudo yum install nginx

インストールが完了したら、下記コマンドで、Nginx内のファイルに移動します。

[ssm-user@ip-10-0-0-231 ~]$ cd /etc/nginx/conf.d/

下記コマンドで、アプリ用の設定ファイルを作成し、設定を行います。

[ssm-user@ip-10-0-0-231 conf.d]$ sudo vi sample.conf

下記で、Play Framework を Nginxから呼ぶように設定します。

upstream scala_play {
  server 127.0.0.1:9000;
}server {
  listen      80;
  server_name DNS名; <- ALBのDNS名root  /var/www/scala/アプリ名;location / {
    proxy_pass http://scala_play;
  }
}

これでDNS名でALB経由で、Play Frameworkを表示させることができるようになりました。

設定が終わったので、Nginxを起動しなおしてDNS名でアクセスできるか確認したいのですが、現状のままだと「Job for nginx.service failed because the control process exited with error code. See “systemctl status nginx.service” and “journalctl -xe” for details.」というエラーが出てしまいます。

エラーの原因を探ると、「could not build server_names_hash, you should increase server_names_hash_bucket_size: 64」というエラーが表示されます。

このエラーは、ドメイン名が長いために発生しているエラーです。今回設定したDNS名が長いので、デフォルトで設定されている文字数を超えてしまったのが、原因です。

なので、デフォルトの設定を変更してDNS名を使用できるように修正します。

まず、下記コマンドでNginxの設定が置いてあるディレクトリに移動します。

[ssm-user@ip-10-0-0-231]$ cd /etc/nginx

nginxディレクトリ内に、nginx.confというファイルがあるので、このファイルに修正を加えていきます。

[ssm-user@ip-10-0-0-231]$ sudo vi nginx.conf

ファイルが開くと、色々な設定が記載されていますが、http内に下記を追加します。これで、server_namに128文字まで入力することが可能になりました。

追加が完了したら、保存して閉じます。

http {
  server_names_hash_bucket_size  128; <- 追加
  ...  
}

これで、Nginxの設定は完了しました。

下記コマンドで、Nginxを起動しましょう。

[ssm-user@ip-10-0-0-231]$ sudo systemctl start nginx

下記コマンド、ちゃんとNginxが起動しているのを確認します。

[ssm-user@ip-10-0-0-231]$ systemctl status nginx.service● nginx.service - The nginx HTTP and reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
   Active: active (running) since Mon 2020-10-05 05:46:44 UTC; 5 days ago
  Process: 12030 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
  Process: 12026 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
  Process: 12025 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
 Main PID: 12032 (nginx)
   CGroup: /system.slice/nginx.service
           ├─12032 nginx: master process /usr/sbin/nginx
           └─12033 nginx: worker process

起動しているのが確認出来たら、クローンしたアプリを起動させます。

[ssm-user@ip-10-0-0-231 アプリ名] $ sbt run

メモリ不足で、sbt runでアプリを立ち上げられない場合があります。

メモリ不足で落ちる場合には、以下の記事を参考にswap領域の拡張を行いましょう。

https://tech.librastudio.co.jp/entry/index.php/2018/05/22/post-1891/

sbtが正常に起動できたら、AWSのマネジメントコンソールからALBのターゲットグループがhelthyになっているのを確認します。

helthyになっていると、ALBとターゲットにしているEC2との連携が正常にできているということです。

早速、ALBのDNS名をアドレスバーに入力してPlay Frameworkが起動出来ているかを確認します。

…なにこれ〜

上記を調べたところ、Play Framework 2.6.x以降からデフォルトで[localhost, local]からしかアクセスを受け付けない設定になっているらしいです。

そのため、他のアドレスからアクセスする際は、許可させる設定を行う必要があります。

Play Frameworkの設定

先ほど出た Host not allowedというエラーを解消していきます。

Play Frameworkのapplication.confファイルに下記を追加します。

play.filters.hosts {
  allowed = ["."]
}

上記設定で、全てのアドレスから接続できるようなります。

これで、Play Frameworkの設定も完了したので、EC2内のアプリにも上記設定を反映して、再度アプリの起動とNginxの起動を行います。

そして、ALBのDNS名でアクセスし、Play Frameworkの画面が表示されているかを確認します。

ローカルと同じように「Welcome to Play!」が表示されていれば、今回のブログで行う設定は完了です！

まとめ

最初AWSへのデプロイ方法は、なにをしたらいいのか全然わかりませんでしたが、無事に終わってホッとしています。

今回AWSへのデプロイを終えて、やる前よりインフラの知識がついたのが、よかったです。
インターネットに関する知識がついたのもよかったです！

次は、FargateとECSを使用して、Docker内でアプリを立ち上げるような設定をしたり、MySQL(DB)の設定、GitHub Actionsを使用して、masterブランチが更新されたら自動デプロイされるような設定も実装していきたいと思います。

最終的には、全ての実装(管理できるもの)をTerraformで管理できるようにしていきたいです！

2部構成で大変長くなってしまいましたが、最後まで読んで頂き、ありがとうございました！

参考文献

[公式]
[Play Framework]
デプロイオプション
Allowed hosts filter

[その他]
Amazon EC2 で Playframeworkを動かそう。
PlayFramework-Scala + (EC2 + ElasticIP + CloudFront) で LINE BOT オウム返し
AWS Elastic Beanstalk (Java8)に最小手順でPlay Framework (Scala)のアプリをデプロイする
AWS EC2 AmazonLinux2 Gitをインストールする
EC2にyumでnodejsをインストールしようとしたらできなかった話
Amazon Linux に sbt を yum で install する方法
amazon EC2(amazon linux)でScala+Play framework の初期画面表示まで
EC2 Linuxにscalaインストール

We are hiring!

株式会社ネクストビートでは

「人口減少社会において必要とされるインターネット事業を創造し、ニッポンを元気にする。」
を理念に掲げ一緒に働く仲間を募集しております。

もちろんモバイルアプリのエンジニアも募集中です。Android/iOS問わず最新の開発技術にどんどん触れていきたい方、ぜひご応募お待ちしております。

https://www.nextbeat.co.jp/recruit

AWS
Scala
Play Framework
Engineer

--

--

takahiko tominaga
nextbeat-engineering

Written by takahiko tominaga

2 Followers
Writer for

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams