恐怖のwe're sorry, but something went wrong.
個人アプリを開発したぞ！
そして、追加実装したから設定済みの自動デプロイで本番環境のアプリを更新！
さぁ、本番環境への反映をチェックと......。
we're sorry, but something went wrong.
何.....だと....! ?´д` ;
本番環境でアプリが開かない！？ :(；ﾞﾟ'ωﾟ'):
そのエラーに見事にハマった。
という事で、エラー解決に至るまでの死闘を描く。
herokuへデプロイした際の同じエラー解決記事は結構見つかったものの、意外にMySQLでの解決策は見つからなかった。
今回はMySQLでの対処法だが、we're sorry, but something went wrong.エラーの全てが今回の内容で解決する訳ではないので、あくまで参考に留めて欲しい。
特に追加実装などでGemを増やした人は特に注意して欲しい
開発環境
- Ruby on Rails6
- DBはMySQL
- AWSにEC2インスタンスを使用してデプロイ済み
- Capistranoで自動デプロイ設定済み
というのが前提です。
事件の始まり（自動デプロイ直後）
ふと思い立って追加実装する為にGemを追加した。
記述を終えてローカル環境での動作を確認したので、私はコミットしてマージを終えた.....。
本番環境へ反映させる為に、以下のコマンドをターミナルのローカルディレクトリで入力。
$ bundle exec cap production deploy
無事にデプロイが完了したメッセージがターミナルに表示されたので、本番環境でのチェックをしたところ、上記画像のようにアプリが開かなくなってしまった.....。
何故だ！？((((；ﾟДﾟ)))))))
ローカルでは問題なくても、いざ本番環境となるとエラーが起きてしまうパターンはある。
エラー文はググれば何となく分かっても、肝心の解決策が浮かばない。
となると、エラーが起きている箇所のログをチェックする必要がある。
容疑者Logの捜査（本番環境のlogを追え！）
ローカル環境でLogをチェックする場合は、log/development.rbをチェックする。
ここで自身のLogが追えるので、ファイルを下にスクロールしていけば最新のLogへとたどり着ける。
しかし今回の問題は本番環境なので、本番環境のログをチェックしないといけない。
その為にはEC2へログインする事になる。
しかし、久しぶりでコマンドがうろ覚え.....。
以下を順にローカルのターミナルに入力していく。
①mkdir ~/.ssh
②cd .ssh/
③lsコマンドで、EC2で作成済みの<鍵名>.pemが表示される。
④chmod 600 <鍵名>.pem
⑤ssh -i <鍵名>.pem ec2-user@<EC2で発行したElastic IP>
すると、
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
と、上記の表示が出てEC2へのログインが完了。
次がいよいよ本番環境のlogのチェック
①$ cd /var/www/<リポジトリ名>
アプリのディレクトリへ移動
②ls
再びlsコマンドを入力。
③cd current
複数のファイルの中にcurrentがあるので移動。
④cd log
⑤ls
laコマンドを入力すると、production.log unicorn.stderr.log unicorn.stdout.log
これらのlogファイルが表示される。
⑥[ec2-user@****** log]$ cat 'production.log'
今回は本番環境のエラー内容を知りたいので、上記を入力する事で本番環境のlogが追える。
その中で表示されるエラー内容をチェックしましょう！
終わらぬ事件（失敗する自動デプロイ）
エラー内容を見つけ、修正したら改めてmasterへコミット。
そして自動デプロイ！
これがそのまま成功すればエラー解決となるが、そうは問屋がおろさなかった。
困ったことに自動デプロイが失敗するようになってしまった。
何故だ！？((((；ﾟДﾟ)))))))
ふと、ここで思った。
事件（エラー）が発生するようになったのは、Gemを増やしてから。
ならば、bundle installしてみよう。
ただし、ローカルと本番環境の両方で。
その結果、
本番環境
Bundle complete! 34 Gemfile dependencies, 115 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
ローカル
Bundle complete! 36 Gemfile dependencies, 126 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
ローカル環境でのGemが36個に対し、本番環境は34個と反映されていなかった。
bundle installしても更新されない。
どうすればいい？((((；ﾟДﾟ)))))))
そこで参考になったのがこの記事。
平和な日常(EC2インスタンスやデータベースの再起動)
つまりは自動デプロイも繰り返すと本番環境に反映しなくなってしまうという事が分かった。
【対処法】
①AWSのマネージメントコンソールにログイン
EC2 → インスタンス → 該当のインスタンスをクリック → アクションのインスタンスの状態 → 再起動 を行います。
②ターミナルからEC2にログイン後、以下のコマンドを実行してnginxとMySQLを再起動しよう。
EC2サーバーで入力
$ sudo service nginx start
$ sudo service mysqld start
もしも、MySQLではなく、mariaDBを使っていたら下記でデータベースを再起動しよう。
EC2サーバーで入力
$ sudo systemctl restart mariadb
これらのコマンドで、データベースやAWSインスタンスを再起動すれば自動デプロイが成功し、Gemのbundle installも反映されました。
今回はGemを起因としたエラーだったので、同じエラーでも全く解決策が違う可能性もあり得ます。
あくまで一つの手段として、インスタンスやデータベースの再起動をした上で、再度デプロイする事でサーバーが開かないエラーからは逃れることが出来る事もあるでしょう。
エラーパターン②
https化後にエラーが発生した場合
同じく「we're sorry, but something went wrong.」が発生した場合でも、通信方式をhttps化した後にも同様のエラーに後日遭遇しました。
結論から書くと、自動デプロイの再実行で解決しました。
# ローカルのアプリディレクトリで実行するコマンド
$ bundle exec cap production deploy
エラー発生した環境
- AWSのRoute53、ACMを利用して「お名前.com」で取得した独自ドメインを設定済み
- ロードバランサーのリスナー設定済み
sslの設定を完了し、設定完了したと思ったのが間違いでした。
お名前.comでメール認証が済んでいなかった事が原因ですが、結果、独自ドメインに制限がかかりアプリが開かなくなってしまいました。
上記で行ってきたインスタンスの再起動、データベースやnginxの再起動も効果なし！
AWS内の値も別に変更していないので、ローカル側の自動デプロイ再実行で直る事に気づくのに時間を要しました。Capistranoでエラーが起きていた疑惑が濃厚でした。
下記コマンドでは、データベースやnginxが正常に起動しているかチェックが可能です。
その他のコマンドもチェックする上で使用する事があるコマンドを列挙します。
起動チェックコマンド
EC2ログイン状態でmariadbの起動チェック
$ sudo systemctl start mariadb
$ sudo systemctl status mariadb
● mariadb.service - MariaDB database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; vendor preset: disabled)
Active: active (running) since 火 2020-12-15 15:12:15 UTC; 1min 55s ago
EC2ログイン状態でnginxの起動チェック
$ sudo systemctl stop nginx (停止)
$ sudo systemctl start nginx （起動）
$ sudo systemctl status nginx （現状のチェック）
● 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 火 2020-12-15 15:12:29 UTC; 1min 30s ago
どちらも**Active: active (running)**と表示されているので、エラー原因の推測から除外する材料になり得ます。
EC2のアプリ実行コマンド
# 下記は、EC2のアプリディレクトリでアプリを起動させる場合に使用
bundle exec unicorn_rails -c config/unicorn.rb -E production -D
# 下記エラーが出たらアプリの起動に失敗しています
master failed to start, check stderr log for details
unicornのエラー表示コマンド
$ less log/unicorn.stderr.log
PSコマンド
psコマンドは、現在動いているプロセスを確認するためのコマンドです。
# EC2のアプリディレクトリで実行（unicornを見たい場合）
$ ps aux | grep unicorn
# 実行すると、一例で下記のような表記が出力される
ec2-user 3836 0.0 0.0 119436 936 pts/0 S+ 15:06 0:00 grep --color=auto unicorn
大事なのは左から2番目の列です。ここに表示されるのがプロセスのid、つまりPIDになります。
killコマンド
killコマンドは、現在動いているプロセスを停止させるためのコマンドです。
# EC2のアプリディレクトリで実行
(上記の２番目列のプロセスを停止させる場合は3836を入力する)
kill 3836
(上記は一例なので、数値は毎回変動します)
任意の行数の処理を表示させるコマンド
# 下記は処理を100行表示させるコマンド
tail -100 log/unicorn.stderr.log
ファイルの中身を確認するコマンド
# 例として、unicorn.rbファイルの中身をチェックする場合
$ cat unicorn.rb
などなど、本番環境で動作を確認するコマンドは多々存在します。
混乱したくなりますが、考えられる解決策を一つずつ実行していくのも、
解決後に要因の推測の一助となります。
EC2からログアウト
EC2サーバーは一定時間経過で自動的にログアウトしますが、自分でログアウトしたい場合は下記コマンド入力でログアウト可能です。
exit
以上です。