見出し画像

Mastodonのmedia objects置き場を自宅にするためにSynology NASに載せたMinIOと、外に繋ぐためのCloudflareを使ってみたメモ

Mastodonのお一人様インスタンスで問題になるのが、連合タイムラインに流れてくるTootたちに付属するメディアファイルが場所を食うこと。普通はAWS S3に置くのがスタンダードなのですが、ずっと固定費用がかかるのが気に食わないのでなんとか自宅サーバーに出来ないか、と取り組み始めたメモです。


実現したいこと

  • 自宅サーバーに(S3互換のオープンソースソフトウェアである)MinIOを設置し、お一人様インスタンスのmedia objectsはこちらに保存する

  • 自宅サーバのIPを隠すために、外部からMinIOへのアクセスは、Cloudflareを経由させる

作業記録

MinIOを動かすマシンの準備

たまたま自宅のSynology NASが購入から数年経って、DSM 7.1では動作が重くなりすぎて更改の時期に当たったので、更改後の機種を、ちょっと性能が高くてDockerが動かせるものに変更した(そしてメモリも増設した)

Cloudflareアカウントの設定

まずはCloudflareが使えないといけないが、その時にはドメイン全体のDNSをCloudflareに預ける必要があると判明(最初は、cdn.garmy.jp みたいにサブドメインを切り出して預けようとしていた)。
あまり嬉しくはないのだが、Mastodonを動かしているVPNへの攻撃対策にもなるかと受け入れることに。
しかし、CloudflareのDNS設定画面は(普通の人の読みやすさを意識しているとはいえ)BIND設定ファイルを元にしたものとは少し違うし、現時点のDNS設定を取り込んだあとにCNAMEをIPに変換したりするので、慎重に確認した上で、NSレコードを変更した。

参考:こちらのページの「フェーズ1」まで。

CloudflareとSynology NASのトンネル接続

前述ページの「フェーズ2」の作業なのだけれど、Synology NASでの操作はこちらが詳しい。なお、Dockerのネットワーク接続はbridge接続でも上手く動作した。

MinIOを入れる前なので、動作確認に何を使おうと考えたのだが、自宅内ネットワークの帯域測定の為に入れたOpenSpeedTestのDocker(SynologyのContainer Manager内で検索すればそのまま入れることができる)が動いていたので、こちらを使うことにした。問題無く動作。

Synology NASへのMinIOの導入とトンネル掘り

インストールは、↓のZenn記事の通り。Dockerの設定で最初に繋がっているポートは9000番だけなので、ちゃんと9001番ポートも外に繋ぎましょう。

管理者ユーザ名・管理者パスワードを環境変数で設定し忘れたのだが、↓の公式ドキュメントによれば、 minioadmin | minioadmin になるそうで、これで問題無く管理者画面に入ることができました。
試しに1個bucketを作り、public設定にし、1つファイルを置いたら問題無くアクセスできたので検証完了としよう。

そして、ファイル置き場はQuota設定をしたい(ディスクを一杯にされる攻撃などを考慮)。MinIOのBucketと、Synology DSM側の共有フォルダの容量制限の両方を設定した(設定はしたが、本当に動作するかは未検証)。

Mastodonのmedia objects保存先設定を変更したら、過去の投稿はどうなるのか?⇒全部MinIOに転送しておきつつ、自分が投稿したファイルは元の場所にも残しておく必要がある。

こちらの記事によれば、連合先に、自身の投稿のメディアファイルの参照先が、お一人様インスタンス内の古いURLで送られるので「消せない」、キャッシュは遠慮無く置き換えられるので「転送後消しても大丈夫」とのこと。

ただ、自身の投稿のメディアファイルのアップロードをする作業が書かれていなかったが、アップロードしないと自分のプロフィールなどがみれない状態になった(後述)ので、結論としては「全部転送しよう」となる。

S3のコマンドラインツールを入れる

上記のページではpip3で入れる、となっているが、pip3には残っていないので、AWS本家から入れる。

記述通りのコマンドでインストールしたら、aws configureで、ACCESS_KEYとSECRET_KEYを設定する。

過去のメディアキャッシュファイルを転送

まず、awsツールでMinIOを見るにはどうするか?なのだが、--endpoint-urlでMinIOサーバーを指定すればよい。

Cloudflareのトンネル出口のサーバを指定。古いキャッシュをsyncコマンドで送り込む(45GB送り込むのに4時間ぐらいかかった)。

$ aws --endpoint-url http://mystorage.garmy.jp s3 sync live/public/system/cache/
s3://media-cache-activitypub-garmy/cache

お一人様インスタンスのmedia objects保存先設定の変更

設定を「Mastodonの設定ファイルの編集」の項に従って設定する。

概ね記載の通りにしたのだが、MinIOをそのまま見せていてBucket名が見えていることから、 S3_ALIAS_HOST の代わりに S3_HOSTNAME を使って設定することにした。

<S3_PROTOCOL>://<S3_HOSTNAME>/<S3_BUCKET>/<object path>

https://docs.joinmastodon.org/admin/optional/object-storage/

そして、設定ファイルを書き換えてstop / startしてみたら…
自分のプロフィール写真とかが表示されない!メディアファイルもアップロード必要じゃん!ということで慌てて

$ aws --endpoint-url http://mystorage.garmy.jp s3 sync live/public/system/
s3://media-cache-activitypub-garmy/

を回して自分の投稿のメディアファイルもアップロード。比較的短時間でアップロード追えて正常化した。

最終動作確認

自分で写真付き投稿をして

ファイルがBucketに乗るのと

https://mystorage.garmy.jp/media-cache-activitypub-garmy/media_attachments/files/112/178/859/657/442/973/original/37d7efe5099a58c2.jpeg

グローバルタイムラインに他の方の画像付き投稿が流れてくるのをみて

確認完了!
これでVPSのディスク容量を気にせずお一人様インスタンスが運用できる!

この記事が気に入ったらサポートをしてみませんか?