AWS（EC2）本番環境へのデプロイ手順をついつい忘れがちなのでメモ

AWS（EC2）本番環境へのデプロイはそんなに頻繁に行う作業ではないので、手順をついつい忘れがち。。。ということで、いつでも見返せるように手順をまとめました。

AWS（EC2）の環境構築については、こちらの記事を参照
Rails + Nginx + Unicorn + postgreSQL を使ったAWS（EC2）の環境構築 -Rails起動してHello Worldを表示させる-

##前提
・開発環境：VirtualBox
・本番環境：AWS（EC2）
・仕様サーバー：Nginx、Unicorn
・ローカルリポジトリのブランチで開発したソースをGitHubにプッシュし、本番環境ではorigin/masterをプルする、という方法を取る

手順① 現状のブランチを確認し、変更内容をステージング環境にaddする

 git branch -a

これで、ローカルリポジトリのブランチ一覧と現在どのブランチにいるのか確認

 git add .

上記コマンドの「.」は変更があった全てのファイルを指している。例えば、ある特定のファイルだけをステージング環境にaddしたければ、「.」の部分をaddしたいファイル名に変更すればOK！

##手順② ステージング環境にaddされたファイルをリポートリポジトリにコミットする

git commit -m "コミットメッセージ"

コミットが出来たら、コミットできたかを下記コマンドで確認

git log

##手順③ GitHubにプッシュし、ブランチをmasterブランチにマージする

git push origin ブランチ名

プッシュしたら、GitHubのページに遷移してプルリクエスト。プルリクエスト後のマージは、個人開発をしているのか、チーム開発をしているのか、等状況に応じて変わるので、臨機応変に対応

##手順④ AWSにSSHでログインし、Unicornのプロセスを停止させる

 kill -QUIT `cat tmp/pids/unicorn.pid` #pidはプロセスIDのこと

###なぜ、Unicornのプロセスを停止させるのか？
vagrantの開発環境であれば、Webブラウザをリロードすれば、変更内容が即時反映されるが、本番環境では変更されたアプリケーションの内容は即時反映されないので、一度プロセスを停止させた状態で、変更内容をGitHubからプルし、再度Unicornを起動させる必要がある。

###production（本番）環境にすぐに変更が反映されない理由

それは、development環境とproduction環境に以下の違いがあるから

■development：キャッシュが無効
■production：キャッシュが有効 

####キャッシュとは？
リクエスト・レスポンスのサイクルの中で生成されたコンテンツを保存しておき、次回同じようなリクエストが発生したときのレスポンスでそのコンテンツを再利用すること。単一サーバー、単一データベースのWebサイトでも数千ユーザーの同時接続による負荷に耐えられるようになる。https://railsguides.jp/caching_with_rails.html
キャッシュにもコンテンツキャッシュやクエリキャッシュなど、いくつか種類があるが、今回変更内容がすぐに反映されない原因を作っているのは、静的ページ等のコンテンツをキャッシュしておく、コンテンツキャッシュ

###production（本番）環境にすぐに変更が反映されない理由（続き）

■development環境はキャッシュが無効だから、Railsアプリケーションに変更を加えてreloadし、再度リクエストを送ると即時反映される。

■production環境はキャッシュが有効だから、Railsアプリケーションに変更を加えてreloadし、再度リクエストを送っても変更前のアプリケーションのコンテンツ内容がキャッシュにより再利用されるので、変更がすぐに反映されない。変更を反映させる場合は一度キャッシュによるコンテンツの再利用を止める必要があるので、Unicornを一度落として、再起動させる必要が生じる。

##手順⑤ git pullする

git pull origin master

##手順⑥ bundle installする

bundle install

##手順⑦ production環境でrake db:migrateする

rake db:migrate RAILS_ENV=production

ローカル環境では、「$ rake db:migrate」しか入力しないかもしれないが、「rake db:migrate」はmigrateする環境指定の記述を省略しており、下記のようにデフォルトでdevelopment環境が指定されていることは頭の片隅に置いておいた方が良い

rake db:migrate RAILS_ENV=development

##手順⑧ production環境でプリコンパイルする

bundle exec rake assets:precompile RAILS_ENV=production

プリコンパイルとは、アセットパイプラインというJavaScriptやCSSのアセットを最小化または圧縮して連結するためのフレームワークで行われる一連の処理を指すが、詳細は下記の記事を参照
https://numb86-tech.hatenablog.com/entry/2018/11/10/002439https://railsguides.jp/asset_pipeline.html

##手順⑨ Unicornを再度、起動させる

unicorn_rails -c /var/www/rails/アプリケーション名/config/unicorn.conf.rb -D -E production

これでUnicornが起動し、git pullされたアプリケーションとUnicornが接続されてデプロイが完了！

AWS（EC2）の環境構築については、こちらの記事を参照
Rails + Nginx + Unicorn + postgreSQL を使ったAWS（EC2）の環境構築 -Rails起動してHello Worldを表示させる-