erpc worker で、アプリが動いているかと時間課金の料金を確かめる
erpc worker status を実行すると、アプリが動いているかと 1 時間あたりの料金がわかります。何かを開始するときは、必ず先に料金が表示されます。やめるときは erpc worker delete --release-server を実行します。まずアプリが時間課金で使っている gRPC・Shreds・Unlimited RPC の利用が終了し、次に時間課金のサーバーの利用が終了します。このページは、プレリリースの ERPC CLI
v0.1.0-rc.4 について説明しています。アプリの状態を確かめる
status は、アプリがロックされているか動いているか、どのリリースか、いつからかを表示します。ログインしていれば、その環境の 1 時間あたりの料金も表示します。項目ごとにアカウントに課金されている料金が並び、アカウントのクレジットと、それがあとどれだけもつかも表示されます。--json では、同じ内容が hourly.charged に入ります。アカウントの課金の一覧に無い項目は、「一覧に無い」と表示され、「利用終了」とは呼ばれません。開始してから 1 分ほどは、その一覧に反映されていないことがあるためです。セッションが無いとき、またはアカウントの課金を読めないときは、
status は記録に残っている内容を表示します。アプリを操作する
アプリの
API_TOKEN はこのマシンで読み取られ、標準入力でサーバーに届きます。コマンドラインにもジャーナルにも残りません。ワーカーのコマンドはどれも --env <name>(既定は default)と --json を受け付けます。ただし secret unlock と secret lock は、アプリではなくこのマシンのキーストアを扱うので、--env を取りません。どこから実行しても、コマンドは erpc が覚えている名前でアプリを見つけます。ただし secret put、secret rm、key import、firewall allow、firewall deny は、--dir でしかアプリを指定できません。時間課金で払うときの流れ
- 何かを開始する前には、必ず料金が表示されます。 ターミナルでは「yes」と答えたときだけ開始します。
--yesを付けたときは、開始する物を指定したそのコマンドラインが「yes」の答えになります。 - 時間課金の商品は ERPC Credit から支払われます。 ERPC Credit は前もって購入しておくもので、クレジットで足りない開始は受け付けません。料金は料金表と ERPC Web Dashboard で確認できます。
- 新しい VPS は、名前が決まった時点で記録に残ります。 準備ができる前からです。次のデプロイは、もう 1 台を購入せずに、その VPS を使います。
deployでは、応答が無かった開始は、新しい開始としてではなく、同じものとして送り直されます。 その依頼のキーは記録に残る([env.<name>.starting])ので、同じコマンドをもう一度実行すると、同じ依頼が送られます。応答によっては、手で消すまでキーが残ります(erpc が記録できなかった購入)。erpc worker runは記録を残さないので、次の実行では新しい依頼になります。- デプロイは 1 つの環境ずつ行ってください。 同じ環境のデプロイを 2 つ同時に始めると、2 つ購入されることがあり、これはサポートしていません。
- 回線がまだ在るかどうかは、アカウントに何が課金されているかで決まります。 時間課金でない回線は、erpc が利用を終了することはありません。ダッシュボードで利用を終了してください。
アプリを削除する
erpc worker delete はワーカーを削除します。erpc worker delete --release-server は、さらにその回線の利用を終了し、続けて時間課金のサーバーの利用を終了します。利用を終了できなかった物は記録に残り、時間課金でない回線は、ダッシュボードで利用を終了するよう名前が表示されます。- オプションなしの削除は、購入したまま一度も接続していない VPS を受け付けません。課金されたまま、その VPS を忘れてしまうからです。接続したことのある時間課金の VPS をオプションなしで削除すると、課金が続いたまま記録から外れ、そのことを警告します。
--forgetは、もう接続できないサーバーに接続しないまま記録から外し、--forget-line <id>は、erpc の外で利用を終了した回線を記録から外します。
サーバーから RPC のレイテンシを測る
erpc worker bench は、その環境のサーバーから RPC 呼び出しの時間を測ります。ERPC の共有 RPC、Unlimited RPC、ほかの RPC を並べて比べられます。時間はサーバー上のエージェントが呼び出しごとに測るので、アプリが実際に受ける数字になります。bash
--methodにはgetSlot、getBlockHeight、getLatestBlockhash、getHealthを指定できます。--no-sharedで共有 RPC を外します。--urlの値には、URL そのもの、op://…・keychain:…・keystore:…の参照(キーの入った URL を保管した場所を指すもの。取引用の鍵のエントリを指すものは受け付けません)、または-(標準入力から読むか、画面に出さない入力で聞きます)を指定できます。エンドポイントが 6 つを超えると受け付けません。- 結果には、p50・p90・p99・最小・最大、失敗の数と最初の理由、そして同じ回の中で最も新しい答えから、それぞれの答えが何スロット遅れていたかが表示されます。
- 鍵は標準入力だけでサーバーに届き、表にはスキーム・ホスト・ポートだけが表示されます。
アプリの状態データをバックアップする
erpc worker backup on は、アプリの状態データを毎日 ERPC Global Storage にバックアップします。restic で暗号化し、サーバーの時刻で --at に指定した時刻から 30 分以内に実行します。ストレージのプランが必要です(erpc storage buy 5)。- バックアップされるのは、アプリの状態データ
/var/lib/private/erpc-worker-<id>です。リリースはデプロイで戻せるので含まれません。Redis と PostgreSQL のデータも対象外です。 - サーバーはスナップショットを削除できません。 erpc のセッションも、アカウントの管理用の鍵も、マスターパスワードも、サーバーは持たないからです。
- 乗っ取られたサーバーにできること: アカウントの中のすべてのマシンのスナップショットを読むこと(このマシンの分も含みます)。
offの後もリポジトリの鍵を持ち続けること(restic はこの鍵を変えません)。別のマシンの名前でスナップショットを足すこと(そのため、その後にrestore latestがどれを選ぶかを確かめてください)。アカウントのストレージを埋めて、すべてのマシンのバックアップを止めること。erpc worker backup offは、サーバーが応答するかどうかにかかわらず、まずサーバーのアクセスキーを無効にします。 - restic はワーカーが動いている間のファイルをそのままコピーします。 そのため、データベースを整合した状態で復元するには、データベース自身のダンプが要ることがあります。サーバーが止まっていて実行されなかった回は、サーバーが戻ったときに実行されます。
erpc worker backup off、status、nowは、それぞれバックアップを止め、状況を表示し、すぐに実行します。スナップショットはoffの後も残り、erpc backup prune --hostで古いものを間引けます。
このマシンで
erpc backup init を済ませてから、このマシンに復元します。bash
複数の環境とマシン
- 1 台のサーバーに置いた複数のワーカーは、それぞれ別のユニットとして動き、サーバーのファイアウォールの表を共有し、それぞれ自分のポートだけを開きます。
- 1 つのアプリに、複数の環境(
[env.staging]、[env.prod])を持たせられます。環境ごとに、サーバーと回線が別になります。 - 環境のサーバーの情報は、
erpc.tomlではなく 1Password に置けます。そうすると、その保管庫にログインしていてアプリのリポジトリを持つマシンなら、どれでもすべてのコマンドを実行できます。そのようなアプリにあるkeychain:とkeystore:の参照は、ほかのマシンからは読めないので、警告が出ます。erpc loginがセッションを 1Password に置いているときは、新しい環境の情報は 1Password に置かれます。deploy --vault <vault-id>で別の保管庫を指定でき、deploy --inlineで情報をerpc.tomlに置けます。






