- Beanstalk用のAMIの最新バージョンを探す
- 普通にEC2インスタンスとして立ち上げて、ログイン。ごにょごにょする。
- AMIを保存して、AMI IDをメモっておく。
- BeanstalkのEnvironmentで、自分で作ったカスタムAMIのIDの指定をする。
これでBeanstalkでアプリが起動してめでたしめでたし、のはずですが、しばらくすると勝手にEC2が落ちますw
BeanstalkのEventログを見てみると、あれ?BeanstalkがEC2インスタンスを落としてるじゃんw 自分で立ち上げておいて落とすなんてヒドい…
Beanstalkが立ち上げてくれたEC2にログインして、http://localhost:8080 を見てみるとちゃんと生きてる。と言う事は、Tomcatの死活監視をしてらっしゃるhostmanager様がたぶん勘違いしているはず…(Elastic Beanstalkの内部的な事は、こちらの資料に詳しく書かれています。: AWSマイスターシリーズReloaded(AWS Beanstalk) )
というわけで、ログ(/opt/elasticbeanstalk/var/log/hostmanager.log)を見てみました。すると、 というエラーが整然と並んで記録されておりますorz
EC2のタイムゾーンを弄ったから?
ちょっとググってみたら、AWSのフォーラムに同じような質問がありました。
- AWS Developer Forums:multiple failures to retrieve status of instance - https://forums.aws.amazon.com/thread.jspa?threadID=63368
質問の回答には「EC2のタイムゾーンをGMT以外で使わない事をオススメする」と言う事で…あぁ、確かに思い当たる節があるw 確かにカスタムAMIを作ったとき、タイムゾーンをJSTにしたわ。 と言う訳で、GMTに戻してみたら、hostmanagerのエラーは出なくなりました。ただ、そのままだとアプリ側の日付処理がずれるので、JVMのオプションに-Duser.timezone="Asia/Tokyo"を指定しました。かっこわるいけど仕方が無い…
これ、どうなんだろ?クラウド的(?)にはタイムゾーンはGMT!ってのも分かりますが、実際は変えちゃう事も多いのでは?
ちなみに問題のhostmanagerがtimestampをパースしている部分ですが、 となってます。Time.iso8601(timestamp)をお好みのものに変更すればうまく行きそうな気もしましたが、ハマるといけないので自重しました(笑)