経緯

• インポート機能利用時、configs をインポートした時はサーバーを再起動したい

経緯を受けての思考プロセス

• node プロセスを child_process external_link を使って自ら複製しよう！
  • → なんか違う
  • → 「自ら process.exit() する」に留め、再起動するかどうかはプロセスを管理する側(e.g. pm2, systemd, k8s...)に任せるべきではないか？

発展

• 調べている過程で「プロセス終了するにしても、今まで graceful shutdown のこととか考えてないなあ」と思った
• 参考:
  • DockerでNode.jsアプリをイイ感じに保つ4つの方法 external_link
  • BretFisher/node-docker-good-defaults の example external_link

やりたいことを一旦まとめる

• GROWI 本体機能として、graceful shutdown を実装する
  • 最低限、MongoDB, ES, socket.io の connection は close する
  • Express の状態管理をどうするかが課題
• 自らプロセス終了する時に、上記を利用する
  • 終了後、docker-compose (dockerize) や k8s から再起動されることを期待する
• docker-compose や k8s からプロセス終了を促される場合(signal を受け取った場合)も上記を利用する

出てきた懸念

PID=1 問題

• コンテナで扱う以上は、official image で PID=1 問題に取り組まないといけないんじゃないか
  • 実は昔から weseek/growi-docker#8 external_link で出てた
  • → 調査しよう → GW-508 external_link

Express の connection ってどうするのがいいんだろう？

• 公式ドキュメント: Health Checks and Graceful Shutdown external_link
  • 「推奨してるわけではないが、terminus external_link や lightship external_link という 3rd-party solution があるよ」と書いてある
  • lightship は README を見た感じ、よく考えてくれてる感がある気がする
    • signalReady, signalNotReady とか
    • (でも必須ではない気もする)
  • コードを見た感じ lightship より terminas の方がスターが多いが、あまり Express の connection について考えてくれてる感がないなあ…
    • → と思ったら https://github.com/hunterloftis/stoppable external_link に任せてるっぽい
  • lightship は k8s でのベストプラクティスとしてこういう記事も参考にせよと書いてある → Handling Client Requests Properly with Kubernetes external_link

k8s 対応

• k8s で扱う以上は、liveness/readiness Prove での挙動ももうちょっと考慮しないといけないんじゃないか
  • 自前で実装した healthcheck API external_link の挙動は、今は完全に Express のライフサイクルと一致しているがそれでいいのか？
    • terminus external_link か lightship external_link のインターフェースに載せるべき？
  • GROWI としての healthcheck API の実装(挙動)はそのままでよくて、terminas や lightship のインターフェースを通して使う、というのがベターかもしれない
    • route は今使っているものを踏襲できるだろうか？