以前に堅牢なデータ保管用BDを作成する手法を考えたのですが、この手法で書き込んだディスクはマウント方法が煩雑。で、もっと良い手法で書き込みが可能だったのでやり方を記しておきます。
少し前にMateChaが死んで、モバイルでTwitterを読み書きするには別の方法が必要になった。まぁオフィシャルなアプリを入れるなりウェブアクセスでやるなり方法は色々あるんだろうけど、そもそもTwitterアレだしなーと思ってなんか別のやつを使おうかな、という判断をした。
で、NostrやBlueskyみたいなのが色々出てきてはいるけどああいうのってiPhone限定でしょ?という雑な理解をしていたり、そもそも招待状要るらしいし……ってんで順当にMastodonのようなActivityPubを喋るやつにしよう、それも出来れば自分用のサーバを立てよう、という方針に決定。
方針が決まったので次は使用するサーバソフトウェアを決める必要がある。以下の観点で検討を行った。
これらの条件に合致しそうな実装をいくつか評価した。
以下の構成でデプロイした。特に変わった点はない。
収容人数は最大でも数名の予定なのでRDBはSQLiteで十分と判断。LitestreamでCloud Storageへレプリケーションして最低限の冗長性を確保する。手癖でnginxを前段に置いてcertbotで証明書を取るようにしたけど、GoToSocialは組み込みの証明書取得機能があるのでそれを使ったほうが楽そう。
良かったらフォローしてみて下さい。
2023/10/21追記: Pleromaに移行しました↓
tl1.yumenosora.net
創作物を一斉に一定期間匿名で公開し、期間終了後に作者名を公開するというイベントがあります。このイベント用のいわゆるアップローダに類するサービスを開発しました。
従来の手法(IaaS上のLinux VMにRailsで構築したアプリケーションを走らせるやり方)と記述量はさほど変わらないという印象。バックエンドとしてFirestoreを使おうが、Postgresを読み書きするRails実装のバックエンドを置こうが、大部分の処理はブラウザ上のReact実装というのであれば、その差は微々たるものなのかもしれず。ただし許容トラフィック量を考えれば圧倒的に有利なはず。従来手法で同等の性能を出そうとするとかなりの追加作業と運用コストがかかるのではないかと。
リリースとロールバックが簡単なのは便利。小規模個人プロジェクトでは持て余すものの、A/Bテストやらcanary releaseなんかがコンソールから簡単に出来るのも便利そう。
*1:イベントが開催されたら
ブロックチェーンを使って遊休ストレージを共有する仕組みを作っているStorj Labsという会社が、Google Cloud Storageのようなオブジェクトストレージサービス"Tardigrade"をリリースしました。
100GBで月1USDと安価く、法定通貨で請求されるから仮想通貨にまつわる面倒事*1も無いのでなかなか良さそう。なお、ingressは無料でegressは1GB辺り$0.045、最初の5GBは無料。また、サポートに連絡するまで5GBの制限があります。
実際に試してみました。
まずhttps://tardigrade.io/に行き、Get Startedからユーザ登録をします。実際に使う場所から近いリージョンが良いでしょう。そしてプロジェクトを作成します。
プロジェクトが出来たら、クライアントをインストールしましょう。
$ cd ~/Downloads $ curl -L https://github.com/storj/storj/releases/latest/download/uplink_linux_amd64.zip -o uplink_linux_amd64.zip $ unzip -o uplink_linux_amd64.zip $ chmod 755 uplink $ sudo mv uplink /usr/local/bin/uplink $ which uplink /usr/local/bin/uplink
プロジェクトページからAPIキーを発行して、uplink CLIに投入。同時にアップロードするファイルの暗号化パスフレーズも要求されるので投入しましょう。
$ uplink setup
バケットを作成してやれば準備完了です。
$ uplink mb sj://hoge
ファイルをアップロードしてみましょう。
$ uplink cp /path/to/file sj://hoge
標準入力からアップロードするならこう。tarで固めつつアップロードするなんかに重宝するかと。
$ echo 'hogehoge' | uplink put sj://hoge/stdin.txt
取り出しもuplink cpで行えます。標準出力に吐かせるならput。
$ uplink cp sj://hoge/file /path/to $ uplink put sj://hoge/file
Uplink S3 Gatewayを使えばAmazon S3互換のAPIが使えるので、S3対応のアプリケーションのストレージをすげ替えて使うのも出来そう。
*1:確定申告とか
— 殊海夕音 (@yune_kotomi) 2019年5月7日
機内ドリンクサービスのスープ、ANAのはネスレでJALのは明治という知識を得た。
— 殊海夕音 (@yune_kotomi) 2018年6月6日
ちなみにAIRDOのは(株)グリーンズ北見である。
ログ管理やアラートメール送信って邪魔くさくないですか？ElasticSearchやKibanaなんかで作る今時のログサーバがあると便利だろうけど、小規模サービスにはオーバースペックだし、メールを使わないサービスなのにわざわざメールサーバ用意してアラートメール送信できるようにするのも本末転倒な気がする。単純な送信ロジックだと、似たようなアラートが大量に出るとメールボムになるから、案外気を使うところも多い。
そこでカケラの樹では、Stackdriverを使ってみることに。
Railsアプリケーションの場合、最低限Gemfileでstackdriver gemを追加するだけで動作する。設定項目は次のドキュメントを参考に。
googleapis.dev
カケラの樹での変更は以下のコミットのとおり。
gitlab.com
config.google_cloud.logging.log_nameに日本語を入れるとログ収集が行われなくなったので、アルファベットにしておいたほうが良さそう。
他にも色々機能があるが、とりあえず簡単に使えるものをいくつか。
GCPのコンソールからLoggingを開くと、ログがブラウザから閲覧できる。検索も可能。
アラートが発生すると通知される。デフォルトではGCPのモバイルアプリへのプッシュ通知が送信される。メールを受信したい場合、コンソール右上の設定を開き、Stackdriver Error Reportingのメールアドレスの項目にチェックを入れる。
類似した例外が複数発生した場合、勝手にまとめてくれる。
画面上から指定した位置での呼び出し履歴を調べたり、変数の値のウォッチが出来る。本番環境で実行中のインスタンスを観察できるのでこれは便利。
ウォッチ式等の副作用でアプリケーションの動作が変わるのを防ぐ仕組みが入っていてかなり厳しいので、誤検知の場合は式全体をGoogle::Cloud::Debugger.allow_mutating_methods!で囲んでやるとよい。
手元の端末でcanonical-livepatchが動いてるのを見て、そういえば3台までいけるんだからサーバでも使おうか、と思った。
$ uname -a Linux yumenosora 4.15.0-1024-gcp #25~16.04.2-Ubuntu SMP Tue Oct 30 14:14:10 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux $ sudo snap install canonical-livepatch canonical-livepatch 8.0.6 from 'canonical' installed $ sudo canonical-livepatch enable [トークン] 2018/11/19 14:20:31 cannot use livepatch: your kernel "4.15.0-1024-gcp" is not eligible for livepatch updates
にゃうーん。Compute Engine上では専用のカーネルが使われるけど、ソレにライブパッチは使えない、みたい。残念。
