웹사이트 검색

Ubuntu 16.04에서 GitLab CI로 지속적인 통합 파이프라인을 설정하는 방법

소개

GitLab Community Edition은 프로젝트 관리 및 소프트웨어 개발에 도움이 되는 추가 기능을 갖춘 자체 호스팅 Git 리포지토리 공급자입니다. GitLab이 제공하는 가장 중요한 기능 중 하나는 GitLab CI라는 내장된 지속적 통합 및 제공 도구입니다.

이 가이드에서는 리포지토리에서 변경 사항을 모니터링하고 자동화된 테스트를 실행하여 새 코드의 유효성을 검사하도록 GitLab CI를 설정하는 방법을 보여줍니다. 기본 Node.js 애플리케이션에 대한 예제 리포지토리를 복사할 실행 중인 GitLab 설치부터 시작하겠습니다. CI 프로세스를 구성한 후 새 커밋이 리포지토리에 푸시되면 GitLab은 CI 러너를 사용하여 격리된 Docker 컨테이너의 코드에 대해 테스트 스위트를 실행합니다.

전제 조건

시작하기 전에 초기 환경을 설정해야 합니다. 코드를 저장하고 CI/CD 프로세스를 관리하도록 구성된 안전한 GitLab 서버가 필요합니다. 또한 자동화된 테스트를 실행할 장소가 필요합니다. 이것은 GitLab이 설치된 동일한 서버이거나 별도의 호스트일 수 있습니다. 아래 섹션에서는 요구 사항에 대해 자세히 설명합니다.

SSL로 보호된 GitLab 서버

소스 코드를 저장하고 CI/CD 작업을 구성하려면 Ubuntu 16.04 서버에 설치된 GitLab 인스턴스가 필요합니다. GitLab은 현재 최소 2개의 CPU 코어와 4GB의 RAM이 있는 서버를 권장합니다. 코드가 노출되거나 변조되지 않도록 보호하기 위해 GitLab 인스턴스는 Let’s Encrypt를 사용하여 SSL로 보호됩니다. 이 단계를 완료하려면 서버에 연결된 도메인 이름 또는 하위 도메인이 있어야 합니다.

다음 자습서를 사용하여 이러한 요구 사항을 완료할 수 있습니다.

  • Ubuntu 16.04로 초기 서버 설정: sudo 사용자 생성 및 기본 방화벽 구성
  • Ubuntu 16.04에서 GitLab을 설치 및 구성하는 방법: 서버에 GitLab을 설치하고 Let’s Encrypt TLS/SSL 인증서로 보호

프로젝트 간에 CI/CD 실행기(자동 테스트를 실행하는 구성 요소)를 공유하는 방법과 이를 단일 프로젝트에 고정하는 방법을 시연할 것입니다. 프로젝트 간에 CI 러너를 공유하려면 공개 가입을 제한하거나 비활성화하는 것이 좋습니다. 설치하는 동안 설정을 수정하지 않은 경우 뒤로 돌아가서 GitLab 설치 문서의 선택적 단계에 따라 가입 제한 또는 비활성화하여 외부인의 남용을 방지하세요.

GitLab CI 실행기로 사용할 하나 이상의 서버

GitLab CI Runner는 코드를 확인하고 자동화된 테스트를 실행하여 새로운 변경 사항을 검증하는 서버입니다. 테스트 환경을 격리하기 위해 Docker 컨테이너 내에서 모든 자동화된 테스트를 실행할 것입니다. 이렇게 하려면 테스트를 실행할 서버에 Docker를 설치해야 합니다.

이 단계는 GitLab 서버 또는 다른 Ubuntu 16.04 서버에서 완료하여 추가 격리를 제공하고 리소스 경합을 방지할 수 있습니다. 다음 자습서에서는 테스트를 실행하는 데 사용할 호스트에 Docker를 설치합니다.

  • Ubuntu 16.04로 초기 서버 설정: sudo 사용자 생성 및 기본 방화벽 구성(GitLab 서버에서 CI 실행기를 설정하는 경우 이 작업을 다시 완료할 필요가 없음)
  • Ubuntu 16.04에서 Docker를 설치하고 사용하는 방법: 1단계와 2단계에 따라 서버에 Docker를 설치합니다.

시작할 준비가 되면 이 가이드를 계속 진행하세요.

GitHub에서 예제 리포지토리 복사

시작하려면 예제 Node.js 애플리케이션을 포함하는 GitLab에서 새 프로젝트를 생성합니다. 수동으로 업로드할 필요가 없도록 GitHub에서 직접 원본 리포지토리를 가져옵니다.

GitLab에 로그인하고 오른쪽 상단 모서리에 있는 더하기 아이콘을 클릭하고 새 프로젝트를 선택하여 새 프로젝트를 추가합니다.

새 프로젝트 페이지에서 프로젝트 가져오기 탭을 클릭합니다.

그런 다음 URL로 리포지토리 버튼을 클릭합니다. GitHub 가져오기 옵션이 있지만 개인 액세스 토큰이 필요하며 리포지토리 및 추가 정보를 가져오는 데 사용됩니다. 우리는 코드와 Git 기록에만 관심이 있으므로 URL로 가져오기가 더 쉽습니다.

Git 리포지토리 URL 필드에 다음 GitHub 리포지토리 URL을 입력합니다.

https://github.com/do-community/hello_hapi.git

다음과 같아야 합니다.

데모이므로 리포지토리를 비공개로 유지하는 것이 가장 좋습니다. 완료되면 프로젝트 만들기를 클릭합니다.

GitHub에서 가져온 저장소를 기반으로 새 프로젝트가 생성됩니다.

.gitlab-ci.yml 파일 이해

GitLab CI는 각 리포지토리 내에서 .gitlab-ci.yml라는 파일을 찾아 코드를 테스트하는 방법을 결정합니다. 가져온 저장소에는 프로젝트에 대해 이미 구성된 gitlab-ci.yml 파일이 있습니다. .gitlab-ci.yml 참조 문서를 읽으면 형식에 대해 자세히 알아볼 수 있습니다.

방금 생성한 프로젝트의 GitLab 인터페이스에서 .gitlab-ci.yml 파일을 클릭합니다. CI 구성은 다음과 같아야 합니다.

image: node:latest

stages:
  - build
  - test

cache:
  paths:
    - node_modules/

install_dependencies:
  stage: build
  script:
    - npm install
  artifacts:
    paths:
      - node_modules/

test_with_lab:
  stage: test
  script: npm test

이 파일은 GitLab CI YAML 구성 구문을 사용하여 수행해야 하는 작업, 실행 순서, 실행 조건 및 각 작업을 완료하는 데 필요한 리소스를 정의합니다. 자체 GitLab CI 파일을 작성할 때 GitLab 인스턴스의 /ci/lint로 이동하여 구문 린터를 방문하여 파일 형식이 올바른지 확인할 수 있습니다.

구성 파일은 테스트 스위트를 실행하는 데 사용해야 하는 Docker 이미지를 선언하는 것으로 시작합니다. Hapi는 Node.js 프레임워크이므로 최신 Node.js 이미지를 사용하고 있습니다.

image: node:latest

다음으로 실행할 다양한 지속적 통합 단계를 명시적으로 정의합니다.

stages:
  - build
  - test

여기에서 선택하는 이름은 임의적이지만 순서에 따라 이후 단계의 실행 순서가 결정됩니다. 단계는 개별 작업에 적용할 수 있는 태그입니다. GitLab은 같은 단계의 작업을 병렬로 실행하고 현재 단계의 모든 작업이 완료될 때까지 다음 단계 실행을 기다립니다. 단계가 정의되지 않은 경우 GitLab은 build, test 및 deploy의 세 단계를 사용하고 모든 작업을 test 에 할당합니다. 기본적으로 단계입니다.

단계를 정의한 후 구성에는 cache 정의가 포함됩니다.

cache:
  paths:
    - node_modules/

실행 또는 단계 사이에 캐시(나중에 사용하기 위해 저장)할 수 있는 파일 또는 디렉터리를 지정합니다. 이렇게 하면 실행 간에 변경되지 않을 수 있는 리소스에 의존하는 작업을 실행하는 데 걸리는 시간을 줄이는 데 도움이 될 수 있습니다. 여기에서 node_modules 디렉토리를 캐싱하고 있습니다. 이 디렉토리는 npm이 다운로드한 종속성을 설치할 위치입니다.

첫 번째 작업은 install_dependencies입니다.

install_dependencies:
  stage: build
  script:
    - npm install
  artifacts:
    paths:
      - node_modules/

작업 이름은 무엇이든 지정할 수 있지만 이름은 GitLab UI에서 사용되므로 설명이 포함된 이름이 도움이 됩니다. 일반적으로 npm install은 다음 테스트 단계와 결합할 수 있지만 단계 간의 상호 작용을 더 잘 보여주기 위해 이 단계를 추출하여 자체 단계에서 실행합니다.

stage 지시문을 사용하여 스테이지를 "빌드\로 명시적으로 표시합니다. 다음으로 script 지시문을 사용하여 실행할 실제 명령을 지정합니다. 다음을 추가하여 여러 명령을 포함할 수 있습니다. script 섹션 내의 추가 라인.

artifacts 하위 섹션은 저장하고 단계 간에 전달할 파일 또는 디렉터리 경로를 지정하는 데 사용됩니다. npm install 명령은 프로젝트에 대한 종속성을 설치하므로 다음 단계에서는 다운로드한 파일에 액세스해야 합니다. node_modules 경로를 선언하면 다음 단계에서 파일에 액세스할 수 있습니다. 테스트 후 GitLab UI에서 보거나 다운로드할 수도 있으므로 바이너리와 같은 빌드 아티팩트에도 유용합니다. 단계 중에 생성된 모든 것을 저장하려면 전체 paths 섹션을 untracked: true로 바꾸십시오.

마지막으로 test_with_lab이라는 두 번째 작업은 테스트 스위트를 실제로 실행할 명령을 선언합니다.

test_with_lab:
  stage: test
  script: npm test

이것을 test 단계에 배치합니다. 이것은 나중 단계이므로 우리의 경우 프로젝트 종속성인 빌드 단계에서 생성된 아티팩트에 액세스할 수 있습니다. 여기서 script 섹션은 단일 항목만 있을 때 사용할 수 있는 한 줄 YAML 구문을 보여줍니다. 명령이 하나만 지정되었으므로 이전 작업에서도 이와 동일한 구문을 사용할 수 있었습니다.

이제 .gitlab-ci.yml 파일이 CI/CD 작업을 정의하는 방법에 대한 기본적인 아이디어를 얻었으므로 테스트 계획을 실행할 수 있는 하나 이상의 실행기를 정의할 수 있습니다.

연속 통합 실행 트리거

저장소에는 .gitlab-ci.yml 파일이 포함되어 있으므로 새 커밋은 새 CI 실행을 트리거합니다. 사용 가능한 러너가 없으면 CI 실행이 "보류 중\으로 설정됩니다. 러너를 정의하기 전에 CI 실행을 트리거하여 보류 상태에서 작업이 어떻게 보이는지 확인하겠습니다. 러너를 사용할 수 있게 되면 즉시 실행됩니다. 보류중인 실행을 선택하십시오.

hello_hapi GitLab 프로젝트 리포지토리 보기로 돌아가 브랜치 및 프로젝트 이름 옆에 있는 더하기 기호를 클릭하고 메뉴에서 새 파일을 선택합니다.

다음 페이지에서 파일 이름 필드에 dummy_file을 입력하고 기본 편집 창에 텍스트를 입력합니다.

완료되면 하단의 변경 사항 커밋을 클릭합니다.

이제 기본 프로젝트 페이지로 돌아갑니다. 작은 일시 중지 아이콘이 가장 최근 커밋에 첨부됩니다. 아이콘 위로 마우스를 가져가면 "Commit:pending\이 표시됩니다.

이는 코드 변경을 검증하는 테스트가 아직 실행되지 않았음을 의미합니다.

자세한 정보를 보려면 페이지 상단으로 이동하여 파이프라인을 클릭하십시오. 파이프라인 개요 페이지로 이동하여 CI 실행이 보류 중으로 표시되고 "stuck\ 레이블이 지정되었음을 확인할 수 있습니다.

참고: 오른쪽에는 CI Lint 도구용 버튼이 있습니다. 여기에서 작성한 gitlab-ci.yml 파일의 구문을 확인할 수 있습니다.

여기에서 보류 상태를 클릭하여 실행에 대한 자세한 정보를 얻을 수 있습니다. 이 보기에는 실행의 여러 단계와 각 단계와 관련된 개별 작업이 표시됩니다.

마지막으로 install_dependencies 작업을 클릭합니다. 이것은 실행을 지연시키는 것에 대한 구체적인 세부 정보를 제공합니다.

여기서 메시지는 러너 부족으로 인해 작업이 중단되었음을 나타냅니다. 아직 구성하지 않았기 때문에 이것은 예상됩니다. 러너를 사용할 수 있게 되면 동일한 인터페이스를 사용하여 출력을 볼 수 있습니다. 빌드 중에 생성된 아티팩트를 다운로드할 수 있는 위치이기도 합니다.

이제 보류 중인 작업이 어떤 모양인지 알았으므로 보류 중인 작업을 선택하기 위해 프로젝트에 CI 러너를 할당할 수 있습니다.

GitLab CI Runner 서비스 설치

이제 GitLab CI 러너를 설정할 준비가 되었습니다. 이렇게 하려면 시스템에 GitLab CI 러너 패키지를 설치하고 GitLab 러너 서비스를 시작해야 합니다. 이 서비스는 서로 다른 프로젝트에 대해 여러 러너 인스턴스를 실행할 수 있습니다.

전제 조건에서 언급한 대로 리소스 경합을 피하려면 GitLab 인스턴스를 호스팅하는 동일한 서버 또는 다른 서버에서 이러한 단계를 완료할 수 있습니다. 어떤 호스트를 선택하든 사용할 구성을 위해 Docker가 설치되어 있어야 합니다.

GitLab CI Runner 서비스를 설치하는 과정은 GitLab 자체를 설치하는 과정과 유사합니다. apt 소스 목록에 GitLab 리포지토리를 추가하는 스크립트를 다운로드합니다. 스크립트를 실행한 후 러너 패키지를 다운로드합니다. 그런 다음 GitLab 인스턴스를 제공하도록 구성할 수 있습니다.

최신 버전의 GitLab CI 러너 리포지토리 구성 스크립트를 /tmp 디렉터리(GitLab 서버에서 사용하는 것과 다른 리포지토리)에 다운로드하여 시작합니다.

  1. curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh -o /tmp/gl-runner.deb.sh

다운로드한 스크립트를 자유롭게 검토하여 수행할 작업에 익숙한지 확인하십시오. 여기에서 스크립트의 호스팅된 버전을 찾을 수도 있습니다.

  1. less /tmp/gl-runner.deb.sh

스크립트의 안전성에 만족하면 설치 프로그램을 실행합니다.

  1. sudo bash /tmp/gl-runner.deb.sh

스크립트는 GitLab 유지 관리 리포지토리를 사용하도록 서버를 설정합니다. 이를 통해 다른 시스템 패키지에 사용하는 것과 동일한 패키지 관리 도구로 GitLab 실행기 패키지를 관리할 수 있습니다. 이 작업이 완료되면 apt-get을 사용하여 설치를 진행할 수 있습니다.

  1. sudo apt-get install gitlab-runner

이렇게 하면 시스템에 GitLab CI 러너 패키지가 설치되고 GitLab 러너 서비스가 시작됩니다.

GitLab 실행기 설정

다음으로 작업 수락을 시작할 수 있도록 GitLab CI 러너를 설정해야 합니다.

이렇게 하려면 러너가 GitLab 서버에서 인증할 수 있도록 GitLab 러너 토큰이 필요합니다. 필요한 토큰 유형은 이 러너를 사용하려는 방법에 따라 다릅니다.

러너에 대한 특정 요구 사항이 있는 경우 프로젝트별 러너가 유용합니다. 예를 들어 gitlab-ci.yml 파일이 자격 증명이 필요한 배포 작업을 정의하는 경우 배포 환경에 올바르게 인증하려면 특정 실행기가 필요할 수 있습니다. 프로젝트에 CI 프로세스에 리소스 집약적인 단계가 있는 경우 이 방법도 좋은 생각일 수 있습니다. 프로젝트별 러너는 다른 프로젝트의 작업을 수락하지 않습니다.

반면 공유 러너는 여러 프로젝트에서 사용할 수 있는 범용 러너입니다. 실행자는 각 프로젝트에 대해 현재 실행 중인 작업 수를 설명하는 알고리즘에 따라 프로젝트에서 작업을 가져옵니다. 이 유형의 주자는 더 유연합니다. 공유 러너를 설정하려면 관리자 계정으로 GitLab에 로그인해야 합니다.

아래에서 이러한 두 러너 유형 모두에 대한 러너 토큰을 얻는 방법을 시연할 것입니다. 가장 적합한 방법을 선택하십시오.

프로젝트별 러너 등록을 위한 정보 수집

러너를 특정 프로젝트에 연결하려면 먼저 GitLab 인터페이스에서 프로젝트 페이지로 이동하세요.

여기에서 왼쪽 메뉴의 설정 항목을 클릭합니다. 그런 다음 하위 메뉴에서 CI/CD 항목을 클릭합니다.

이 페이지에는 러너 설정 섹션이 표시됩니다. 확장 버튼을 클릭하시면 자세한 내용을 보실 수 있습니다. 상세보기에서 왼쪽에는 프로젝트별 주자를 등록하는 방법이 설명되어 있습니다. 지침의 4단계에 표시된 등록 토큰을 복사합니다.

이 프로젝트에 대한 활성 공유 러너를 비활성화하려면 오른쪽에 있는 공유 러너 비활성화 버튼을 클릭하면 됩니다. 이것은 선택 사항입니다.

준비가 되면 이 페이지에서 수집한 정보를 사용하여 러너를 등록하는 방법을 알아보기 위해 건너뛰십시오.

공유러너 등록을 위한 정보 수집

공유주자 등록에 필요한 정보를 찾기 위해서는 관리자 계정으로 로그인해야 합니다.

관리 영역에 액세스하려면 상단 탐색 모음에서 렌치 아이콘을 클릭하여 시작하십시오. 왼쪽 메뉴의 개요 섹션에서 러너를 클릭하여 공유 러너 구성 페이지에 액세스합니다.

페이지 상단에 표시된 등록 토큰을 복사합니다.

이 토큰을 사용하여 프로젝트의 GitLab CI 러너를 등록합니다.

GitLab 서버에 GitLab CI Runner 등록

이제 토큰이 있으므로 GitLab CI 실행기 서비스가 설치된 서버로 돌아갑니다.

새 러너를 등록하려면 다음 명령을 입력하십시오.

  1. sudo gitlab-runner register

실행기를 구성하기 위한 일련의 질문을 받게 됩니다.

gitlab-ci 코디네이터 URL(예: https://gitlab.com/)을 입력하세요.

https://를 사용하여 SSL을 지정하여 GitLab 서버의 도메인 이름을 입력합니다. 선택적으로 도메인 끝에 /ci를 추가할 수 있지만 최신 버전은 자동으로 리디렉션됩니다.

이 러너에 대한 gitlab-ci 토큰을 입력하십시오

마지막 섹션에서 복사한 토큰입니다.

이 러너에 대한 gitlab-ci 설명을 입력하십시오.

이 특정 주자의 이름입니다. 이것은 커맨드 라인과 GitLab 인터페이스에 있는 러너 서비스의 러너 목록에 표시됩니다.

이 러너에 대한 gitlab-ci 태그를 입력하십시오(쉼표로 구분).

러너에게 할당할 수 있는 태그입니다. GitLab 작업은 올바른 종속성이 있는 호스트에서 실행되도록 이러한 태그 측면에서 요구 사항을 표현할 수 있습니다.

이 경우 비워 둘 수 있습니다.

Runner를 현재 프로젝트에 잠글지 여부 [true/false]

러너를 특정 프로젝트에 할당합니다. 다른 프로젝트에서는 사용할 수 없습니다.

여기서 "false\를 선택하십시오.

실행자를 입력하세요.

작업을 완료하기 위해 러너가 사용하는 방법입니다.

여기서 "docker\를 선택합니다.

기본 Docker 이미지(예: ruby:2.1)를 입력하세요.

.gitlab-ci.yml 파일에 이미지 사양이 포함되지 않은 경우 작업을 실행하는 데 사용되는 기본 이미지입니다. 여기에서 일반적인 이미지를 지정하고 우리가 한 것처럼 .gitlab-ci.yml 파일에서 보다 구체적인 이미지를 정의하는 것이 가장 좋습니다.

여기에 작은 보안 기본값으로 "alpine:latest\를 입력합니다.

프롬프트에 응답하면 프로젝트의 CI/CD 작업을 실행할 수 있는 새 러너가 생성됩니다.

다음을 입력하면 현재 GitLab CI 러너 서비스에서 사용할 수 있는 러너를 볼 수 있습니다.

  1. sudo gitlab-runner list



Output
Listing configured runners                          ConfigFile=/etc/gitlab-runner/config.toml
example-runner                                      Executor=docker Token=e746250e282d197baa83c67eda2c0b URL=https://example.com

이제 러너를 사용할 수 있으므로 GitLab의 프로젝트로 돌아갈 수 있습니다.

GitLab에서 CI/CD 실행 보기

웹 브라우저로 돌아가서 GitLab의 프로젝트로 돌아갑니다. 러너를 등록한 후 얼마나 오래되었는지에 따라 러너가 현재 실행 중일 수 있습니다.

또는 이미 완료되었을 수 있습니다.

상태와 관계없이 CI 실행의 현재 상태를 보려면 실행 중 또는 통과 아이콘(또는 문제가 발생한 경우 실패)을 클릭하십시오. 상단 파이프라인 메뉴를 클릭하여 비슷한 보기를 얻을 수 있습니다.

GitLab CI 실행 상태를 볼 수 있는 파이프라인 개요 페이지로 이동합니다.

단계 헤더 아래에는 실행 중인 각 단계의 상태를 나타내는 원이 있습니다. 단계를 클릭하면 단계와 관련된 개별 작업을 볼 수 있습니다.

빌드 단계 내에서 install_dependencies 작업을 클릭하십시오. 이렇게 하면 작업 개요 페이지로 이동합니다.

이제 사용 가능한 러너가 없다는 메시지를 표시하는 대신 작업 출력이 표시됩니다. 우리의 경우 이것은 각 패키지를 설치한 npm의 결과를 볼 수 있음을 의미합니다.

오른쪽을 따라 다른 항목도 볼 수 있습니다. 단계를 변경하고 아래의 실행을 클릭하면 다른 작업을 볼 수 있습니다. 실행으로 생성된 모든 아티팩트를 보거나 다운로드할 수도 있습니다.

결론

이 가이드에서는 GitLab CI의 지속적인 통합 및 배포 기능을 보여주기 위해 GitLab 인스턴스에 데모 프로젝트를 추가했습니다. gitlab-ci.yml 파일에서 파이프라인을 정의하여 애플리케이션을 빌드하고 테스트하는 방법과 단계에 작업을 할당하여 서로의 관계를 정의하는 방법에 대해 논의했습니다. 그런 다음 GitLab CI 러너를 설정하여 프로젝트에 대한 CI 작업을 선택하고 개별 GitLab CI 실행에 대한 정보를 찾는 방법을 시연했습니다.