セルフホスト型Gitランナーを開発者の日々のワークフローに取り入れると、何が変わるのでしょうか？

セルフホスト型Git Runnerが日々のワークフローに組み込まれると、本番環境の依存要素になります。開発者はそのキュー、ツールチェーン、ネットワークアクセス、シークレット、キャッシュ、復旧時間に依存するようになります。

したがって、構成では制御と実行を分離し、ジョブを使い捨て可能にし、意図的に共有する状態だけを保持する必要があります。高速な永続Runnerは便利ですが、見えない構成のずれや広範な権限を持つ認証情報によって、その利便性が脆弱な信頼境界になりかねません。

Runnerをリモートコード実行環境として扱う

受け付けたジョブはすべて、所有するインフラ上でリポジトリが制御するコードを実行します。デプロイ用やパッケージ用の認証情報を付与する前に、どのリポジトリ、ブランチ、コントリビューター、プルリクエストイベントがRunnerを利用できるかを定めます。

マイクロVMベースのRunner設計では、ジョブごとに使い捨ての仮想マシンを使用し、セルフホスト環境のパフォーマンスを維持しながら、次のジョブに引き継がれる状態を減らします。

信頼されたリリースジョブと通常のテストには、別々のRunnerグループを使用します。公開リポジトリやフォークから起動したワークフローを、本番デプロイ用シークレットを持つ実行環境と共有してはいけません。

高速な1台のマシンからキューの運用ルールへ移行する

日常的に使われるようになると、ジョブの開始時間、同時実行数、キャンセル、優先度に対する期待が生まれます。キューの待ち時間とジョブの実行時間は別々に計測し、テストが遅いのかRunnerの容量が不足しているのかを混同しないようにします。

同時ビルドによってメモリ、ストレージ、Dockerイメージの取得が飽和する手前に、同時実行数を設定します。長時間のテストマトリクスの後回しにできない場合は、対話型ジョブやリリースジョブ用の容量を確保します。

Runnerがオフラインのときの開発者向け代替手段を文書化します。ホスト型実行、ローカルコマンド、または遅延可能な非クリティカルジョブなどです。代替手段がなければ、メンテナンスが予定外の開発停止につながります。

再構築可能なキャッシュと永続状態を分離する

キャッシュは日々の作業を効率化しますが、サイズ上限、所有者、削除ルールが必要です。ビルド成果物とリリースの証跡は、保持期間が明確な外部の保存先に置き、無制限に拡大するワークスペースフォルダーには保存しないでください。

イメージまたはプロビジョニングスクリプトからランナーを置き換えられるようにしてください。ホストの再構築で唯一の署名キーやテスト結果が失われるなら、それらの資産は誤った役割の場所に保存されています。

Featured

ZimaBoard 2 - 大きなアイデアを実現するミニホームサーバー

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

パッチ適用、可観測性、障害時の責任者を決める

ランナーのバージョン、OSのパッチ、Dockerやツールチェーンのバージョン、ディスク使用量、ジョブの失敗率、キューの待ち時間、キャッシュの増加量を追跡してください。ランナーが個人用サーバーであっても、メンテナンス時間帯と担当者をそれぞれ1つ決めましょう。

実証的なワークフロー保守の研究では、自動化そのものが継続的なバグ修正やCIの改善作業を生むことがわかりました。セルフホスティングでは、ホストのライフサイクルもその保守負担に加わります。

オフライン状態、繰り返し発生するジョブの失敗、ディスク容量不足、通常より長いキューに対してアラートを設定してください。ログから、リポジトリのコード、ランナーイメージ、ネットワークアクセス、ホストのどれが原因で失敗したかを特定できる必要があります。

日常のワークフロー準備状況をテストする

ランナーを再構築し、デプロイ用認証情報をローテーションし、2つのビルドを同時に実行し、キャッシュをいっぱいにしてから削除し、ジョブの実行中にホストを意図的にオフラインにしてください。開発者が障害を確認でき、代替経路を利用できることを確かめましょう。

ダウンタイムが許容され、ジョブが信頼できる場合は、ランナーを1台のホストに置きましょう。認証情報やメンテナンス時間帯を分ける必要がある場合は、リリース用、信頼されていないワークロード用、ハードウェア固有のワークロード用に分離してください。ホームサーバーOSガイドを参考に、ランナーのホストを定期的なアップデートと復旧に適したものにしましょう。

ジョブの失敗によってリリースや顧客対応の作業が滞るようになったら、ランナーを趣味のサービスとして扱うのはやめましょう。その段階では、ほかの開発依存関係と同じように、サービスの所有者、予備容量、テスト済みの代替手段を定めてください。

セットアップの最終ルール

すべてのサービスに明確な役割があり、状態が保護され、アクセス経路が制御され、復元がテスト済みで、トポロジーの分割や拡張を判断する測定可能な基準があれば、セットアップは合格です。