リモートレポジトリのWebHookとGoogle Cloud Functionsを使って、slack通知を作るときに使ったもの。
今の日付(date)が入ったpush.testという名前のファイルを作って、コミットして、remote-nameのbranch-nameにプッシュして削除まで行う。
履歴はたくさん残る。
date > push.test && git add push.test && git commit -m "`cat push.test`" && git push remote-name branch-name && git rm push.test
GKE上で動かしているgunicornアプリケーションで、特に負荷が高いわけでもないのに、突然
[CRITICAL] WORKER TIMEOUT (pid:667)
というログを出しまくって止まってしまうことが発生していた。
いつなるかわからないのでしばらく見守っていたけど、原因を調べることにした。
gunicornのタイムアウトはconfファイルで設定している。
gunicorn_conf.py
worker_class = "gevent" proxy_protocol = True x_forwarded_for_header = "X-Real-IP" bind = ":80" # reload = True timeout = 5 graceful_timeout = 5 # loglevel="debug"
Dockefileでは下記のように実行
CMD ["gunicorn", "-c", "gunicorn_conf.py", "arms:app"]
エラーが発生したときには、ログには上記の [CRITICAL] WORKER TIMEOUT が連発するだけで、エラーの原因がわからないなーと思っていたけど考えれば当たり前で、アプリ内の処理は特に時間がかかっているだけなので、エラーとは認識できない。
そのため、これから下記の対策を行う。
タイムアウトは以前記事にも書いたtimeout-decoratorを使う。
そして、本番公開を行ったけど、いつ起こるかわからないのでしばらく様子見。
現時点の仮説としてはおそらくRedisへの接続でたまに時間がかかってしまうのと予想している。
アクセスの負荷とはあまり関係ないので、GKEでRedisのpodが移動したりでネットワークがつながらなくなっている可能性も。
その際は待っても解決しないので、PODごと落として、再起動させる必要があるかも。
社外に書類などを送るときに、ZIPでパスワードかけて添付して送る、というのがめんどくさいので出来たサービスです。
プレスリリース
prtimes.jp
サービスについては本サイトに書いてあるので、開発系の話をします。
SPRINTはこれ。邦題が良くないけどみんなで読みました。もちろん経費で購入。
SPRINT 最速仕事術――あらゆる仕事がうまくいく最も合理的な方法
まるまる1週間は難しく全体で2週間かかったり、インタビュー対象はほかの社員に協力してもらったり、本そのままはできませんでした。
それでもめちゃくちゃ疲れました。
また1回目のプロトタイプの反応がいまいちだったので、機能を削ったりして、公開までに2回やりました。
初期公開までの開発期間は一時他の案件で中断があったものの賞味3か月程度。
これまでbizocean本体のPHPはIDEを使ってましたが、今回は私の押し付けでvimでやってもらいましたが難なく使えている模様。
GCPをフル活用したため、ややこしい一部は除いて、ほぼメインのtakumi(仮)一人でプログラムから、サーバー、インフラ整備までできてしまいました。
シンプルなサービスなので、最初のプロジェクトとしてはちょうどよかったかも。
今回初挑戦の複数人コードレビューでかなりゴミを消せて無駄なテーブルも減ってリソース節約にもなって、読みやすいコードにもなったので、どんどんやっていきたい。
まだmargeやpullではまることが多い。
現在開発できるメンバーは4人だけどそれぞれがメインで年１つずつぐらいは作っていけそう。
