昨日11/2に私の個人Mastodonサーバーmstdn.asterism.xyzを、4.2系ベースのフォークから4.4.8バニラまでアップデートを行いました。
この記事は作業中のメモを見ながら明確にミスだった部分などを振り返り、次回のアップデート(おそらく今月リリースの4.5系へのアプデか、あるいは来年四月のUbuntu 26.04 LTSへの移行かその辺り)で同じようなミスをしないように覚えとこうねというやつです。
元々の環境について
- Xserver VPSのメモリ4GB/vCPU4コア/SSD100GBインスタンス1つで稼働
- Ubuntu 22.04 LTS
- docker：リバースプロキシ用のCaddy、mastodon-web, sidekiq, streaming
- ネイティブに：PostgreSQL14.x, redis6.0.x, Elasticsearch(確か8.7とかだっけな…)
- メンテナンスSSH用にzerotierによるVPN接続
- メディアファイル用のS3
- S3用のCDN CloudFront
ここ2年ほどmohemoheがメンテナンスしていたmastodon4.2系ベースのフォーク(DBスキーマは未変更なのでイメージ差し替えだけで動かせた) mstdn-plusminus-io/mastodonを動かしていましたが、mastodon公式の4.2系メンテナンス終了や、日本語全文検索に魅力を感じなくなった事などいくつかの理由からバニラmastodonへ戻る事にしました。
ベースが4.2系かつUbuntu 22.04と古いため、必要な作業をリストアップする部分からで実作業というよりもその準備に手間取りました。(実作業は実作業でかなりトラブル続きでしんどかったですが)
作業概要
- ミドルウェア系
- psqlは問題なし
- elasticsearchは利用停止するため削除
- redisはubuntu22.04だと6.0系のため将来的なmastodon4.5対応のためにredis公式のリポジトリを使い最新版にする
- アプリケーション系
- 基本的にはイメージ差し替えとdb:migrate、後はDB暗号化で増えた環境変数の設定のみ
必要なものは上記のみのため、ざっくりの作業順としては
- 丼とcaddyを停止
- apt update upgrade
- ライブパッチあるとはいえずっと起動しっぱだからトラブル防止のために一応再起動
- elasticsearchを利用しない状態に設定した上で削除
- psqlバックアップ取得
- 古いredisの設定ファイルを一応確認してからアンインストール
- redisのaptリポジトリを探して設定、新しいredisをインストール
- docker-compose.ymlでのイメージ指定を公式の4.3系最新に指定して、db:migrateや新しい環境変数の発行と設定
- コンテナを起動して稼働確認
- 丼とcaddyをまた停止
- イメージの指定を4.4系最新にして、db:migrateなど
- 稼働確認 といった流れ。
mastodonそのものに関しては特に問題なかったため、これ以降はトラブルがあった部分についてのみ書きます。
トラブルその1：ストレージの空きを確認し忘れたままvacuum
DBのバックアップはgz圧縮で特に問題なく行えていましたが、作業開始時点で80GB/100GBくらいの利用状況でした。
この状態でダンプ+手元に持ってきてからサーバー側ファイルの削除を行った後、「あっそういやvacuum fullとかあったな。ちょうどいいしやっとくか」とか適当考えて流したせいで無駄に時間を食いました。
勿論処理中にディスクフルで処理が止まり単に時間を無駄にしただけになってしまい、この状態で運用続けるのもまぁ不安だよねという状態。
当初はいきなりの削除まではしないつもりだったelasticsearchをapt purgeして、またmastodon用のDBをテーブル一つ一つ指定してvacuum fullするなどで数GBの空きはできましたがそれでも73GB/100GB程度。作業を続けることはできますが、不安と言えばまぁ不安という感じ。
どうするか悩んでいましたが、Xserver VPSにディスク追加とか無かったよなー確か…などと考えながらサービスサイトを眺めていたところどうやらメモリとストレージを無料で追加してもらえるようだったのでこれを申請しgot kotonaki。
トラブルその2：サーバー内から名前解決ができない
大盛り無料申請と適用完了通知が届いてからXserver VPS管理画面からインスタンスを起動してしばらく待ちましたが、なにやらSSHができない。
zerotier管理画面から見てもどうやらVPS側から接続しに来ていない様子。仕方ないのでXserver VPSのwebシリアルコンソールから接続して復旧作業を開始しました。
zerotier-cliでleaveやjoinし直しなどを行っても一向に進まないため、もしやNWの問題化と判断し試しにgoogle.comへpingしたところ名前解決不可状態でした。
Xserver VPSではnetplanは使っていないようだったのでどうすっかなぁとググっていたところ「/etc/systemd/resolved.confの [Resolve] 以下にDNS=でアドレス指定すればいいで」という情報を見つけて対応、その後VPSを再起動したところzerotierが問題なく接続できた。
トラブルその3：新しいredisをインストールできない
古いredisパッケージのpurge後、redis.ioの公式ドキュメントに従いaptリポジトリを追加して apt install redis を実行したが、どうしても古いバージョンがインストールされてしまう。
バージョン指定してインストールできるのは知ってるけど、それやるとアプデがapt update apt upgradeだけで完結しなくなって地味にめんどい。
パッケージの名前被ってるからそれが原因かねぇ、とか思い色々調べているとaptで使うリポジトリには優先度を設定できるらしい。
/etc/apt/preferences.d/redis.pref へこんなのを記載
Package: redis redis-server redis-tools Pin: origin packages.redis.io Pin-Priority: 1000apt policy redis とか実行すると、どのバージョンがインストールされるか確認できる。
トラブルその4：redisの設定変更忘れ
/etc/redis/redis.conf で、bind設定したはいいけどprotected-modeの変更を忘れていた。
protected-mode noトラブルその5：壊れたパッケージの修復
4.3.14へのアップデート後一度SSHを切っていたが、4.3.14が一通り問題なさそうだったため続きの4.4.8へのアップデート作業を始めるためにSSHを繋いだところ、アップデート待ちのパッケージが残っている通知が出ていた。
そもそも作業の一番最初にapt update apt upgradeは行っているのにおかしいなと思いつつもう一度upgradeを実行したが、なにやらapt list –upgradableで表示される対象がkept outされている様子。
多分再インストールで問題ないんだろうなと思いつつ、一応軽く検索したけど予想通りで問題なさそうだったため apt install --reinstall udev systemd などとして無事アップデートは行えた。
トラブルその6：NW系ユニットの起動が遅い？
先のzerotierのトラブル(zerotierのトラブルでは無いんだけど)もあったので念のためVPSの再起動を行ったが、ここで再びトラブル。またzerotierがつながらない。
webシリアルコンソールから確認したところ、名前解決ができないどころか外部への通信自体ができない。何？
先述の通りnetplanでは設定していないため(dhcpで割り当ててると思うんだけど今netplan使わないで設定するのってどこ経由でやんのかなんも分らん。どっかいじっても勝手に上書きされたりするし)、VPSユーザーである私の側で対応できそうにもなく。
ここまできてどうしようもないトラブル引いちゃったなぁどうしよっかなぁ、どっか新しく契約してバックアップから戻すかぁ？一応手元にはDBダンプあるし、とか考えてた所、いつの間にかVPS側から外部へpingなどなど通るように。いったい何？
単に起動が遅かっただけ？にしてもwebシリアルコンソールからログインできるようになってからもう10分くらい経っとるが…。など。本当に謎。
Linode使ってた頃はこの辺netplanで普通にちゃんとできたから楽だったんだけどねぇ。ubuntu26.04にするタイミングでまたどっか別のVPSに変えるかぁ？でも海外だと円が安すぎてなぁ…。
まとめ
正直自分で十分回避可能だったトラブルはストレージ容量くらいで、他はもうどうしようもなかった感がある。(redisバージョンはあんまトラブルでもないし)
Xserver VPSかなり安いからNW周りの設定情報もうちょい転がってればいいんだけれども。netplanでいけたわ、みたいなレポートなんかも見つからないし。
