従来の Upstart/daemontools 等の init系プロセスでは、
- double forking による自身を デーモン化するプロセス
- Puma/Unicorn 等の Hot restart
init 系プロセスの管理から外れてしまう問題があった。
それによってプロセス監視などの管理がうまくいかない為、server-starter や unicornherder 等のツールを導入してこれらの問題を解決していた。 -- 【対策】
この問題に対して、systemd では、cgroups を利用して init プロセスをコントローラできている。
systemd を導入することで、【対策】 を無くし、簡易化できる利点がある。
Docker
+ systemd
+ Puma / Unicorn
+ Rails App
Docker
+ systemd
+ Agent App (Double-Forking Deamon)
セキュリティ面は docker 化しているから、そんなに恩恵はない？
管理するプロセスのログを 1つにまとめれる
運用をしないアプリエンジニアからすると、利点はわかりにくかったけど、
DevOps として考えると、見るべきログを統一化できるというのは、大変よい。
アプリ毎にログの見方が違う、複数に分散する。という問題を解決できる。
フィルタリング方法もある程度、統一できる 時間などは --since, --until オプションが用意されている
journalctl --since "2019-05-01" --until "2019-05-01 01:00"
- 並列化による効率化
- 依存管理
- プロセス停止機能