インフラ担当Mです。
今回は4月初旬からにわかに話題になり始めた『Mastodon』の概略と、サーバ構築方法についてです。
世界的にはTwitterやFacebook、国内ではLINEを始めとして、
ここ10年ほどで急速にソーシャルネットワークサービスが社会に普及したことは
皆さんもご存じの通りかと思います。
ですが普及と共に、その問題点も浮き彫りとなってきました。
例えば以下のようなポイントです。
- 運営ポリシーの不透明さからくる、アカウント凍結や削除への不信感
- 企業運営であるが故のマネタイズから逃れられないこと。またその難しさ。
- グローバル展開に伴う、社会倫理や法律の差異から生じる軋轢
- サービスの継続性が運営企業の運営方針、運営状態と紐付いてしまっている。
例に挙げた問題点は、サービス運営側が特定の国家に属するいち企業であるという
点に端を発しているとも考えられます。
であるが故に、解決が難しい問題でもあります。
Mastodonの特徴と利点
そこで登場するのが今回取り上げるMastodonです。
GNU Social互換のコミュニケーションツールとして、国内でにわかに注目を集めています。
特徴としては以下のようなものがあります。
- Twitterライクなインタフェースを持つマイクロブログシステム
- 個別に立てられたサーバ(インスタンスと呼びます)が、緩やかに接続されて連合として動くこと
- 公開範囲の設定が細かく行える。
- 連合間でキャッシュしあうため、特定インスタンスがサービス停止しても完全な参照不能には為り難い。
- 環境構築手順が確立されており、容易であること。
これにより前述の既存SNSの抱える問題点に対し、いくつかの解決方法が提示されてます。
(問題1)運営ポリシーの不透明さからくる、アカウント凍結や削除への不信感
(回答)運営ポリシーは、インスタンスの運営者次第となるが、
Mastodonというサービスの範囲内で、複数のインスタンスの中から、
自らに適した運営ポリシーを持つインスタンスを選択する余地がある。
(問題2)企業運営であるが故のマネタイズから逃れられないこと。またその難しさ。
(回答)個々のインスタンスでは、運営者が管理可能な範囲のユーザを管理すればよく、
設備への投資が適正な範囲で収められるため、マネタイズの重要性が相対的に低くなる。
(問題4)サービスの継続性が運営企業の運営方針、運営状態と紐付いてしまっている。
(回答)仮に利用していたインスタンスが閉鎖されても、他のインスタンスに移転する余地がある。
また、連合での他サーバキャッシュにより、情報が失われづらい。
筆者の雑感
15~20年ほど前、個々のWebサイトが独自に「掲示板」を持っていた時代がありました。
Mastodonは、見方によってはその再来とも言えます。
ただ、「掲示板」の時代と大きく違うのは特徴としてあげた
2,個別に立てられたサーバ(インスタンスと呼びます)が、緩やかに接続されて連合として動くこと
の部分ですね。
Mastodonでは、特定のインスタンスにアカウントを取得しますが、
インスタンスを跨いだ形でのユーザフォローが可能です。
例えば、AインスタンスにいるBさんが、CインスタンスのDさんをフォローすることができます。
逆も当然可能です。
こうやってフォローが成立した段階で、AインスタンスとCインスタンスが連合となります。
連合になると、お互いのインスタンス上でPublic指定でToot(TwitterでいうTweet)されたものが、
お互いの連合タイムラインに表示されるようになります。
こうやってそれぞれのインスタンスで繋がっていくことで、
大きなひとつの連合タイムラインが発生するというわけです。
もちろん、自分自身のタイムラインや、ローカルインスタンスのみのタイムラインもありますので
必要に応じて使い分けることが出来ます。
「掲示板」時代は、利用者の流入方法や、過疎化という問題がつきまといましたが
そのあたりの問題はこの緩やかな繋がりでかなり解消されるのではないかと考えます。
また公開範囲設定が細かく行えることで、ローカルのみ、もしくはフォロワーのみでの
コミュニケーションなども行える点にも注目です。
Mastodonの問題点
最後にMastodonが抱える問題点についても記載しておきます。
1,インスタンス自体のセキュリティ的な安全性やコスト
個々人がインスタンスを容易に立てることが可能であるということは、裏返せば
そのインスタンスの管理は、インスタンスを立てた人物に委ねられるということです。
プログラム的なセキュリティ問題もありますし、またGNUプロダクトということで
改造も可能なため、悪意ある人物が運営するインスタンスというものが発生しないとも限りません。
また、特定のインスタンスに人が集中した場合は、
管理者に掛かるコスト(インフラ的な金銭面、管理コスト面)も無視出来ません。
2,グローバル展開での社会的、法律的な軋轢
個々のインスタンスはそれぞれの国の社会倫理や法律に従う必要があるのは言うまでもありません。
しかし、連合の機能により、世界を跨いだインスタンスで繋がると、途端に複雑化します。
A国では合法であっても、B国では違法であるということも当然あるわけです。
特に画像等はキャッシュであっても違法とされることもありますので注意が必要です。
既に国内で乱立したインスタンスと、西欧のインスタンス間で問題化した事例もあり、
今後システム的にも改善が必要と思われます。
まだまだ開発進行中のプロダクトですが、それ故に開発者としてはコミットする余地が
大きく残されており、今後のSNSの動向を見る上でも無視出来ない存在に急速になりつつあります。
この後で簡単に説明しますが、立ち上げも非常に簡潔に済みますので、
技術者の方は是非挑戦してみてください。
Mastodonのセットアップについて
gitリポジトリにdocker-compose.ymlがデフォルトで含まれているため、それを利用するのが尤も手軽です。
Mastodonの運用方針として、通常の複数人で利用するモードと、シングルユーザモードの2種類があります。
また、DBの永続化なども視点としてはありますが、
まずは尤もシンプルな複数人利用モードでの立ち上げを目指します。
基本以下のページの内容を補足する形です。
https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Docker-Guide.md
1,環境準備
まずはDockerとdocker-composeが動作する環境を準備します。
CentOSであれば7以上が必要となりますので、セットアップします。
2,gitのクローン
適当なディレクトリ以下で、githubからソースをcloneします。
1 |
git clone https://github.com/tootsuite/mastodon.git |
3,.env.productionの編集
Cloneして生成されたmastodonディレクトリに移動し、
そこにある.env.production.sampleをコピーして必要項目を埋めていきます。
1 |
cp .env.production.sample .env.production |
3-1,ドメイン設定
ドメインと、SSL利用の有無を設定します。
ドメインは適当なものを準備を。
最初はSSLを切っておいた方がいいかもしれません。
.env.production内では以下が該当項目です。
1 2 3 4 |
# Federation LOCAL_DOMAIN=example.com LOCAL_HTTPS=true ※SSLを使わない場合はfalseに。 |
3-2.シリアルの生成
複数のインスタンスが立つことが前提のMastodonではユニークなシリアルキーを設定する必要があります。
.env.production内での項目としては以下の3つです。
1 2 3 |
PAPERCLIP_SECRET= SECRET_KEY_BASE= OTP_SECRET= |
シリアルキーは以下のコマンドを./mastodonで実行することで得られます。
1 |
docker-compose run --rm web rake secret |
これを、3回実施し、それぞれで得られたシリアルを前述の3項目にセットしてください。
3-3.SMTPサーバの設定
ユーザ登録などでメール送信を行うため、SMTPサーバの設定が必要です。
.env.production上では以下が該当します。
1 2 3 4 5 6 7 8 9 10 |
SMTP_SERVER=smtp.mailgun.org SMTP_PORT=587 SMTP_LOGIN= SMTP_PASSWORD= SMTP_FROM_ADDRESS=notifications@example.com #SMTP_DOMAIN= # defaults to LOCAL_DOMAIN #SMTP_DELIVERY_METHOD=smtp # delivery method can also be sendmail #SMTP_AUTH_METHOD=plain #SMTP_OPENSSL_VERIFY_MODE=peer #SMTP_ENABLE_STARTTLS_AUTO=tru |
なにを設定するかは環境次第ですが、推奨とされている従量課金型のメールサービスや
GMail、もしくはローカルのSMTPサーバなどを利用すると良いでしょう。
4,ビルドとマイグレーション
まずはDockerコンテナをビルドします。
1 |
docker-compose build |
続いてDockerコンテナ上に構築されたDBに対してマイグレーションを実施します。
マイグレーション時は以下のコマンドを./mastodon直下で実行します。
1 |
docker-compose run --rm web rails db:migrate |
1 |
docker-compose run --rm web rails assets:precompile |
5,イメージ起動
ここまでエラー無く完了したら、いよいよイメージの起動です。
1 |
docker-compose up -d |
を実行すると、mastodonが起動します。
起動したMastodonは、Port番号3000でWebサービスを開始しますので、
1 |
http://localhost:3000/ |
などで、ブラウザから閲覧可能です。
閲覧して、可愛い(?)マストドンさんとログインページが出てくれば成功です。
6,リバースプロキシの設定
このまま勢いに任せて公開…してしまってもいいのですが、このままだと
ポート指定でのアクセスになり少々不便ですし、SSLも使えません。
ですので、Dockerの親機などにnginxなどでリバースプロキシを噛ませます。
nginxの設定ファイルなどは公式で配布されているものを利用すると手軽です。
https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Production-guide.md
SSL証明書もリバースプロキシ上で設定すると良いでしょう。
7,管理アカウントの作成
Mastodonには管理用のアカウントを作成する機能があります。
管理用アカウントでは、通常のWebインタフェースの管理画面上に、管理用のメニューが追加されます。
まずは普通にアカウントを作成し、そのアカウントに対してAdoministrator権限を付与します。
付与するには./mastodon直下にて
1 |
docker-compose run --rm web rake mastodon:make_admin USERNAME=(対象のアカウント) |
を実施すればOKです。Webインタフェース上からの新規アカウント追加の可否も
このメニュー内で設定出来ますので、まずは管理用のアカウントを作成してください。
8,最後に
単純な起動方法については以上です。
これでとりあえずインスタンスが立ち上がります。
ここからの運用はあなた次第です。是非趣味のインスタンスを立ち上げて、色々試してみてください。