배포 안전성

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

배포 작업은 특정 유형의 CI/CD 작업입니다. 파이프라인의 다른 작업보다 민감할 수 있으며 추가 조치가 필요할 수 있습니다. GitLab에는 배포 보안과 안정성을 유지하는 데 도움이 되는 여러 기능이 있습니다.

다음과 같은 작업을 수행할 수 있습니다.

지속적인 배포 워크플로를 사용하고 동시에 동일한 환경으로의 병렬 배포가 발생하지 않도록 하려면 다음 옵션을 활성화해야 합니다.

개요는 CD 파이프라인/워크플로를 안전하게 유지하는 방법을 참조하십시오.

크리티컬 환경의 쓰기 액세스 제한

기본적으로 환경은 적어도 개발자 역할을 가진 팀 멤버에 의해 수정될 수 있습니다. 크리티컬 환경(예: 프로덕션 환경)의 쓰기 액세스를 제한하려면 보호된 환경을 설정할 수 있습니다.

한 번에 하나의 배포 작업만 실행되도록 보장

GitLab CI/CD의 파이프라인 작업은 병렬로 실행되므로 두 개의 다른 파이프라인에서 두 배포 작업이 동시에 동일한 환경으로 배포를 시도할 수 있습니다. 이는 원하는 동작이 아니며 배포는 순차적으로 발생해야 합니다.

.gitlab-ci.yml에서 resource_group 키워드를 사용하여 한 번에 하나의 배포 작업만 실행되도록 보장할 수 있습니다.

예시: 

deploy:
 script: deploy-to-prod
 resource_group: prod

리소스 그룹을 사용하기 전의 문제가 있는 파이프라인 흐름 예시:

  1. 파이프라인 A의 deploy 작업이 실행됨.
  2. 파이프라인 B의 deploy 작업이 실행됨. 이는 예상치 못한 결과를 초래할 수 있는 병렬 배포입니다.
  3. 파이프라인 A의 deploy 작업이 완료됨.
  4. 파이프라인 B의 deploy 작업이 완료됨.

리소스 그룹을 사용한 후의 개선된 파이프라인 흐름 예시:

  1. 파이프라인 A의 deploy 작업이 실행됨.
  2. 파이프라인 B의 deploy 작업이 시작을 시도하지만 처음 deploy 작업이 완료될 때까지 대기함.
  3. 파이프라인 A의 deploy 작업이 완료됨.
  4. 파이프라인 B의 deploy 작업이 실행됨.

자세한 내용은 리소스 그룹 설명서를 참조하십시오.

오래된 배포 작업 방지

  • GitLab 15.5에서 변경되어 오래된 작업 실행을 방지합니다.

파이프라인 작업의 유효한 실행 순서는 실행마다 다를 수 있으며 원하지 않는 동작을 초래할 수 있습니다. 예를 들어 더 최신 파이프라인의 배포 작업이 이전 파이프라인의 배포 작업보다 먼저 완료될 수 있습니다. 이로 인해 이전 배포는 이후에 완료되어 “더 최신” 배포를 덮어쓰게 됩니다.

오래된 배포 작업 방지 기능을 활성화하여 새로운 배포 작업을 시작할 때 이전 배포 작업이 실행되지 않도록 할 수 있습니다.

오래된 배포 작업이 시작되면 파이프라인 보기에서 다음과 같이 레이블이 지정됩니다:

  • 파이프라인 보기: 오래된 배포 작업 실패
  • 완료된 작업 보기: 이 배포 작업은 최신 배포보다 오래되었기 때문에 실패함.

오래된 배포 작업이 매뉴얼 작업인 경우 실행 () 버튼은 “자동으로 실행되지 않고 매뉴얼으로 시작해야 하지만 최신 배포보다 오래되어 실행할 수 없습니다.”라는 메시지와 함께 비활성화됩니다.

작업의 연령은 작업 시작 시간에 의해 결정되며 커밋 시간이 아니므로 어떤 상황에서는 새로운 커밋도 방지될 수 있습니다.

롤백 배포를 위한 작업 재시도

  • GitLab 15.6에서 롤백을 위한 작업 재시도를 통한 롤백이 도입되었습니다.
  • GitLab 16.3에서 롤백 배포를 위한 작업 재시도 체크박스가 도입되었습니다.

안정적인 오래된 배포로 빠르게 롤백해야 할 수 있습니다. 기본적으로 배포 롤백을 위한 파이프라인 작업 재시도가 활성화되어 있습니다.

파이프라인 재시도를 비활성화하려면 롤백 배포를 위한 작업 재시도 허용 체크박스를 선택 해제하십시오. 민감한 프로젝트에서는 파이프라인 재시도를 비활성화해야 합니다.

롤백이 필요한 경우 이전 커밋으로 새 파이프라인을 실행해야 합니다.

예시

오래된 배포 작업 방지를 활성화하기 전의 문제가 있는 파이프라인 흐름 예시:

  1. 기본 브랜치에서 파이프라인 A가 생성됨.
  2. 나중에 더 최신 커밋 SHA로 기본 브랜치에서 파이프라인 B가 생성됨.
  3. 파이프라인 B의 deploy 작업이 우선 완료되어 더 최신 코드를 배포함.
  4. 파이프라인 A의 deploy 작업이 나중에 완료되어 이전 코드를 배포하고, 더 최신(최근) 배포를 덮어쓰게 됨.

오래된 배포 작업 방지를 활성화한 후의 개선된 파이프라인 흐름 예시:

  1. 기본 브랜치에서 파이프라인 A가 생성됨.
  2. 나중에 더 최신 SHA로 기본 브랜치에서 파이프라인 B가 생성됨.
  3. 파이프라인 B의 deploy 작업이 우선 완료되어 더 최신 코드를 배포함.
  4. 파이프라인 A의 deploy 작업이 실패하여 더 최신 파이프라인의 배포를 덮어쓰지 않게 됨.

배포 동결 창 동안 배포 방지

특정 기간 동안 배포를 방지하려면, 예를 들어 대부분의 직원이 없는 계획된 휴가 기간 동안, 배포 동결을 설정할 수 있습니다. 배포 동결 기간 동안 어떠한 배포도 실행할 수 없습니다. 이는 예상치 못한 배포가 발생하지 않도록 하는 데 도움이 됩니다.

다음 구성된 배포 동결은 환경 배포 디렉터리 페이지 상단에 표시됩니다.

프로덕션 비밀 보호

프로덕션 비밀은 성공적인 배포에 필요합니다. 예를 들어 클라우드로 배포할 때 클라우드 제공업체는 서비스에 연결하려면 이러한 비밀을 필요로 합니다. 프로젝트 설정에서 이러한 비밀에 대한 CI/CD 변수를 정의하고 보호할 수 있습니다. 보호된 변수는 보호된 브랜치 또는 보호된 태그에서 실행되는 파이프라인에만 전달됩니다. 다른 파이프라인은 보호된 변수를 받지 않습니다. 또한 특정 환경에 맞는 변수 설정을 할 수 있습니다. 보호된 환경에서 보호된 변수를 사용해서 의도치 않게 비밀이 노출되지 않도록 해야 합니다. 또한 프로덕션 비밀을 러너(runner) 측에 정의하여 유지보수자 역할을 하는 사용자가 비밀을 읽지 못하도록 하고, 러너(runner)가 보호된 브랜치에서만 실행되도록 할 수 있습니다.

자세한 내용은 파이프라인 보안을 참조하십시오.

배포를 위한 별도의 프로젝트

프로젝트의 유지관리자(Maintainer) 역할을 하는 모든 사용자는 프로덕션 비밀을 액세스할 수 있습니다. 프로덕션 환경으로의 배포를 제한하려면 CD(Continuous Deployment) 권한을 원본 프로젝트와 분리하고 프로덕션 비밀 및 CD 구성에 대한 접근을 막는 새로운 권한 모델을 구성하는 별도의 프로젝트를 만들 수 있습니다. 멀티 프로젝트 파이프라인을 사용하여 CD 프로젝트를 개발 프로젝트에 연결할 수 있습니다.

.gitlab-ci.yml의 변경 방지

.gitlab-ci.yml에는 애플리케이션을 프로덕션 서버에 배포하는 규칙이 포함될 수 있습니다. 이 배포는 일반적으로 Merge Request을 푸시한 후 자동으로 실행됩니다. 개발자가 .gitlab-ci.yml을 변경하지 못하도록 하려면 다른 리포지터리에서 정의해야 합니다. 구성은 다른 프로젝트의 파일을 참조하여 완전히 다른 권한 집합을 가진 리포지터리에 정의할 수 있습니다 (배포를 위한 별도의 프로젝트와 유사함). 이 시나리오에서 .gitlab-ci.yml은 공개적으로 접근할 수 있지만, 해당 다른 프로젝트에서 적절한 권한을 가진 사용자만 편집할 수 있습니다.

자세한 정보는 사용자 지정 CI/CD 구성 경로를 참조하세요.

배포 전 승인 필요

프로덕션 환경으로의 배포를 승격하기 전에, 전용 테스트 그룹에서 교차 확인하는 것은 안전을 보장하는 효과적인 방법입니다. 자세한 정보는 배포 승인을 참조하세요.