IaC/CI CD Tool

2. GitLab이란? / GitLab Runner 개념 및 설치

Somaz 2023. 4. 23. 20:09
728x90
반응형

Overview

오늘은 GitLab Runner의 개념과 설치 방법에 대해 알아보려고 한다.

 

다음시간에는 GitLab CI/CD 구동방식과 GitLab 문법에 대해 자세히 공부해보려고 한다.

 

GitLab 설치는 아래의 페이지를 참고하기 바란다.

2023.04.21 - [IaC/CI CD Tool] - 1. Gitlab이란? / 개념 및 설치

 

 


GitLab Runner란?

GitLab Runner는 GitLab과 함께 작동하여 코드 변경 사항을 자동으로 빌드, 테스트 및 배포하는 CI 도구이다. 

 

 

 

CI/CD 파이프라인에 정의된 작업을 실행하는 오픈 소스 프로젝트로 Runners라는 시스템에서 작업을 실행한다.

GitLab Runner는 Linux, macOS, Windows 및 Kubernetes 클러스터와 같은 다양한 운영 체제 및 플랫폼에 설치할 수 있다. 그리고 가상 머신, 물리적 서버 또는 클라우드 기반 환경에서 실행할 수 있다.

GitLab Runner는 Shell, Docker, Kubernetes 등과 같은 다양한 ""executors"를 사용하여 작업을 실행할 수 있다.

 

 


 

GitLab Runner의 작동 방식

  • CI/CD 파이프라인이 구성된 GitLab 리포지토리에 코드 변경 사항을 푸시하면 GitLab은 하나 이상의 작업이 포함된 새 파이프라인을 생성한다.
  • GitLab Runner는 GitLab 서버에서 실행할 새 작업을 주기적으로 확인한다. 작업을 사용할 수 있는 경우 러너는 작업을 선택하고 실행을 시작한다.
  • Runner는 프로젝트의 .gitlab-ci.yml 파일에 정의된 작업 단계(예: 빌드, 테스트 또는 배포)를 실행한다. 이러한 단계에는 코드를 빌드, 테스트 및 배포하는 데 필요한 스크립트, 명령 및 기타 작업이 포함될 수 있다.
  • Runner가 작업을 실행하면 실시간 상태 업데이트, 로그 및 생성된 모든 아티팩트를 GitLab 서버로 다시 보낸다. 이를 통해 파이프라인 및 해당 작업의 진행 상황을 모니터링하고 검토할 수 있다.
  • 작업이 완료되면 Runner는 최종 상태(성공 또는 실패)를 GitLab 서버에 보고한다. 이를 통해 코드 또는 파이프라인에서 해결해야 하는 문제 또는 개선 사항을 식별할 수 있다.

 

GitLab Runner의 종류

공유 러너(Shared Runner)

이러한 실행기는 GitLab 인스턴스 내의 모든 프로젝트에서 사용할 수 있다. GitLab 관리자가 구성하고 관리하며 동일한 GitLab 인스턴스의 모든 프로젝트에서 사용할 수 있다. Shared Runner는 여러 프로젝트 및 팀에 공통 빌드 환경을 제공하려는 경우에 유용하다.

 

그룹 러너(Group Runner)

그룹 러너는 GitLab 인스턴스 내의 특정 프로젝트 그룹 전용이다. 그룹 관리자가 구성하고 관리할 수 있으며 해당 그룹 내의 프로젝트에서만 사용할 수 있다. Group Runner를 사용하면 GitLab 인스턴스의 다른 프로젝트에 영향을 주지 않고 특정 프로젝트 그룹의 CI/CD 리소스를 관리할 수 있다.

 

개인화 러너(Specific Runner)

Project Runner라고도 하는 특정 Runner는 단일 프로젝트 전용이다. 해당 Runner는 프로젝트의 CI/CD 파이프라인에 특별히 사용되는 리소스 및 환경에 대한 제어를 제공한다. 다른 프로젝트와 공유해서는 안 되는 프로젝트에 대한 고유한 요구 사항이나 리소스가 있을 때 유용할 수 있다.

 


GitLab Group Runner 설정

 

나머지 설정방법과 거의 동일하다.

 


 

1. Gitlab menu - Group - Your Group

 


 

2. 원하는 Group 선택


 

3. Settings - CI/CD 

 

 

CI/CD 메뉴에서 Runners로 접근하면 Group runners에 등록할 URl과 토큰 정보가 보인다.

이 값은 서버에서 runner를 생성할 때 필요하다.

 

 

 


GitLab Runner 설치(Helm)

Group Runner를 사용할 것이다. 그리고 Kubernetes에 구성할 것이다.

 


 

Step 1. 사전준비

  • gitlabUrl - 러너를 등록할 GitLab 서버 전체 URL (예: http://gitlab.example.com)
  • runnerRegistrationToken - GitLab에 새 러너를 추가하기 위한 등록 토큰이다. (CICD - Runner Tab 등록)

 


 

Step 2. GitLab Repo 추가

$ helm repo add gitlab https://charts.gitlab.io/

$ helm repo list
NAME                    URL
stable                  https://charts.helm.sh/stable
gitlab                  https://charts.gitlab.io/

# 최신 chart 확인
$helm repo update

 


 

Step 3. role / rolebinging yaml 파일 추가(최신버전에서는 필요X)

$ cat gitlab-runner-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: gitlab-runner-role
rules:
  - apiGroups: ["extensions", "apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: [""]
    resources: ["pods","services","secrets","pods/exec", "serviceaccounts"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

$ cat gitlab-runner-role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gitlab-runner-role-binding
subjects:
- kind: ServiceAccount
  name: default
roleRef:
  kind: Role
  name: gitlab-runner-role
  apiGroup: rbac.authorization.k8s.io

 


 

Step 4. overide values.yaml 작성(legacy)

기존 values.yaml에 덮어쓰기 할 overide values.yaml을 작성해준다.

 

build.yaml과 deploy.yaml 2개를 작성해줄 것이다.

 

개발형상이 여러개라면 아래와 같이 작성하면 된다.

  • values-deploy-<dev1>.yaml / values-deploy-<dev2>.yaml

build runner는 build-image 라는 namespace를 만들어서 해당 namespace에 build용 머신을 만들어준다.

그리고 tags 부분만 수정하여 나중에 .gitlab.yml 파일에 tags 부분만 잘 작성해주면 해당 gitlab-runner에서 작동한다.

 

중요한 value는 아래와 같다.

  • gitlabUrl
  • runnerRegistrationToken
  • rbac
  • tags
# gitlab-runner image 버전을 작성 
image: gitlab/gitlab-runner:v13.0.0

# imagePullPolicy 작성
imagePullPolicy: IfNotPresent

# imagePullSecrets 작성
imagePullSecrets:
  - name: "secret"
  
# runner replicas 작성
replicas: 1

# gitlabUrl 작성
gitlabUrl: http://gitlab.example.com/

# runnerRegistrationToken 작성
runnerRegistrationToken: "<Token>" # group runner
terminationGracePeriodSeconds: 3600
concurrent: 10
checkInterval: 30

# rbac 작성
rbac:
  create: true
  rules:
    - apiGroups: ["extensions", "apps"]
      resources: ["deployments"]
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
    - apiGroups: [""]
      resources: ["pods", "services", "secrets", "pods/exec", "serviceaccounts"]
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  clusterWideAccess: true
  serviceAccountName: default
  podSecurityPolicy:
    enabled: false
    resourceNames:
    - gitlab-runner
   
metrics:
  enabled: true
runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "ubuntu:18.04"
        
# tag 작성
  tags: "build-image"
  privileged: false
...
  cache: {}
  builds: {}
  services: {}
  helpers: {}
securityContext:
  runAsUser: 999
  fsGroup: 999
resources: {}
affinity: {}
nodeSelector: {}
tolerations: []
hostAliases: []
podAnnotations: {}
podLabels: {}
#hpa: {}
secrets: []
configMaps: {}

 

Step 4. overide values.yaml 작성(최신버전v.legacy)

values.yaml이 변경되었다. 해당 내용을 참고하면 된다.

image:
  registry: registry.gitlab.com
  image: gitlab-org/gitlab-runner
  tag: alpine-v13.0.0

imagePullPolicy: IfNotPresent

imagePullSecrets:
   - name: "somaz-secret" # your image registry secrets
   
replicas: 3

gitlabUrl: http://gitlab.somaz.link/

runnerRegistrationToken: "GR1XXXXXXXXXXXXXXxx" # your runner registration token

rbac:
  create: true
  
  rules: 
    - apiGroups: ["extensions", "apps"]
      resources: ["deployments"]
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
    - apiGroups: [""]
      resources: ["pods", "services", "secrets", "pods/exec", "serviceaccounts"]
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]  

  clusterWideAccess: false

  podSecurityPolicy:
    enabled: false
    resourceNames:
    - gitlab-runner

  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "ubuntu:22.04"

  tags: "build-image"

securityContext:
  allowPrivilegeEscalation: true  # Permits elevating privileges; similar to 'sudo'.
  readOnlyRootFilesystem: false   # The root filesystem can be written to.
  runAsNonRoot: false             # Allows the process to run as the root user.
  privileged: true                # Grants the container almost all the same privileges as the host.
  capabilities:
    drop: []                      # No Linux capabilities are dropped; retains all.

 

 

Step 4. overide values.yaml 작성(최신버전v.2024-05-31)

values.yaml이 변경되었다. 해당 내용을 참고하면 된다.

image:
  registry: registry.gitlab.com
  image: gitlab-org/gitlab-runner
  tag: alpine-v17.0.0

imagePullPolicy: IfNotPresent

imagePullSecrets:
   - name: "somaz-secret" # your image registry secrets
   
replicas: 3

gitlabUrl: http://gitlab.somaz.link/

runnerToken: "glrt-xxxxx_Xxxxxxa-xxxxx" # token 값이 변경되었다.

rbac:
  create: true
  
  rules: 
    - apiGroups: ["extensions", "apps"]
      resources: ["deployments"]
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
    - apiGroups: [""]
      resources: ["pods", "pods/exec", "pods/attach", "services", "secrets", "serviceaccounts"]
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete", "attach"]

  clusterWideAccess: false

  podSecurityPolicy:
    enabled: false
    resourceNames:
    - gitlab-runner

  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        image = "ubuntu:22.04"

  tags: "build-image"

securityContext:
  allowPrivilegeEscalation: true  # Permits elevating privileges; similar to 'sudo'.
  readOnlyRootFilesystem: false   # The root filesystem can be written to.
  runAsNonRoot: false             # Allows the process to run as the root user.
  privileged: true                # Grants the container almost all the same privileges as the host.
  capabilities:
    drop: []                      # No Linux capabilities are dropped; retains all.

 

Step 5. GitLab Runner 설치

# Before installing, it's a good practice to check the available versions of the GitLab Runner Helm Chart.
helm search repo -l gitlab/gitlab-runner

# Decide on a dedicated namespace for GitLab Runner. Replace <namespace> with your desired namespace name.
kubectl create namespace <namespace>

# If you have specific security configurations or access controls, you may need to set up roles and role bindings. If you've determined it's necessary, apply the provided role and role binding configurations.
# To install
helm install -n <namespace> <release name> -f <helm values file>.yaml gitlab/gitlab-runner

# To upgrade
helm upgrade -n <namespace> <release nam> -f <helm values file>.yaml gitlab/gitlab-runner

 


Reference

 

GitLab Runner Docs

 

GitLab Runner Configure

 

Gitlab Runner Setting(인포그랩)

 

참고 기술 블로그(사람인)

 

Offical GitLab Runner Helm Chart

 

GitLab Runner documentation for Kubernetes installation

 

https://github.com/somaz94/cicd-monitoring/tree/main/gitlab-runner

728x90
반응형

'IaC > CI CD Tool' 카테고리의 다른 글

2. Github Action (With Syntax)  (0) 2023.05.22
1. Github Action이란?  (0) 2023.05.19
ArgoCD란?  (0) 2023.05.17
3. GitLab이란? / GitLab CI/CD  (0) 2023.04.24
1. GitLab이란? / 개념 및 설치  (0) 2023.04.20