RAM.と表示されていて丁寧だね......という気持ちになる*1。具体的にはヒープ領域が足りずNode.jsのプロセスがクラッシュする。ような形で指定することで回避できる。18環境かつメモリが少ない場合はsetupの際に以下のコマンドを発行すれば良い。mastodon:setupS3にオブジェクトを書き込むことができないこれはややひっかかった。bucketの中身はCloudFront経由で配信するので、bucketの設定でパブリックアクセスをすべてブロックしている。Mastodonの中でS3を操作するのに使っているPaperclipはデフォルトでpublic-readのパーミッションでオブジェクトを作成しにいこうとする。Forbiddenエラーが返ってきてしまう。これでオブジェクトを作れるようになる。実際にどういう通信をしているのかな〜と確認するのに以下のIssueコメントが役に立った。オプションとして渡すと通信の様子がログに出てくる。いうのをproductionにおもむろに差しこんで遊べるのはおひとりさまインスタンスのいいところだと思う。運用そんなに難しいことはしていない。ヘルスチェックと、アップデート戦略を決めるくらい。Mackerel導入Ubuntuなので公式の手順に則ってmackerel-agentをインストールしただけ。個人のSlackにmastodonチャンネルを作ってホストがreachableかどうかと、外形監視だけ通知するように仕込んだ。エンドポイントがあるのでこれを利用する。加えていくつかのミドルウェアのメトリックも取得することにした。PostgreSQLのメトリックも見たいけどなぜか設定してなかったのでこれはあとでやる。"mackerel-plugin-sidekiq"詳しくはこちらmackerel.ioしばらく見ている限りは1GBのメモリだと常時70%-90%くらい使っていて暇がない感じがする。普通に動いているので良いでしょうという感じ。だいたい30フォロー/フォロワーの規模感でこれなので、もっと増えたときにどうなるのかは分からない。アップデート戦略あんまり凝ったことはせず、ひとまず以下のようにした。アップデート情報をキャッチできるようにRSSを購読する週1でアップデートデーを設けて必要だったら更新するアップデート情報はRSSをSlackに流すようにした。都度SlackのIntegrationを変更するのは面倒なので、一旦大チェッカーで受けて、ひとつのフィードにまとめてからSlackに流すようにしている。daichkr.hatelabo.jpアップデートデーはTodoist上で管理していて、週1でリマインドされる。緊急性の高い更新がやってきた場合はアップデートデーによらず対応するつもりだけど、いまのところはNode.jsの軽微な更新しか来ていない。引っ越しもともと別のサーバにいたのでアカウントを引っ越した。Activityを利用した引っ越しの仕組みがあって、フォロワー側の実装がこれに対応している場合はそのフォロワーのフォロー先を強制的に新しいインスタンスに向けることができる。misskeyやgotosocial、Wildebeestなどでは現時点では対応しておらず、別途フォローをお願いすることになる。docs.joinmastodon.org投稿はエクスポートできるがインポートはできないので注意が必要。いまのところ流速がおだやかで平和〜という状態。APIの思い出いいネタで面白かった。APIとの思い出があるなと思ったので自分も書く。今のTwitterはOAuthでreadやwriteの権限をとってくるが、昔はもっと牧歌的でBASIC認証を利用してAPIにアクセスできた。当時書いたコードはもうどこにもないと思うけど、ちまちま情報を取得してうまく加工するツールみたいなのを作っていたと思う。そんな折にBASIC認証が廃止されると聞いて、めんどくさいなあと思った覚えがある。これが高校生くらいの頃で、OAuthなんて全然知らなかったので切り替わる時にドキュメントを全部印刷して読んでOAuthとはなんぞやを学んだ。当時はiPadが出たばかりでタブレット端末などは持っていなかったので、長い文章を読む時は家のレーザプリンタで印刷して読んでいたのだった。1.0aの書類がまだ実家に眠っているのではないか。ブルーPLUS(プラス)Amazon作ったものたちもうどれも動かないと思う。上から順に新しい(一番下が古い)。ふしぎなもので、この順番で思い入れが強まっていく。作った時期が大学生ごろに集中しているので、これは青春補正だろうなと思う。Shinagawa)のスタッフをやっていて、Twitterを監視してなにかあったらアクティブサポートする担当として動いていた。スマートフォンでツイートを監視したくて、TweetDeckでは間に合わなかったのでSlackで監視することにした。APIでなんとかしたいと思って、専用のデーモンみたいなやつを作った。便利だったけど用途が結構限定されるのでこれ以降使ってない。当時書いた紹介記事はこちら。owlproxy当時(今はどうか知らない)の夜フクロウはTwitter公式の画像アップローダに対応していなかった。任意のサードパーティ画像アップローダを指定する仕組みはあったため、ローカルにプロキシを立てて公式側にアップロードできるようにした。2015のLTで話した。飯テロ.inGyaPCの発表資料にもちょろっと書いた、Twitterアカウントでログインできるご飯画像アップローダ(閉鎖済、ドメインも手放し済)。通報機能が悪用されて画像が一つも無くなったりしたら嫌だなと思って、通報数で公開状態を制限するんじゃなくてTwitterでmentionをもらって自分の判断で公開停止する形にした。通報されたら手でMySQLのレコードに論理削除フラグを立てる仕組み。これまた牧歌的だったと思う。ぼくが恣意的にご飯画像かどうかを判断できるので微妙な仕組みではある。いまの時代に生まれていたら機械学習を学んでなんとかしていたと思う。ちなみにGIGAZINEで紹介されたことがある。GIGAZINEはいろいろあるけどこういう記事でもずっと残していて偉い。余談だけどこのブログのタイトルのせいで作者名をあんパンと勘違いされた状態で記事が出ていた。問い合わせて直してもらった。APIを扱えるようにするクライアントライブラリも自作していた。OSで動かすのに便利だった。これを作った当時、世の中の動向に疎すぎたのでnpmの存在を知らなかった。package.jsonもなにもなくて、当然依存モジュールは存在しないのでOAuth周りも全部自分で書いていた(正確にはsha1まわりのライブラリだけ他repoからもってきている)。Compilerを使っていた。5以前のコードなのでPromiseはPの字もなくcallbackでなんとかしていて涙ぐましい。自分の中では黒歴史的な存在だけど、書いてて楽しかったので思い入れはそこそこ強い。APIが廃止されたときだった。あれ以降、遊び場としてのTwitterは完全に面白みを失って興味がなくなったと思う。プラットフォームとしての興味もこのころからだんだん薄れていった。負荷をかけまくるユーザが減ったということでビジネス的には正しかったのかもしれない。いう話を来週くらいに書くであろう。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。