GitLab Runner Infrastructure Toolkit (GRIT)은 퍼블릭 클라우드 공급자에서 일반적인 러너 구성을 만들고 관리하는 데 사용할 수 있는 Terraform 모듈 라이브러리입니다.

GRIT으로 러너 만들기#

GRIT를 사용하여 AWS에서 자동 스케일링 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 프로젝트에 새 러너를 만듭니다. 러너 관리자는 docker-autoscaler 실행기를 사용하여 aws 및 linux 태그가 있는 작업을 실행합니다. 러너는 워크로드에 따라 새 Auto Scaling Group(ASG)을 통해 1~5개의 VM을 프로비저닝합니다. ASG는 러너 팀이 소유한 공개 AMI를 사용합니다. 러너 관리자와 ASG 모두 새 VPC에서 작동합니다. 모든 리소스는 제공된 값(grit-runner)을 기반으로 이름이 지정되어 단일 AWS 프로젝트에서 서로 다른 이름으로 이 모듈의 여러 인스턴스를 만들 수 있습니다.

지원 수준 및 min_support 매개변수#

모든 GRIT 모듈에 대해 min_support 값을 제공해야 합니다. 이 매개변수는 운영자가 배포에 요구하는 최소 지원 수준을 지정합니다. GRIT 모듈은 none, experimental, beta 또는 GA의 지원 지정과 연관됩니다. 목표는 모든 모듈이 GA 상태에 도달하는 것입니다.

none은 특수한 경우입니다. 지원 보장이 없는 모듈로 주로 테스트 및 개발용입니다.

experimental, beta, ga 모듈은 GitLab 개발 단계 정의를 준수합니다.

공유 책임 모델#

GRIT는 Authors(모듈 개발자)와 Operators(GRIT로 배포하는 사람) 간의 공유 책임 모델에서 운영됩니다. 각 역할의 구체적인 책임과 지원 수준이 결정되는 방법에 대한 자세한 내용은 GORP 문서의 공유 책임 섹션을 참조하세요.

러너 상태 관리#

러너를 유지 관리하려면:

1. 모듈을 GitLab 프로젝트에 체크인합니다.

2. GitLab Terraform backend.tf에 Terraform 상태를 저장합니다:

   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
   

러너 삭제#

러너와 해당 인프라를 제거하려면:

terraform destroy

지원되는 구성#

고급 구성#

최상위 모듈#

공급자의 최상위 모듈은 러너의 고도로 분리되거나 선택적인 구성 측면을 나타냅니다. 예를 들어 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
   }

   # ...추가 구성 생략
}

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]
   }

   # ...추가 구성 생략
}

GRIT에 기여#

GRIT는 커뮤니티 기여를 환영합니다. 기여하기 전에 다음 리소스를 검토하세요:

개발자 원본 증명서 및 라이선스#

GRIT에 대한 모든 기여는 개발자 원본 증명서 및 라이선스의 적용을 받습니다. 기여함으로써 GitLab Inc.에 제출하는 현재 및 미래의 기여에 대해 이러한 조건에 동의합니다.

행동 강령#

GRIT는 Contributor Covenant에서 채택된 GitLab 행동 강령을 따릅니다. 이 프로젝트는 배경이나 정체성에 관계없이 모든 사람에게 괴롭힘이 없는 경험을 만드는 데 전념합니다.

기여 가이드라인#

GRIT에 기여할 때 다음 가이드라인을 따르세요:

• 전반적인 아키텍처 설계를 위한 GORP 가이드라인을 검토합니다.
• Terraform 사용에 대한 Google의 모범 사례를 준수합니다.
• 복잡성과 반복을 줄이기 위해 컴포저블 모듈 접근 방식을 따릅니다.
• 기여에 적절한 Go 테스트를 포함합니다.

테스트 및 린팅#

GRIT는 품질을 보장하기 위해 여러 테스트 및 린팅 도구를 사용합니다:

• 통합 테스트: Terratest를 사용하여 Terraform 플랜을 검증합니다.
• 엔드투엔드 테스트: e2e 디렉토리에서 사용 가능합니다.
• Terraform 린팅: tflint, terraform fmt, terraform validate를 사용합니다.
• Go 린팅: Go 코드(주로 테스트)에 golangci-lint를 사용합니다.
• 문서: GitLab 문서 스타일 가이드를 따르며 vale 및 markdownlint를 사용합니다.

개발 환경 설정, 테스트 실행 및 린팅에 대한 자세한 지침은 CONTRIBUTING.md를 참조하세요.

GRIT를 사용하는 곳#

GRIT는 GitLab 에코시스템 내의 다양한 팀과 서비스에서 채택되었습니다:

• GitLab Dedicated: GitLab Dedicated의 호스팅 러너는 GRIT를 사용하여 러너 인프라를 프로비저닝하고 관리합니다.
• GitLab Self-Managed: GRIT는 많은 GitLab Self-Managed 고객들 사이에서 많이 요청됩니다. 일부 조직은 표준화된 방식으로 러너 배포를 관리하기 위해 GRIT를 채택하기 시작했습니다.

조직에서 GRIT를 사용하고 있으며 이 섹션에 소개되고 싶다면 머지 리퀘스트를 열어주세요!