これは完全に直感で根拠も無いんですが、Mastodon公式の docker-compose.yml は筋悪いので使いづらいと思いますよ
@whywaita ボリュームじゃなくて特定のディレクトリな所がツラいですね。
@ikeji 個人的にはprecompileをdocker execで叩かないといけないの大変そうだなと思っています。Volumeは恐らく設定すれば動くと思いますが、検証してないので断定はできないですね…
@whywaita あと、precompileしてあっても、起動時にnpmとbabelが動くのが謎です。
@ikeji ん、/api/v1/streamingでbabel-nodeがstreaming用のプロセスを動作させてますよね？おそらくですがこれは動的に動いているような気がします
@whywaita 具体的には、docker run -> npm run streaming -> babel-nodeっていう順番に起動してますが、
docker build時に babel index.js --output index-compiled.jsってしておいてもらって、
docker runの気には直接 node index-compiled.js ってしてくれれば、結構な量のメモリが節約できて、
メモリ貧乏な自分としては、とても嬉しいかな、と。
@ikeji ああ、そういうことでしたか（私のインスタンスだとDocker剥がしたのでピンときてませんでした）
babelの挙動追ってないですが、確かに先にcompileしておくと早そうではありますね（とはいえそこまで逐次処理してるのか怪しいですが）
@whywaita スピード的には問題ないんですが、コンパイラが常駐するようなもんなのでメモリ使用量が…
@ikeji 確かにそうかもしれないですね〜 pumaやsidekiqの方がひどいのであまり気にしてませんでしたｗ
@whywaita たしかに。うちではpumaとsidekiqが100MBづつで、streamerが20MBぐらいです。
@ikeji なのでRuby部分の方が悪ですね…
@whywaita assetのprecompileと同じで、コンテナ作成時にやっておいて欲しかったなーと。