GitLab CICD

GitLap Runner

• GitLab Runner는 GitLab CI/CD 파이프라인에서 Job을 실행하는 애플리케이션
  • GitLab에 푸시한 코드를 자동으로 테스트, 빌드, 배포 등을 실행하는 작업을 실제로 수행하는 역할이 GitLab Runner
• Self-managed Runner
  • 직접 설치하고 관리하는 Runner를 의미
  • GitLab에서 기본 제공하는 “GitLab-hosted Runner”도 있지만, 이건 GitLab이 관리
  • Self-managed Runner는 사용자가 자신의 서버, 클라우드, 또는 로컬 머신에 설치해서 쓰는 방식
• GRIT (GitLab Runner Infrastructure Toolkit)
  • GRIT은 Terraform 모듈들의 라이브러리입니다.
  • 여러 개의 Runner를 클라우드 환경에서 쉽게 만들고 설정할 수 있도록 도와줌.
  • AWS, GCP, Azure 같은 퍼블릭 클라우드 환경에서 Runner를 구축하는 데 유용.
  • GitLab의 Runner 팀이 직접 개발하고 유지보수하는 공식 툴.
  • GRIT을 사용하는 이유
    • 반복적인 Runner 설정을 코드로 자동화 가능
    • Terraform으로 인프라 상태를 버전 관리 및 추적 가능
    • 확장성과 유연성이 높아 수십, 수백 대의 Runner도 일관되게 배포 가능
• Runner가 Job을 처리하는 방식
  • Runner는 일반적으로 GitLab Runner를 설치한 그 머신에서 Job을 처리.
  • 다른 방법도 가능 (아래 방법 외에도 다양)로컬 머신 Runner를 설치한 서버에서 바로 Job실헹 Shell Executor

    도커 컨테이너 실행	Job마다 컨테이너를 생성해서 실행	Docker Executor
    ssh 접속해 실행	원격 서버에 ssh로 접속해 실행	SSH Executor

• Executor : Runner가 Job을 어떤 환경에서 실행할지 결정하는 방식
• Executor로 도커 선택시 job 실행 과정 정리
  • 깃랩은 .gitlab-ci.yml를 미리 읽고 정보를 파싱해놓음
  • Runner는 주기적으로 POST /api/v4/jobs/request API를 호출하여 실행할 작업이 있는지 물어봄
  • 깃랩이 파싱해놓은 정보를 json형태로 body에 담아 응답
    • commands : 실행 스크립트 명령어 정보

    {
      "commands": "npm install\\nnpm run build",
      "image": {"name": "node:18"},
      ...
    }
    

  • 러너는 응답 정보(docker image 등)를 이용해 컨테이너 생성
  • 컨테이너 내부에서 commands 정보를 이용해 쉘 스크립트 생성
  • 쉘 스크립트 실행
  • 완료 후 job 성공 실패에 상관 없이 컨테이너 삭제
• Docker-in-Docker?
  • Runner도 컨테이너, Job도 컨테이너에서 실행되는 환경

  [호스트 머신]
  ├── [GitLab Runner 컨테이너]
  │     └── docker.sock 공유
  │     └── Runner는 명령어로 Job 컨테이너 생성 요청
  │
  ├── [Job 컨테이너] ← 여기가 실제 스크립트가 실행되는 곳!
  

• Executor가 SSH 방식인 경우
  1. .gitlab-ci.yml 파일을 GitLab에서 파싱
  2. GitLab이 Runner에 Job을 전달 (script 포함된 JSON 형식)
  3. Runner가 .gitlab-ci.yml의 script 내용을 받아옴
  4. Runner가 ssh로 지정된 원격 서버에 접속
  5. Runner가 cd로 작업 디렉토리 이동 후,
  6. 받은 script 명령어들을 순서대로 실행'
• tag를 통해 어떤 Runner를 사용할지 알 수 있음
• artifac