ランナーを探索する
GitHub ランナーは、GitHub Actions ワークフローを実行するコンピューティング リソースです。 各ランナーは一度に 1 つのジョブを実行できます。 開発者は、GitHub リポジトリから直接、ビルド、テスト、デプロイ タスクを行うことができます。 GitHub ランナーには、主に次の 2 種類があります。
- GitHub ホステッド ランナーは、GitHub が提供および管理する仮想化またはコンテナー化されたコンピューティング リソースです。
- セルフ ホステッド ランナーとは、GitHub ユーザーや組織がプロビジョニングおよび管理する、物理的、仮想化、コンテナー化されたコンピューティング リソースです。
それぞれの種類にいくつかの固有の特徴があり、多くの異なる機能を備え、いくつかの異なる考慮事項が必要です。
GitHub では、公開リポジトリでセルフ ホステッド ランナーを使用することを強くお勧めします。 そうすることで、組織の非公開の環境内で誰でもコードを実行できるようになる可能性があるため、重大なセキュリティ リスクが生じます。
GitHub ホステッド ランナー
GitHub ホステッド ランナーには、GitHub Actions 内でワークフローを実行するための便利なソリューションが用意されており、基盤となるハードウェアおよびソフトウェア コンポーネントを管理する必要がなくなります。 需要に応じて自動的に拡張されるように設計されているため、使用量のピーク時に最適なパフォーマンスが保証されます。 GitHub では、GitHub ホステッド ランナー向けに、Ubuntu Linux、Microsoft Windows、macOS など、さまざまなソフトウェア構成やオペレーティング システムに対応した事前構成済みの環境が複数用意されています。
GitHub ホステッド ランナーには、オペレーティング システムの既定の組み込みツールが含まれています。 たとえば、Ubuntu および macOS ランナーには、grep、find、which が含まれています。 ランナーにプリインストールされている他のすべてのツールを識別するには、Windows および Ubuntu ランナー イメージの各ビルドのソフトウェア部品表 (SBOM) を確認できます。 または、ワークフロー ログの [ジョブの設定] セクションでランナー イメージ サブセクションを確認することもできます。 付属ソフトウェア エントリに続くリンクは、ワークフローを実行したランナーにプレインストールされたすべてのツールについて説明しています。 既存のワークフローの一部としてパッケージをインストールするジョブを作成することで、GitHub ホステッド ランナーに追加のソフトウェアをインストールすることもできます。
GitHub ホステッド ランナーは、GitHub のクラウド インフラストラクチャ上で実行し、仮想マシンやコンテナーを利用してワークフローを実行します。 各ワークフローの実行は、独自の環境内で分離されるため、セキュリティと再現性が保証されます。 GitHub ホステッド ランナーは GitHub Actions とシームレスに統合され、ユーザーは GitHub リポジトリでホストされたワークフロー内で直接参照できます。
GitHub ホステッド ランナーを使用する場合、GitHub Actions の使用には制限があります。 特に、ワークフロー内の各ジョブの実行時間は最大 6 時間です。 ジョブがこの制限に達すると、ジョブは終了させられ、完了できずに失敗します。 各ワークフローは 35 日間に制限されています。 ワークフローの実行がこの制限に達した場合、その実行はキャンセルされます。 この期間には、実行時間と、待機と承認に費やされた時間が含まれます。
前提条件
GitHub ホステッド ランナーを実装する前に、GitHub Actions を使用してワークフローを定義できる GitHub リポジトリが必要です。 ランナーは、GitHub Actions にアクセスできるすべての GitHub ユーザーが利用できます。
実装
セルフ ホステッド ランナーとは異なり、GitHub ホステッド ランナーは、個々のワークフロー実行の一部として自動的にプロビジョニングされます。 ユーザーは、ワークフローを YAML 形式のファイルとして定義し、GitHub リポジトリの .github/workflows ディレクトリに格納します。 ワークフロー構成内で、ユーザーはオペレーティング システムやソフトウェアの依存関係など、必要なランナー環境を指定します。 ワークフローがトリガーされるたびに、一致する仕様のランナーがオンデマンドで設定され、ジョブごとに 1 つのランナーが設定されます。 トリガーは、コード プッシュ、pull request、リポジトリ ディスパッチ イベントなどのイベントに基づいて、手動または自動に設定できます。
GitHub ホステッド ランナーは、GitHub Actions で提供されるトークンや資格情報を使用して GitHub を認証します。 また、GitHub プラットフォームと通信し、ワークフロー成果物をダウンロードするために、組み込みの接続性に依存しています。
管理
GitHub は、GitHub ホステッド ランナーの更新とメンテナンスを管理し、最新のソフトウェア バージョンとセキュリティ更新プログラムを確実に適用します。 ランナーに含まれるソフトウェア ツールは毎週更新されます。 ランナー アクティビティは監視され、ログに記録されるため、ワークフロー実行の追跡やトラブルシューティングが促進されます。
ライセンスおよびコスト
GitHub ホステッド ランナーは GitHub Actions の価格に含まれており、無料レベルを超えたワークフローについては、使用量に応じて課金されます。 GitHub は、需要に応じてランナーを自動的にプロビジョニングおよび割り当て解除するため、ユーザーは自動化されコスト効率の良いスケーリングの恩恵を受けます。
セルフホステッド ランナー
GitHub ホステッド ランナーと比較して、セルフ ホステッド ランナーにはより大きな制御とカスタマイズのオプションがあり、実行環境はより幅広い要件に対応できます。 また、ネットワーク接続性、コスト、リソースの可用性などの基準に応じて、オンプレミスでもクラウドでもデプロイできます。
セルフ ホステッド ランナーは、ユーザーがプロビジョニングおよび管理し、実行環境を完全に制御できます。 また、ハードウェア仕様、ソフトウェア構成、ネットワーク設定などを完全にカスタマイズできます。 また、既存のインフラストラクチャやツールとの統合を促進し、互換性や相互運用性の問題が発生する可能性を最小限に抑えます。
GitHub ホステッド ランナーとは異なり、個々のジョブの実行やワークフローの実行にかかる時間に制限はありません。
前提条件
ユーザーは、ランナー ソフトウェアおよび依存する追加ソフトウェアのインストールを含め、選択したインフラストラクチャ上でセルフ ホステッド ランナーを設定および構成する必要があります。 セルフ ホステッド ランナーのソース コードは、オープンソース プロジェクトとして https://github.com/actions/runner に GitHub で公開されています。 各セルフ ホステッド ランナーは、GitHub Actions と通信してワークフローを実行するエージェントとして機能します。
セルフ ホステッド ランナーは、GitHub プラットフォームへのアクセスやワークフロー成果物のダウンロードのために、発信ネットワーク接続、認証資格情報、および承認が必要です。 ランナーの場所によっては、これらの要件を満たすためにファイアウォール規則を構成する必要がある場合があります。
実装
GitHub ホステッド ランナーと同様に、実装では YAML 形式のワークフローを定義し、GitHub リポジトリの .github/workflows ディレクトリに格納します。 ただし、ワークフローでセルフ ホステッド ランナーを使用するためには、まずユーザーが必要な認証トークンや資格情報を提供して登録する必要があります。 登録の一環として、ユーザーはランナー名、ラベル、実行環境パラメーターなどの特性を指定します。
登録は、エンタープライズ内のさまざまなレベルで行うことができます。
- リポジトリ レベル (単一リポジトリ)
- 組織レベル (組織内の複数のリポジトリ)
- エンタープライズ レベル (企業全体の複数の組織)
管理
ソフトウェア更新プログラムやセキュリティ更新プログラムのインストールなど、セルフ ホステッド ランナーの更新およびメンテナンスはユーザーの責任で行われます。 メンテナンスには、ランナーの正常性とパフォーマンスを監視し、ランナーの実行時に発生した問題のトラブルシューティングも含まれます。
ライセンスおよびコスト
セルフ ホステッド ランナーには、GitHub Actions の価格を超えたライセンス料や、コンピューティング、ストレージ、ネットワークなどの関連インフラストラクチャのコストは発生しません。 リソースの割り当てと使用状況の最適化は、ユーザーの責任になります。