GitLab Dedicated用のホストされるRunner

GitLabホストのrunnerでCI/CDジョブを実行できます。これらのRunnerはGitLabによって管理され、GitLab Dedicatedインスタンスと完全に統合されています。GitLab DedicatedのGitLabホストされたRunnerは、オートスケールするインスタンスRunnerで、GitLab Dedicatedインスタンスと同じリージョンのAWS EC2上で実行されます。

ホストされたRunnerを使用する場合:

• 各ジョブは、特定のジョブ専用にプロビジョニングされたばかりの仮想マシン（VM）で実行されます。
• ジョブが実行されるVMには、パスワードなしでsudoアクセスできます。
• ストレージは、オペレーティングシステム、プリインストールされたソフトウェアを含むDockerイメージ、および複製されたリポジトリのコピーによって共有されます。これは、ジョブで使用できるディスクの空き容量が少なくなることを意味します。
• デフォルトでは、タグ付けされていないジョブは、Small Linux x86-64 Runnerで実行されます。GitLab管理者は、GitLabでタグなしのジョブを実行するオプションを変更できます。

Linux上のホストされるRunner

GitLab DedicatedのLinux上のホストされたRunnerは、Docker Autoscaler executorを使用します。各ジョブは、完全に分離された一時的な仮想マシン（VM）内のDocker環境を取得し、最新バージョンのDocker Engineで実行されます。

Linuxのマシンタイプ - x86-64

Linux x86-64上のホストされたRunnerに対して、次のマシンタイプが利用可能です。

Linuxのマシンタイプ - Arm64

次のマシンタイプは、Linux Arm64上のホストされたRunnerで使用できます。

デフォルトのRunnerタグは、作成時に割り当てられます。管理者は、後でインスタンスRunnerのタグの設定を変更できます。

コンテナイメージ

Linux上のRunnerはDocker Autoscaler executorを使用しているため、.gitlab-ci.ymlファイルでコンテナイメージを定義することで、任意のコンテナイメージを選択できます。選択したDockerイメージが、基盤となるプロセッサアーキテクチャと互換性があることを確認してください。例の.gitlab-ci.ymlファイルを参照してください。

イメージが設定されていない場合、デフォルトはruby:3.1です。

Docker HubコンテナレジストリからのDockerイメージを使用すると、レート制限が発生する可能性があります。これは、GitLab Dedicatedが単一のネットワークアドレス変換（NAT）IPアドレスを使用しているためです。

レート制限を回避するには、代わりに以下を使用してください:

• GitLabコンテナレジストリに格納されているDockerイメージ。
• レート制限のない他のパブリックレジストリに格納されているDockerイメージ。
• 依存プロキシ。これは、プルスルーキャッシュとして機能します。

Docker in Dockerのサポート

Runnerは、privilegedモードで実行するように設定されており、Docker in Dockerをサポートして、Dockerイメージをネイティブにビルドか、分離されたジョブ内で複数のコンテナを実行します。

ホストされたRunnerを管理する

スイッチボードでホストされたRunnerを管理する

スイッチボードを使用して、GitLab DedicatedインスタンスのホストされたRunnerを作成および表示できます。

前提要件:

• GitLab DedicatedのホストされたRunnerのサブスクリプションを購入する必要があります。

スイッチボードでホストされたRunnerを作成する

インスタンスごとに、タイプとサイズの組み合わせごとに1つのRunnerを作成できます。スイッチボードには、使用可能なRunnerオプションが表示されます。

ホストされたRunnerを作成するには:

1. スイッチボードにサインインします。
2. ページの上部にあるHosted runners（ホストされたRunner）を選択します。
3. New hosted runner（新しいホストされたRunner）を選択します。
4. Runnerのサイズを選択し、Create hosted runner（ホストされたRunnerを作成）を選択します。

ホストされたRunnerを使用する準備ができると、メールで通知が届きます。

既存のRunnerに設定されている送信プライベートリンクは、新しいRunnerには適用されません。新しいRunnerごとに個別のリクエストが必要です。

スイッチボードでホストされたRunnerを表示する

ホストされたRunnerを表示するには:

1. スイッチボードにサインインします。
2. ページの上部にあるHosted runners（ホストされたRunner）を選択します。
3. オプション。ホストされたRunnerのリストから、GitLabでアクセスするRunnerのRunner IDをコピーします。

GitLabでホストされたRunnerを表示および設定する

GitLab管理者は、管理者エリアから、GitLab DedicatedインスタンスのホストされたRunnerを管理できます。

GitLabでホストされたRunnerを表示する

Runnerページとフリートダッシュボードで、GitLab DedicatedインスタンスのホストされたRunnerを表示できます。

前提要件:

• 管理者である必要があります。

GitLabでホストされたRunnerを表示するには:

1. 左側のサイドバーの下部で、管理者を選択します。
2. CI/CD > Runnersを選択します。
3. オプション。フリートダッシュボードを選択します。

GitLabでホストされたRunnerを設定する

前提要件:

• 管理者である必要があります。

Runnerタグのデフォルト値を変更するなど、GitLab DedicatedインスタンスのホストされたRunnerを設定できます。

利用可能な設定オプションは次のとおりです:

• ジョブの最大タイムアウトを変更する。
• タグ付きまたはタグなしジョブを実行するようにRunnerを設定します。

GitLabでグループまたはプロジェクトのホストされたRunnerを無効にする

デフォルトでは、ホストされたRunnerは、GitLab Dedicatedインスタンス内のすべてのプロジェクトとグループで使用できます。GitLabメンテナーは、プロジェクトまたはグループのホストされたRunnerを無効にすることができます。

セキュリティとネットワーク

GitLab DedicatedのホストされたRunnerには、GitLab Runnerビルド環境のセキュリティを強化する組み込みレイヤーがあります。

GitLab DedicatedのホストされたRunnerには、次の設定があります:

• ファイアウォールルールにより、一時的なVMからパブリックインターネットへの送信トラフィックのみが許可されます。
• ファイアウォールルールは、パブリックインターネットから一時的なVMへの受信トラフィックを許可しません。
• ファイアウォールルールは、VM間の通信を許可しません。
• Runnerマネージャーのみが、一時的なVMと通信できます。
• 一時的なRunner VMは、単一のジョブのみを提供し、ジョブの実行後に削除されます。

AWSアカウントへのホストされたRunnerからのプライベート接続を有効にすることもできます。

詳細については、GitLab DedicatedのホストされたRunnerのアーキテクチャ図を参照してください。

送信プライベートリンク

送信プライベートリンクは、GitLab DedicatedのホストされたRunnerとAWS VPC内のサービス間の安全な接続を作成します。この接続は、パブリックインターネットへのトラフィックを公開せず、ホストされたRunnerが以下を実行できるようにします:

• カスタムシークレットマネージャーなどのプライベートサービスにアクセスします。
• インフラストラクチャに格納されているアーティファクトまたはジョブDockerイメージを取得する。
• インフラストラクチャにデプロイします。

GitLab管理のRunnerアカウント内のすべてのRunnerに対して、デフォルトで2つの送信プライベートリンクが存在します:

• GitLabインスタンスへのリンク
• GitLab制御のPrometheusインスタンスへのリンク

これらのリンクは事前に設定されており、変更できません。テナントのPrometheusインスタンスはGitLabによって管理されており、ユーザーはアクセスできません。

ホストされたRunnerの他のVPCサービスで送信プライベートリンクを使用するには、サポートリクエストを使用した手動設定が必要です。詳細については、送信プライベートリンクを参照してください。

IP範囲

GitLab DedicatedのホストされたRunnerのIP範囲は、リクエストに応じて利用可能です。IP範囲は最大限の努力に基づいて維持されており、インフラストラクチャの変更によりいつでも変更される可能性があります。詳細については、カスタマーサクセスマネージャーまたはアカウント担当者にお問い合わせください。

ホストされるRunnerを使用する

スイッチボードでホストされたRunnerを作成すると、Runnerを使用する準備ができます。

Runnerを使用するには、使用するホストされたRunnerと一致するように、.gitlab-ci.ymlファイル内のジョブ設定でタグを調整します。

Linux medium x86-64 Runnerの場合は、次のようにジョブを設定します:

job_name:
  tags:
    - linux-medium-amd64  # Use the medium-sized Linux runner

デフォルトでは、タグ付けされていないジョブは、Small Linux x86-64 Runnerによって取得されます。GitLab管理者は、タグなしのジョブを実行しないようにGitLabでインスタンスRunnerを設定することができます。

ジョブ設定を変更せずにジョブを移行するには、既存のジョブ設定で使用されているタグと一致するようにホストされたRunnerタグを変更します。

ジョブがエラーメッセージno runners that match all of the job's tagsで停止している場合は:

1. 正しいタグを選択したかどうかを確認します
2. インスタンスRunnerがプロジェクトまたはグループに対して有効になっているかどうかを確認します。

アップグレード

Runnerバージョンのアップグレードには、短いダウンタイムが必要です。Runnerは、GitLab Dedicatedテナントのスケジュールされたメンテナンス期間中にアップグレードされます。ゼロダウンタイムアップグレードを実装するためのイシューが存在します。

価格

価格の詳細については、アカウント担当者にお問い合わせください。

GitLab Dedicatedのお客様には、30日間のFreeトライアルをご用意しています。トライアルには以下が含まれます:

• Small、Medium、およびLarge Linux x86-64 Runner
• SmallおよびMedium Linux ARM Runner
• 最大100の同時実行ジョブをサポートする制限付きのオートスケール設定