セルフホステッドランナーから GitHub ホストランナーへの移行

GitHub-ホスティッドランナーまたはセルフホステッドランナーでワークフローを実行することも、ランナーの種類を組み合わせて使用することもできます。

このチュートリアルでは、ランナーの現在の使用方法を評価し、セルフホステッドランナーから GitHubホストランナーにワークフローを効率的に移行する方法について説明します。

1. 現在の CI インフラストラクチャを評価する

セルフホステッドランナーから GitHubホスト型大規模ランナーへの移行は、現在の CI インフラストラクチャの徹底的な評価から始まります。仕様と環境を慎重に一致させるために時間がかかる場合は、さまざまなランナーでワークフローの実行を開始するときに問題の修正に費やされる時間を最小限に抑えることができます。

CPU コア、RAM、ストレージ、チップアーキテクチャ、オペレーティングシステムなど、ワークフローの実行に使用される各マシン仕様のインベントリを作成します。
ランナーのいずれかがランナーグループの一部であるか、ラベルを持っている場合に注意してください。この情報を使用して、新しいランナーへのワークフローの移行を簡略化できます。
ワークフローが依存するカスタムイメージとプレインストールされた依存関係を文書化します。これらは移行戦略に影響を与えます。
現在、セルフホステッドランナーを対象としているワークフローとその理由を特定します。たとえば、GitHub Actions 使用状況メトリックでは、[ ジョブ ] タブを使用し、ランナーラベル ( self-hosted やカスタムラベルなど) でフィルター処理して、そのラベルを使用しているリポジトリとジョブを確認します。特定のワークフローファイルを検証する必要がある場合は、コード検索を使用して、 runs-on: self-hosted またはその他のセルフホステッドラベルを参照するワークフローファイルを検索することもできます。
プライベートネットワークリソース (内部パッケージレジストリ、プライベート API、データベース、オンプレミスサービスなど) にアクセスするワークフローを特定します。これには、追加のネットワーク構成が必要になる場合があるためです。

2. 処理要件を GitHub ホストのランナータイプにマッピングする

GitHub は、GPU 対応マシンのオプションを備えた複数のオペレーティングシステム (Linux、Windows、macOS) でマネージドランナーを提供します。「ラージャーランナーリファレンス」を参照してください。

インベントリ内の各個別のマシン仕様を適切な GitHub-hosted runner 仕様にマップします。
セルフホステッドランナーで、適切な GitHub-hosted runner がないものをメモしておいてください。
セルフホステッドランナーで引き続き実行する必要があるワークフローを移行計画から除外します。

3. 容量要件の見積もり

GitHubホストランナーをプロビジョニングする前に、ワークフローに必要なコンピューティング容量を見積もります。現在のセルフホステッドランナーの使用状況を確認すると、適切なランナーサイズの選択、コンカレンシー制限の設定、潜在的なコスト変更の予測に役立ちます。

GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。
Organizationの名前をクリックしてください。
Organization 名の下にある [ Insights] をクリックします。
[Insights] ナビゲーションメニューで、[ アクションの利用状況メトリック] をクリックします。
表示するメトリックが含まれているタブをクリックします。「GitHub Actions のメトリックについて」を参照してください。

次のデータポイントを確認して、ホストランナーの容量を見積もってください。

     **合計消費時間 (分**): ベースライン コンピューティング需要を見積もるのに役立ちます。

     **ワークフロー実行の数**: より多くのコンカレンシーを必要とする可能性があるピーク アクティビティ時間を識別します。

     **OS の種類間でのジョブ配布**: Linux、Windows、macOS ランナーの適切な組み合わせを確実にプロビジョニングします。

     **ランナー ラベル ([ジョブ] タブ):** ランナー ラベルでフィルター処理して、ラベルが使用されている場所を理解します。

結果を容量計画に変換します。
- 必要に応じて、使用率の高いワークフローを大きなランナーサイズに一致させます。
- 事前構築済みイメージまたはカスタムイメージを利用して、ランタイムを削減できる可能性があるワークフローを特定します。
- 一般的に同時に実行されるジョブの数を決定して、コンカレンシーを見積もります。
ギャップを書き留めます。
- 現在ホストされているランナーイメージがサポートしていないハード依存関係を持つワークフロー。
- 異常に長い実行時間または特別な環境要件を持つジョブ。 (これらのカスタムイメージが必要な場合があります)。

容量計画では、プロビジョニングするランナーの数、使用するマシンの種類、および次の手順でランナーグループとポリシーを構成する方法について説明します。

4. ランナーグループとポリシーを構成する

容量のニーズを見積もったら、ランナーグループとアクセスポリシーを構成して、GitHubホストランナーを適切な組織やワークフローで使用できるようにします。

ランナーをプロビジョニングする前にランナーグループを構成すると、移行によって誤ってアクセスが広くなりすぎないようにしたり、予期しないコストの増加を引き起こしたりしないようにすることができます。

エンタープライズレベルでランナーグループを作成し、ホストランナーを使用できるユーザーを定義します。「より大きなランナーへのアクセスの制御」を参照してください。

ランナーグループを使用して、組織、リポジトリ、またはワークフローごとにアクセスのスコープを設定します。セルフホステッドランナーから移行する場合は、可能な場合は、既存のランナーグループ名またはラベルを再利用することを検討してください。これにより、GitHub-hosted runners に切り替えたときに、ワークフローを変更せずに作業を続行できます。
新しい GitHub-hosted runners を適切なグループに追加し、手順 3 で特定した使用パターンに基づいてコンカレンシー制限を設定します。自動スケーリングの詳細については、より大きなランナーを管理するを参照してください。
ポリシー設定を確認して、ランナーが目的のワークフローでのみ使用されていることを確認します。たとえば、特定のリポジトリへの使用を制限したり、信頼されていないワークフローがより強力なコンピューターの種類にアクセスできないようにしたりします。

メモ

macOS の大規模なランナーをランナーグループに追加することはできず、ワークフローファイル内で直接参照する必要があります。

5. GitHub-hosted ランナーをセットアップする

次に、前に特定したマシンの種類と容量に基づいて、GitHubホストランナーをプロビジョニングします。

ワークフローの要件に一致するマシンのサイズとオペレーティングシステムを選択します。使用可能なイメージと仕様については、 AUTOTITLE を参照してください。
各ランナーをランナーグループに割り当て、同時実行の制限を構成して、同時に実行できるジョブの数を制御します。
イメージの種類を選択します。
- 使用する GitHub マネージドイメージは、維持管理されており、頻繁に更新される環境を提供します。
- セットアップ時間を短縮するために、事前にインストールされた依存関係が必要な場合は、カスタムイメージを使用します。「カスタムイメージの使用」を参照してください。
環境変数、ソフトウェアのインストール、スタートアップスクリプトなど、必要なカスタマイズを適用します。その他の例については、 AUTOTITLE を参照してください。
必要に応じて、ランナーが内部リソースにアクセスする必要がある場合は、プライベートネットワークを構成します。「GitHubホストランナーを使用したプライベートネットワーク」を参照してください。

プライベート接続オプションを構成する

ワークフローでプライベートリソース (内部パッケージレジストリ、プライベート API、データベース、オンプレミスサービスなど) へのアクセスが必要な場合は、ネットワークとセキュリティの要件に合ったアプローチを選択します。

Azure プライベートネットワークを構成する

内部リソースへの安全なアクセスのために、Azure Virtual Network (VNET) 内で GitHub でホストされているランナーを実行します。

Azure Virtual Network (VNET) を作成し、ランナーのサブネットとネットワークセキュリティグループを構成します。
ランナーグループの Azure プライベートネットワークを有効にします。「GitHubホストランナーのプライベートネットワークを企業で構成する方法」を参照してください
NSG やファイアウォール規則などのネットワーク構成を適用して、イングレストラフィックとエグレストラフィックを制御します。
プライベートネットワーク用に構成されたランナーグループを使用するように、ワークフローターゲットを更新します。

詳細な手順については、以下を参照してください。

        [AUTOTITLE](/organizations/managing-organization-settings/configuring-private-networking-for-github-hosted-runners-in-your-organization)

        [AUTOTITLE](/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/configuring-private-networking-for-github-hosted-runners-in-your-enterprise)

WireGuard オーバーレイネットワークを使用して接続する

Azure プライベートネットワークが適用されない場合 (たとえば、ターゲットネットワークがオンプレミスまたは別のクラウドにあるため)、WireGuard などの VPN オーバーレイを使用して、プライベートリソースへのネットワークレベルのアクセスを提供できます。

詳細な手順と例については、 WireGuard を使用してネットワークオーバーレイを作成するを参照してください。

プライベートリソースへの信頼できるアクセスに API ゲートウェイで OIDC を使用する

ランナーがプライベートネットワークに参加する必要がない場合は、OIDC を使用して、API ゲートウェイ経由で公開するサービスへの信頼された有効期間の短いアクセスを確立できます。この方法により、有効期間の長いシークレットの必要性を減らし、ワークフローで必要な特定のエンドポイントへのネットワークアクセスを制限できます。

詳細な手順と例については、 OIDC とともに API ゲートウェイを使用するを参照してください。

6. 新しいランナーを使用するようにワークフローを更新する

GitHub-hosted runners が構成されたら、それらをターゲットにするようにワークフローファイルを更新します。

新しいランナーを、セルフホストランナーが使用していたのと同じ名前のランナーグループに割り当てた場合は、既存のラベルを再利用します。この場合、ワークフローは新しいランナーを変更せずに自動的に使用します。

新しいランナーグループまたはラベルを作成した場合は、ワークフロー YAML ファイルの実行フィールドを更新します。例えば次が挙げられます。

jobs:
  build:
    runs-on: [github-larger-runner, linux-x64]
    steps:
      - name: Checkout code
        uses: actions/checkout@v5
      - name: Build project
        run: make build

セルフホステッドラベル ( self-hosted、 linux-x64、カスタムラベルなど) へのハードコーディングされた参照を確認し、適切な GitHubホストランナーラベルに置き換えます。
更新された各ワークフローをテストして、新しいランナーで正しく実行されていることを確認します。環境の違いまたは不足している依存関係に関連する問題を監視します。

7. 未使用のセルフホステッドランナーを削除する

GitHub-hosted runners でワークフローが更新およびテストされたら、不要になったセルフホステッドランナーをすべて削除します。これにより、ジョブが誤って古いインフラストラクチャをターゲットにするのを防ぐことができます。「セルフホストランナーの削除」を参照してください。

セルフホステッドランナーを削除する前に、完全に移行されていることを確認します。

GitHub Actions 使用状況メトリックで、[ジョブ] タブを使用し、ランナーラベル (self-hosted やカスタムラベルなど) でフィルター処理して、リポジトリやジョブでセルフホステッドランナーがまだ使用されていないことを確認します。

セルフホステッド ランナーから GitHub ホストランナーへの移行

この記事で

セルフホステッドランナーから GitHub ホストランナーへの移行