GitLab Runnerインフラストラクチャツールキット

GitLab Runner Infrastructure Toolkit（GRIT）は、パブリッククラウドプロバイダー上で一般的なrunner設定を多数作成および管理するために使用できる、Terraformモジュールのライブラリです。

GRITでrunnerを作成する

GRITを使用して、Amazon Web ServicesでオートスケールLinux Dockerをデプロイするには、次の手順を実行します:

1. GitLabとAWSへのアクセスを提供するために、次の変数を設定します:

   • GITLAB_TOKEN
   • AWS_REGION
   • AWS_SECRET_ACCESS_KEY
   • AWS_ACCESS_KEY_ID

2. 最新のGRITリリースをダウンロードし、.local/gritに展開します。

3. main.tf Terraformモジュールを作成します:

   module "runner" {
     source = ".local/grit/scenarios/aws/linux/docker-autoscaler-default"
   
     name               = "grit-runner"
     gitlab_project_id  = "39258790" # gitlab.com/josephburnett/hello-runner
     runner_description = "Autoscaling Linux Docker runner on AWS deployed with GRIT. "
     runner_tags        = ["aws", "linux"]
     max_instances      = 5
     min_support        = "experimental"
   }

4. モジュールを初期化して適用します:

   terraform init
   terraform apply

これらの手順では、GitLabプロジェクトに新しいrunnerを作成します。Runnerマネージャーは、docker-autoscaler executorを使用して、awsおよびlinuxとしてタグ付けされたジョブを実行します。runnerは、ワークロードに基づいて、新しいオートスケールグループ（ASG）を介して1〜5台のVMをプロビジョニングします。ASGは、runnerチームが所有するパブリックAMIを使用します。RunnerマネージャーとASGはどちらも、新しいVPCで動作します。すべてのリソースは、指定された値（grit-runner）に基づいて名前が付けられます。これにより、単一のAWSプロジェクトで、名前の異なるこのモジュールの複数のインスタンスを作成できます。

サポートレベルとmin_supportパラメータ

すべてのGRITモジュールにmin_support値を指定する必要があります。このパラメータは、オペレーターがデプロイに必要な最小サポートレベルを指定します。GRITモジュールは、none、experimental、beta、またはGAのサポート指定に関連付けられています。目標は、すべてのモジュールがGAステータスに到達することです。

noneは特別なケースです。主にテストと開発を目的とした、サポート保証のないモジュール。

experimental、beta、およびgaモジュールは、GitLabの開発ステージングの定義に準拠しています。

責任共有モデル

GRITは、作成者（モジュール開発者）とオペレーター（GRITでデプロイするユーザー）間の責任共有モデルに基づいて運用されます。各ロールの具体的な責任とサポートレベルの決定方法の詳細については、GORPドキュメントの責任共有セクションを参照してください。

Runnerの状態を管理する

Runnerを維持するには、次の手順に従います:

1. モジュールをGitLabプロジェクトにチェックインします。

2. Terraformの状態をGitLab Terraform backend.tfに保存します:

   terraform {
     backend "http" {}
   }

3. .gitlab-ci.ymlを使用して変更を適用します:

   terraform-apply:
     variables:
       TF_HTTP_LOCK_ADDRESS: "https://gitlab.com/api/v4/projects/${CI_PROJECT_ID}/terraform/state/${NAME}/lock"
       TF_HTTP_UNLOCK_ADDRESS: ${TF_HTTP_LOCK_ADDRESS}
       TF_HTTP_USERNAME: ${GITLAB_USER_LOGIN}
       TF_HTTP_PASSWORD: ${GITLAB_TOKEN}
       TF_HTTP_LOCK_METHOD: POST
       TF_HTTP_UNLOCK_METHOD: DELETE
     script:
       - terraform init
       - terraform apply -auto-approve

Runnerを削除

runnerとそのインフラストラクチャを削除するには:

terraform destroy

サポートされている設定

高度な設定

トップレベルモジュール

プロバイダーのトップレベルモジュールは、高度に分離された、またはオプションのrunner設定の側面を表します。たとえば、fleetingとrunnerは、アクセス認証情報とインスタンスグループ名のみを共有するため、個別のモジュールです。vpcは、一部のユーザーが独自のVPCを提供するため、個別のモジュールです。既存のVPCを持つユーザーは、他のGRITモジュールに接続するために、一致する入力構造を作成するだけで済みます。

たとえば、トップレベルのVPCモジュールを使用して、VPCを必要とするモジュールのVPCを作成できます:

module "runner" {
   source = ".local/grit/modules/aws/runner"

   vpc = {
      id         = module.vpc.id
      subnet_ids = module.vpc.subnet_ids
   }

   # ...additional config omitted
}

module "vpc" {
   source   = ".local/grit/modules/aws/vpc"

   zone = "us-east-1b"

   cidr        = "10.0.0.0/16"
   subnet_cidr = "10.0.0.0/24"
}

ユーザーは独自のVPCを提供でき、GRITのVPCモジュールを使用する必要はありません:

module "runner" {
   source = ".local/grit/modules/aws/runner"

   vpc = {
      id         = PREEXISTING_VPC_ID
      subnet_ids = [PREEXISTING_SUBNET_ID]
   }

   # ...additional config omitted
}

GRITへのコントリビュート

GRITは、コミュニティからのコントリビュートを歓迎します。コントリビュートする前に、次のリソースを確認してください:

開発者のオリジン証明書とライセンス

GRITへのすべてのコントリビュートは、開発者のオリジン証明書とライセンスに従います。コントリビュートすることにより、GitLab Inc.に提出された現在および将来のコントリビュートについて、これらの条件に同意したことになります。

行動規範

GRITはGitLabの行動規範に従います。これは、コントリビューター規約から採用されています。このプロジェクトは、バックグラウンドやアイデンティティに関係なく、誰にとってもハラスメントのない体験を保証することに取り組んでいます。

コントリビューションのガイドライン

GRITにコントリビュートする場合は、次のガイドラインに従ってください:

• 全体的なアーキテクチャ設計については、GORPガイドラインを確認してください。
• Terraformを使用するためのGoogleのベストプラクティスを遵守してください。
• 複雑さと繰り返しを軽減するために、再利用可能なモジュールアプローチに従います。
• コントリビューションのために適切なGo言語テストを含めてください。

テストとLint

GRITは、品質を確保するために、いくつかのテストツールとLintツールを使用しています:

• 統合テスト: Terratestを使用して、Terraformプランを検証します。
• E2Eテスト: e2eディレクトリで利用できます。
• Terraform Lint: tflint、terraform fmt、およびterraform validateを使用します。
• Go言語Lint: Go言語コード（主にテスト）には、golangci-Lintを使用します。
• ドキュメント: GitLabドキュメントのスタイルガイドラインに従い、valeとmarkdownlintを使用します。

開発環境のセットアップ、テストの実行、およびLintの詳細な手順については、CONTRIBUTING.mdを参照してください。

GRITのユーザー

GRITは、GitLabエコシステム内のさまざまなチームやサービスで採用されています:

• GitLab Dedicated: GitLab Dedicatedのホストされたrunnerは、GRITを使用してrunnerインフラストラクチャをプロビジョニングおよび管理します。

• GitLab Self-Managed: GRITは、多くのGitLabセルフマネージドのお客様から非常に要望されています。一部の組織は、標準化された方法でrunnerのデプロイを管理するために、GRITの採用を開始しています。

組織でGRITを使用しており、このセクションで紹介されたい場合は、マージリクエストを開いてください。