220629 수 GitLab CI Runners & Executors 간단한 가이드

• GitLab CI Runners & Executors 간단한 가이드
  • Executors
  • 현재 내가 사용하고 있는 Runner 확인하기
  • Shell executor
  • SSH executor
  • VirtualBox/Parallels Executor
  • Docker executor
  • Docker Machine executor
  • Kubernetes executor

GitLab CI Runners & Executors 간단한 가이드

Executors

GitLab CI 작업을 위한 자체 인프라를 생성하려면 자체 GitLab Runner를 호스팅해야 합니다.
하지만 Shell, SSH, 도커 등 어떤 Executor를 선택해야 할지 혼란스러울 수 있습니다.

GitLab CI는 젠킨스와 같은 더 전통적인 CI 서버의 기본 설치와 달리 다른 구조를 사용합니다.

GitLab 서버는 GitLab Runner는 다른 서버의 어딘가에 위치해 있어야 하며, 작업을 GitLab Runner에게 위임합니다.

• Job : 파이프라인의 가장 작은 구성 요소로, 실행해야 하는 하나 이상의 명령이 포함되어 있습니다.
• Runner : GitLab 서버와 다른 곳에 위치한 서버에 설치된 에이전트입니다. GitLab Runner는 GitLab 서버로부터 실행할 작업에 대한 지시를 받습니다. 각 runner 는 GitLab 서버에 등록되어야 합니다.
• Executors : 각 실행자는 하나 이상의 executor를 정의합니다. 하나의 executor는 본질적으로 작업이 실행될 환경입니다.

GiLab 을 사용하면, 필요에 따라 다른 executors 를 사용할 수 있습니다.

• Shell
• SSH
• VirtualBox
• Parallels
• Docker
• Docker Machine
• Kubernetes

가장 최고의 executors 라는 것은 특별히 없습니다. 각 executor 는 고유의 use case 를 가지고 있으므로 어느 것이 가장 적합한지 이해하기 위해 다양하게 숙지하는 것이 가장 좋습니다.

현재 내가 사용하고 있는 Runner 확인하기

많은 사람들이 GitLab CI를 사용하고 있지만 뒤에서 정확히 어떤 일이 일어나는지는 모릅니다.
실행 중인 작업(job)의 위치와 사용 중인 실행자(executor) 유형을 모를 경우 이 작업을 수행해야 합니다.

GitLab으로 이동하여 파이프라인이 있는 프로젝트를 엽니다. 파이프라인을 확인해서 파이프라인 stage 를 클릭한 후 job 을 선택합니다.

여기서 해당 작업에 대한 로그를 볼 수 있습니다. 로그에서는 사용자가 찾고 있는 내용을 제공합니다.

위 스크린샷에서는 아래와 같은 정보를 확인할 수 있습니다.

• the version of the runner (14.3.0-rc1)
• where it is running (docker-auto-scale)
• which executor is being used (docker+machine)

Shell executor

executor는 runner 가 설치된 기기에서 작업(job)을 실행하고 있습니다. 젠킨스가 작업을 실행하는 방법과 유사합니다.

작업 설정에서(job configuration) Docker 이미지를 지정하면, 셸 실행자(shell executor)는 Docker가 설치되어 있더라도 이를 무시합니다.

즉, 서버에 필요한 모든 dependency 들이 설치되어 있어야 합니다. 예를 들어 작업을 실행하는 데 Node.js가 필요한 경우 Runner가 설치된 시스템에 Node.js를 설치해야 합니다.

필요한 모든 것을 runtime에 이미 사용할 수 있기 때문에 작업이 매우 빠르게 실행됩니다. Git 저장소도 사용할 수 있으므로 최신 변경 사항만 가져옵니다.(fetch)

• 언제 사용하나요?
  • Native 실행 환경이(Native-run environment) 정말로 필요한 경우(예: 소프트웨어가 특정 OS 또는 하드웨어에서 실행되는지 확인해야 함)
• 고려해야 할 사항
  • 사용 중인 버전과 같이, environment가 명확하게 문서화되지는 않았습니다. 나중에 작업을 다른 인프라로 이동할 때는 작업에 필요한 종속성과 버전을 파악해야 합니다.
  • 이전 job에서 "남은 것(left-over)"이 있고, 깨끗한 빌드 환경이 없습니다.
  • 두 개의 다른 버전이 필요한 경우(예를 들어 한 프로젝트에 PHP v7과 다른 PHP v8이 필요한 경우) 종속성을 관리하는 것이 더 어려울 수 있습니다.
  • 이 실행기에서 실행 중인 다른 작업은 다른 프로젝트와 해당 비밀에 액세스할 수 있으므로 해당 작업을 완전히 신뢰해야 합니다.

SSH executor

SSH executor를 사용하면 SSH를 통해 시스템에 명령을 전송할 수 있습니다. 이 Executor는 Shell Executor와 매우 유사하지만 Bash 스크립트에서만 작동합니다.

명령이 SSH를 통해 전송되기 때문에 Shell Executor 에 비해 더 높은 수준의 보안을 허용합니다. 명령어는 명령이 전체 파일 시스템에 액세스할 수 없기 때문입니다.

• 언제 사용하나요?
  • SSH를 사용하여 GitLab Runner 실행 머신에 연결할 수 있습니다.
  • 작업(jobs)이 실행되고있는 머신에 GitLab Runner 가 없거나 설치되기를 원하지 않는경우 작업을 실행합니다.
• 고려해야 할 사항
  • 사용 중인 버전과 같이, environment가 명확하게 문서화되지 않았습니다. 나중에 작업을 다른 인프라로 이동할 때는 작업에 필요한 종속성과 버전을 파악해야 합니다.
  • 이전 job에서 "남은 것(left-over)"이 있고, 깨끗한 빌드 환경이 없습니다.
  • 두 개의 다른 버전이 필요한 경우(예를 들어 한 프로젝트에 PHP v7과 다른 PHP v8이 필요한 경우) 종속성을 관리하는 것이 더 어려울 수 있습니다.
  • 작업 아티팩트를(job artifact) 업로드하려면 추가 구성/문제 해결이 필요할 수 있습니다.

VirtualBox/Parallels Executor

VirtualBox/Parallels는 모두 가상화 툴입니다. 완전히 가상화된 방식으로 작동하는 OS를 시작할 수 있습니다.

GitLab CI 파이프라인의 맥락에서 모든 작업이 가상화된 환경을 시작합니다.

• 언제 사용하나요?
  • 가상화를 통해서만 필요한 빌드 환경을 구축할 수 있는 경우(예: 서로 다른 운영 체제에 대해 테스트해야 함)
  • 조직 내에서 도커가 완전히 채택되지 않거나 이해되지 않을 때.
  • VirtualBox/Parallels를 더 잘 이해하고 이미 다른 목적(예: 개발 환경)에 사용되는 경우.
• 고려해야 할 사항
  • 작업을 실행하기 전에 운영 체제를 시작하는 오버헤드가 있습니다.
  • 작업이 실패하면 디버깅하기가 어렵습니다.
  • 가상화된 환경에 대한 연결이 SSH를 통해 이루어지면 연결 문제가 발생할 수 있습니다
    (예: 오류: 작업 실패(시스템 오류): ssh Dial() 오류: ssh: 핸드쉐이크 실패: read tcp 127.0.0.1:49401->127.0.0.1:42655: read: connection reset by 피어).
  • 작업 아티팩트를 업로드하려면 추가 구성/문제 해결이 필요할 수 있습니다.

Docker executor

사용할 Docker 컨테이너가 파이프라인에 정의됩니다. 이를 통해 매우 간단한 실행 환경을 구현할 수 있습니다. 이 기능은 기본적으로 윈도우를 포함한 모든 운영 체제(도커 윈도우 실행자 포함)에서 잘 동작합니다.

시스템에서 여러 작업(jobs)을 아무런 간섭 없이 실행할 수 있습니다. (퍼포먼스 성능 제외)

대부분의 프로젝트에는 Docker 환경을 사용하는것을 추천합니다. 모든 dependency 는 Docker 이미지와 파이프라인 Configuration 에 정의됩니다.

• 언제 사용하나요?
  • 모든 작업(jobs) 를 위해 환경을 정리해야할 때
  • 프로젝트가 각자 독립적으로 운영되어야 할 때
• 고려해야 할 사항
  • 모든 작업 실행에 대해 도커 이미지를 풀링(다운로드)하는 오버헤드입니다.

Docker Machine executor

작업이 실행되는 방식에 있어 도커 시스템 실행자는 Docker Executor 과 크게 다르지 않습니다. 이 Executor는 자동 확장 기능에 중점을 둡니다.

Docker Machine은 Docker가 만든 도구입니다. Docker 관계자들은 Docker Machine 은 "Machine을 사용하면 컴퓨터, 클라우드 공급자 및 데이터 센터 내부에 Docker 호스트를 생성할 수 있습니다. 서버를 만들고 서버에 Docker를 설치한 다음 Docker 클라이언트가 서버와 통신하도록 구성합니다." 라고 설명합니다.

그러나 이 기술은 더 이상 사용되지 않고 현재 GitLab은 이에 대한 대안을 찾고 있다고 합니다.

• 언제 사용하나요?
  • 구축 인프라를 확장해야 할 경우
• 고려해야 할 사항
  • Docker Machine은 이제 더 이상 사용되지 않으므로 교체를 염두해야합니다.

Kubernetes executor

프로젝트에 Kubernetes를 사용하고 있고 그 의미를 이해하고 있다면 이 Executor 를 사용하는 것이 좋습니다.

GitLab CI 작업 context 에서 GitLab Runner는 Kubernetes 클러스터에서 작업을 실행합니다. 이러한 방식으로 각 작업은 자체 pod를 갖게 됩니다.

• 언제 사용하나요?
  • 빌드 인프라를 확장해야 하는 경우
  • 기존 Kubernetes 클러스터가 있는 경우.

---

출처 : medium.com/devops-with-valentine