デプロイ #AWS

GithubにSSH鍵を登録

アプリケーションのコードをGithubからEC2サーバへクローンします。全世界に公開できるIPアドレスを持ったEC2サーバ上でアプリを動かすためです。
現状、EC2サーバにアプリケーションのコードをクローンしようとしてもpermission deniedとエラーが出てしまいます。
これは、Githubから見てこのEC2インスタンスが何者かわからないためです。
EC2インスタンスからGithubにアクセスするためには、作成したEC2インスタンスのSSH公開鍵をGithubに登録する必要があります。
SSH鍵をGithubに登録すると、Githubはそれを認証に利用し、コードのクローンを許可してくれるようになります。
EC2インスタンスからGithubにアクセスするためには、作成したEC2インスタンスのSSH公開鍵をGithubに登録します。
SSH鍵をGithubに登録すると、Githubはそれを認証に利用し、コードのクローンを許可してくれるようになります。
これからターミナル（ローカル）とターミナル（EC2サーバ）を使いますので、ターミナルでcommand T で2つ使えるようにしましょう。
ターミナル（EC2サーバ）に入るためには以下のことを実行してください。
ターミナル（ローカル）

$ cd  .ssh/

$ ssh -i ダウンロードした鍵の名前.pem ec2-user@作成したEC2インスタンスと紐付けたElastic IP

途中で passphrase など３段階ほど入力を求められることがありますが、全て何も入力せずにEnterキーで進んでください。
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 ~]$ ssh-keygen -t rsa -b 4096

次に、以下のコマンドで生成されたSSH公開鍵を表示し、値をコピーします。
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 ~]$ cat ~/.ssh/id_rsa.pub

catで表示させた公開鍵を、Githubにアクセスして登録していきます。
以下のURLにアクセスしてください。
https://github.com/settings/keys
タイトルはなんでもOKです。
keyは公開鍵をペーストしてください。
Add SSH keyで保存します。
Githubに鍵を登録できたら、SSH接続できるか以下のコマンドで確認できます。
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 ~]$ ssh -T git@github.com

途中でこのまま続けるかどうかYes/Noで聞かれることがありますが、Yesで進んでください。
Permission denied (publickey). と表示された場合は、SSH鍵の設定が間違っているので、作業を確認をしてください。

アプリケーションサーバの設定

まず、アプリケーションサーバとは、ブラウザからの「リクエスト」を受け付けRailsアプリケーションを実際に動作させるソフトウェアのことです。rails sコマンドのことです。
ローカル環境でRuby on Railsのアプリケーションの動作を確認する際は
①ターミナルからrails sコマンドを打つ
②ブラウザでlocalhost:3000にアクセス
の順番になります。
①の操作で「アプリケーションサーバの起動」を行なっています。
つまり、環境開発の場合
①rails sコマンドでappサーバを起動
②ブラウザからlocalhostにアクセス
となります。
アプリケーションサーバが動いていれば、ブラウザからのリクエストを受け付けてRailsアプリケーションが動作します。
なので、全世界に公開するEC2サーバ上でもアプリケーションサーバを動かす必要があります。

Unicorn

全世界に公開されるサーバ上で良く利用されるアプリケーションサーバです。rails sコマンドの代わりにunicorn_railsコマンドで起動することができます。
本番環境の場合
①unicorn_railsコマンドでUnicorn(appサーバ)を起動
②ブラウザからドメインにアクセス
Unicornを理解するために必要な重な概念がプロセスです。

プロセス

PC(サーバ)上で動く全てのプログラムの実行時の単位です。ここで言うプログラムとは、ブラウザや音楽再生ソフト、ExcelといったGUIや、Rubyなどのスクリプト言語の実行などが含まれます。
プログラムが動いている数だけ、プロセスが存在しています。例えばテキストエディタを起動する時、テキストエディタ用のプロセスが生み出されます。
PCがMacの場合、アクティビティモニタというアプリケーションでプロセスを確認することができます。
アクティビティモニタは、現在MacPC上で動いているプログラムの状況をモニタリングするアプリです。
「PID(プロセスアイディー)」というに数字が入っていますが、これはプロセスを識別するための一意の数字になります。PIDがあることで、あるプログラムから別のプロセスを指定して操作したり、プロセスからプログラムを停止したりできます。
Unicornなどのアプリケーションサーバを起動するとアプリケーションサーバのプロセスが生まれます。アプリケーションサーバのプロセスがあれば、リクエストを受け付けブラウザにレスポンスを返すことができます。

Unicornをインストール

Gemfile

group :production do
  gem 'unicorn', '5.4.1'
end

ターミナル（ローカル）

$ bundle install

このgroup :production do ~ endの間に記述されたgemは本番環境のみで読み込まれます。
次に、config/unicorn.rbを作成します。

config/unicorn.rb

#サーバ上でのアプリケーションコードが設置されているディレクトリを変数に入れておく
app_path = File.expand_path('../../', __FILE__)

#アプリケーションサーバの性能を決定する
worker_processes 1

#アプリケーションの設置されているディレクトリを指定
working_directory app_path

#Unicornの起動に必要なファイルの設置場所を指定
pid "#{app_path}/tmp/pids/unicorn.pid"

#ポート番号を指定
listen 3000

#エラーのログを記録するファイルを指定
stderr_path "#{app_path}/log/unicorn.stderr.log"

#通常のログを記録するファイルを指定
stdout_path "#{app_path}/log/unicorn.stdout.log"

#Railsアプリケーションの応答を待つ上限時間を設定
timeout 60

#以下は応用的な設定なので説明は割愛

preload_app true
GC.respond_to?(:copy_on_write_friendly=) && GC.copy_on_write_friendly = true

check_client_connection false

run_once = true

before_fork do |server, worker|
  defined?(ActiveRecord::Base) &&
    ActiveRecord::Base.connection.disconnect!

  if run_once
    run_once = false # prevent from firing again
  end

  old_pid = "#{server.config[:pid]}.oldbin"
  if File.exist?(old_pid) && server.pid != old_pid
    begin
      sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
      Process.kill(sig, File.read(old_pid).to_i)
    rescue Errno::ENOENT, Errno::ESRCH => e
      logger.error e
    end
  end
end

after_fork do |_server, _worker|
  defined?(ActiveRecord::Base) && ActiveRecord::Base.establish_connection
end

worker(ワーカー)

Unicornは、プロセスを分裂させることができます。この分裂したプロセス全てをworkerと呼びます。プロセスを分裂させることで、リクエストに対してのレスポンスを高速にすることができます。後述するworker_processesという設定項目で、workerの数を決定します。
ブラウザなどからリクエストが来ると、UnicornのworkerがRailsアプリケーションを動かします。Railsは、リクエストの内容とルーティングを照らし合わせ最終的に適切なビュー(HTML)もしくはJSONをレスポンスします。レスポンスを受け取ったUnicornは、それをブラウザに返します。一連の動きはおよそ0.1 ~ 0.5秒程度で行われます。常にそれ以上のスピードでリクエストが頻発するようなアプリケーションだと、1つのworkerだけでは処理が追いつかず、レスポンスまで長い時間がかかってしまったり最悪サーバがストップしてしまいます。そんな時、worker_processesの数を 2,3,4と増やすことでアプリケーションからのレスポンスを早くすることができます。

Unicornの設定

設定項目	詳細
worker_processes	リクエストを受け付けレスポンスを生成するworker(ワーカー)の数を決めます。
working_directory	UnicornがRailsのコードを動かす際、ルーティングなど実際に参照するファイルを探すディレクトリを指定します。
pid	Unicornは、起動する際にプロセスidが書かれたファイルを生成します。その場所を指定します。
listen	どのポート番号のリクエストを受け付けることにするかを決定します。今回は、3000番ポートを指定しています。

ここまで変更できたら、いったんファイルをコミットしておきましょう。Githubにpushしてください。ブランチを切っている場合は、masterブランチにmergeもしておきましょう。

デプロイ時にエラーの原因となる記述の対策

Uglifierというgemがあり、これはJavaScriptを軽量化するためのものです。しかし、ChatSpaceのJavaScriptで使用しているテンプレートリテラル記法（`）に対応していません。そのため、デプロイ時にエラーの原因となります。
そこで、この部分をコメントアウトすることで対策できます。

config/environments/production.rb（修正前）

config.assets.js_compressor = :uglifier

config/environments/production.rb（修正後）

# config.assets.js_compressor = :uglifier

変更修正したらGitHub Desktopからコミットしてプッシュしましょう。この時必ず、masterブランチで行うようにしてください。もし、別ブランチでコミット&プッシュした場合は、リモートリポジトリでプルリクエストを作成し、ブランチをmasterへマージしてください。

Githubからコードをクローン

Unicornの設定を済ませたコードをEC2インスタンスにクローンします。
まず、以下のコマンドを入力して、ディレクトリを作成します。今回は、ここで作成したディレクトリにアプリケーションを設置することにします。

/var/wwwディレクトリを作成し、権限をec2-userに変更

ターミナル（EC2サーバ）

#mkdirコマンドで新たにディレクトリを作成
[ec2-user@ip-172-31-23-189 ~]$ sudo mkdir /var/www/
#作成したwwwディレクトリの権限をec2-userに変更
[ec2-user@ip-172-31-23-189 ~]$ sudo chown ec2-user /var/www/

Githubから「リポジトリURL」を取得

clone or downloadをクリックし、URLをコピーしてください。

取得した「リポジトリURL」を使って、コードをクローン

ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 ~]$ cd /var/www/
[ec2-user@ip-172-31-23-189 www]$ git clone https://github.com/<ユーザー名>/<リポジトリ名>.git

本番環境での設定

アプリケーションのコードをEC2サーバにクローンすることができました。続いて、サービスを公開するための設定を行なっていきます。
※これ以降基本的には、作業は /var/www/アプリ名で行います。

EC2の能力を拡張

現状動かしているEC2のインスタンスではコンピューターの能力が足りず、Gemのインストール時などにエラーが発生する可能性があります。具体的には、コンピューターの処理能力に関係するメモリというものが足りません。
そこで、今後の設定を行う前にメモリを増強する処理を行います。

Swap(スワップ)領域

コンピュータが処理を行う際、メモリと呼ばれる場所に処理内容が一時的に記録されます。メモリは容量が決まっており、容量を超えてしまうとエラーで処理が止まってしまいます。Swap領域は、メモリが使い切られそうになった時にメモリの容量を一時的に増やすために準備されるファイルです。
EC2はデフォルトではSwap領域を用意していないため、これを準備することでメモリ不足の処理エラーを防ぎます。
Swap領域の用意です。
ターミナル（EC2サーバ）

#ホームディレクトリに移動
[ec2-user@ip-172-31-25-189 ~]$ cd

#処理に時間がかかる可能性があるコマンドです
[ec2-user@ip-172-31-25-189 ~]$ sudo dd if=/dev/zero of=/swapfile1 bs=1M count=512
# しばらく待って、以下のように表示されれば成功
512+0 レコード入力
512+0 レコード出力
536870912 バイト (537 MB) コピーされました、 7.35077 秒、 73.0 MB/秒

[ec2-user@ip-172-31-25-189 ~]$ sudo chmod 600 /swapfile1

[ec2-user@ip-172-31-25-189 ~]$ sudo mkswap /swapfile1
# 以下のように表示されれば成功
スワップ空間バージョン1を設定します、サイズ = 524284 KiB
ラベルはありません, UUID=74a961ba-7a33-4c18-b1cd-9779bcda8ab1

[ec2-user@ip-172-31-25-189 ~]$ sudo swapon /swapfile1

[ec2-user@ip-172-31-25-189 ~]$ sudo sh -c 'echo "/swapfile1  none        swap    sw              0   0" >> /etc/fstab'

これで、Swap領域を確保することができました。
次に、クローンしたアプリケーションを起動するために必要なgemを以下のコマンドでインストールします。
クローンしたディレクトリに移動し、rbenvでインストールされたRubyが使われているかチェックします。
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 www]$ cd  /var/www/リポジトリ名
[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ ruby -v
ruby 2.5.1p112 (2016-04-26 revision 54768) [x86_64-linux]

ruby 2.5.1 ... となっていれば成功です。そうでない場合は、もともと用意されているRubyが利用されているので、Rubyのインストールが成功しているか確認してください。
確認できたら本番環境でgemを管理するためのbundlerをインストールして、bundle installを実行します。
まず今まで開発環境（ローカル）で開発してきたアプリにおいて、どのバージョンのbundlerが使われていたのか確認します。
ターミナル（ローカル）

#アプリ名のディレクトリで以下を実行
$ bundler -v
Bundler version 2.0.1
# 開発環境によってバージョンは異なります。

開発環境で仕様しているbundlerのバージョンがわかったので、同じバージョンのものをEC2サーバ側にも導入します。上記の場合では、bundler 2.0.1のバージョンを導入して bundle install を実行します。
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ gem install bundler -v 2.0.1
# ローカルで確認したbundlerのバージョンを導入する
[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ bundle install
# 上記コマンドは、数分以上かかる場合もあります。

環境変数の設定

データベースのパスワードなどセキュリティのためにGithubにアップロードすることができない情報は、環境変数というものを利用して設定します。
環境変数は、Railsからは ENV['<環境変数名>'] という記述でその値を利用することができます。
今、config/secrets.yml と config/database.yml を確認すると、例えばですが <%= ENV["SECRET_KEY_BASE"] %> と書かれている部分は、 SECRET_KEY_BASE という環境変数の値になります。

secret_key_base

Cookieの暗号化に用いられる文字列です。Railsアプリケーションを動作させる際は必ず用意する必要があります。また、外部に漏らしてはいけない値であるため、こちらも環境変数から参照します。
secret_key_baseは以下のコマンドを打つことで生成できます。
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ rake secret

長い英数の羅列が出てきます。この後利用するのでコピーしておいてください。
環境変数は /etc/environment というファイルに保存することで、サーバ全体に適用されます。環境変数の書き込みはvimコマンドを使用して行います。
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 ~]$ sudo vim /etc/environment

何もない画面になると思います。iと打ち込んで入力モードに切り替えた後、下記の記述を打ち込みます。=の前後にスペースは入れません。
/etc/environment

#設定したMySQLのrootユーザーのパスワードを入力
DATABASE_PASSWORD='MySQLのrootユーザーのパスワード'
SECRET_KEY_BASE='先程コピーしたsecret_key_base'

書き込みができたら esc(エスケープキー)を押下後、:wqと入力して内容を保存します。保存できたら環境変数を適用するために一旦ログアウトします。
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 ~]$ exit

exitでログアウトすると、ローカル環境となります。再度SSHし直します。
ターミナル（ローカル）

$ ssh -i [ダウンロードした鍵の名前].pem ec2-user@[作成したEC2インスタンスと紐付けたElastic IP]
（ダウンロードした鍵を用いて、ec2-userとしてログイン）

SSHし直したら、 env というコマンドと grep を組み合わせて、先程設定した環境変数が適用されているか確認します。
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 ~]$ env | grep SECRET_KEY_BASE
SECRET_KEY_BASE='secret_key_base'

[ec2-user@ip-172-31-23-189 ~]$ env | grep DATABASE_PASSWORD
DATABASE_PASSWORD='MySQLのrootユーザーのパスワード'

立ち上げたばかりのEC2インスタンスはSSHでアクセスすることはできますが、HTTPなどの他の通信方法ではつながりません。そのため、WEBサーバとして利用するEC2インスタンスは事前にHTTPがつながるように「ポート」を開放します。
ポートの設定をするためにはEC2の「セキュリティグループ」という設定を変更します。
セキュリティグループとは、EC2サーバが属するまとまりのようなもので、複数のEC2インスタンスのネットワーク設定を一括で行うためのものです。

セキュリティグループのポートを設定

まずは、AWSのEC2インスタンス一覧画面から、対象のインスタンスを選択し、「セキュリティグループ」のリンクをクリックします。
次に、インスタンスの属するセキュリティグループの設定画面に移動するので、「インバウンド」タブの中の「編集」をクリックします。
モーダルが開くので、「ルールの追加」をクリックします。
タイプを「カスタムTCPルール」、プロトコルを「TCP」、ポート範囲を「3000」、送信元を「カスタム」「0.0.0.0/0」に設定します。
「0.0.0.0」は「全てのアクセスを許可する」という意味です。
以上で、ポートの開放が完了です。
この作業が終わっていないと、起動したRailsにアクセスできません。

本番環境でRailsを起動

unicorn_railsコマンド

-c config/unicorn.rb は設定ファイルの指定、 -E production は環境を「本番モードとして動作させる」ことを示します。
-Dで、プログラムを起動させつつターミナルで別のコマンドを打てるようにするオプションです。
unicorn のgemをインストールしていると unicorn_rails というコマンドが使えるようになります。
ローカル環境でrails s と同じように使います。
ターミナル(EC2サーバ)

[ec2-user@ip-172-31-23-189 ~]$ cd /var/www/[リポジトリ]
[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ bundle exec unicorn_rails -c config/unicorn.rb -E production -D
master failed to start, check stderr log for details

まだこの状態だとエラーが出てしましいます。エラーログの確認をします。
先程の config/unicorn.rb をもう一度確認してみると、 stderr_path "#{app_path}/log/unicorn.stderr.log" という記述があります。これは、「Unicorn関係で起きたエラーをlog/unicorn.stderr.log」に記録するという指定になっています。
なので log/unicorn.stderr.log を確認します。

ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ less log/unicorn.stderr.log
I, [2016-12-21T04:01:19.135154 #18813]  INFO -- : Refreshing Gem list
I, [2016-12-21T04:01:20.732521 #18813]  INFO -- : listening on addr=0.0.0.0:3000 fd=10
E, [2016-12-21T04:01:20.734067 #18813] ERROR -- : Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
/home/ec2-user/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/activerecord-5.0.0.1/lib/active_record/connection_adapters/mysql2_adapter.rb:29:in `rescue in 
〜省略〜
/home/ec2-user/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/unicorn-5.1.0/bin/unicorn_rails:209:in `<top (required)>'
/home/ec2-user/.rbenv/versions/2.5.1/bin/unicorn_rails:23:in `load'
/home/ec2-user/.rbenv/versions/2.5.1/bin/unicorn_rails:23:in `<main>'

このERRORという行を見ると、これは本番環境でインストールするmysqlの設定がローカルとは異なるため、mysqlへ接続できなくなっている状態です。
なので、本番環境のmysqlの設定に合わせるため、ローカルのdatabase.ymlを以下のように編集します。
config/database.yml（ローカル）

roduction:
  <<: *default
  database: それぞれのアプリケーション名
  username: root
  password: <%= ENV['DATABASE_PASSWORD'] %>
  socket: /var/lib/mysql/mysql.sock

リモートリポジトリが更新されたため、サーバ上のアプリケーションにも反映させます。
先ほどはgit cloneコマンドを利用しましたが、今回はすでにEC2とGithubは接続できているため、git pullコマンドを利用します。
※別にブランチを切っている場合は、masterブランチにmergeしてから以下のコマンドを実行してください。
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 <リポジトリ名>] git pull origin master

データベースを作成しマイグレーションを実行し直します。
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ rails db:create RAILS_ENV=production
Created database '<データベース名>'
[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ rails db:migrate RAILS_ENV=production

もしここでMysql2::Error: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock'というエラーが起こった場合、mysqlが起動していない可能性があります。sudo service mysqld startというコマンドをターミナルから打ち込み、mysqlの起動を試してください。
データベースの準備ができたので、再びRailsの起動
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ bundle exec unicorn_rails -c config/unicorn.rb -E production -D

ブラウザで http://＜サーバに紐付けたElastic IP＞:3000/ にアクセスしてみて、ブラウザにCSSの反映されていない（ビューが崩れている）画面が表示されていれば成功です。
本番モードでは、事前にアセットをコンパイルする必要があります。
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ rails assets:precompile RAILS_ENV=production

Unicornのプロセスの確認

コンパイルが成功したら反映を確認するため、Railsを再起動するんですが、まずは今動いているUnicornをストップします。そのために、Unicornのプロセスを確認し、プロセスを止めます。ターミナルからプロセスを確認するにはpsコマンドを利用します。

psコマンド

psコマンドは、現在動いているプロセスを確認するためのコマンドです。
aux は、psコマンドのオプションです。表示結果を見やすくしてくれます。また、| grep unicornとしているのはpsコマンドの結果からunicorn関連のプロセスのみを抽出するためです。
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ ps aux | grep unicorn

以下のようにプロセスが表示されます。
ターミナル（EC2サーバ）

ec2-user 17877  0.4 18.1 588472 182840 ?       Sl   01:55   0:02 unicorn_rails master -c config/unicorn.rb -E production -D
ec2-user 17881  0.0 17.3 589088 175164 ?       Sl   01:55   0:00 unicorn_rails worker[0] -c config/unicorn.rb -E production -D
ec2-user 17911  0.0  0.2 110532  2180 pts/0    S+   02:05   0:00 grep --color=auto unicorn

大事なのは左から2番目の列です。ここに表示されるのがプロセスのid、つまりPIDになります。
「unicorn_rails master」と表示されているプロセスがUnicornのプロセス本体です。この時のPIDは、17877となります。
ターミナルからプロセスをストップするにはkillコマンドを利用します。

killコマンド

killコマンドは、現在動いているプロセスを停止させるためのコマンドです。
ターミナル（EC2サーバ）
[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ kill <確認したunicorn rails masterのPID>
```
プロセスを表示させ終了できているかの確認
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ ps aux | grep unicorn
...
ec2-user 17911  0.0  0.2 110532  2180 pts/0    S+   02:05   0:00 grep --color=auto unicorn

実行結果が上記のようになっていればUnicornを停止が完了です。ローカルの ctrl + cでサーバをストップするという作業と同じことです。

プロセスが終了できない場合

下記の２行が表示が消えていない場合はプロセスが終了できていないことになります。
ターミナル（EC2サーバ）

ec2-user 17877  0.4 18.1 588472 182840 ?       Sl   01:55   0:02 unicorn_rails master -c config/unicorn.rb -E production -D
ec2-user 17881  0.0 17.3 589088 175164 ?       Sl   01:55   0:00 unicorn_rails worker[0] -c config/unicorn.rb -E production -D

そのような場合は、プロセスを強制終了します。オプション-9をkillコマンドにつけると強制終了を実行できます。通常のkillコマンドで削除できない場合はこちらを使用します。

$ kill -9 [プロセスID]  

#プロセスIDはpsコマンドで検索した結果の数字に置き換えてください。上記であれば17877です。

再びunicornを起動します。このとき RAILS_SERVE_STATIC_FILES=1 という指定を先頭に追加します。これは、コンパイルされたアセットをRailsが見つけられるような指定になります。
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ RAILS_SERVE_STATIC_FILES=1 unicorn_rails -c config/unicorn.rb -E production -D

もう一度、ブラウザで http://＜Elastic IP＞:3000/ にアクセスしてみて、レイアウト崩れも無くサイトが正常に表示されていれば成功です。
ちなみに、以下のようにコマンドを実行する事で正常に動いている際のログも確認することができます。
ターミナル（EC2サーバ）

[ec2-user@ip-172-31-23-189 <リポジトリ名>]$tail -f log/production.log

tail コマンド

指定したファイルの最後の行を表示するコマンドです。-fオプションを追加することで、そのままリアルタイムに更新されるようになります。
tail -fコマンドによる表示を終了したい場合は、ctrl + cで中断できます。

Railsの起動がうまくできなかった時

上記のコマンドを実行してもRailsが起動しないときや、起動できてもIPアドレス:3000にアクセスするとエラーが表示されないときに考えられるのは
pushのし忘れ、またはEC2サーバ側でのpullのし忘れは無いか
EC2サーバ側で、/var/www/<リポジトリ名>/log/unicorn.stderr.logをlessまたはcatコマンドで確認し、エラーが出ていないか確認する（下に行くほど最新のログです。時刻表記がUTCであることに注意してください）
ローカルでの編集のpushやEC2でのgit pullを忘れていないか
mysqlの起動は正しく行えているか
EC2サーバ側のSECRET_KEY_BASE等は正しく設定できているか
EC2インスタンスの再起動を行ってみる
などを確認してみてください。