- 중요 환경에 대한 쓰기 액세스 제한
- 동시에 하나의 배포 작업만 실행되도록 보장
- 오래된 배포 작업 방지
- 배포 동결 기간 중 배포 방지
- 프로덕션 시크릿 보호
- 배포를 위한 별도의 프로젝트
.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작업이 실행됨.
자세한 내용은 자원 그룹 문서를 참조하십시오.
오래된 배포 작업 방지
- GitLab 15.5에서 변경되어 오래된 작업 실행을 방지함.
GitLab CI/CD 파이프라인 작업의 실제 실행 순서는 각 실행마다 다를 수 있으며 원치 않는 동작을 초래할 수 있습니다. 예를 들어, 더 최신의 파이프라인에서의 배포 작업이 이전 파이프라인의 배포 작업보다 먼저 완료될 수 있습니다. 이는 이전 배포가 나중에 종료되어 “더 최신” 배포를 덮어쓰는 경쟁 조건을 만듭니다.
오래된 배포 작업 방지 기능을 활성화하여 더 최신의 배포 작업이 시작될 때 이전 배포 작업이 실행되지 않도록 할 수 있습니다.
더 오래된 배포 작업이 시작될 때 실패하고 다음과 같이 표시됩니다.
- 파이프라인 보기에서
오래된 배포 작업 실패 - 완료된 작업을 볼 때
오래된 배포 작업은 최신 배포보다 오래되었고 따라서 실패했습니다..
작업 연령은 커밋 시간이 아닌 작업 시작 시간에 의해 결정되므로 어떤 경우에는 더 최신의 커밋도 방지될 수 있습니다.
롤백 배포를 위한 작업 재시도
빠르게 안정적인 오래된 배포로 롤백할 수 있는 경우가 있습니다. 기본적으로 배포 롤백을 위한 파이프라인 작업 재시도가 활성화되어 있습니다.
파이프라인 재시도를 비활성화하려면 롤백 배포를 위한 작업 재시도 허용 확인란을 선택 해제하십시오. 민감한 프로젝트에서는 파이프라인 재시도를 비활성화해야 합니다.
롤백이 필요한 경우 이전 커밋으로 새 파이프라인을 실행해야 합니다.
예시
오래된 배포 작업 방지를 활성화하기 전의 문제가 있는 파이프라인 흐름의 예:
- 기본 브랜치에서 Pipeline-A가 생성됨.
- 이후 더 최신의 커밋 SHA로 기본 브랜치에서 Pipeline-B가 생성됨.
- Pipeline-B의
deploy작업이 먼저 완료되어 더 최신 코드를 배포함. - Pipeline-A의
deploy작업이 나중에 완료되어 더 오래된(최신) 배포를 덮어쓰기함.
오래된 배포 작업 방지를 활성화한 이후 문제가 있는 파이프라인 흐름의 예:
- 기본 브랜치에서 Pipeline-A가 생성됨.
- 이후 더 최신의 SHA로 기본 브랜치에서 Pipeline-B가 생성됨.
- Pipeline-B의
deploy작업이 먼저 완료되어 더 최신 코드를 배포함. - Pipeline-A의
deploy작업이 실패하여 더 최신 파이프라인에서의 배포를 덮어쓰지 않게 됨.
배포 동결 기간 중 배포 방지
특정 기간(예: 대부분의 직원이 휴가 중인 계획된 휴가 기간) 동안 배포를 방지하고 싶은 경우 [배포 동결](../../user/project/releases/in 다음 구성된 배포 동결은 맨 위의 환경 배포 목록 페이지에 표시됩니다.
프로덕션 시크릿 보호
프로덕션 시크릿은 성공적으로 배포하기 위해 필요합니다. 예를 들어, 클라우드로 배포할 때 클라우드 제공업체는 서비스에 연결하기 위해 이러한 시크릿을 요구합니다. 프로젝트 설정에서 이러한 시크릿에 대한 CI/CD 변수를 정의하고 보호할 수 있습니다. 보호된 변수는 보호된 브랜치 또는 보호된 태그에서 실행되는 파이프라인에만 전달됩니다. 다른 파이프라인은 보호된 변수를 받지 않습니다. 또한 특정 환경에 변수의 범위를 지정할 수 있습니다. 우리는 보호된 변수를 보호된 환경에서 사용하여 시크릿이 의도치 않게 노출되지 않도록 권장합니다. 또한 런너 측에서 프로덕션 시크릿을 정의할 수 있습니다. 이렇게 함으로써 Maintainer 역할을 하는 다른 사용자가 시크릿을 읽지 못하도록 하고 런너가 보호된 브랜치에서만 실행되도록 할 수 있습니다.
더 자세한 정보는 파이프라인 보안을 참조하세요.
배포를 위한 별도의 프로젝트
프로젝트에 대한 Maintainer 역할을 하는 모든 사용자는 프로덕션 시크릿에 액세스할 수 있습니다. 만약 프로덕션 환경으로의 배포를 제한하려면 별도의 프로젝트를 생성하고 CD 권한을 원본 프로젝트와 분리하여 새로운 권한 모델을 구성할 수 있습니다. 그렇게 함으로써 원본 프로젝트의 Maintainer 역할을 하는 사용자가 프로덕션 시크릿 및 CD 구성에 액세스하지 못하도록 할 수 있습니다. 다중 프로젝트 파이프라인을 사용하여 CD 프로젝트를 개발 프로젝트에 연결할 수 있습니다.
.gitlab-ci.yml의 변경으로부터 보호
.gitlab-ci.yml에는 애플리케이션을 프로덕션 서버로 배포하기 위한 규칙이 포함될 수 있습니다. 일반적으로 이 배포는 병합 요청을 푸시한 후 자동으로 실행됩니다. 개발자가 .gitlab-ci.yml을 변경하지 못하도록 하려면 이것을 다른 저장소에 정의할 수 있습니다. 이 구성은 다른 프로젝트에 있는 다른 파일을 참조할 수 있도록 만들어진 전혀 다른 권한 집합을 갖습니다(배포를 위한 별도의 프로젝트와 유사). 이러한 시나리오에서 .gitlab-ci.yml은 공개적으로 접근할 수 있지만 적절한 권한을 갖춘 사용자만이 편집할 수 있습니다.
더 자세한 정보는 사용자 정의 CI/CD 구성 경로를 참조하세요.
배포하기 전 승인 요청
프로덕션 환경으로의 배포를 승인하기 전에 특정 테스트 그룹에서 교차 확인하는 것은 안전을 보장하는 효과적인 방법입니다. 더 자세한 정보는 배포 승인을 참조하세요.
도움말