タイトルの通り、マストドンの技術的な話です。
マストドンは、常時、他のインスタンスから流れてきた画像も保存しています。ですから、やたら画像を大量に投稿してる人をフォローしている人が居た場合、たとえ自分のインスタンスでの画像投稿が少なかったとしても、あっという間にDBが圧迫されてしまう可能性があります。もし、DBが満杯になると、インスタンスは止まってしまいます*1。
Amemiya.workの場合、1月4日の時点で、DBが入っているvdb1の容量が120GB（72％）を超えました。そろそろなんとかしないと……ということで、他のインスタンスから流れてきた画像のうち、古いものを消してしまうことにしました。
v2.5.0より、tootctlという機能が追加されました。これは、管理者向けの機能で、今まで色々と面倒だった色々な管理を簡単に済ますことができます。
……こういうこともあるので、v1.x系を使ってるインスタンスは、すぐにでも、DB吹っ飛ばしてでも最新版を入れた方がいいと思います。余程、OStatusに思い入れがあるなら別ですが。
このtootctl、軽く検索をかけると、Dockerを使わない方法での扱い方しかヒットしませんでした*2。
そこで例によって、鯖缶工場にて相談しました。ご教示感謝いたします。
sudo docker-compose run --rm web bundle exec bin/tootctl media remove --days=30
これを入力すると、「.」が沢山出てきて削除が始まります。完全に終わり切る前に寝落ちしてしまったのですが、翌朝寝起き直後に確認してみた所、無事に38GB（23％）まで減少していました。
「sudo RAILS_ENV=production」の代わりに「sudo docker-compose run --rm web」と入れているような感じです。
「sudo docker-compose run --rm web bundle exec bin/tootctl」までがtootctlを呼び出すためのやつのようで、それ以降に続いているものがtootctlのコマンドとオプションです。
tootctlには色々な機能がありますが、今回は、画像を削除する機能を使うので、「media remove」です。ここでいう画像とは、先に述べたように、他のインスタンスから流れてきた画像です。ですから、たとえば、自分のインスタンスの住民が投稿した画像が削除されることはありませんし、自分のインスタンスで投稿された画像によって領域が圧迫されている場合には、この手は使えません。
で、その後のオプション「--days=30」は、「30日以上経過したものを削除する」というオプションです。デフォルトだと7日以上経過したものが削除されます。別にそれでも良かったんですけど、まあ、一応。
とりあえず、これで様子をみてみます。
