No.31
ActivityPub Relayチャレンジ2回目
S.H.さん（ @S_H_@gamelinks007.net )が、うまくすれば月550円からリレーサーバが運用できるかも、ということで作成されたActivityPub Relayのデプロイに挑戦した、 #わーさんがやってみた シリーズ2回目の記事です。
話題にしているActivityPub Relayのソースコードはこちら。
https://github.com/S-H-GAMELINKS/activity-pub-relay
そして、デプロイするまでの初回記事はこちらです。
デプロイ後の初期設定
なんと、VPSにログインしにいくことなく、手元のPCでできてしまいます。
自分のPCのactivity-pub-relayディレクトリ内で以下のコマンドを使用しましょう。
kamal console
なんと、これでVPS側のRailsのアプリケーションのコンソールを起動できるそうです。
実際、何やら実行結果が流れた後に、コマンドが打てるようになります。
初期設定としては、メールアドレスとパスワードが必要です。
実際は、それぞれ自分のメールやパスワードを使用してください。
User.create!(email_address: "relay@example,com", password: "relay_example_password")
入力時は、このメールアドレスとパスワードをそれぞれ囲っている記号に十分注意してください。
似たような記号がありますが、間違えるとこんな感じでエラーになります。
(activity-pub-relay):1: syntax error, unexpected instance variable, expecting `do' or '{' or '(' (SyntaxError)
うまく設定できれば https:// <リレーサーバのドメイン> /session/new にてログインできるようになりますので、ブラウザからログインに行きます。
ダッシュボードに接続されれば、初期設定はできています。
kamal consoleの終わらせ方
わーさんはコントロールキー+Dにて終わらせました。
exitと打ってエンターキーでも終了できるそうです。
初期設定後の操作
リレーへのサーバーの追加・強制脱退方法
参加させたいサーバーのコントロールパネルにてリレーの設定項目に https:// <リレーサーバのドメイン> /inbox を追加すると、自動的にリレーに参加していきます。
v0.3.0では、ダッシュボードからSubscribe serversというリンクを辿れば、参加サーバーの一覧が確認できます。
サーバー名をクリックすることで、強制脱退や情報の再取得が可能なメニューにアクセスできます。
ジョブキューの確認方法
v0.3.0では、ダッシュボードからjob dashboardのリンクを辿れば閲覧できます。
なんと、このリレーサーバー、終わったジョブをデータベースから定期的に自分で削除する機能があり、つまりその分データベースの肥大化が抑えられるというエコ仕様。
うまくすれば月550円（KAGOYAさんの最小プラン）からリレーサーバが運用できるかも、というのはつまりそういうことのようです。
サーバーのアプデ
v0.3.0以降にデプロイされたサーバーであれば、基本的にタグに追従し、環境をアプデしていけば良さそうです。
以下、手元のPCにて行いましょう。
⓪Rubyのバージョンアップ（必要時）
rbenv install ＜バージョン数字＞
rbenv global ＜バージョン数字＞
①更新内容の確認とソース変更
cd activity-pub-relay
git fetch --tags
git checkout ＜新しいタグ＞
補足：gitがdetached HEADの状態であるというコメントについて
（『さばかんライフ！』原稿から、多少の文言を今回の仕様に合わせて変更しています。本文のノリを確認したいあなたにも！）
gitというシステムを使うことでプログラムなどのバージョン管理ができますが、例えば同じプログラムで安定版と開発版を並行して取り扱いたいときに、ブランチという仕組みで枝分かれさせて管理していることが多いです。
もしプログラムの開発に関わっている場合は、このブランチを追いかけて、変更を取り入れたり提案したりします。
一方で、タグという、ここでバージョンを分けるよ！という目印となる仕組みもあり、今回はMastodonなどと同様に、このタグのついたまさにその瞬間のプログラムを自分のPCに引っ張ってきて更新するようなコマンドを採用しています（ `git checkout ＜新しいタグ＞` 、が該当コマンドで、これを実行したらソースが置き換わっています）。
このコマンドの中には、どのブランチを追いかける、という情報は含まれていません。
ブランチを追いかけずに特定のバージョンだけをピンポイントで更新すると、その後、そのバージョンに変更を加えても、提案する先の情報がなく、変更の提案ができません。よって、gitから、ブランチの情報がないよ！とコメントが出されます。これがdetached HEADの正体です。
無改造の場合は、公式にタグで指定された更新を追いかけるだけで問題ないと思われますので、コメントが出てもスルーしました。
②Rubyパッケージアップデート
bundle install
③VPSへの転送
kamal deploy
S.H.さん（ @S_H_@gamelinks007.net )が、うまくすれば月550円からリレーサーバが運用できるかも、ということで作成されたActivityPub Relayのデプロイに挑戦した、 #わーさんがやってみた シリーズ2回目の記事です。
話題にしているActivityPub Relayのソースコードはこちら。
https://github.com/S-H-GAMELINKS/activity-pub-relay
そして、デプロイするまでの初回記事はこちらです。
デプロイ後の初期設定
なんと、VPSにログインしにいくことなく、手元のPCでできてしまいます。
自分のPCのactivity-pub-relayディレクトリ内で以下のコマンドを使用しましょう。
kamal console
なんと、これでVPS側のRailsのアプリケーションのコンソールを起動できるそうです。
実際、何やら実行結果が流れた後に、コマンドが打てるようになります。
初期設定としては、メールアドレスとパスワードが必要です。
実際は、それぞれ自分のメールやパスワードを使用してください。
User.create!(email_address: "relay@example,com", password: "relay_example_password")
入力時は、このメールアドレスとパスワードをそれぞれ囲っている記号に十分注意してください。
似たような記号がありますが、間違えるとこんな感じでエラーになります。
(activity-pub-relay):1: syntax error, unexpected instance variable, expecting `do' or '{' or '(' (SyntaxError)
うまく設定できれば https:// <リレーサーバのドメイン> /session/new にてログインできるようになりますので、ブラウザからログインに行きます。
ダッシュボードに接続されれば、初期設定はできています。
kamal consoleの終わらせ方
わーさんはコントロールキー+Dにて終わらせました。
exitと打ってエンターキーでも終了できるそうです。
初期設定後の操作
リレーへのサーバーの追加・強制脱退方法
参加させたいサーバーのコントロールパネルにてリレーの設定項目に https:// <リレーサーバのドメイン> /inbox を追加すると、自動的にリレーに参加していきます。
v0.3.0では、ダッシュボードからSubscribe serversというリンクを辿れば、参加サーバーの一覧が確認できます。
サーバー名をクリックすることで、強制脱退や情報の再取得が可能なメニューにアクセスできます。
ジョブキューの確認方法
v0.3.0では、ダッシュボードからjob dashboardのリンクを辿れば閲覧できます。
なんと、このリレーサーバー、終わったジョブをデータベースから定期的に自分で削除する機能があり、つまりその分データベースの肥大化が抑えられるというエコ仕様。
うまくすれば月550円（KAGOYAさんの最小プラン）からリレーサーバが運用できるかも、というのはつまりそういうことのようです。
サーバーのアプデ
v0.3.0以降にデプロイされたサーバーであれば、基本的にタグに追従し、環境をアプデしていけば良さそうです。
以下、手元のPCにて行いましょう。
⓪Rubyのバージョンアップ（必要時）
rbenv install ＜バージョン数字＞
rbenv global ＜バージョン数字＞
①更新内容の確認とソース変更
cd activity-pub-relay
git fetch --tags
git checkout ＜新しいタグ＞
補足：gitがdetached HEADの状態であるというコメントについて
（『さばかんライフ！』原稿から、多少の文言を今回の仕様に合わせて変更しています。本文のノリを確認したいあなたにも！）
gitというシステムを使うことでプログラムなどのバージョン管理ができますが、例えば同じプログラムで安定版と開発版を並行して取り扱いたいときに、ブランチという仕組みで枝分かれさせて管理していることが多いです。
もしプログラムの開発に関わっている場合は、このブランチを追いかけて、変更を取り入れたり提案したりします。
一方で、タグという、ここでバージョンを分けるよ！という目印となる仕組みもあり、今回はMastodonなどと同様に、このタグのついたまさにその瞬間のプログラムを自分のPCに引っ張ってきて更新するようなコマンドを採用しています（ `git checkout ＜新しいタグ＞` 、が該当コマンドで、これを実行したらソースが置き換わっています）。
このコマンドの中には、どのブランチを追いかける、という情報は含まれていません。
ブランチを追いかけずに特定のバージョンだけをピンポイントで更新すると、その後、そのバージョンに変更を加えても、提案する先の情報がなく、変更の提案ができません。よって、gitから、ブランチの情報がないよ！とコメントが出されます。これがdetached HEADの正体です。
無改造の場合は、公式にタグで指定された更新を追いかけるだけで問題ないと思われますので、コメントが出てもスルーしました。
②Rubyパッケージアップデート
bundle install
③VPSへの転送
kamal deploy
- ユーザ「和条門 尚樹」の投稿だけを見る (※時系列順で見る)
- この投稿と同じカテゴリに属する投稿：
- この投稿日時に関連する投稿：
- この投稿に隣接する前後3件ずつをまとめて見る
- この投稿を再編集または削除する
