ローカル開発環境からのアップロードができない場合
環境変数を設定し、それをCarrierWaveから使えるようにするには、以下の３箇所の設定が正しい必要があります。
1、CarrierWaveの設定ファイル(CarrierWave.rb)
2、Railsアプリケーション全体の秘密情報を管理するファイル(secrets.yml)
3.OSが提供するデータ共有の仕組み、漏洩のリスクが低い(環境変数)
キーを安全に運用するための仕組みは、CarrierWave.rb=>secrets.yml=>環境変数
となります。
環境変数およびsecrets.ymlの設定が正しいか
1、ChatSpaceがあるフォルダで、「rails c」を実行します。
2、コンソール内で、以下のコマンドを実行します。
コンソール
Rails.application.secrets.aws_access_key_id
Rails.application.secrets.aws_secret_access_key
「Rails.application.secrets」＋「.キーの名前」を実行する事でsecrets.ymlの設定を呼び出すことができます。
上の2つのコマンドを実行して、正しくAWSのキーとパスワードが表示されればOKです。
うまくいかなかった場合は、bash_profileの内容を確認します。
※OSがCatalina以降で環境構築をしている方は、zshというシェルを使用しているので、bash_profileの部分をzshrcと置き換えてください。
ターミナル
cat ~/.bash_profile
表示されたbash_profileの中に、以下の記述があるか確認してください。
~/.bash_profile
export AWS_SECRET_ACCESS_KEY='AWSのシークレットキー'
export AWS_ACCESS_KEY_ID='AWSのアクセスキー'
もしなければ、AWSの設定ができていないので、確認して追加してください。
次に、bash_profileの内容を反映させます。
ターミナル
source ~/.bash_profile
bash_profileにコマンドを書いただけでは設定は反映しません。
次は、carrierwave.rbの設定を確認します。
require 'carrierwave/storage/abstract'
require 'carrierwave/storage/file'
require 'carrierwave/storage/fog'
CarrierWave.configure do |config|
config.storage = :fog
config.fog_provider = 'fog/aws'
config.fog_credentials = {
provider: 'AWS',
aws_access_key_id: Rails.application.secrets.aws_access_key_id,
aws_secret_access_key: Rails.application.secrets.aws_secret_access_key,
region: 'ap-northeast-1'
}
config.fog_directory = 'ここにバケット名を入れます'
config.asset_host = 'https://s3-ap-northeast-1.amazonaws.com/ここにバケット名を入れます'
end
このような記述になっているかを確認してください。
バケットの指定が正しいかの確認
AWSのサービスからS3を選択し、バケットを表示させます。先ほどのcarrierwave-rbでS3のバケット名を指定しています。その内容が正しいか確認してください。
バケットの指定は「バケット名」「リージョン」の両方を正しく行う必要があります。
・バケット名が正しく設定できているか
・S3のリージョンが「アジアパシフィック（東京）」になっているか
を確認してください。もし違ったら直してください。
本番環境からのアップロードができない場合
S3へのアップロードができない場合、まずエラーメッセージを確認します。
ローカルでは、仮想サーバーを起動したターミナルを見ればエラーメッセージが表示されていました。
しかし、本番環境ではローカルのターミナルに当たるものがありません。
Capistranoが動く場合
以下の設定を行うと、本番環境でもローカル開発環境と同じように、ブラウザにエラーメッセージが表示されるようになります。
〜省略〜
config.consider_all_requests_local = true
〜省略〜
「config/environments/production.rb」のファイルの中から、上記の記述を見つけ、もともと「false」になっているので、「true」に変更します。
この変更を本番環境に反映させる必要があるので以下の2つの操作を行います。
①GitHubへのプッシュ
②「bundle exec cap production deploy」の実行
なお、エラー対応が終わったら、忘れずにfalseに戻してデプロイをし直してください。
Capistranoがエラーになる場合
Capistranoがエラーになってしまう場合は、上記の方法が取れません。
なので、エラーログを直接確認します。
エラーの内容によって、主に以下の2つのファイルにログが書き込まれます。
どちらに該当するかわかりにくい場合は、両方とも確認してください。
Unicornのエラーログの確認方法
ターミナル
cat /var/www/（アプリ名）/current/log/unicorn.stderr.log
ターミナル
cat /var/www/（アプリ名）/current/log/production.log
Railsアプリのエラーログの確認方法
エラーログの見方
・ファイルの下に行くほど新しいログが載っています
・いつのログなのかを必ず確認しましょう
まず、ログの中にタイムスタンプがあったら、そこに９時間を足しましょう（標準時での出力になるため、日本は９時間の時差があります）。その時刻と、今の時刻を見比べて今起きたエラーなのかをチェックします。
エラーメッセージが出ない場合や、原因を特定できない場合は以下のチェックを行いましょう。
- 環境変数が正しく設定できているか確認してください。
リモートでの環境変数が正しく設定されていないとS3へのアクセスができません。下記のコマンドで確認します。
ローカルのターミナル
ssh -i ~/.ssh/<pemファイルの名前> ec2-user@<IP>
sshでリモートにログインします。
リモートのターミナル
> env | grep AWS
出力された結果が、AWSのキー、パスワードと一致するか確認してください。
なお、「|」は複数の処理を行うためのもので、「A | B」と書くことで、Aの処理が終わったらBの処理をする、という指定ができます。
envは、現在設定されている環境変数を確認するためのコマンドです。
grepは文字の検索をして絞込みを行ってくれるコマンドです。そのあとに「AWS」と付ける事で、「AWS」という文字列を含んだ行のみ表示がされます。
つまり、「env | grep AWS」とコマンドを実行する事で、環境変数の中に「AWS」という文字を含んだものだけを出力してほしい、という意味になります。
変更後のコードが本番に反映しているかの確認
ローカル開発環境での変更が、本番環境にうまく反映されていないときは、以下の確認をしてください。
プッシュ先のGitHubを直接確認してください。
最後に変更したファイルをGitHubでチェックして、変更点が反映しているか確認してください。
万が一プッシュができていない場合は、もう一度プッシュを行ってください。
GitHubにプッシュされている場合は、EC2へのプルで失敗している可能性もあるので、以下の確認をしてみてください。
ローカルのターミナル
ssh -i ~/.ssh/<pemファイルの名前> ec2-user@<IP>
sshでリモートにログインをします。
最新のファイルは以下のフォルダ内に格納されているので、最後の変更が反映しているか確認してください。
/var/www/（アプリ名）/current/app
このフォルダ以下にファイルが格納されているので、catコマンドで内容を確認してください。
サーバーを再起動
コードが最新になっているのにアプリに反映しないのは、サーバーの再起動ができていない場合があります。念の為、NginxおよびUnicornの再起動をしてから、再度アプリで確認してみてください。
Nginxの再起動
リモートのターミナル
sudo service nginx restart
Unicornの再起動
リモートのターミナル
> ps aux |grep unicorn
# Unicornのプロセスidを確認する
> kill -9 （unicornのプロセスid）
ローカルのターミナル
> bundle exec cap production deploy
これで、デプロイできました。