セルフホストgithubランナー
CIおよびビルドランナー
ホスト型CI分は従量制で、キュー待ちが発生し、低速です。チームが生産的になるとコスト曲線は急激に悪化します。専用コアのインスタンス2台と高速NVMeは、ほとんどのホスト型ティアを上回るビルド能力を発揮し、プッシュ頻度に関係なく月額固定費です。ネストされた仮想化も含まれているため、Docker-in-DockerやKVMベースのテストスイートを回避策なしで実行できます。
この構成の理由
TORQUEがコア数を提供し、Gen5 NVMeがアーティファクトのスループットを提供し、ネストされた仮想化は無料です。フォージにランナーを登録し、ホスト型プランを解約してください。
当社がデプロイする構成
サイジング
並行ジョブあたり専用コア2つと4GBが下限です。コンパイル言語では4コアと8GBが必要です。したがって32コアのTORQUEノードは、32ではなく8つの重いジョブまたは約14の軽いジョブを実行します。スクラッチディスクはどちらよりも重要です。並行ジョブあたり30〜50GBをNVMe上に用意し、イメージレイヤー、依存関係ツリー、ビルド出力に使用します。ジョブがネストされた仮想化を必要とする場合は、ノードあたり1コア追加してください。ノードを追加するタイミングは、ジョブの所要時間ではなく、キューの待ち時間で判断します。
ネストされた仮想化と、それがいつ必要か
ほとんどのCIはコンテナで正常に動作します。ゲスト内で実際のハイパーバイザーが必要なケースは3つあります。VMイメージとcloud-initのテスト、KVMアクセラレーションを使用したAndroidまたは組み込みエミュレーターの実行、そして信頼できないプルリクエストがランナーに到達してはならないコードを実行するジョブです。TORQUEはゲストにSVMを公開するため、VPS内でKVMが動作し、エミュレーターはソフトウェアエミュレーションではなくネイティブ速度で実行されます。これはAndroidテストスイートで約1桁の差があります。コストは、外側のハイパーバイザーに1コア、内側のゲストでディスクがわずかに遅くなることです。両方を予算に組み込んでください。
アーティファクトパスが通常ボトルネック
遅いパイプラインをプロファイリングすると、コンパイルステップが最大のバーになることはめったにありません。ベースイメージのプル、キャッシュの復元、アーティファクトのアップロード、結果のプッシュが、一般的なビルドの壁時計時間の大部分を占めます。リターンの順に3つの修正：同じプライベートVLANにレジストリプルスルーキャッシュを置き、レイヤーがパブリックインターネットではなくローカルネットワーク経由で到着するようにします。スクラッチをNVMeに置き、レイヤー展開がシークバインドされないようにします。キャッシュキーを正確にし、モノリシックなアーカイブではなく必要なものを復元します。高密度のBergamoコアは安価です。ネットワークを待つことはそうではありません。
問題点
- Docker-in-Docker用にoverlayfsをoverlayfsに重ねる。ネストされたoverlayドライバーは低速で、レイヤーが破損することがあります。ジョブ内で専用ブロックデバイスを使用するか、代わりにネストされたKVM上でビルダーを実行してください。
- クリーンアップをしない。ぶら下がったイメージ、ビルドキャッシュ、古いボリュームは数週間でスクラッチNVMeを満たし、最初の症状は1年間正常に動作していたステップでビルドが失敗することです。失敗時ではなく、タイマーでクリーンアップしてください。
- キャッシュ転送がビルド時間を超えることを許す。ジョブごとにプル/プッシュされる3GBの依存関係キャッシュは、ゼロからコンパイルするよりコストがかかる可能性があります。両方を測定し、キャッシュをランナーと同じプライベートVLANに置いてください。
マシンを調整
- その他 — Nested virtualisation (VMX/SVM) · 含む
- CPUスケジューリング — Pinned physical cores · €9
- ストレージと暗号化 — ZFS with hourly snapshots · €7