# セルフホステッド ランナーから GitHub ホストランナーへの移行 現在の CI インフラストラクチャを評価し、セルフホステッド ランナーから GitHubホストランナーにワークフローを移行する方法について説明します。 GitHub-ホスティッドランナーまたはセルフホステッドランナーでワークフローを実行することも、ランナーの種類を組み合わせて使用することもできます。 このチュートリアルでは、ランナーの現在の使用方法を評価し、セルフホステッド ランナーから GitHubホストランナーにワークフローを効率的に移行する方法について説明します。 ## 1. 現在の CI インフラストラクチャを評価する セルフホステッド ランナーから GitHubホスト型大規模ランナーへの移行は、現在の CI インフラストラクチャの徹底的な評価から始まります。 仕様と環境を慎重に一致させるために時間がかかる場合は、さまざまなランナーでワークフローの実行を開始するときに問題の修正に費やされる時間を最小限に抑えることができます。 1. CPU コア、RAM、ストレージ、チップ アーキテクチャ、オペレーティング システムなど、ワークフローの実行に使用される各マシン仕様のインベントリを作成します。 2. ランナーのいずれかがランナー グループの一部であるか、ラベルを持っている場合に注意してください。 この情報を使用して、新しいランナーへのワークフローの移行を簡略化できます。 3. ワークフローが依存するカスタム イメージとプレインストールされた依存関係を文書化します。これらは移行戦略に影響を与えます。 4. 現在、セルフホステッド ランナーを対象としているワークフローとその理由を特定します。 たとえば、GitHub Actions 使用状況メトリックでは、\[ **ジョブ** ] タブを使用し、ランナー ラベル ( `self-hosted` やカスタム ラベルなど) でフィルター処理して、そのラベルを使用しているリポジトリとジョブを確認します。 特定のワークフロー ファイルを検証する必要がある場合は、コード検索を使用して、 `runs-on: self-hosted` またはその他のセルフホステッド ラベルを参照するワークフロー ファイルを検索することもできます。 5. プライベート ネットワーク リソース (内部パッケージ レジストリ、プライベート API、データベース、オンプレミス サービスなど) にアクセスするワークフローを特定します。これには、追加のネットワーク構成が必要になる場合があるためです。 ## 2. 処理要件を GitHub ホストのランナータイプにマッピングする GitHub は、GPU 対応マシンのオプションを備えた複数のオペレーティング システム (Linux、Windows、macOS) でマネージド ランナーを提供します。 「[ラージャー ランナー リファレンス](/ja/actions/reference/runners/larger-runners)」を参照してください。 1. インベントリ内の各個別のマシン仕様を適切な GitHub-hosted runner 仕様にマップします。 2. セルフホステッド ランナーで、適切な GitHub-hosted runner がないものをメモしておいてください。 3. セルフホステッド ランナーで引き続き実行する必要があるワークフローを移行計画から除外します。 ## 3. 容量要件の見積もり GitHubホストランナーをプロビジョニングする前に、ワークフローに必要なコンピューティング容量を見積もります。 現在のセルフホステッド ランナーの使用状況を確認すると、適切なランナー サイズの選択、コンカレンシー制限の設定、潜在的なコスト変更の予測に役立ちます。 1. GitHub の右上隅にあるプロフィール画像をクリックしてから、**\[ Your organizations]** をクリックします。 2. Organizationの名前をクリックしてください。 3. Organization 名の下にある **\[ Insights]** をクリックします。 ![組織の水平ナビゲーション バーのスクリーンショット。 グラフ アイコンと \[分析情報\] というラベルのタブが、濃いオレンジ色の枠線で強調されています。](/assets/images/help/organizations/org-nav-insights-tab.png) 4. \[Insights] ナビゲーション メニューで、\[ **アクションの利用状況メトリック**] をクリックします。 5. 表示するメトリックが含まれているタブをクリックします。 「[GitHub Actions のメトリックについて](/ja/actions/concepts/metrics)」を参照してください。 6. 次のデータ ポイントを確認して、ホストランナーの容量を見積もってください。 * **合計消費時間 (分**): ベースライン コンピューティング需要を見積もるのに役立ちます。 * **ワークフロー実行の数**: より多くのコンカレンシーを必要とする可能性があるピーク アクティビティ時間を識別します。 * **OS の種類間でのジョブ配布**: Linux、Windows、macOS ランナーの適切な組み合わせを確実にプロビジョニングします。 * **ランナー ラベル (\[ジョブ] タブ):** ランナー ラベルでフィルター処理して、ラベルが使用されている場所を理解します。 7. 結果を容量計画に変換します。 * 必要に応じて、使用率の高いワークフローを大きなランナー サイズに一致させます。 * 事前構築済みイメージまたはカスタム イメージを利用して、ランタイムを削減できる可能性があるワークフローを特定します。 * 一般的に同時に実行されるジョブの数を決定して、コンカレンシーを見積もります。 8. ギャップを書き留めます。 * 現在ホストされているランナー イメージがサポートしていないハード依存関係を持つワークフロー。 * 異常に長い実行時間または特別な環境要件を持つジョブ。 (これらのカスタム イメージが必要な場合があります)。 容量計画では、プロビジョニングするランナーの数、使用するマシンの種類、および次の手順でランナー グループとポリシーを構成する方法について説明します。 ## 4. ランナー グループとポリシーを構成する 容量のニーズを見積もったら、ランナー グループとアクセス ポリシーを構成して、GitHubホストランナーを適切な組織やワークフローで使用できるようにします。 ランナーをプロビジョニングする前にランナー グループを構成すると、移行によって誤ってアクセスが広くなりすぎないようにしたり、予期しないコストの増加を引き起こしたりしないようにすることができます。 1. エンタープライズ レベルでランナー グループを作成し、ホストランナーを使用できるユーザーを定義します。 「[より大きなランナーへのアクセスの制御](/ja/enterprise-cloud@latest/actions/how-tos/manage-runners/larger-runners/control-access#creating-a-runner-group-for-an-enterprise)」を参照してください。 ランナー グループを使用して、組織、リポジトリ、またはワークフローごとにアクセスのスコープを設定します。 セルフホステッド ランナーから移行する場合は、可能な場合は、既存のランナー グループ名またはラベルを再利用することを検討してください。 これにより、GitHub-hosted runners に切り替えたときに、ワークフローを変更せずに作業を続行できます。 2. 新しい GitHub-hosted runners を適切なグループに追加し、手順 3 で特定した使用パターンに基づいてコンカレンシー制限を設定します。 自動スケーリングの詳細については、 [より大きなランナーを管理する](/ja/actions/how-tos/manage-runners/larger-runners/manage-larger-runners#configuring-autoscaling-for-larger-runners) を参照してください。 3. ポリシー設定を確認して、ランナーが目的のワークフローでのみ使用されていることを確認します。 たとえば、特定のリポジトリへの使用を制限したり、信頼されていないワークフローがより強力なコンピューターの種類にアクセスできないようにしたりします。 > \[!NOTE] macOS の大規模なランナーをランナー グループに追加することはできず、ワークフロー ファイル内で直接参照する必要があります。 ## 5. GitHub-hosted ランナーをセットアップする 次に、前に特定したマシンの種類と容量に基づいて、GitHubホストランナーをプロビジョニングします。 1. ワークフローの要件に一致するマシンのサイズとオペレーティング システムを選択します。 使用可能なイメージと仕様については、 [AUTOTITLE を](/ja/actions/reference/runners/larger-runners#runner-images)参照してください。 2. 各ランナーをランナー グループに割り当て、同時実行の制限を構成して、同時に実行できるジョブの数を制御します。 3. イメージの種類を選択します。 * 使用する GitHub マネージド イメージは、維持管理されており、頻繁に更新される環境を提供します。 * セットアップ時間を短縮するために、事前にインストールされた依存関係が必要な場合は、カスタム イメージを使用します。 「[カスタム イメージの使用](/ja/actions/how-tos/manage-runners/larger-runners/use-custom-images)」を参照してください。 4. 環境変数、ソフトウェアのインストール、スタートアップ スクリプトなど、必要なカスタマイズを適用します。 その他の例については、 [AUTOTITLE を](/ja/actions/how-tos/manage-runners/github-hosted-runners/customize-runners)参照してください。 5. 必要に応じて、ランナーが内部リソースにアクセスする必要がある場合は、プライベート ネットワークを構成します。 「[GitHubホストランナーを使用したプライベート ネットワーク](/ja/enterprise-cloud@latest/actions/concepts/runners/private-networking)」を参照してください。 ### プライベート接続オプションを構成する ワークフローでプライベート リソース (内部パッケージ レジストリ、プライベート API、データベース、オンプレミス サービスなど) へのアクセスが必要な場合は、ネットワークとセキュリティの要件に合ったアプローチを選択します。 #### Azure プライベート ネットワークを構成する 内部リソースへの安全なアクセスのために、Azure Virtual Network (VNET) 内で GitHub でホストされているランナーを実行します。 1. Azure Virtual Network (VNET) を作成し、ランナーのサブネットとネットワーク セキュリティ グループを構成します。 2. ランナー グループの Azure プライベート ネットワークを有効にします。 「[GitHubホストランナーのプライベートネットワークを企業で構成する方法](/ja/enterprise-cloud@latest/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/configuring-private-networking-for-github-hosted-runners-in-your-enterprise#1-add-a-new-network-configuration-for-your-enterprise)」を参照してください 3. NSG やファイアウォール規則などのネットワーク構成を適用して、イングレス トラフィックとエグレス トラフィックを制御します。 4. プライベート ネットワーク用に構成されたランナー グループを使用するように、ワークフロー ターゲットを更新します。 詳細な手順については、以下を参照してください。 * [組織内のGitHubホストランナーのプライベート ネットワークの構成](/ja/organizations/managing-organization-settings/configuring-private-networking-for-github-hosted-runners-in-your-organization) * [GitHubホストランナーのプライベートネットワークを企業で構成する方法](/ja/enterprise-cloud@latest/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 を使用してネットワーク オーバーレイを作成する](/ja/actions/how-tos/manage-runners/github-hosted-runners/connect-to-a-private-network/connect-with-wireguard) を参照してください。 #### プライベート リソースへの信頼できるアクセスに API ゲートウェイで OIDC を使用する ランナーがプライベート ネットワークに参加する必要がない場合は、OIDC を使用して、API ゲートウェイ経由で公開するサービスへの信頼された有効期間の短いアクセスを確立できます。 この方法により、有効期間の長いシークレットの必要性を減らし、ワークフローで必要な特定のエンドポイントへのネットワーク アクセスを制限できます。 詳細な手順と例については、 [OIDC とともに API ゲートウェイを使用する](/ja/actions/how-tos/manage-runners/github-hosted-runners/connect-to-a-private-network/connect-with-oidc) を参照してください。 ## 6. 新しいランナーを使用するようにワークフローを更新する GitHub-hosted runners が構成されたら、それらをターゲットにするようにワークフロー ファイルを更新します。 1. 新しいランナーを、セルフホストランナーが使用していたのと同じ名前のランナーグループに割り当てた場合は、既存のラベルを再利用します。 この場合、ワークフローは新しいランナーを変更せずに自動的に使用します。 2. 新しいランナー グループまたはラベルを作成した場合は、ワークフロー YAML ファイルの実行フィールドを更新します。 例えば次が挙げられます。 ```yaml jobs: build: runs-on: [github-larger-runner, linux-x64] steps: - name: Checkout code uses: actions/checkout@v6 - name: Build project run: make build ``` 3. セルフホステッド ラベル ( `self-hosted`、 `linux-x64`、カスタム ラベルなど) へのハードコーディングされた参照を確認し、適切な GitHubホストランナー ラベルに置き換えます。 4. 更新された各ワークフローをテストして、新しいランナーで正しく実行されていることを確認します。 環境の違いまたは不足している依存関係に関連する問題を監視します。 ## 7. 未使用のセルフホステッド ランナーを削除する GitHub-hosted runners でワークフローが更新およびテストされたら、不要になったセルフホステッド ランナーをすべて削除します。 これにより、ジョブが誤って古いインフラストラクチャをターゲットにするのを防ぐことができます。 「[セルフホストランナーを削除する](/ja/actions/how-tos/manage-runners/self-hosted-runners/remove-runners)」を参照してください。 セルフホステッド ランナーを削除する前に、完全に移行されていることを確認します。 * GitHub Actions 使用状況メトリックで、**\[ジョブ]** タブを使用し、ランナー ラベル (`self-hosted` やカスタム ラベルなど) でフィルター処理して、リポジトリやジョブでセルフホステッド ランナーがまだ使用されていないことを確認します。