- 중요한 환경에 대한 쓰기 액세스 제한
- 한 번에 하나의 배포 작업만 실행하도록 보장
- 오래된 배포 작업 방지
- 배포 동결 기간에 배포 방지
- 프로덕션 시크릿 보호
- 배포용 별도 프로젝트
.gitlab-ci.yml변경 방지- 배포 전 승인 요구
배포 안정성
배포 작업은 특정 유형의 CI/CD 작업입니다. 파이프라인 내 다른 작업보다 민감할 수 있으며 추가적인 주의가 필요할 수 있습니다. GitLab에는 배포 보안과 안정성을 유지하는 데 도움이 되는 여러 가지 기능이 있습니다.
다음을 수행할 수 있습니다.
- 프로젝트에 적절한 역할을 할당합니다. 각 사용 권한에 대해 GitLab이 지원하는 다른 사용자 역할 및 각 권한은 프로젝트 멤버 권한을 참조하세요.
- 중요한 환경에 대한 쓰기 액세스 제한
- 배포 동결 창 동안 배포 방지
- 프로덕션 암호 보호
- 배포용 프로젝트 분리
지속적 배포 작업 흐름을 사용하고 동시에 동일 환경으로의 동시 배포를 방지하려면 다음 옵션을 활성화해야 합니다.
개요를 보려면 CD 파이프라인/작업흐름 보호 방법을 참조하세요.
중요한 환경에 대한 쓰기 액세스 제한
기본적으로, 환경은 적어도 개발자 역할을 할당받은 팀 멤버에 의해 수정될 수 있습니다. 중요한 환경(예: 프로덕션 환경)의 쓰기 액세스를 제한하려면 보호 환경을 설정할 수 있습니다.
한 번에 하나의 배포 작업만 실행하도록 보장
GitLab CI/CD의 파이프라인 작업은 병렬로 실행되므로 두 개의 다른 파이프라인에서 두 배포 작업이 동시에 동일한 환경에 배포를 시도할 수 있습니다. 이는 원하는 동작이 아니며, 배포는 순차적으로 진행되어야 합니다.
귀하의 .gitlab-ci.yml에서 resource_group 키워드를 사용하여 한 번에 하나의 배포 작업만 실행되도록 할 수 있습니다.
예를 들면:
deploy:
script: deploy-to-prod
resource_group: prod
리소스 그룹을 사용하기 전의 문제가 있는 파이프라인 흐름 예제:
- Pipeline-A의
deploy작업이 실행을 시작합니다. - Pipeline-B의
deploy작업이 실행을 시작합니다. 이것은 예기치 않은 결과를 초래할 수 있는 동시 배포입니다. - Pipeline-A의
deploy작업이 완료됩니다. - Pipeline-B의
deploy작업이 완료됩니다.
리소스 그룹을 사용한 후 향상된 파이프라인 흐름 예제:
- Pipeline-A의
deploy작업이 실행을 시작합니다. - Pipeline-B의
deploy작업이 실행을 시작하려고 하지만 첫 번째deploy작업이 완료될 때까지 기다립니다. - Pipeline-A의
deploy작업이 완료됩니다. - Pipeline-B의
deploy작업이 실행을 시작합니다.
더 많은 정보는 리소스 그룹 문서를 참조하세요.
오래된 배포 작업 방지
파이프라인 작업의 유효한 실행 순서는 실행 간에 다를 수 있으며, 이는 원하지 않는 동작을 초래할 수 있습니다. 예를 들어, 더 최신의 파이프라인의 배포 작업이 이전 파이프라인의 배포 작업보다 먼저 완료될 수 있습니다. 이 때문에 이전 배포가 ‘새로운’ 배포를 덮어쓸 수 있는 경합 조건이 발생합니다.
오래된 배포 작업 방지 기능을 활성화하여 더 이상의 배포작업이 새로운 배포 작업을 시작할 때 실행되지 않도록 할 수 있습니다.
더 이전의 배포 작업을 시작하면 실패하고 다음과 같이 표시됩니다:
- 파이프라인 보기에서
오래된 배포 작업 실패. - 완료된 작업 보기에서
이 배포 작업은 최신 배포보다 오래되었고, 따라서 실패했습니다.라는 메시지가 표시됩니다.
오래된 배포 작업이 매뉴얼인 경우 재생 버튼이 비활성화되며 “이 배포 작업은 자동으로 실행되지 않으며 매뉴얼으로 시작해야 하지만, 최신 배포보다 오래되어 실행될 수 없습니다.”라는 메시지가 표시됩니다.
작업 연령은 커밋 시간이 아닌 작업 시작 시간으로 결정되므로 특정 상황에서 새로운 커밋이 방지될 수 있습니다.
롤백 배포를 위한 작업 다시 시도
빠르게 안정적인 오래된 배포로 롤백해야 할 수 있습니다. 기본적으로 배포 롤백을 위한 파이프라인 작업 다시 시도가 활성화되어 있습니다.
파이프라인 재시도를 비활성화하려면 롤백 배포를 위한 작업 다시 시도 허용 확인란을 선택해제하세요. 민감한 프로젝트에서 파이프라인 재시도를 비활성화해야 합니다.
롤백이 필요한 경우 이전 커밋으로 새로운 파이프라인을 실행해야 합니다.
예시
오래된 배포 작업 방지를 활성화하기 전의 문제가 있는 파이프라인 흐름 예제:
- Pipeline-A가 기본 브랜치에서 생성됩니다.
- 이후, Pipeline-B가 더 최신의 커밋 SHA로 기본 브랜치에서 생성됩니다.
- Pipeline-B의
deploy작업이 먼저 완료되어 더 최신 코드를 배포합니다. - Pipeline-A의
deploy작업이 나중에 완료되어 더 오래된 코드를 배포하며, 새로운(최신) 배포를 덮어씁니다.
오래된 배포 작업 방지를 활성화한 후의 향상된 파이프라인 흐름 예제:
- Pipeline-A가 기본 브랜치에서 생성됩니다.
- 이후, Pipeline-B가 기본 브랜치에서 새로운 SHA로 생성됩니다.
- Pipeline-B의
deploy작업이 먼저 완료되어 더 최신 코드를 배포합니다. - Pipeline-A의
deploy작업이 실패하여 더 이상 새로운 파이프라인에서 배포를 덮어쓰지 않게 됩니다.
배포 동결 기간에 배포 방지
특정 기간 동안 배포를 방지하려면, 예를 들어 대부분의 직원이 휴가 중인 계획된 휴가 기간 동안, 배포 동결를 설정할 수 있습니다. 배포 동결 기간 동안에는 어떠한 배포도 실행되지 않습니다. 이는 예상치 못한 배포가 발생하지 않도록 하는 데 도움이 됩니다.
다음으로 구성된 배포 동결은 환경 배포 디렉터리 페이지 상단에 표시됩니다.
프로덕션 시크릿 보호
프로덕션 시크릿은 성공적인 배포에 필요합니다. 예를 들어, 클라우드로 배포할 때 클라우드 제공업체는 자신들의 서비스에 연결하기 위해 이러한 시크릿을 필요로 합니다. 프로젝트 설정에서 이러한 시크릿에 대한 CI/CD 변수를 정의하고 보호할 수 있습니다. 보호된 변수는 보호된 브랜치 또는 보호된 태그에서 실행되는 파이프라인에만 전달됩니다. 다른 파이프라인은 보호된 변수를 받지 않습니다. 또한 특정 환경에 변수의 범위를 지정할 수 있습니다. 시크릿이 실수로 노출되지 않도록 하기 위해, 보호된 환경에서 보호된 변수를 사용하는 것을 권장합니다. 또한 프로덕션 시크릿을 러너(runner) 측면에서 정의할 수도 있습니다. 이는 Maintainer 역할을 가진 다른 사용자가 시크릿을 읽지 못하도록 하고, 러너(runner)가 보호된 브랜치에서만 실행되도록 합니다.
자세한 정보는 파이프라인 보안을 참조하세요.
배포용 별도 프로젝트
프로젝트의 Maintainer 역할을 하는 모든 사용자는 프로덕션 시크릿에 액세스할 수 있습니다. 프로덕션 환경에 배포할 수 있는 사용자 수를 제한해야 하는 경우, 별도 프로젝트를 생성하고 원래 프로젝트와 CD 권한을 격리하는 새로운 권한 모델을 구성할 수 있습니다. 이렇게 함으로써 원래 프로젝트의 Maintainer 역할을 하는 사용자가 프로덕션 시크릿과 CD 구성에 액세스하지 못하도록 할 수 있습니다. 다중 프로젝트 파이프라인을 사용하여 CD 프로젝트를 개발 프로젝트에 연결할 수 있습니다.
.gitlab-ci.yml 변경 방지
.gitlab-ci.yml에는 애플리케이션을 프로덕션 서버에 배포하는 규칙이 포함될 수 있습니다. 이 배포는 일반적으로 Merge Request을 푸시한 후 자동으로 실행됩니다. 개발자가 .gitlab-ci.yml을 변경하지 못하도록 하기 위해 이를 다른 리포지터리에 정의할 수 있습니다. 구성은 완전히 다른 권한 집합을 가진 다른 프로젝트의 파일을 참조할 수 있습니다 (배포용 프로젝트를 분리하는 것과 유사함). 이 시나리오에서 .gitlab-ci.yml은 공개적으로 액세스할 수 있지만, 다른 프로젝트에서 적절한 권한을 갖춘 사용자만이 편집할 수 있습니다.
자세한 정보는 사용자 정의 CI/CD 구성 경로를 참조하세요.
배포 전 승인 요구
프로덕션 환경으로의 배포를 승인하기 전에 전용 테스트 그룹에서 교차 검증하는 것은 안전을 보장하는 효과적인 방법입니다. 자세한 정보는 배포 승인을 참조하세요.
도움말