さくらの VPS + CentOS7 で 俺専用 Mastodon インスタンスを立ててみた話

Mastodon インスタンスを自分専用に運用してみようと思い、手元で余っていた さくらの VPS (さくらインターネット) を利用して CentOS7 + nginx + Docker で立ててみたのでメモ

Mastodon (マストドン) が先週の頭、4月10日くらいから日本でも急激に話題になって、@nullkal 氏が自腹で mstdn.jp インスタンスを立ててくれた辺りからはもう一部でお祭り騒ぎになっていました。

で、いい機会だし、ちょっとお勉強を兼ねて自分専用の Mastodon インスタンス (所謂、おひとり様インスタンスですね) を立ててみようと週末に思い立ち、土曜日の空いた時間でやってみたら 2~3時間で比較的簡単に立てられましたので、備忘録がてらエントリーにしてみようと思います。

使用した環境としては下記のような基本構成に、適時必要なものをいくつか入れた感じ。サーバは元々テストサーバとして使っていたやつが用済みになったので流用。なので個人専用インスタンス立てるだけならもっとコスト抑える方法はあると思います。

  • さくらの VPS (2G プラン - メモリ 2GB / SSD 50GB / 仮想 3Core)
  • CentOS 7 x86_64 カスタム OS インストール
  • nginx
  • Docker (docker-engine / docker-compose)

目次

Mastodon に関しては、頻繁にドキュメントが更新されている関係上、下記に書いている手順が最新とは限りませんので、必ず公式ドキュメントをあわせて参照してください。ちなみに本エントリーを最初に書いた時点で使ったのが Mastodon v1.2.2、その後、v1.3.2 → v1.3.3 まで上げて動作確認できていますので、これらバージョンまでなら書いてある内容で概ね問題ないと思います。

長いので目次をつけました。

  1. Mastodon について
  2. さくらの VPS 上に Mastodon インスタンスを立てる
    1. CentOS7 の基本設定
    2. nginx のインストールと設定
    3. Docker のインストールと設定
      1. docker-engine のインストール
      2. docker-compose のインストール
      3. docker-compose を落としてもデータがぶっ飛ばないように設定
    4. Mastodon のインストールと設定
      1. 設定ファイル .env.production の編集
        1. DB 関連、ドメイン関連の設定
        2. ストレージ関連の設定
        3. rake secret key の設定
        4. メール関連の設定
    5. DB の設定
    6. Let's Encrypt を使用して SSL 証明書を取得、nginx の設定
      1. 証明書の更新を自動化
      2. nginx の設定を仕上げ、SSL のセキュリティ設定も
    7. Mastodon のアカウント作成、管理者設定
    8. SINGLE_USER_MODE を true に
    9. cron による定期メンテナンス
    10. Mastodon のアップデート
  3. 余談
  4. 参考にさせていただいたページ
  5. 参考リンク
  6. 原作者への寄付
  7. 関連エントリー

Mastodon について

Mastodon

Mastodon とは? については他に色々書かれているので今さら書く必要もなさそう。Mastodon の設計思想自体は特に目新しいものではなく、同じく OStatus に準拠した GNU Social の互換実装なわけですが、リリースされたタイミングやインターフェースを含めたデザインのおかげでしょうか? 一気に人気になりました。

ちなみに日本語で Mastodon を紹介した記事だと下記の記事などが最初ですかね。

あと、日本語で用語などを解説する Wiki も立ち上がっているようです。

Mastodon や GNU Social の思想はともかく、mstdn.jp のように数千どころか数万人のアカウントを抱えてしまうとさすがにそのインフラコストは個人が抱えられる範囲を軽く超えてしまいます。

なので安易にインスタンス立てると多分大変なことになるので、ある程度覚悟のある人以外はやめた方がいいと思いますが、完全に個人専用なら自分の責任の範囲だけで運用できますし、フォロー / フォロワー間でのやりとりに限定すれば完全個人インスタンスで十分楽しめますから、遊びとして試してみるのもいいと思います。

また、他人が作ったインスタンスの運営方針が気に入らないとか、重たくて嫌だとか、あるいは信用できない...... みたいな人にもいいですね。これが本来の設計思想に合致したインスタンスの立て方だとは思いますけども。

さくらの VPS 上に Mastodon インスタンスを立てる

では下記に私がやった手順をまとめていきます。VPS の立ち上げから基本的な設定までは簡単にしか書いていませんが、その辺は一般的な手順として見てください。

CentOS7 の基本設定

まずはまっさらなさくらの VPS に、カスタム OS として用意されている CentOS 7 x86_64 を標準構成でインストールして起動。それから DNS の設定を済ませて、今回のインスタンスで使うドメインでサーバの IP アドレスが名前解決できるようにしておきます。

サーバが立ち上がったら SSH して必要なユーザーを作成後、ファイアウォールの設定。firewall-cmd で必要なポート設定などをしておきます。私の環境では HTTP/HTTPS と SSH 用のポート (初期設定からポート変更) だけ開放。

続いて、

# vi /etc/ssh/sshd_config 

して、SSH 関連の設定を色々。セキュリティ的に問題ないように。

設定が終わったら、

# systemctl restart sshd.service

した上で、SSH しなおしてみて問題ないことを確認。

念のためサーバ時刻周りの設定 (Chrony) を確認。それから基本的なツールをとりあえず入れておきます。

# yum -y install wget
# yum -y groupinstall base
# yum -y install zlib-devel
# yum install -y readline-devel

仕上げに yum update しておきます。

# yum update

最後に SELinux を無効化しておきます。

# vi /etc/sysconfig/selinux
SELINUX=disabled

nginx のインストールと設定

次に nginx をインストールします。nginx リポジトリをインストールしてから、nginx 本体をインストールします。

# yum install http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm
# yum -y install --enablerepo=nginx nginx
# systemctl start nginx
# systemctl enable nginx

これで私の環境では nginx/1.11.13 がインストールされました。

インストール後に nginx を起動して問題なければひとまずは OK。細かい設定は後でやるので一旦忘れて、Docker 関連のセットアップへ。

ちなみに、nginx を HTTP/2 に対応させる手順は、別途下記の記事で書いていますので参考まで。

Docker のインストールと設定

続いて Docker をインストールしていきます。まずは docker-engine から。

docker-engine のインストール

リポジトリを追加。

# vim /etc/yum.repos.d/docker.repo
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg

インストールします。

# yum install -y docker-engine

インストールが完了したら起動。

# systemctl start docker
# systemctl enable docker

docker-compose のインストール

次に docker-compose を入れていきます。まずは Changelog を見て、最新のリリースを確認しておきます。

私が作業した時点での最新は 1.12.0 だったので、下記のように任意の場所で最新のリリースを取得。

# curl -L "https://github.com/docker/compose/releases/download/1.12.0/docker-compose-$(uname -s)-$(uname -m)" > /usr/bin/docker-compose

権限を付与します。

# chmod +x /usr/bin/docker-compose

バージョンを問い合わせて、正しくインストールされたことを確認します。

# docker-compose --version
docker-compose version 1.12.0, build b31ff33

docker-compose を落としてもデータがぶっ飛ばないように設定

このままだと、docker-compose を落としたときなどに DB 含めデータが全部ぶっ飛びますので、docker-compose.yml を編集してデータが永続化されるようにしておきます。

# vim docker-compose.yml

下記のように設定。

services:

  db:
    restart: always
    image: postgres:alpine
### Uncomment to enable DB persistance
    volumes:
      - ./postgres:/var/lib/postgresql/data

  redis:
    restart: always
    image: redis:alpine
### Uncomment to enable REDIS persistance
    volumes:
      - ./redis:/data

これで、サーバを再起動したりという事態が発生しても、データは残るようになります。

正しくデータが永続化されているかの確認方法や、一度上記の手順を忘れてインスタンスを立ち上げてしまった場合の対処法などについては下記が参考になります。

Mastodon のインストールと設定

さて、いよいよ Mastodon を入れていきます。今回は、/opt/mastodon に必要なファイルを置く前提で進めます。まずは必要なファイルを GitHub から取得します。タグ付きの最新リリース版を使用するようにチェックアウトします。

# cd /opt
# git clone https://github.com/tootsuite/mastodon.git
# cd mastodon
# git checkout $(git tag | tail -n 1)

以降は、/opt/mastodon 内で作業します。

まず、設定ファイルに記述する、

PAPERCLIP_SECRET=
SECRET_KEY_BASE=
OTP_SECRET=

の各 Key を取得するため、下記のコマンドを 3回実行。1回目は時間かかると思いますが、2回目以降はわりとすぐ終わります。

# docker-compose run --rm web rake secret

処理が終わると、最後に Key が出力されますのでそれをコピーしておきます。前述の通り、3つの Key が必要です。

設定ファイル .env.production の編集

次に設定ファイルを書き換えていきます。

# cp .env.production.sample .env.production
# vim .env.production
DB 関連、ドメイン関連の設定

まずは基本的な設定ですね。

# Service dependencies
REDIS_HOST=redis
REDIS_PORT=6379
DB_HOST=db
DB_USER=example
DB_NAME=example
DB_PASS=************
DB_PORT=5432

# Federation
LOCAL_DOMAIN=mastodon.example.com
LOCAL_HTTPS=true

DB に関連する設定を下記に。任意のユーザー名、DB 名、パスワードを設定しますが、後で実際に DB に設定しないといけないので手元で参照できるようにしておきましょう。

DB_USER=example
DB_NAME=example
DB_PASS=************

下記の部分は、ドメイン名の設定と、SSL を有効にする設定。SSL 証明書に関しては後で Let's Encrypt を使用して行います。

# Federation
LOCAL_DOMAIN=mastodon.example.com
LOCAL_HTTPS=true
ストレージ関連の設定

デフォルト状態では Mastodon が利用するストレージ領域 (画像や動画などの保存場所) はローカルサーバ上に置かれますが、運用を続けるとかなりサイズが肥大化するので、できれば外部に出してあげた方がよいです。下記で別途記事を書いていますので参考まで。

rake secret key の設定

次に、先ほど rake secret で取得した Key を下記の項目にそれぞれ記述します。

PAPERCLIP_SECRET=
SECRET_KEY_BASE=
OTP_SECRET=
メール関連の設定

メール設定 (E-mail configuration) は、自分専用インスタンスとして利用するなら不要ですが、一応、通知関連で自分宛にメールを飛ばしたい時に必要かなと思ってやっておきました。外部サービスとして、「SparkPost」 を利用する前提です。

まず、SparkPost でアカウントを作成しておきます。

アカウント作成が完了すると、ドメインを登録しろといわれるので登録します。この際、API Key が発行されますので、これを間違いなく手元にメモしておきます。これ忘れると API Key を発行しなおさないといけなくなります。

登録が完了したら、管理画面からドメイン設定を確認すると、下記のように DNS の設定をしろと、DKIM(Domainkeys Identified Mail) レコードの値を指定されますので、言われたとおりに DNS の TXT レコードとして設定します。

SparkPost のドメイン管理画面

「test」 を押して、正しくレコードが登録されたことが確認できたら問題なし。先ほど控えた、API Key の情報を持って、サーバの設定ファイル (.env.production) に戻ります。

下記のように設定。SMTPFROMADDRESS= に設定するのは、各メールの送信元となるアドレスです。

# E-mail configuration
# Note: Mailgun and SparkPost (https://sparkpo.st/smtp) each have good free tiers
SMTP_SERVER=smtp.sparkpostmail.com
SMTP_PORT=587
SMTP_LOGIN=SMTP_Injection
SMTP_PASSWORD=[先ほど取得した API Key]
SMTP_FROM_ADDRESS=example@mastodon.example.com
#SMTP_DELIVERY_METHOD=smtp # delivery method can also be sendmail
SMTP_AUTH_METHOD=plain
#SMTP_OPENSSL_VERIFY_MODE=peer
SMTP_ENABLE_STARTTLS_AUTO=true

ここまでで一旦設定ファイルの編集は終わりです。

ちなみに、ここでは詳しく触れませんが、設定項目内には EMAILDOMAINBLACKLISTEMAILDOMAINWHITELIST といった項目があります。

例えば EMAILDOMAINWHITELIST に会社や学校のドメインを指定しておけば、そのドメインのアドレスを持っている人しか登録 (というか登録してもアカウントを有効にできない) できなくなりますので、社内専用インスタンスみたいな運用もしやすいかもしれません。

もちろん、適時管理画面から 「新規登録を受け付ける」 の項目を 「無効」 にしておく方がよいと思いますが (後述)。

さて、続いて DB の設定などをして、Mastodon を立ち上げます。

DB の設定

ビルドして、立ち上げます。

# docker-compose build
# docker-compose up -d

立ち上がったら、DB コンテナに入って、DB の設定を行います。

# docker exec -it mastodon_db_1 bash

先ほど .env.production に設定した、下記の各情報を参考に、ユーザーと DB を作成します。

DB_USER=example
DB_NAME=example
DB_PASS=************

usernamedbname はそれぞれ必要なものに読みかえてください。

# su - postgres
$ createuser -P username
$ Enter password for new role:
$ Enter it again:
$ createdb dbname -O username
$ exit
# exit

マイグレーション等、実行してコンテナを再起動します。無事コンテナが立ち上がることを確認できたら、一旦 stop して次の作業へ。

# docker-compose run --rm web rails db:migrate
# docker-compose run --rm web rails assets:precompile
# docker stop $(docker ps -a -q) && docker-compose up -d
# docker-compose stop

そろそろ仕上げの作業。次に SSL 証明書を取得して、nginx の設定を仕上げていきます。

Let's Encrypt を使用して SSL 証明書を取得、nginx の設定

以前、Let's Encrypt を使ってみた件については下記のエントリーで書いていますが、今回は nginx での運用ですので少し手順が異なります。

まず、Certbot クライアントを GitHub から取得します。ここでは /opt 以下にクライアントを置く前提で進めます。

# cd /opt
# git clone https://github.com/certbot/certbot

次に一旦 nginx をストップしてから、先ほど落としてきた Certbot クライアントを実行します。ちなみに、mastodon.example.com の部分は実際に SSL 証明書を使用するドメインに読みかえてください。

# systemctl stop nginx
# cd /opt/certbot
# ./certbot-auto certonly --standalone -d mastodon.example.com

メールアドレスを聞かれますので、確実に受信できるアドレスを入力して進めます。続いて利用規約が表示されますので問題なければ 「Agree」 すると証明書が取得できます。

証明書は /etc/letsencrypt/live/[指定したドメイン名]/ に保存されます。保存されるのは下記の 4ファイル。

  • cert.pem (サーバ証明書)
  • chain.pem (中間証明書)
  • fullchain.pem (上段:サーバ証明書 / 下段:中間 CA 証明書)
  • privkey.pem (秘密鍵 / Private Key)

証明書の更新を自動化

SSL 証明書の自動更新設定を行います。Let's Encrypt から発行される証明書は有効期限が 90日と短く、頻繁に更新が発生するので、更新作業を自動化しておかないと運用時に現実的ではありません。

私の環境では crontab に下記のように設定しておきました(crontab -e)。

0 2,5 */7 * * systemctl stop nginx && /opt/certbot/letsencrypt-auto renew --force-renew && systemctl start nginx

一旦、nginx を止めてから letsencrypt-auto renew--force-renew オプション付きで実行してあげれば、全証明書が一気に更新されます。一見雑な感じですが、通常はこれで問題ないです。

実行間隔は、7日に一度、夜中の 2時と朝 5時に 2回チャレンジするようにしてありますが、90日の間に 1回更新されればよいわけですから、月に 1回とかでもよいと思います。

なお、ドメインを指定して証明書の更新を実行したい場合などは、letsencrypt-auto certonly してあげればよいと思います。詳しくは下記のドキュメントなどを参考にしてみてください。

nginx の設定を仕上げ、SSL のセキュリティ設定も

SSL 証明書が手に入ったので、実際に立ち上げた Mastodon インスタンスが表示できるように nginx の設定を仕上げていきます。ついでに SSL 関連の設定もきちんとやって、Qualys の 「SSL Server Test」 および 「Observatory by Mozilla」 で 「A+」 評価が出るようにしておきます。

まずは、nginx 用の設定ファイルを作成します。下記のように適当な名前を付けて設定ファイルを新規作成しましょう。

# vim /etc/nginx/conf.d/mastodon.example.com.conf

設定内容は下記のドキュメントを参考に。

参考までに、私の環境で実際に設定した内容は下記のようになります (一部 mastodon.example.com になっている部分は実際に使用するドメインに置き換えてください)。

なお、#gzip から下は、上記ドキュメントに書いてあるままのコピペです。

map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    return 301 https://$host$request_uri;
}

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name mastodon.example.com;
  root /home/mastodon/live/public;
  index index.html index.php index.xml;

  #ssl
  ssl_session_timeout 1d;
  ssl_session_cache shared:SSL:50m;
  ssl_session_tickets off;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_prefer_server_ciphers on;
  ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
  ssl_certificate /etc/letsencrypt/live/mastodon.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/mastodon.example.com/privkey.pem;
  ssl_dhparam /etc/nginx/ssl/dhparam.pem;
  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/letsencrypt/live/mastodon.example.com/fullchain.pem;
  resolver 8.8.4.4 8.8.8.8 valid=300s;
  resolver_timeout 10s;
  add_header Strict-Transport-Security 'max-age=315360000; includeSubDomains; preload';
  add_header Content-Security-Policy "script-src 'self'; frame-ancestors 'none'; object-src 'none';";

  #gzip
  gzip on;
  gzip_disable "msie6";
  gzip_vary on;
  gzip_proxied any;
  gzip_comp_level 6;
  gzip_buffers 16 8k;
  gzip_http_version 1.1;
  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

  location / {
    try_files $uri @proxy;
  }

  location @proxy {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";
    proxy_pass_header Server;

    proxy_pass http://127.0.0.1:3000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  location /api/v1/streaming {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";

    proxy_pass http://localhost:4000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  error_page 500 501 502 503 504 /500.html;
}

Mastodon インスタンスのルートディレクトリは、/home/mastodon/live/public になりますので、そのように設定。80番ポートへのアクセスは、すべて 443 ポートにリダイレクトしてしまいます。

SSL 関連の設定は、下記などを参考にしながら決めています。

ssl_dhparam の設定がありますが、

ssl_dhparam /etc/nginx/ssl/dhparam.pem;

これについては、別途下記の通り作成しておきましょう。

# mkdir /etc/nginx/ssl
# cd /etc/nginx/ssl
# openssl dhparam 2048 -out dhparam.pem

SSL 関連の設定については、前述の通り、Qualys の 「SSL Server Test」 および 「Observatory by Mozilla」 で 「A+」 評価が出ることを基準にしています。下記は例として 「SSL Server Test」 を通した結果。狙い通りです。

SSL Server Test (Powered by Qualys SSL Labs) による mastodon.burnworks.com のチェック結果

なお、nginx の default.conf については特にいじらず進めています。

Mastodon のアカウント作成、管理者設定

nginx の設定が完了したら、

# docker-compose up -d
# systemctl restart nginx

して、ブラウザでアクセスしてみましょう。Mastodon インスタンスが表示されれば成功です。速攻で最初のアカウントを取得しましょう。

Mastodon

メール設定が正しくできていれば、アカウント登録後、メールが届くはずです。もしメールが届かない場合は、下記のコマンドで強制的にメール認証を通してしまいましょう。

docker-compose run --rm web rails mastodon:confirm_email USER_EMAIL=[登録したメールアドレス]

次に登録したアカウントに管理者権限を付けます。サーバに戻り、下記のコマンドで先ほど作成した Mastodon アカウントに管理者権限を付与します。

# docker-compose run --rm web rails mastodon:make_admin USERNAME=[管理者にしたい username]

Mastodon に戻って、設定画面を開くと、管理者用メニューが表示されるはずです。

Mastodon の管理者専用設定画面

各項目は、クリックすると編集できますが、まず最初に 「新規登録を受け付ける」 の項目をクリックして 「無効」 にしましょう。これでアカウントの新規登録を一旦止めることができます。

次のステップで SINGLEUSERMODEtrue にして、完全な自分専用インスタンスにしますが、ここまでで、ほぼ自分専用インスタンスが完成している状態になります。

例えば、少人数だけが参加するインスタンスが立てたければ、必要なアカウントを作成した後で 「新規登録を受け付ける」 を 「無効」 にしておけば、それ以上はアカウント登録されることがなくなるというわけです。

SINGLE_USER_MODEtrue

最初に作ったアカウント以外は一切作る予定はない、完全なシングルアカウントインスタンスとして運用するなら、下記の設定を行います。

# cd /opt/mastodon
# vim .env.production

として、設定ファイルを開き、下記の項目のコメントアウトを外してあげます。

SINGLE_USER_MODE=true

Docker コンテナと、nginx を再起動してあげれば、設定が反映されます。

# docker stop $(docker ps -a -q) && docker-compose up -d
# systemctl restart nginx

SINGLEUSERMODEtrue にすると、トップページへのアクセスはすべて、accounts/1 のユーザーページにリダイレクトされ、/about ページからアカウントの作成ができなくなります (当たり前ですが登録済みアカウントでのログインはできます)。

これで完全な俺専用インスタンスのできあがりですね。シングルユーザーなので、当然ローカルタイムラインには自分の Toot (トゥート) しか流れてきませんけども。

アカウントのフォローはすべて 「リモートフォロー」 になります。投稿画面の上にある検索フォームに、

[username]@[instance-domain]

という形、例えば mstdn.jp 上の、burnworks をフォローしたければ、

burnworks@mstdn.jp

のように検索すると該当するユーザーが検索されますので、フォローボタンを押せばリモートフォローできます。

あるいは、自分のインスタンスにログインした状態で、リモートフォローしたい人のアカウントページを開き、「リモートフォロー」 ボタンを押した後、出てくる入力フォームに [自分のアカウント]@[自分のインスタンスのドメイン] と入力後、フォローボタンを押せば、リモートフォローできます。

実は Mastodon の日本語訳には当初、一部間違いがあって、上記の方法のリモートフォローをしようとしたとき [フォローしたい人のユーザー名]@[ドメインを入力してください] と表示されてしまっていましたが、前述の通り、ここに入れるのは 「自分の情報」 です。修正された翻訳はすでにマージされているようですので、徐々に直っていくとは思いますが。

例えば私が他のインスタンスのアカウントをフォローするときは下記のように入力します。

Mastodon リモートフォロー時の入力例

cron による定期メンテナンス

Mastodon v1.3.3 以降は mastodon:daily 内に含まれる mastodon:push:refresh の処理について cron ではなく Sidekiq が実行するよう変更が入っています。初期に書かれた解説記事などで mastodon:push:refresh を cron で定期的に回しましょうと書かれている情報は古いので注意しましょう

Mastodon の安定稼働のため、cron による定期メンテが必要です。

詳しくは 「Production-guide.md」 に記述がありますが、毎日実行すべき cron ジョブとして下記が指定されています。

RAILS_ENV=production
@daily cd /home/mastodon/live && /home/mastodon/.rbenv/shims/bundle exec rake mastodon:daily > /dev/null

私の環境では下記のように設定してあります。ドキュメントではデイリータスクになっているんですが、1日 2回くらい回してもいいんじゃないかと思います。

@daily cd /opt/mastodon && docker-compose run --rm web rails mastodon:daily

最初に作業していたときに mastodon:daily というコマンドはなかったので、アップデートで整理されたのかもしれません (mastodon:push:refreshmastodon:media:clearmastodon:feeds:clear あたりを実行しろと書かれていた記憶があるので、その辺を mastodon:daily としてまとめたっぽい)。

ちなみに管理業務に使えるコマンドの一覧は下記で確認できます。

# docker-compose run --rm web rails rake -T

Mastodon のアップデート

基本的には git fetch 後に最新のリリースにチェックアウト、再ビルドという手順で問題ないと思いますが、たまにリリース版でもバグが入っている時があるので注意。下記に Mastodon 1.3.2 に上げた時の手順を参考までに記載しておきます。

# cd /opt/mastodon
# git fetch
remote: Counting objects: 2524, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 2524 (delta 1190), reused 1190 (delta 1190), pack-reused 1327
Receiving objects: 100% (2524/2524), 806.66 KiB | 0 bytes/s, done.
Resolving deltas: 100% (1654/1654), completed with 438 local objects.
From https://github.com/tootsuite/mastodon
 * [new branch]      ashfurrow-patch-1 -> origin/ashfurrow-patch-1
 * [new branch]      feature-account-domain-blocks -> origin/feature-account-domain-blocks
 * [new branch]      feature-trademark -> origin/feature-trademark
 * [new branch]      feature-webpack -> origin/feature-webpack
   a0ed88a..01e011b  master     -> origin/master
   5322654..728db4c  skylight   -> origin/skylight
 * [new tag]         v1.3.2     -> v1.3.2
From https://github.com/tootsuite/mastodon
 * [new tag]         v1.3       -> v1.3
 * [new tag]         v1.3.1     -> v1.3.1

まずは、Mastodon のインストールディレクトリに移動して git fetch でファイルを取得。

次に git status して手元でのファイル更新を確認。

# git status
# HEAD detached at v1.2.2
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   docker-compose.yml
#
no changes added to commit (use "git add" and/or "git commit -a")

構築手順でも書いている通り、docker-compose.yml を編集しているのでその変更だけ避難させておかないといけません。

git stash して docker-compose.yml への変更を一時避難させておいてから v1.3.2 タグにチェックアウト。git stash pop して避難させておいた変更を戻します。

# git stash
# git checkout v1.3.2
# git stash pop
# HEAD detached at v1.3.2
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   docker-compose.yml
#
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (43b0ee7791afb90cb5d84669adf2aa4664f75411)

上の例では、git checkout v1.3.2 としてタグを明示的に指定していますが、git checkout $(git tag | tail -n 1) のようにして最新のタグにチェックアウトしてもよいと思います。

あとはビルドして Docker コンテナと、nginx を再起動すれば終わり。/about/more にアクセスして、バージョン情報が更新されているか確認しましょう。

# docker-compose build
# docker-compose run --rm web rails db:migrate
# docker-compose run --rm web rails assets:precompile
# docker stop $(docker ps -a -q) && docker-compose up -d
# systemctl restart nginx

最新の情報は下記の公式ドキュメントを参照してください。

[追記] Mastodon が保存する画像データなどを外部サーバに置く話

別エントリーとして下記に書きました。

[追記] Mastodon 1.4 系へのアップデートでハマった話

Mastodon v1.4 系へのアップデート時に実行した assets:precompile が失敗するため、Docker for Windows と Bash on Ubuntu on Windows で Mastodon のビルド環境を作って切り抜けましたというお話。


ということで、俺専用インスタンスを さくらの VPS 上に立ち上げるまでの手順でした。書いてみたら長かった......

とはいえ、今回のような小規模インスタンスであれば、Docker のおかげでかなり楽に立ち上げることができます。

実際に運用してみてどの程度サーバに負荷がかかるのかなどは、ちょっと様子を見ながらだと思いますが、自分専用ならまぁその辺は気楽にいけるのでいいかなと。別に落ちたところで困るのは自分だけですからね。

あと、自分専用インスタンスだと、カスタマイズなんかもやろうと思えば自由にできるので、その辺も落ち着いたら試してみようかなと思います。あまりいじりすぎるとアップデート等が面倒になるのでほどほどにしておく方がよいとは思いますが。

ちなみに、私は mstdn.jp にもアカウントを持っていますが、自分で立てたインスタンスから、mstdn.jp 上の自分をフォローする行為はなんていうかちょっと新鮮でしたよ。

なお、大規模インスタンスの運用については、企業としていち早くインスタンスの運用に乗り出した pixiv さんの下記の記事が参考になります。

余談

Mastodon、信用できないインスタンスにアカウント登録するとパスワード情報を抜かれる怖いみたいな話をみましたが、そんなの Mastodon に限らずどんな Web サービスでも同じですよ。

参考にさせていただいたページ

参考リンク

本エントリーの内容とは直接は関係ないですが Mastodon 関連で参考になるページへのリンク。

iPhone で Mastodon するためのクライアントとして下記 「Amaroq for Mastodon」 を利用しています。その他、アプリリストは Mastodon のドキュメント内にもあります。

ネタフルさんで Mastodon インスタンスの立て方に関するまとめとか、ユーザーごとの Atom フィードの件とか。

色々と便利なツールなども提供されはじめたみたいですね。

原作者への寄付

Mastodon の原作者である Gargron 氏への寄付は下記から可能です。

関連エントリー

記事をここまで御覧頂きありがとうございます。
この記事が気に入ったらサポートしてみませんか?