기본적으로 GitLab CI/CD의 파이프라인은 동시에 실행됩니다. 동시성은 머지 리퀘스트에서 피드백 루프를 개선하는 중요한 요소이지만, 배포 잡의 동시성을 제한하여 하나씩 실행하고 싶은 경우도 있습니다. 리소스 그룹을 사용하여 안전하게 지속적인 배포 워크플로우를 최적화하기 위해 잡의 동시성을 전략적으로 제어합니다.

리소스 그룹 추가#

리소스 그룹에는 하나의 리소스만 추가할 수 있습니다.

다음 파이프라인 구성(리포지터리의 .gitlab-ci.yml 파일)이 있다고 가정합니다:

build:
  stage: build
  script: echo "Your build script"

deploy:
  stage: deploy
  script: echo "Your deployment script"
  environment: production

브랜치에 새 커밋을 푸시할 때마다 build와 deploy 두 개의 잡이 있는 새 파이프라인이 실행됩니다. 하지만 짧은 간격으로 여러 커밋을 푸시하면 여러 파이프라인이 동시에 실행되기 시작합니다. 예를 들어:

• 첫 번째 파이프라인이 build -> deploy 잡을 실행합니다.
• 두 번째 파이프라인이 build -> deploy 잡을 실행합니다.

이 경우 다른 파이프라인의 deploy 잡들이 production 환경에 동시에 실행될 수 있습니다. 동일한 인프라에 여러 배포 스크립트를 실행하면 인스턴스를 손상시키거나 혼란을 주고, 최악의 경우 손상된 상태로 남길 수 있습니다.

deploy 잡이 한 번에 하나씩 실행되도록 하려면 동시성에 민감한 잡에 resource_group 키워드를 지정합니다:

deploy:
  # ...
  resource_group: production

이 구성으로 파이프라인 효율성을 극대화하기 위해 build 잡을 동시에 실행하면서도 배포의 안전성이 보장됩니다.

사전 요구사항#

• GitLab CI/CD 파이프라인에 대한 지식
• GitLab 환경 및 배포에 대한 지식
• CI/CD 파이프라인을 구성하기 위한 프로젝트에 대한 Developer, Maintainer 또는 Owner 권한.

프로세스 모드#

배포 환경에 맞게 잡 동시성을 제어하는 프로세스 모드를 선택할 수 있습니다. 다음 모드가 지원됩니다:

프로세스 모드 변경#

리소스 그룹의 프로세스 모드를 변경하려면 API를 사용하고 process_mode를 지정하여 기존 리소스 그룹 편집 요청을 전송해야 합니다:

• unordered
• oldest_first
• newest_first
• newest_ready_first

프로세스 모드 간 차이점 예시#

다음 .gitlab-ci.yml 파일은 build 잡과 deploy 잡이 있습니다. 각 잡은 자체 스테이지에서 실행되고 deploy 잡에는 production으로 설정된 리소스 그룹이 있습니다:

build:
  stage: build
  script: echo "Your build script"

deploy:
  stage: deploy
  script: echo "Your deployment script"
  environment: production
  resource_group: production

짧은 간격으로 세 개의 커밋이 프로젝트에 푸시되면, 세 개의 파이프라인이 거의 동시에 실행됩니다:

• 첫 번째 파이프라인이 build -> deploy 잡을 실행합니다. 이 배포 잡을 deploy-1이라고 합니다.
• 두 번째 파이프라인이 build -> deploy 잡을 실행합니다. 이 배포 잡을 deploy-2라고 합니다.
• 세 번째 파이프라인이 build -> deploy 잡을 실행합니다. 이 배포 잡을 deploy-3이라고 합니다.

리소스 그룹의 프로세스 모드에 따라:

• 프로세스 모드가 unordered로 설정된 경우:
  • deploy-1, deploy-2, deploy-3은 동시에 실행되지 않습니다.
  • 잡 실행 순서에는 보장이 없습니다. 예를 들어 deploy-1이 deploy-3 이전 또는 이후에 실행될 수 있습니다.
• 프로세스 모드가 oldest_first인 경우:
  • deploy-1, deploy-2, deploy-3은 동시에 실행되지 않습니다.
  • deploy-1이 먼저, deploy-2가 두 번째, deploy-3이 마지막으로 실행됩니다.
• 프로세스 모드가 newest_first인 경우:
  • deploy-1, deploy-2, deploy-3은 동시에 실행되지 않습니다.
  • deploy-3이 먼저, deploy-2가 두 번째, deploy-1이 마지막으로 실행됩니다.

크로스 프로젝트/부모-자식 파이프라인을 통한 파이프라인 수준 동시성 제어#

동시 실행에 민감한 다운스트림 파이프라인에 대해 resource_group을 정의할 수 있습니다. trigger 키워드는 다운스트림 파이프라인을 트리거할 수 있고 resource_group 키워드와 함께 사용할 수 있습니다. resource_group은 배포 파이프라인의 동시성을 제어하는 데 효율적이며, 다른 잡은 계속 동시에 실행될 수 있습니다.

다음 예시는 프로젝트에 두 개의 파이프라인 구성이 있습니다. 파이프라인이 실행되기 시작하면 민감하지 않은 잡이 먼저 실행되며 다른 파이프라인의 동시 실행에 영향을 받지 않습니다. 그러나 GitLab은 배포(자식) 파이프라인을 트리거하기 전에 실행 중인 다른 배포 파이프라인이 없는지 확인합니다. 다른 배포 파이프라인이 실행 중이면 GitLab은 해당 파이프라인이 완료될 때까지 기다렸다가 다른 것을 실행합니다.

# .gitlab-ci.yml (부모 파이프라인)

build:
  stage: build
  script: echo "Building..."

test:
  stage: test
  script: echo "Testing..."

deploy:
  stage: deploy
  trigger:
    include: deploy.gitlab-ci.yml
    strategy: mirror
  resource_group: AWS-production

# deploy.gitlab-ci.yml (자식 파이프라인)

stages:
  - provision
  - deploy

provision:
  stage: provision
  script: echo "Provisioning..."

deployment:
  stage: deploy
  script: echo "Deploying..."
  environment: production

잠금이 다운스트림 파이프라인이 완료될 때까지 해제되지 않도록 trigger:strategy를 정의해야 합니다.

관련 주제#

• API 문서
• 로그 문서
• 안전한 배포를 위한 GitLab

트러블슈팅#

파이프라인 구성에서 데드락 방지#

oldest_first 프로세스 모드는 파이프라인 순서에 따라 잡을 실행하도록 강제하므로 다른 CI 기능과 잘 작동하지 않는 경우가 있습니다.

예를 들어 부모 파이프라인과 동일한 리소스 그룹이 필요한 자식 파이프라인을 실행하면 데드락이 발생할 수 있습니다. 다음은 잘못된 설정의 예시입니다:

# 나쁜 예
test:
  stage: test
  trigger:
    include: child-pipeline-requires-production-resource-group.yml
    strategy: mirror

deploy:
  stage: deploy
  script: echo
  resource_group: production
  environment: production

부모 파이프라인에서 test 잡을 실행하면 자식 파이프라인이 실행되고, strategy: mirror 옵션으로 test 잡이 자식 파이프라인이 완료될 때까지 기다립니다. 부모 파이프라인은 다음 스테이지에서 production 리소스 그룹의 리소스가 필요한 deploy 잡을 실행합니다. 프로세스 모드가 oldest_first이면 가장 오래된 파이프라인의 잡, 즉 deploy 잡이 다음에 실행됩니다.

그러나 자식 파이프라인도 production 리소스 그룹의 리소스가 필요합니다. 자식 파이프라인은 부모 파이프라인보다 새 것이기 때문에, 자식 파이프라인은 deploy 잡이 완료될 때까지 기다리는데, 이 일은 절대로 발생하지 않습니다.

이 경우 부모 파이프라인 구성에서 resource_group 키워드를 지정해야 합니다:

# 좋은 예
test:
  stage: test
  trigger:
    include: child-pipeline.yml
    strategy: mirror
  resource_group: production # 부모 파이프라인에서 리소스 그룹 지정

deploy:
  stage: deploy
  script: echo
  resource_group: production
  environment: production

리소스를 기다리는 중 상태로 잡이 멈춤#

간혹 Waiting for resource: <resource_group> 메시지와 함께 잡이 중단됩니다. 해결하려면 먼저 리소스 그룹이 올바르게 작동하는지 확인합니다:

1. 잡 세부 정보 페이지로 이동합니다.

2. 리소스가 잡에 할당되어 있으면 현재 리소스를 사용 중인 잡 보기를 선택하고 잡 상태를 확인합니다.

   • 상태가 running 또는 pending이면 기능이 올바르게 작동하는 것입니다. 잡이 완료되고 리소스를 해제할 때까지 기다립니다.
   • 상태가 created이고 프로세스 모드가 Oldest first 또는 Newest first이면 기능이 올바르게 작동하는 것입니다. 잡의 파이프라인 페이지를 방문하여 실행을 차단하는 업스트림 스테이지 또는 잡을 확인합니다.
   • 이전 조건이 충족되지 않으면 기능이 올바르게 작동하지 않을 수 있습니다. GitLab에 이슈를 보고합니다.

3. 현재 리소스를 사용 중인 잡 보기가 사용 불가능하면 리소스가 잡에 할당되지 않은 것입니다. 대신 리소스의 예정 잡을 확인합니다.

   1. REST API로 리소스의 예정 잡을 가져옵니다.
   2. 리소스 그룹의 프로세스 모드가 Oldest first인지 확인합니다.
   3. 예정 잡 목록에서 첫 번째 잡을 찾고 GraphQL로 잡 세부 정보를 가져옵니다.
   4. 첫 번째 잡의 파이프라인이 더 이상 실행되지 않아야 하는 오래된 파이프라인인 경우 파이프라인 또는 잡 자체를 취소합니다.
   5. 선택 사항. 다음 예정 잡이 여전히 더 이상 실행되지 않아야 하는 오래된 파이프라인에 있는 경우 이 과정을 반복합니다.
   6. 문제가 지속되면 GitLab에 이슈를 보고합니다.

복잡하거나 바쁜 파이프라인에서의 경쟁 조건#

위의 솔루션으로 문제를 해결할 수 없다면 알려진 경쟁 조건 이슈가 발생한 것일 수 있습니다. 경쟁 조건은 복잡하거나 바쁜 파이프라인에서 발생합니다. 예를 들어 다음과 같은 경우에 경쟁 조건이 발생할 수 있습니다:

• 여러 자식 파이프라인이 있는 파이프라인.
• 여러 파이프라인이 동시에 실행되는 단일 프로젝트.

이 문제가 발생하고 있다고 생각되면 GitLab에 이슈를 보고하고 새 이슈 링크와 함께 이슈 436988에 댓글을 남겨주세요. 문제를 확인하기 위해 GitLab에서 전체 파이프라인 구성과 같은 추가 세부 정보를 요청할 수 있습니다.

임시 해결 방법으로 다음을 수행할 수 있습니다:

• 새 파이프라인을 시작합니다.

• 중단된 잡과 동일한 리소스 그룹을 가진 완료된 잡을 다시 실행합니다.

  예를 들어 setup_job과 deploy_job이 동일한 리소스 그룹을 가지고 있다면, setup_job이 완료된 후 deploy_job이 리소스를 기다리며 중단될 수 있습니다. setup_job을 다시 실행하여 전체 프로세스를 다시 시작하고 deploy_job이 완료될 수 있도록 합니다.

GraphQL을 통해 잡 세부 정보 가져오기#

GraphQL API에서 잡 정보를 가져올 수 있습니다. 트리거 잡이 UI에서 액세스할 수 없기 때문에 크로스 프로젝트/부모-자식 파이프라인을 통한 파이프라인 수준 동시성 제어를 사용하는 경우 GraphQL API를 사용해야 합니다.

GraphQL API에서 잡 정보를 가져오려면:

1. 파이프라인 세부 정보 페이지로 이동합니다.

2. 잡 탭을 선택하고 중단된 잡의 ID를 찾습니다.

3. 대화형 GraphQL 탐색기로 이동합니다.

4. 다음 쿼리를 실행합니다:

   {
     project(fullPath: "<fullpath-to-your-project>") {
       name
       job(id: "gid://gitlab/Ci::Build/<job-id>") {
         name
         status
         detailedStatus {
           action {
             path
             buttonTitle
           }
         }
       }
     }
   }
   

   job.detailedStatus.action.path 필드에는 리소스를 사용하는 잡 ID가 포함됩니다.

5. 다음 쿼리를 실행하고 위의 기준에 따라 job.status 필드를 확인합니다. pipeline.path 필드에서 파이프라인 페이지를 방문할 수도 있습니다.

   {
     project(fullPath: "<fullpath-to-your-project>") {
       name
       job(id: "gid://gitlab/Ci::Build/<job-id-currently-using-the-resource>") {
         name
         status
         pipeline {
           path
         }
       }
     }
   }
   

이슈 보고#

다음 정보와 함께 새 이슈를 오픈합니다:

• 영향받은 잡의 ID.

• 잡 상태.

• 문제가 발생하는 빈도.

• 문제를 재현하는 단계.

  추가 지원을 위해 지원팀에 문의하거나 개발팀과 연락할 수도 있습니다.