ランナーを管理する

完了

このセクションでは、企業内で GitHub Actions ランナーの使用を管理するために、GitHub Enterprise Cloud と GitHub Enterprise Server で使用できるさまざまなツールと戦略について説明します。

ワークロードに適したランナーを選択する

次の 2 種類のランナーで GitHub Actions ワークフローを実行できます。GitHub ホステッド ランナーまたはセルフホステッド ランナー。

Note

GitHub ホステッド ランナーは Enterprise Cloud にのみ使用できます。 Enterprise Server インスタンスがある場合、このセクションは適用されません。

GitHub ホステッド ランナーを使用すると、ワークフローを迅速かつ簡単に実行することができます。一方で、セルフホステッド ランナーは、独自のカスタム環境でワークフローを実行するための高度に構成可能な方法です。 たとえば、組織用の IP アドレス許可リストや、ワークフローを実行するための特殊なハードウェア構成を使用する必要がある場合は、セルフホステッド ランナーを使用します。

次の表は、GitHub ホステッド ランナーとセルフホステッド ランナーを比較したものです。 これを参考にして、ワークロードに適したランナーを選択してください。

GitHub ホステッド ランナー セルフホステッド ランナー
オペレーティング システム、プリインストールされたパッケージとツール、セルフホステッド ランナー アプリケーションの自動更新プログラムを受け取ります。 セルフホステッド ランナー アプリケーションの自動更新プログラムのみを受け取ります。 オペレーティング システムとその他すべてのソフトウェアは、お客様の責任で更新する必要があります。
GitHub によって管理および保守されます。 既に料金を支払っているクラウド サービスまたはローカル マシンを使用することができます。 また、ハードウェア、オペレーティング システム、ソフトウェア、セキュリティの要件に合わせてカスタマイズすることもできます。
ジョブを実行するたびにクリーンなインスタンスを提供します。 ジョブを実行するたびにクリーンなインスタンスを用意する必要はありません。
GitHub プランの無料通話分を使用できます。無料通話分を超えた場合は 1 分ごとの料金が適用されます。 GitHub Actions には無料で使用できますが、ランナー マシンの保守コストはお客様の負担となります。

セルフホステッド ランナーへのアクセスを構成する

Enterprise Cloud と Enterprise Server では、セルフホステッド ランナー グループを使用して、組織およびエンタープライズ レベルでセルフホステッド ランナーへのアクセスを制御することができます。 この機能は、セルフホステッド ランナーへのアクセスを特定の組織やユーザーに制限する必要がある場合に便利です。 たとえば、これらの組織やユーザーの信頼レベルに基づいて操作したり、セキュリティ リスクを軽減したりすることができます。

たとえば、エンタープライズ インスタンス内の特定の組織のみに、運用環境にコードを展開することを許可したいとします。 これを実現するには、運用環境にコードを展開するすべてのランナーを含むグループをエンタープライズ レベルで作成し、コードの展開を許可された特定の組織にグループ アクセスを制限することができます。

エンタープライズ レベルでグループを作成するには、エンタープライズ アカウントに移動して、サイドバーの [Policies] (ポリシー) > [Actions] (アクション) に移動します。 [Runner groups] (ランナー グループ) タブで、[New runner group] (新しいランナー グループ) を選択します。 表示される画面では、グループ名と組織のアクセス ポリシーを指定することができます。

全組織のグループ名の例が表示された新しいグループ画面のスクリーンショット。

組織レベルでグループを作成するには、組織の [Settings](設定)、サイドバーの [Actions](アクション) の順に移動します。 [Runner groups] (ランナー グループ)[New runner group] (新しいランナー グループ) の順に選択します。 表示される画面では、グループ名とリポジトリのアクセス ポリシーを指定できます。

全リポジトリのグループ名の例が表示された新しいグループ画面のスクリーンショット。

新しいランナーが作成されると、それらは企業や組織内の既定のグループに自動的に割り当てられます。 ランナーは一度に 1 つのグループにのみ属することができますが、Enterprise Cloud と Enterprise Server の両方で、ランナーを既定グループから別のグループに移動することができます。

企業での使用に合わせてセルフホステッド ランナーを構成する

Enterprise Cloud と Enterprise Server には、企業での使用に合わせてセルフホステッド ランナーをカスタマイズできる複数の機能があります。 これらの機能には、"ラベル"、"プロキシ サーバー"、"IP 許可リスト" などがあります。

Labels

セルフホステッド ランナーは、GitHub Actions に追加されると自動的に既定のラベルを受け取ります。 これらの既定ラベルは、次の表に示すように、ランナーのオペレーティング システムとハードウェアのアーキテクチャを示しています。

既定のラベル 説明
self-hosted すべてのセルフホステッド ランナーに適用される既定のラベル
linuxwindows、または macOS ランナーのオペレーティング システムに応じて適用されます。
x64ARM、または ARM64 ランナーのハードウェア アーキテクチャに応じて適用されます。

Enterprise Cloud と Enterprise Server では、これらの既定のラベルに加えて、カスタム ラベルを作成してランナーに追加することができます。 カスタム ラベルは、特定の機能を持つランナー上でジョブを実行する必要がある場合に便利な機能です。 たとえば、ワークフローの 1 つのジョブに特定の種類のグラフィック ハードウェアが必要な場合、gpu カスタム ラベルを作成して、そのハードウェアがインストールされているランナーに割り当てることができます。 ラベルが gpu のすべてのランナーには、そのジョブを実行する資格があります。

セルフホステッド ランナーにラベルを追加するには、セルフホステッド ランナーが登録されている組織、リポジトリ、または企業の GitHub Actions 設定に移動します (組織またはリポジトリの場合は [Actions] (アクション) の下、エンタープライズの場合は [Policies] (ポリシー) > [Actions] (アクション) の下)。 次の手順を実行します。

  1. [ランナー] の下にあるランナーの一覧を見つけます。 ランナーがグループ内にある場合は、ランナー グループを見つけ、ランナーのドロップダウンを選択して、ランナー一覧を表示します。

    ドロップダウンが強調表示されたランナー グループの例のスクリーンショット。

  2. 更新するランナーを見つけ、ラベルのドロップダウンを選択してラベル選択メニューを表示します。 このメニューには、セルフホステッド ランナーで使用できるすべてのカスタム ラベルが表示されます。 既にセルフホステッド ランナーに割り当てられているラベルには、その横にチェックマークが表示されます。

    ラベル メニューが表示されたランナーの例のスクリーンショット。

  3. 既存のラベルを選択してランナーに追加するか、[フィルター ラベル] フィールドに新しいラベルの名前を入力し、[新しいラベルの作成] を選択します。 ラベルを作成すると、自動的にランナーに追加されます。

プロキシ サーバー

セルフホステッド ランナーがプロキシ サーバー経由で GitHub と通信する必要がある場合は、Enterprise Cloud と Enterprise Server の両方で、次の環境変数を使用してプロキシ構成を変更することができます。

環境変数 説明
https_proxy HTTPS トラフィック用のプロキシ URL。 必要に応じて、基本認証の資格情報を含めることもできます。 例:
http://proxy.local
http://192.168.1.1:8080
http://username:password@proxy.local
http_proxy HTTP トラフィックのプロキシ URL。 必要に応じて、基本認証の資格情報を含めることもできます。 例:
http://proxy.local
http://192.168.1.1:8080
http://username:password@proxy.local
no_proxy プロキシを使用しないホストのコンマ区切りのリスト。 no_proxy ではホスト名のみが許可されています。 IP アドレスは使用できません。 例:
example.com
example.com,myserver.local:443,example.org

Note

プロキシの環境変数はセルフホステッド ランナー アプリケーションの起動時に読み込まれるため、アプリケーションの構成や起動前に環境変数を構成しておく必要があります。 プロキシの構成を変更した場合は、セルフホステッド ランナー アプリケーションを再起動する必要があります。

Windows の場合、プロキシの環境変数名の大文字と小文字は区別されません。 Linux および macOS の場合、すべて小文字の環境変数を使用することをお勧めします。 Linux または macOS 上で、https_proxyHTTPS_PROXY のように、小文字と大文字の両方の環境変数がある場合、セルフホステッド ランナー アプリケーションには小文字の環境変数が使用されます。

IP 許可リスト

Enterprise Cloud または Enterprise Server 組織によって IP 許可リストが構成されている場合、セルフホステッド ランナーが GitHub と通信するには、セルフホステッド ランナーの IP アドレスまたは IP アドレス範囲を IP 許可リストに追加する必要があります。

セルフホステッド ランナーの IP アドレスまたは IP アドレス範囲を組織の IP 許可リストに追加するには、組織の [Settings](設定) に移動し、サイドバーの [Organization security](組織のセキュリティ) を選択します。 [IP Address](IP アドレス) で、セルフホステッド ランナーの IP アドレスまたは IP アドレス範囲を CIDR 表記で追加し、[+ Add](追加) を選択します。

セルフホステッド ランナーの監視とトラブルシューティング

Enterprise Cloud と Enterprise Server には、セルフホステッド ランナーの監視、トラブルシューティング、更新を可能にするツールが用意されています。 ビルドが失敗し始めた場合、リポジトリの一部のファイルがロックされた場合、またはワークフローの実行が止まった場合は、ワークフローを実行するランナーのトラブルシューティングが問題の解決に役立ちます。

セルフホステッド ランナーをトラブルシューティングする場合の主な手順は次のとおりです。

  1. セルフホステッド ランナーが登録されている組織、リポジトリ、または企業の GitHub Actions 設定でランナーの状態を確認します (組織またはリポジトリの場合は [Actions] (アクション) の下、エンタープライズの場合は [Policies] (ポリシー) > [Actions] (アクション) の下)。
  2. _diag フォルダーの Runner_ ファイルで、ランナーのアクティビティと自動更新を確認します。
  3. _diag フォルダーの Worker_ ファイルで、ランナーが実行したジョブの状態を確認します。

ランナーのオペレーティング システムに応じて、次の表に示すように追加の手順を実行できます。

Mac Windows Linux
launchd を使用してセルフホステッド ランナー アプリケーション サービスを確認します PowerShell を使用してセルフホステッド ランナー アプリケーション サービスを確認します - journalctl を使用してセルフホステッド ランナー アプリケーション サービスを確認します
- ジョブにコンテナーが必要な場合は、Docker がインストールされて実行されていることと、systemctl を使用して Docker のアクセス許可を確認します。