しょーがないのでスタンドアロン版で復旧を図る
先の記事でも書いたのですが、Kubernetes基盤に構築していたMastodonが華麗にも吹っ飛びました。
そこで頑張って復旧にいそしみ、5/11にようやく復帰しました。イヤー、非常に長い道のりだった。現在はサービス自体は再開してるんですが、3ヶ月ほどデータが巻き戻ってしまいました。
参考として、あるいは備忘録として記事にまとめることにしました。
[Fediverse][Mastodon] Mastodonサーバの再建：v3.1.3版
RAILS
[Kubernetes][Migration][Mastodon] 実家サイトへMastodon環境を移転する
引っ越すことになりました
実は、今月の中旬あたりに引っ越すことになりました。理由としては、
- 私の体の不調で2Fより上のフロアへの移動が厳しく、1Fの部屋を探す必要があったこと
- 同様に体の不調で、風呂の出入りが厳しいことがあり(現住居の浴槽が昔ながらの底が深いタイプ)、今風の浅い浴槽がある部屋に住みたかった
- 現住居はペット入室厳禁物件であり、実家の親兄弟が愛犬を連れて遊びにこれない。その状況を緩和したかった
- そもそも、現住居が老朽化して壁紙が崩れてる状況にあり、生活上支障が生じていた
というところなんですが、それで部屋を決め、引っ越すことになったわけです。
[Linux][Mastodon][Virtualization] KubernetesインフラにMastodonエンジンを突っ込む
前提事項
ここで記載する内容なんですが、以下が前提になっています。
- 読む人はDockerやdocker-composeについてよく理解されている
- 読む人はKubernetes(k8s)についてよく理解されている
- Kubernetes(k8s)クラスタ及びネットワークコンポーネント(当環境ではProject Calico)、DBコンテナ環境やらRedisコンテナ環境やらはすでに出来上がっている
ちょっと期待はずれな内容かもしれませんので、先に記載しておきます。
今回やった事
ずばり、Mastodonエンジンのコンテナ化です。元々Mastodonはコンテナ構成のものも払い出されては居ますが、あくまでdocker-composeを前提としたものであり、Kubernetesのようなクラスタ構成を想定したものとはなっていません。
私自身、以前Dockerコンテナ型のインスタンスを立てて挫折した経験があるんですが、当時は全くコンテナ技術に対する知見がなく、理解しようとしても中々理解至るのに苦慮しましたが、今回自宅環境でKubernetesに手を出した、ということもあり、思い切ってやってみることにしました。
[Linux][Mastodon] カスタマイズしたMastodonインスタンスをバージョンアップする
カスタマイズしたMastodonインスタンスのバージョンアップは容易ではない
Mastodonインスタンスのバージョンアップ、純正品から一切のソースを弄ってない場合(通称「バニラ」と言われるみたい)は比較的手順は簡単で、参考情報として「さくらインターネットさんの情報」が役に立ちます。が、以下のようなカスタマイズを施している場合、そうは行かなくなります。
- ログイン画面の象さんロゴを変更した
- v2.0.0から登場したテーマ選択機能を実装し、カスタマイズテーマを適用した
- 過去投稿した「アカウント削除時の影響を緩和する手法」の様に、master適用外となったパッチを適用した
この時、単純にバージョンをあげようとすると以下のようなエラーが出ます。
$ git checkout v2.1.0rc3 error: Your local changes to the following files would be overwritten by checkout: config/locales/en.yml config/locales/ja.yml Please, commit your changes or stash them before you can switch branches. Aborting $ git merge v2.1.0rc3 error: Your local changes to the following files would be overwritten by merge: config/locales/en.yml config/locales/ja.yml Please, commit your changes or stash them before you can merge. Aborting
こんな風に、checkoutしようとしても、mergeしようとしてもカスタマイズしようとした箇所が競合し、適用ができませんで、どうしたもんかと悩みました。
「20171024][Mastodon] IPv6しか繋がらない、そんなインスタンスを作ってみる
はじめに
これまで、インスタンスづくりは外部のサイトを見様見真似で作ってきた経緯があり、今回も見様見真似で作ったものの、色々内容が整理できてきたこともあり、ブログに構築手順を書き起こしてみました。
※一部、手順を修正しました。具体的にはnodejsのインストール周りです。
先に言っとくんですが、あくまで備忘録として頭の中のものをExportしたものになります。本来はMastodonのProduction Guideを参照することが望ましいです。ただ、当該ドキュメントはubuntuベースとなっていて、当方のCentOSには合わないところもあったりするため、そこを補正する際にいろんなサイトをチラ見してます。
なので、正確性についてはどうぞご容赦賜りたく・・・(結局言いたい所はそれかというツッコミは勘弁を)
方針
とりあえず、こんな方針で作ってみることにしました。
- IPv6アドレスだけを受け付けるインスタンスを構築する
- サーバは自宅仮想基盤内にVMを構築し、それを使用する
- 2vCPU/2GB RAM/40GB VHD(SSDデータストア配置)のスペックで構築
- DNSに登録するレコードはAAAAレコードだけにする。IPv4アドレスは名前解決しない。
- あくまでIPv4はyumリポジトリやメール配送など、クライアント用途としてしか使用しない
- インスタンス名とサーバ名は異なるものとする。
- 当該インスタンスでは、サーバ名はsns-v6.bluecore.netと言う名称ですが、インスタンス名はまた別物(v6don.bluecore.net)です。
- OSはCentOS7の最新を使う(yum -y updateでコンポーネントを最新化する)
- インスタンスはオールインワン構成にする(AP/Redis/DBを同一サーバ内で構成する)
- 証明書はLet’s Encryptを使うことにする
- 設置セグメントは本番/ステージングインスタンスと同じところにする
- Dockerは使用しない
- 非Dockerの方がログが見やすいというのがあります。サービス監視も楽です。
- Dockerの構成も利点はあって、とっととイメージを組み込むことで、前提アプリケーション導入をバイパスできる点などが挙げられます。Linux不慣れな人はこちらが良いのかも。
- フィルタリングはサーバ側で行わずに、ゲートウェイ側のACLで行う
- メールサーバは本番/ステージングと同様に、内部メールサーバを経由する。
- メールは外向けに関しては【内部メールサーバ】⇒【メールゲートウェイ】⇒【インターネット】と言う経路で発送される。
