【結論】
・デプロイでは、下記の理由でエラー特定が困難な場合が多い
・コードが残らない
・設定箇所が多岐に亘る
・ログにエラー箇所が直接的に明示されていない
・これらに対処出来るようになるには、
通信全体の仕組みと、各種パッケージの仕組みを理解し、
場数を踏んでいく必要がある。
・デプロイに限らず、自分が書いているコードが
どのような処理を行っているか、きちんと理解しないと
急なトラブルに対応ができない。
【目次】
- 冷静になってみて
- エラー特定の困難さ
- エラーへの対策
- Uglifier::Error: Unexpected character '`'
- アクセスキーの設定ミス
- プロセスが二つ走っていた
- 誤字脱字
- 《今日の学習進捗》
【本題】
エラー特定の困難さ
今回デプロイをするにあたって、
アプリケーション開発に無いエラー特定の難しさを感じました。
それは、下記の３つです。
・コードに残らない
アプリケーション開発では、
スペルミスをしたとしても、
それがコードとして残ります。
対して、デプロイに関しては、
・EC2インスタンスの設定
・本番環境へのパッケージの導入
・MySQLのパスワード設定
・git-secretsの条件を設定・・・など
コードに残らない設定が多々あり、
過去の処理を正しく行えたか、追うのが困難になります。
・設定箇所が多岐に亘る
アプリ開発であれば、少し記述しては、
動作検証をするという事を習慣化させれば、
エラーが発生しても、直近に記述した内容を
見返すだけで、簡単にエラーが特定出来るケースが多いです。
対して、デプロイでは、一つを機能させる為の
設定箇所が多岐に亘る為、一通り作業を終えてからで無いと
検証ができず、エラーが発生した場合に見返す箇所が多くなってしまいます。
・エラーログでエラー箇所まで特定できない
Railsのエラー画面やJavaScriptのコンソールであれば、
ご丁寧にエラーが発生している箇所のコードを表示してくれるし、
エラー特定の手掛かりを掴みやすいです。
対して、デプロイにもmysql起動時などに起こったエラーを
ログから見れるように設定できますが、
エラー箇所が明示されていない為、
それだけでエラー箇所を特定する事が困難です。
エラーへの対策
これらを柔軟に対処するには、
サーバーやデータベースのメカニズムや
各種パッケージの仕組みを理解した上で、
場数を踏んで行くしか無いのかと感じました。
アプリ開発でも同様の事が言えますが、
デプロイについては、その必要性をより強く感じさせられました。
次に、実際に今回のデプロイで
発生したエラーを列挙していきます。
Uglifier::Error: Unexpected character '`'
これはサーバー側でRailsを起動できなかった時に発生したエラーです。
The deploy has failed with an error: Exception while executing as ec2-user@**********: rake exit status: 1
rake stdout: Nothing written
rake stderr: rake aborted!
Uglifier::Error: Unexpected character '`'
これは、この投稿が役立ちました。
taremimi.hatenablog.jp
アクセスキーの設定ミス
次はCapistranoを利用した自動デプロイで発生したエラーです。
Access denied for user 'root'@'localhost' (using password: YES)
これは、MySQL 5.6 リファレンスマニュアルが参考になりました。
dev.mysql.com
プロセスが二つ走っていた
次はunicornが起動できないエラーです。
`bind': Address already in use - bind(2) for 0.0.0.0:3000
これは次の投稿が参考になりました。
hyottokoaloha.hatenablog.com
なぜか二つプロセスが動いていて、killしたら直りました。
誤字脱字
その他にも、誤字脱字で動かなくなる事象もありました。
単純なことに、多くの時間を費やしたことで、
とにかく慎重に記述していく事が必要だと感じました。
《今日の学習進捗》
とりあえずデプロイは完了。
ポートフォリオの作成に着手する。
学習開始からの期間 ：42日
今日までの合計時間：414h
今日までに到達すべき目標時間：384h
目標との解離：30h
「10,000時間」まで、
残り・・・「9586時間！」