파이프라인 아키텍처
파이프라인은 GitLab의 CI/CD의 기본적인 컴포넌트입니다. 이 페이지는 이와 관련된 중요한 개념들을 문서화합니다.
다양한 방법으로 파이프라인을 구성할 수 있으며, 각각에는 고유한 장점이 있습니다. 이러한 방법들은 필요에 따라 혼합하여 사용할 수 있습니다:
- 기본: 모든 구성이 한 곳에 있는 간단한 프로젝트에 적합합니다.
- 유향성 비순환 그래프: 효율적인 실행이 필요한 대규모 복잡한 프로젝트에 적합합니다.
-
상위-하위 파이프라인: 단일 리포지터리 및 독립적으로 정의된 컴포넌트가 많은 프로젝트에 적합합니다.
개요를 보려면 상위-하위 파이프라인 기능 데모를 참조하세요.
-
다중 프로젝트 파이프라인: 크로스 프로젝트 의존성이 필요한 대규모 제품에 적합하며, 마이크로서비스 아키텍처와 같은 아키텍처에 꼭 맞습니다.
예를 들어, 웹 애플리케이션을 세 가지 다른 GitLab 프로젝트에서 배포할 수 있습니다. 다중 프로젝트 파이프라인을 사용하면 각 프로젝트에서 파이프라인을 트리거할 수 있으며, 각각의 빌드, 테스트 및 배포 프로세스가 있습니다. 연결된 파이프라인을 모두 한 곳에서 시각화할 수 있으며, 모든 교차 프로젝트 의존성을 확인할 수 있습니다.
개요를 보려면 다중 프로젝트 파이프라인 데모를 참조하세요.
기본 파이프라인
기본 파이프라인은 GitLab에서 가장 간단한 파이프라인입니다. 빌드 단계의 모든 작업을 동시에 실행하고, 그 모두가 완료되면 테스트 및 이후 단계를 마찬가지로 실행합니다. 가장 효율적이지는 않지만 단계가 많을 경우 복잡해질 수 있지만 유지 관리가 쉽습니다.
다이어그램과 일치하는 기본 .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
를 시작합니다.
다이어그램과 일치하는 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 파이프라인으로 두 가지의 이점을 동시에 얻을 수 있습니다.
다이어그램과 일치하는 상위 파이프라인을 위한 /.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
일반 설정 단계 또는 통합된 배포 단계를 하위 파이프라인 트리거 전후에 실행하도록 작업을 설정할 수 있습니다.