배포 job은 특수한 종류의 CI/CD job입니다. 파이프라인의 다른 job보다 더 민감할 수 있으며 특별한 주의가 필요할 수 있습니다. GitLab에는 배포 보안과 안정성을 유지하는 데 도움이 되는 여러 기능이 있습니다.

다음을 수행할 수 있습니다:

• 프로젝트에 적절한 역할을 설정합니다. GitLab이 지원하는 다양한 사용자 역할과 각 역할의 권한에 대한 내용은 프로젝트 멤버 권한을 참조하세요.
• 중요한 환경에 대한 쓰기 액세스 제한
• 배포 동결 기간 동안 배포 방지
• 프로덕션 시크릿 보호
• 배포를 위한 별도 프로젝트

지속적인 배포 워크플로를 사용하고 동일한 환경에 동시 배포가 발생하지 않도록 하려면:

• 한 번에 하나의 배포 job만 실행되도록 합니다.
• 오래된 배포 job을 방지합니다.

개요는 CD 파이프라인/워크플로를 보호하는 방법을 참조하세요.

중요한 환경에 대한 쓰기 액세스 제한#

기본적으로 환경은 Developer 권한 이상을 보유한 팀원이 수정할 수 있습니다. 중요한 환경(예: production 환경)에 대한 쓰기 액세스를 제한하려면 보호된 환경을 설정할 수 있습니다.

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

GitLab CI/CD의 파이프라인 job은 병렬로 실행되므로 두 개의 다른 파이프라인에서 두 개의 배포 job이 동시에 동일한 환경에 배포를 시도할 수 있습니다. 배포는 순차적으로 이루어져야 하므로 이는 원하지 않는 동작입니다.

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

예를 들어:

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

resource group 없이 문제가 있는 파이프라인 흐름의 예:

1. Pipeline-A에서 deploy job이 실행되기 시작합니다.
2. Pipeline-B에서 deploy job이 실행되기 시작합니다. 이는 예상치 못한 결과를 일으킬 수 있는 동시 배포입니다.
3. Pipeline-A에서 deploy job이 완료됩니다.
4. Pipeline-B에서 deploy job이 완료됩니다.

resource group을 사용한 개선된 파이프라인 흐름:

1. Pipeline-A에서 deploy job이 실행되기 시작합니다.
2. Pipeline-B에서 deploy job이 시작을 시도하지만 첫 번째 deploy job이 완료될 때까지 기다립니다.
3. Pipeline-A에서 deploy job이 완료됩니다.
4. Pipeline-B에서 deploy job이 실행되기 시작합니다.

자세한 내용은 Resource Group 문서를 참조하세요.

오래된 배포 job 방지#

파이프라인 job의 실제 실행 순서는 실행마다 달라질 수 있어 원하지 않는 동작이 발생할 수 있습니다. 예를 들어 더 최신 파이프라인의 배포 job이 이전 파이프라인의 배포 job보다 먼저 완료될 수 있습니다. 이로 인해 이전 배포가 나중에 완료되어 "최신" 배포를 덮어쓰는 경쟁 조건이 발생합니다.

오래된 배포 job 방지 설정을 사용하여 더 새로운 배포 job이 시작될 때 이전 배포 job이 실행되지 않도록 방지할 수 있습니다.

이전 배포 job이 시작되면 실패하며 다음과 같이 레이블이 지정됩니다:

• 파이프라인 보기에서 failed outdated deployment job.
• 완료된 job을 볼 때 The deployment job is older than the latest deployment, and therefore failed.

이전 배포 job이 수동인 경우 실행([play]) 버튼이 This deployment job does not run automatically and must be started manually, but it's older than the latest deployment, and therefore can't run. 메시지와 함께 비활성화됩니다.

job 나이는 커밋 시간이 아닌 job 시작 시간으로 결정되므로 일부 상황에서는 더 새로운 커밋이 방지될 수 있습니다. 예를 들어 파이프라인 A(이전 커밋)와 파이프라인 B(더 새로운 커밋) 모두 수동 배포 job이 있는 경우. 파이프라인 B를 만든 후에 파이프라인 A의 job을 시작하면, 파이프라인 자체는 더 새롭지만 파이프라인 B의 수동 배포 job은 오래된 것으로 차단됩니다.

롤백 배포를 위한 job 재시도#

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

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

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

예시#

오래된 배포 job 방지 설정이 비활성화된 경우의 문제가 있는 파이프라인 흐름 예시:

1. 기본 브랜치에서 Pipeline-A가 생성됩니다.
2. 나중에 기본 브랜치에서 Pipeline-B가 생성됩니다(더 새로운 커밋 SHA).
3. Pipeline-B의 deploy job이 먼저 완료되어 더 새로운 코드를 배포합니다.
4. Pipeline-A의 deploy job이 나중에 완료되어 이전 코드를 배포하여 더 새로운(최신) 배포를 덮어씁니다.

설정이 활성화된 경우의 개선된 파이프라인 흐름:

1. 기본 브랜치에서 Pipeline-A가 생성됩니다.
2. 나중에 기본 브랜치에서 Pipeline-B가 생성됩니다(더 새로운 SHA).
3. Pipeline-B의 deploy job이 먼저 완료되어 더 새로운 코드를 배포합니다.
4. Pipeline-A의 deploy job이 실패하여 더 새로운 파이프라인의 배포를 덮어쓰지 않습니다.

배포 동결 기간 동안 배포 방지#

특정 기간 동안(예: 대부분의 직원이 부재 중인 계획된 휴가 기간) 배포를 방지하려면 배포 동결을 설정할 수 있습니다. 배포 동결 기간 동안에는 배포를 실행할 수 없습니다. 이는 예상치 못한 배포가 발생하지 않도록 보장하는 데 유용합니다.

다음에 구성된 배포 동결은 환경 배포 목록 페이지 상단에 표시됩니다.

프로덕션 시크릿 보호#

프로덕션 시크릿은 성공적인 배포에 필요합니다. 예를 들어 클라우드에 배포할 때 클라우드 공급자는 해당 서비스에 연결하기 위해 이러한 시크릿을 요구합니다. 프로젝트 설정에서 이러한 시크릿에 대한 CI/CD 변수를 정의하고 보호할 수 있습니다. 보호된 변수는 보호된 브랜치 또는 보호된 태그에서 실행되는 파이프라인에만 전달됩니다. 다른 파이프라인은 보호된 변수를 가져오지 않습니다. 또한 변수의 범위를 특정 환경으로 지정할 수 있습니다. 시크릿이 의도치 않게 노출되지 않도록 보호된 환경에서 보호된 변수를 사용하는 것이 좋습니다. 또한 러너 측에서 프로덕션 시크릿을 정의하여 Maintainer 권한을 가진 다른 사용자가 시크릿을 읽지 못하도록 하고 러너가 보호된 브랜치에서만 실행되도록 할 수 있습니다.

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

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

프로젝트에 대한 Maintainer 권한이 있는 모든 사용자는 프로덕션 시크릿에 액세스할 수 있습니다. 프로덕션 환경에 배포할 수 있는 사용자 수를 제한해야 하는 경우 별도의 프로젝트를 만들고 원본 프로젝트에서 CD 권한을 분리하고 Maintainer 권한이 있는 원래 사용자가 프로덕션 시크릿 및 CD 구성에 액세스하지 못하도록 하는 새로운 권한 모델을 구성할 수 있습니다. 멀티 프로젝트 파이프라인을 사용하여 CD 프로젝트를 개발 프로젝트에 연결할 수 있습니다.

변경으로부터 .gitlab-ci.yml 보호#

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

자세한 내용은 사용자 정의 CI/CD 구성 경로를 참조하세요.

배포 전 승인 요구#

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