この記事は 一人アドベントカレンダー Advent Calendar 2018 22日目の記事です。国見小道のおひとりさまアドベントカレンダーではなく、ねそ氏 によるおひとりさまアドベントカレンダーです。このアドカレなんか新規登録できてるんやが!?!?
というわけで(?)お邪魔しまして、またMastodon構築記事を書きます。後日談のため、Mastodonサーバー管理者とか、ある程度掴み始めたMastodonインスタンス立てたいマンであれば楽しく読めるかと思います。
mstdn.komittee.net構築裏でローンチRTAをしていました。
ローカルタイムラインの仕組みに限界を感じていたため(インターネット蟹工船アドカレ記事参照)、おひとりさまインスタンス立ち上げるか~wとなった際、ついでだし時間計測してみっかwとなり(??)、勝手にRTAを開催しました。2018/05/27 ~ 2018/05/31 という期間でやってました。
記録は、103時間20分(4日と7時間20分)でした。Togglで計測した結果だと実作業時間は31時間でした。
nere9でのハッシュタグ から当時の苦悩を確認できます。
ねそ氏に無慈悲されました。
そんななか、横から抜き去っていく美少女を観測しました。
無慈悲されました。
そういうわけで、この記事はねそ氏アドベントカレンダー22日目なのです。
インフラに強ければ早く立ち上げられる
これについては 先日の記事でさんざん書きましたが、それを実証したことになりました。ねそ氏はMastodonサーバーを立てるのは2回めという話でしたが、GCPからConoHa VPSに移動しているのを見るとインフラ周りについて事情が変わっていたはずですが、結果として 3時間ほどでMastodonサーバーが立っている ので、なるほどインフラを制してれば丼鯖立つのは早いんやな、と。
ゴールテープを切りつつ遠のく背中を見ながら思いましたね…
ここから、自分がMastodonサーバーを立てるときに引っかかった点をざっくり書いていきます。
ドメイン周りで引っかかった
Mastodonは常時SSL化を強制させるソフトウェアです。それ自体は現在のWebの風潮から見て間違いはないかと思いますが、常時SSL化にはSSLサーバー証明書というものが必要になってきます。個人で適用する証明書はだいたいがドメイン認証による証明書ですが、このドメインに何を選ぶかで引っかかりました。
僕はメインドメインに komittee.net
を取得しましたが、ワイルドカード証明書 *.komittee.net
を当ててもサブドメインに適用されない場合があります。当てたい証明書のサブドメインが *.*.komittee.net
の場合です。このサブドメイン cdn.files.komittee.net
は画像をCDNに乗せて配信するために使ってますが、証明書が適用できず、RTAのあとで追加1日ほど悩みました。インフラに慣れてないってのはこういうことです。
ほかにも、Aレコード・Cレコード・AAAAレコードってなんぞやとか、DNS浸透いうなってなんやねんとか、2年目以降の費用でやすいのはどれやねんとPDF読み込んだりとかで、学習に時間がかかったのがドメイン周りでした。
ドメイン取得には時間がかかる
この認識がすっかり抜け落ちておりました。ローンチRTAをやるうえで、ドメインやメールサービス(SES)の稼働準備は済ませておくべきでした。
SSH接続の際にはtmuxなどを使おう
SSH接続をただやっていると不意に接続が切れる場合があります。そこからつなぎ直すのは割とロスですし集中力が途切れます。そのため、SSH接続したらtmuxなどその辺のあれそれを起動して、SSH先の作業としゃれこみましょう。
AWSならではのわかりにくさ
マニュアルがわかりづらい
AWS使ってる人は同意してくれると思うんですが、マニュアルがわかりづらいです。 書いてあることについて過不足なく丁寧に書いているとは思うんですが、やりたいことに一発でフィットしてくれるようなマニュアルではありませんでした。
これはAWSコンソールの「サービス一覧」にも言えることで、サービスそれぞれが具体的に何ができるのかいまいちつかめない感じがあります。これはエバンジェリストが動画での解説を頑張っているなどがありますが、使用例がたくさん閲覧できるようになると加速度的に世界が幸せになれるんじゃないかなと思います。
クラウド死のワナに要注意。料金設定の流し読み厳禁
AWSは、マニュアルのわかりづらさに引きずられて 料金体系もわかりづらいです。 これほんと何とかしてほしい。
EC2, RDS, ElastiCache, S3あたりがMastodon立てるときに使うサービスですが、従量課金の部分はまあ xxUSD/hour
で分かりますが、EC2で言えば ALB、ElasctiCacheで言えばリードレプリカなど、動くインスタンスが倍になる(値段も倍になる)設定がさらっと入っていたりだとか。
僕はALBとリードレプリカの罠に嵌りました。無料枠のお陰で1台分と変わらない金額だったため、なんとかなりました。これら以外にも色々罠があるんで、選択項目については逐一検索をかけて「自分が何をしようとしているのか」を把握しましょう。
VPCがいまだによくわかってない
構築時に取ったEvernoteに苦悩が残ってたのですが、VPC周りがすごく面倒くさいです。どの設定がどう影響するのか… その関係性がつかめておらず、いまだにdev環境作るときに手間取ってます。Cloud9をもっとサクサク使いたいんですがっ… !
mastodon:setupを一発で決めろ
これについても先日の記事でガっと書きました。このコマンドは2018/12現在のMastodonにおいて超重要なコマンドです。抜かりなく決めましょう。このコマンドさえ決まってしまえば、7割は構築できたも同じです。
ただし、 Mastodon構築1回目の人がこのコマンドを1発で決めるのは無理ゲー です。もし幸運にもインスタンスを立てる前に弊記事をご覧になってくれた人は、何を準備すれば1発で決めれるか、対話で聞かれた内容に対して何を入力すればいいのか、事前に調べましょう。(コードを読むしかないんだけどね…)
僕は当然ながらズブの素人だったため、このコマンドを何度も何度も走らせました。走らせるたびに10分、ひどい時は項目について何聞かれてるかわからなくて1時間ぐらいかかってました。 正直、質問が不親切とさえ思いました。「わざわざ別リポジトリでドキュメントを管理してるんだからソース見ずに建てられるやろw」という僕の思惑が見事に崩れ去りました。
「S3_HOSTNAMEってなに?」 「AWS_ACCESS_KEYってどこで確認できるの??」 「REDISのPASSWORDなんて設定してないんだけど???」 などなど。各項目についてはMastodonのInstallationガイドでそれぞれ明示してほしい気持ちがありました。正直。
幸い、やっていることは .env.production
の出力なので、コケても後でテキストエディタで項目を足しても対応できます。が、 db:setup
や assets:precompile
などMastodonの重要コマンドを飛ばしてしまうため、コケたら後で該当コマンドを打たないといけなくなるため、面倒になります。やはり、mastdon:setup
を抜かりなく決めることが重要だと思います。
Dockerはいいぞ
RTAをするうえで、サクっとサービスが動くようになるのはとても重要です。それには、Dockerが立役者になれます。サクっと立ち上げたくて、凝ったメンテナンスをしないというのであれば、Dockerを選ぶのがよいでしょう。
Railsのコマンドでコケた
いままで上げたものの中では小さなところですが、Railsのコマンドが不慣れで戸惑いました。あと、コマンドの打ち方がマニュアルと違っていたのですが、先行してアップデートしていたmonacaさんのトゥートに助けられました。 ありがとうございました。
おわりに
そんなこんなでMastodonローンチRTAには実作業時間31時間かかりました。営業日換算で丸4日かかってますね。まだまだです。それはそれとして、Mastodon構築したおかげでインフラには少し強くなることができたのと、AWSを触れたことで収入アップの種になったことがITエンジニア業を営む中ででかいなぁとしみじみ思っております。
次の23日目を担当するのはねそ氏ではなく、pepepperさんです。