Ubicloud から Latchkey への移行: 何が変わるか

Ubicloud も Latchkey も、1行の runs-on 変更でマネージド GitHub Actions ランナーを接続できるため、両者の切り替えは手間がかかりません。実際的な違いは、ジョブが一時的な理由で失敗したときに何が起きるかです。

Ubicloud のドキュメントによると、ubuntu-latest ラベルを ubicloud-standard-2 のような Ubicloud ラベルに変更することでランナーを採用します。Latchkey も同じ方法で動作します。1行の runs-on 変更で、YAML と actions はそのままです。したがって両者の移行はほぼラベルの変更です。異なるのは信頼性です。Latchkey は自己修復 CI を追加しており、一時的および機構的な失敗(メモリ不足による強制終了、ディスクフルエラー、レジストリのタイムアウト)を検出、修正、自動リトライし、赤いビルドを再実行する手間を残しません。移行時に実際に何が変わるかを以下に示します。

Ubicloud と Latchkey の概要比較

変わらないもの

• 切り替えは両プラットフォームで1行の runs-on 変更なので、ワークフロー、actions、YAML には手を触れません。
• どちらも標準の GitHub Actions ランナーを実行するため、actions/checkout、actions/cache、その他のステップは同じように動作します。
• どちらも GitHub ホストランナーより安価なので、コストを節約と引き換えにするのではなく、より安い2つの選択肢を比較していることになります。

Ubicloud が本当に得意なこと

Ubicloud はオープンソースのクラウドであり(そのランナースタックは GitHub 上のオープンソースプロジェクト ubicloud/ubicloud の一部です)、価格で積極的に競争しています。Ubicloud の料金ページによると、1分あたりで課金され、GitHub Actions と比べて大幅な節約を前面に打ち出しており、加えて少額の月次クレジットがあります。オープンソースのインフラと最も低い表示価格が最優先事項なら、それは本物で誠実な強みです。ベンダーの料金は変わるため、現在の Ubicloud の料金は同社のサイトで確認してください。

Latchkey が追加するもの

Latchkey は自己修復 CI を中心に構築されています。そのマネージドランナーでは、一時的および機構的な失敗が自動的に検出され、リトライされるため、再実行の費用を払うことも赤いビルドを見張ることもなくなります。また、パイプラインを高速化するために AI によるビルド最適化を適用し、GitHub Actions より1分あたり最大70%安く課金します。正直に言うべきトレードオフ: Latchkey はオープンソースではありません。オープンソースが必須要件なら、Ubicloud は Latchkey にはできない形でそのニーズを満たします。

移行の進め方

• すべてを一度に切り替えるのではなく、代表的なワークフローを1つ選んで試します。
• その runs-on ラベルを Ubicloud ラベルから ubuntu-latest に戻し、次に Latchkey ラベルに変更します。
• 自己修復が一時的な失敗を回復する様子を確認できるように、不安定だったブランチも含めて数回実行します。
• より多くのワークフローに展開する前に、請求額とグリーンビルド率を Ubicloud と比較します。

結論

オープンソースと最も低い表示価格が優先事項なら、Ubicloud は堅実な選択であり、そのまま使い続ける価値があります。実際の悩みが不安定な再実行であり、一時的な失敗から自力で回復するランナーが欲しいなら、Latchkey の方が適しています。どちらも1行の変更で済むため、単一のワークフローで Latchkey を試し、判断する前に実際の Ubicloud ビルドと比較できます。

よくある質問

関連ガイド