MastodonをさくらVPSとさくらオブジェクトストレージで構築する
はじめに
Mastodon も大分楽しんで、そろそろ自分のインスタンスを持とうか考えていたのですが、ふとその気になったのでぼっちインスタンスを構築してみました。
Mastodon のインスタンス構築ですが、結構大変でした。特に、さくらクラウドのオブジェクトストレージには泣かされたのでその辺も含めメモ書き程度になりますが、記録を残しておきたいと思います。
サーバー構成
サーバーは、さくらVPSの2GプランでHDD(200GB)を選択しました。SSD(50GB)という選択肢もなくはなかったのですが、データベースサーバーも兼ねるので速度より容量を選択しました。
そして、これがこのサーバー構成の特徴になるのですが、画像の保存は Amazon S3 互換のさくらクラウドのオブジェクトストレージを採用しました。
最初は、200GBもあれば十分だろうと思っていたのですが、一度立ち上げたらディスクの拡張は容易ではないし長く使えないのでさくらつながりでさくらオブジェクトストレージの採用を決めました。。
残念だったのが、Mastodon は Web サーバーが Apache ではなく nginx だったので、Site Guard Lite という WAF(Web Application Firewall) が使えなかったことですね。
ミドルウェア構成
Mastodon は Ruby on Rails やたくさんの最新技術で作られているので、できるだけ不確定要素を除外することを基本方針にしました。それでも、経験のない技術ばかりで泣きそうでしたが。
まずは、標準OSとして Ubuntu が上げられていますが、これを止めて CentOS7 にしました。Ubuntu は馴染みがないので何かあったとき対処できないし、セキュリティ対策も十分にできそうもなかったのもあります。CentOS7 なら自分の中で対応方法がある程度確立しているというのもあります。
そして、Docker は使わない。を方針にしました。Docker は便利そうなのですが、OS の上にレイヤーをはさんで1つのインスタンスを動かすのは不安しかありませんでした。設定を間違うとデータが飛ぶとかありますし。という訳で、Docker もなし。
これで情報をあさっていたらドンピシャな情報があったので、基本的にこの手順と場合により公式ドキュメントを観たりして構築していきました。
セキュリティ対策
CentOS7のセキュリティ対策は、兄弟サイトの以下の記事を参考にしてください。
PostgreSQL で大ハマリ
上記手順に従って作業を勧めていたのですが、 突然、user カラムがないぞみたいなエラーが発生して大ハマリです。これ根が深い問題で、PostgreSQL は template1 というデータベーステンプレートからデータベースを作成するようなのですが、文字コードは ASCII になっていて Unicode の Mastodon のデータベースが作成できなくなっていました。
じゃあ、以下の情報を見つけて対応しようと思ったら、今度は権限がないと怒られて作業ができない。
PostgreSQL のスーパーユーザは、ここでは postgres だったのですが、Peer認証というもので弾かれてテンプレートの削除ができなかったです。
いろいろ試行錯誤をしたところ、postgress と mastodon の Linux ユーザーに passwd コマンドでパスワードを設定して、postgres ユーザーで上記サイトの作業を行ったところ問題を解消することができました。
PostgreSQL をコマンドラインから扱ったことがなかったから、これはきつかったです。
さくらオブジェクトストレージで大ハマリ
オブジェクトストレージと聞いてもピンとこない方もいると思うので、よいスライドがあったので貼っておきます。
まあ、簡単に言うと、Amazon S3 互換のストレージで、容量に制限がなく、使った分だけお金を払えばよいというものです。ただ、Amazon S3 を個人で運用しようと思おうと転送料金が大変なことになるので、ここは個人の味方?であるさくらのオブジェクトストレージを選択した訳です。
100GBで月額540円なんてなんてお得なんでしょう。 転送量は月10GBを超えたら108円というのもお得です。計算はしていないですが、Amazon S3 だったら大変なことになるのではないでしょうか。
さて、動作するようになった Mastodon に さくらオブジェクトストレージを組み込もうと思ったら、これがなかなかどころか非常に大変でした。まず、S3 互換をうたっているものの v2 までで、現在の v4 に対応していないので設定方法が分かりせん。
ググりにググって、かすかな情報から設定内容が分かりました。その他の項目も同じような感じです。挙句の果てにはソースコードをいじらないと動作しない部分があってまいりました。
さて、では、オブジェクトストレージの設定を行う .env.production の該当部分を見てみましょう。ソースをいじっったので以下の設定で動くようになっていることにご注意ください。
# S3 (Minio Config (optional) Please check Minio instance for details)
S3_ENABLED=true
S3_BUCKET=bucket-name
AWS_ACCESS_KEY_ID=key-id
AWS_SECRET_ACCESS_KEY=xxxxxxxxxx
S3_REGION=tokyo #なんでもいい
S3_PROTOCOL=https
S3_HOSTNAME=b.sakurastorage.jp #ソースの変更で動作
S3_ENDPOINT=https://b.sakurastorage.jp #分からなかった
S3_SIGNATURE_VERSION=s3 #v2互換の指定。分かるわけない。
で、ソースコードの修正ですが、なんでそんなことを行うかというと1つが画像のアップロードはできるようになるのですが、画像の表示の URL がオブジェクトストレージと Mastodon で異なるのですよね。これを合わせないといけない。
もう一つは画像のキャッシュ回避なのでしょうが、画像の後ろに xxx.jpg?23432 のようにタイムスタンプが付いているとオブジェクトストレージがなにかの命令と解釈して権限がないとエラーを返すのですよね。こちらも解消しないといけません。
修正するファイルは、live/config/initializers/paperclip.rb になります。このファイルは起動時に初期設定を行うファイルでオブジェクトストレージの設定も行っています。
unless ENV['S3_ENDPOINT'].blank?
Paperclip::Attachment.default_options[:s3_options] = {
endpoint: ENV['S3_ENDPOINT'],
signature_version: ENV['S3_SIGNATURE_VERSION'] || 'v4',
force_path_style: true,
}#コメントアウト
#Paperclip::Attachment.default_options[:url] = ':s3_path_url'
#以下の2行を追加
Paperclip::Attachment.default_options[:url] = ':s3_domain_url'
Paperclip::Attachment.default_options[:use_timestamp] = false
この設定を行ったら以下のコマンドで、Mastodon サービスを再起動します。
systemctl restart mastodon-*.service
これで画像の投稿と表示ができるようになります。
ここにたどり着くまでが長かったです。。。
おわりに
Mastodon のインスタンスを自力で立ち上げるのは結構大変だな、というのが正直な感想です。
馴染みのない技術が多いですし、トラブルシュートしようにもネットに情報がない状態なのでかなり厳しいです。
この記事が困った方のお役に立てば幸いです。
スポンサーリンク
Twitter ではブログにはない、いろんな情報を発信しています。
@fnyaさんをフォロー
コメント