파이프라인 아키텍처

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

파이프라인은 GitLab의 CI/CD의 기본적인 컴포넌트입니다. 이 페이지는 이와 관련된 중요한 개념들을 문서화합니다.

다양한 방법으로 파이프라인을 구성할 수 있으며, 각각에는 고유한 장점이 있습니다. 이러한 방법들은 필요에 따라 혼합하여 사용할 수 있습니다:

  • 기본: 모든 구성이 한 곳에 있는 간단한 프로젝트에 적합합니다.
  • 유향성 비순환 그래프: 효율적인 실행이 필요한 대규모 복잡한 프로젝트에 적합합니다.

  • 상위-하위 파이프라인: 단일 리포지터리 및 독립적으로 정의된 컴포넌트가 많은 프로젝트에 적합합니다.

    개요를 보려면 상위-하위 파이프라인 기능 데모를 참조하세요.

  • 다중 프로젝트 파이프라인: 크로스 프로젝트 의존성이 필요한 대규모 제품에 적합하며, 마이크로서비스 아키텍처와 같은 아키텍처에 꼭 맞습니다.

    예를 들어, 웹 애플리케이션을 세 가지 다른 GitLab 프로젝트에서 배포할 수 있습니다. 다중 프로젝트 파이프라인을 사용하면 각 프로젝트에서 파이프라인을 트리거할 수 있으며, 각각의 빌드, 테스트 및 배포 프로세스가 있습니다. 연결된 파이프라인을 모두 한 곳에서 시각화할 수 있으며, 모든 교차 프로젝트 의존성을 확인할 수 있습니다.

    개요를 보려면 다중 프로젝트 파이프라인 데모를 참조하세요.

기본 파이프라인

기본 파이프라인은 GitLab에서 가장 간단한 파이프라인입니다. 빌드 단계의 모든 작업을 동시에 실행하고, 그 모두가 완료되면 테스트 및 이후 단계를 마찬가지로 실행합니다. 가장 효율적이지는 않지만 단계가 많을 경우 복잡해질 수 있지만 유지 관리가 쉽습니다.

graph LR subgraph deploy stage deploy --> deploy_a deploy --> deploy_b end subgraph test stage test --> test_a test --> test_b end subgraph build stage build --> build_a build --> build_b end build_a -.-> test build_b -.-> test test_a -.-> deploy test_b -.-> deploy

다이어그램과 일치하는 기본 .gitlab-ci.yml 파이프라인 구성 예제: 

stages:
  - build
  - test
  - deploy

default:
  image: alpine

build_a:
  stage: build
  script:
    - echo "이 작업은 무언가를 빌드합니다."

build_b:
  stage: build
  script:
    - echo "이 작업은 다른 무언가를 빌드합니다."

test_a:
  stage: test
  script:
    - echo "이 작업은 무언가를 테스트합니다. 모든 빌드 단계가 완료되면 실행됩니다."

test_b:
  stage: test
  script:
    - echo "이 작업은 다른 무언가를 테스트합니다. 이 또한 모든 빌드 단계가 완료될 때 실행됩니다. test_a와 거의 동시에 시작됩니다."

deploy_a:
  stage: deploy
  script:
    - echo "이 작업은 무언가를 배포합니다. 테스트 단계가 모두 완료된 후에만 실행됩니다."
  environment: production

deploy_b:
  stage: deploy
  script:
    - echo "이 작업은 다른 무언가를 배포합니다. 테스트 단계가 모두 완료된 후에만 실행됩니다. deploy_a와 거의 동시에 시작됩니다."
  environment: production

유향성 비순환 그래프 파이프라인

효율성이 중요하고 모든 작업을 가능한 빨리 실행하고 싶다면 유향성 비순환 그래프 (DAG)를 사용할 수 있습니다. 작업 간의 의존성 관계를 정의하기 위해 needs 키워드를 사용합니다. GitLab이 작업 간의 관계를 알고 있으면 가능한 빨리 모든 작업을 실행하며, 가능하면 후속 단계로 건너뛸 수도 있습니다.

아래 예시에서, 만약 build_a와 test_a가 build_b와 test_b보다 훨씬 빠르다면, GitLab은 build_b가 아직 실행 중일지라도 deploy_a를 시작합니다.

graph LR subgraph 유향성 비순환 그래프 파이프라인 build_a --> test_a --> deploy_a build_b --> test_b --> deploy_b end

다이어그램과 일치하는 DAG .gitlab-ci.yml 파이프라인 구성 예제: 

stages:
  - build
  - test
  - deploy

default:
  image: alpine

build_a:
  stage: build
  script:
    - echo "이 작업은 무언가를 빠르게 빌드합니다."

build_b:
  stage: build
  script:
    - echo "이 작업은 다른 무언가를 느리게 빌드합니다."

test_a:
  stage: test
  needs: [build_a]
  script:
    - echo "이 테스트 작업은 build_a가 완료되자마자 시작합니다."
    - echo "build_b나 빌드 단계의 다른 작업들이 완료될 때를 기다리지 않습니다."

test_b:
  stage: test
  needs: [build_b]
  script:
    - echo "이 테스트 작업은 build_b가 완료되자마자 시작합니다."
    - echo "빌드 단계의 다른 작업이 완료될 때를 기다리지 않습니다."

deploy_a:
  stage: deploy
  needs: [test_a]
  script:
    - echo "build_a와 test_a가 빠르게 실행되므로 이 배포 작업은 훨씬 빨리 실행될 수 있습니다."
    - echo "build_b나 test_b를 기다릴 필요가 없습니다."
  environment: production

deploy_b:
  stage: deploy
  needs: [test_b]
  script:
    - echo "build_b와 test_b가 느리게 실행되므로 이 배포 작업은 훨씬 늦게 실행됩니다."
  environment: production

상위-하위 파이프라인

파이프라인이 더 복잡해지면 몇 가지 관련된 문제가 발생할 수 있습니다:

  • 단계별 구조는 각 단계의 모든 작업이 다음 단계의 첫 번째 작업이 시작되기 전에 완료될 필요가 있어서 시간이 지연되는 문제가 발생합니다.
  • 단일 전역 파이프라인의 구성이 관리하기 어려워집니다.
  • include를 통한 가져오기는 구성의 복잡성을 증가시키며, 작업이 의도치 않게 중복될 수 있는 네임스페이스 충돌을 일으킬 수 있습니다.
  • 파이프라인 UX에 작업이 너무 많아지며, 이로 인해 처리해야 할 단계도 많아집니다.

또한 때로는 파이프라인의 동작을 더 다이나믹하게 만들어야 할 필요가 있습니다. YAML이 동적으로 생성된다면 이를 선택하여 하위 파이프라인을 시작하거나 시작하지 않을 수 있는 능력은 매우 강력합니다.

상위 파이프라인 확장된 그래프

위의 기본 파이프라인 및 유향성 비순환 그래프 예제에서 독립적으로 빌드할 수 있는 두 가지 패키지가 있을 수 있습니다. 이러한 경우 상위-하위 파이프라인을 사용하는 것이 이상적입니다. 구성을 여러 파일로 분리하여 간단하게 유지할 수 있습니다. 상위-하위 파이프라인을 다음과 결합할 수 있습니다:

  • rules 키워드: 예를 들어 해당 영역에 변경 사항이 있을 때에만 하위 파이프라인을 트리거합니다.
  • include 키워드: 공통 동작을 가져와 중복을 방지합니다.
  • 하위 파이프라인 내부의 DAG 파이프라인으로 두 가지의 이점을 동시에 얻을 수 있습니다.
graph LR subgraph 상위 파이프라인 trigger_a -.-> build_a trigger_b -.-> build_b subgraph 하위 파이프라인 B build_b --> test_b --> deploy_b end subgraph 하위 파이프라인 A build_a --> test_a --> deploy_a end end

다이어그램과 일치하는 상위 파이프라인을 위한 /.gitlab-ci.yml 구성 예제: 

stages:
  - triggers

trigger_a:
  stage: triggers
  trigger:
    include: a/.gitlab-ci.yml
  rules:
    - changes:
        - a/*

trigger_b:
  stage: triggers
  trigger:
    include: b/.gitlab-ci.yml
  rules:
    - changes:
        - b/*

독립적으로 빌드할 수 있는 두 개의 하위 파이프라인의 예제인 a 디렉터리에 위치한 하위 a 파이프라인 구성, DAG needs 키워드를 사용하는 예제: 

stages:
  - build
  - test
  - deploy

default:
  image: alpine

build_a:
  stage: build
  script:
    - echo "이 작업은 무언가를 빌드합니다."

test_a:
  stage: test
  needs: [build_a]
  script:
    - echo "이 작업은 무언가를 테스트합니다."

deploy_a:
  stage: deploy
  needs: [test_a]
  script:
    - echo "이 작업은 무언가를 배포합니다."
  environment: production

독립적으로 빌드할 수 있는 두 개의 하위 파이프라인의 예제인 b 디렉터리에 위치한 하위 b 파이프라인 구성, DAG needs 키워드를 사용하는 예제: 

stages:
  - build
  - test
  - deploy

default:
  image: alpine

build_b:
  stage: build
  script:
    - echo "이 작업은 다른 무언가를 빌드합니다."

test_b:
  stage: test
  needs: [build_b]
  script:
    - echo "이 작업은 다른 무언가를 테스트합니다."

deploy_b:
  stage: deploy
  needs: [test_b]
  script:
    - echo "이 작업은 다른 무언가를 배포합니다."
  environment: production

일반 설정 단계 또는 통합된 배포 단계를 하위 파이프라인 트리거 전후에 실행하도록 작업을 설정할 수 있습니다.