- 중요 환경에 대한 쓰기 접근 제한
- 한 번에 하나의 배포 작업만 실행되도록 보장
- 구식 배포 작업 방지
- 배포 동결 기간 동안 배포 방지
- 프로덕션 비밀 보호
- 배포를 위한 별도 프로젝트
.gitlab-ci.yml
변경 방지- 배포 전에 승인 요구
배포 안전성
배포 작업은 특정 종류의 CI/CD 작업입니다.
이들은 파이프라인의 다른 작업보다 더 민감할 수 있으며,
추가적인 주의가 필요할 수 있습니다. GitLab에는 배포 보안 및 안정성을 유지하는 데 도움을 주는 여러 기능이 있습니다.
다음과 같은 작업을 수행할 수 있습니다:
-
프로젝트에 적절한 역할을 설정합니다. 프로젝트 멤버 권한을 참조하여 GitLab에서 지원하는 다양한 사용자 역할과 각 역할의 권한을 확인하세요.
- 중요 환경에 대한 쓰기 접근 제한
- 배포 중단 기간 동안 배포 방지
- 생산 비밀 보호
- 배포를 위한 별도의 프로젝트
지속적인 배포 워크플로우를 사용하고 있고 동일한 환경에 대한 동시 배포가 발생하지 않도록 하려면, 다음 옵션을 활성화해야 합니다:
개요에 대한 내용은 CD 파이프라인/워크플로우를 보호하는 방법을 참조하세요.
중요 환경에 대한 쓰기 접근 제한
기본적으로 환경은 최소한 개발자 역할을 가진 모든 팀원이 수정할 수 있습니다.
중요 환경(예: production
환경)에 대한 쓰기 접근을 제한하려면, 보호된 환경을 설정할 수 있습니다.
한 번에 하나의 배포 작업만 실행되도록 보장
GitLab CI/CD의 파이프라인 작업은 병렬로 실행되므로, 두 개의 서로 다른 파이프라인에서 두 개의 배포 작업이
동시에 동일한 환경에 배포를 시도할 수 있습니다. 이는 원하지 않는 동작으로, 배포는 순차적으로 발생해야 합니다.
.gitlab-ci.yml
에서 resource_group
키워드를 사용하여 한 번에 하나의 배포 작업만 실행되도록 보장할 수 있습니다.
예를 들어:
deploy:
script: deploy-to-prod
resource_group: prod
자원 그룹을 사용하기 전 문제가 발생하는 파이프라인 흐름 예시:
-
deploy
작업이 Pipeline-A에서 실행을 시작합니다. -
deploy
작업이 Pipeline-B에서 실행을 시작합니다. 이는 예기치 않은 결과를 초래할 수 있는 동시 배포입니다. -
deploy
작업이 Pipeline-A에서 완료됩니다. -
deploy
작업이 Pipeline-B에서 완료됩니다.
자원 그룹을 사용한 후 개선된 파이프라인 흐름:
-
deploy
작업이 Pipeline-A에서 실행을 시작합니다. -
deploy
작업이 Pipeline-B에서 시작을 시도하지만, 첫 번째deploy
작업이 완료될 때까지 기다립니다. -
deploy
작업이 Pipeline-A에서 완료됩니다. -
deploy
작업이 Pipeline-B에서 실행을 시작합니다.
자세한 내용은 Resource Group 문서를 참조하세요.
구식 배포 작업 방지
- 변경됨 GitLab 15.5에서 구식 작업 실행을 방지합니다.
파이프라인 작업의 효과적인 실행 순서는 실행마다 다를 수 있으며,
이는 원치 않는 동작을 초래할 수 있습니다. 예를 들어, 배포 작업이
새로운 파이프라인에서 완료되기 전에 오래된 파이프라인에서 배포 작업이 완료될 수 있습니다.
이로 인해 더 오래된 배포가 나중에 완료되어 “더 새로운” 배포를 덮어쓰는 경쟁 조건이 발생합니다.
더 새로운 배포 작업이 시작될 때 오래된 배포 작업이 실행되지 않도록 하려면,
구식 배포 작업 방지 기능을 활성화하세요.
오래된 배포 작업이 시작되면 실패하고 다음과 같이 표시됩니다:
- 파이프라인 뷰에서
failed outdated deployment job
. - 완료된 작업을 볼 때
이 배포 작업은 최신 배포보다 오래되어 실패했습니다.
오래된 배포 작업이 수동인 경우, 실행 () 버튼이 비활성화되며
이 배포 작업은 자동으로 실행되지 않으며 수동으로 시작해야 하지만, 최신 배포보다 오래되어 실행할 수 없습니다.
라는 메시지가 표시됩니다.
작업의 나이는 작업 시작 시간을 기준으로 하며, 커밋 시간으로 판단하지 않으므로,
상황에 따라 최신 커밋이 방지될 수 있습니다.
롤백 배포를 위한 작업 재시도
안정적인 이전 배포로 신속하게 롤백해야 할 수 있습니다.
기본적으로 파이프라인 작업 재시도는 배포 롤백에 대해 활성화되어 있습니다.
파이프라인 재시도를 비활성화하려면 롤백 배포에 대한 작업 재시도를 허용 체크박스를 선택 해제하세요.
민감한 프로젝트에서는 파이프라인 재시도를 비활성화해야 합니다.
롤백이 필요한 경우, 이전 커밋을 사용하여 새 파이프라인을 실행해야 합니다.
예시
문제 있는 파이프라인 흐름의 예시 이전에 최신 배포 작업 방지 기능을 활성화할 때:
- Pipeline-A가 기본 브랜치에서 생성됩니다.
- 나중에 Pipeline-B가 기본 브랜치에서 생성됩니다(더 새로운 커밋 SHA로).
- Pipeline-B의
deploy
작업이 먼저 완료되고, 더 새로운 코드를 배포합니다. - Pipeline-A의
deploy
작업이 나중에 완료되고, 더 오래된 코드를 배포하여 덮어씁니다(최신 배포).
개선된 파이프라인 흐름 이후에 최신 배포 작업 방지 기능을 활성화할 때:
- Pipeline-A가 기본 브랜치에서 생성됩니다.
- 나중에 Pipeline-B가 기본 브랜치에서 생성됩니다(더 새로운 SHA로).
- Pipeline-B의
deploy
작업이 먼저 완료되고, 더 새로운 코드를 배포합니다. - Pipeline-A의
deploy
작업이 실패하여 더 새로운 파이프라인의 배포를 덮어쓰지 않도록 합니다.
배포 동결 기간 동안 배포 방지
특정 기간 동안 배포를 방지하려는 경우, 예를 들어 대부분의 직원이 없는 예정된 휴가 기간 동안, 배포 동결을 설정할 수 있습니다.
배포 동결 기간 동안 배포를 실행할 수 없습니다.
이는 배포가 예기치 않게 발생하지 않도록 하는 데 도움이 됩니다.
다음에 구성된 배포 동결은 환경 배포 목록 페이지 상단에 표시됩니다.
프로덕션 비밀 보호
프로덕션 비밀은 성공적으로 배포하려면 필요합니다. 예를 들어 클라우드에 배포할 때 클라우드 제공업체는 서비스에 연결하기 위해 이러한 비밀을 요구합니다. 프로젝트 설정에서 이러한 비밀에 대한 CI/CD 변수를 정의하고 보호할 수 있습니다.
보호된 변수는 보호된 브랜치 또는 보호된 태그에서 실행되는 파이프라인에만 전달됩니다.
다른 파이프라인은 보호된 변수를 받지 않습니다. 특정 환경에 변수를 범위 지정할 수도 있습니다.
우리는 비밀이 우발적으로 노출되지 않도록 보호된 환경에서 보호된 변수를 사용하는 것을 권장합니다.
프로덕션 비밀을 러너 측에서 정의할 수도 있습니다.
이것은 Maintainer 역할을 가진 다른 사용자가 비밀을 읽지 못하도록 하고, 러너가 보호된 브랜치에서만 실행되도록 합니다.
자세한 내용은 파이프라인 보안을 참조하세요.
배포를 위한 별도 프로젝트
프로젝트에 대한 Maintainer 역할을 가진 모든 사용자가 프로덕션 비밀에 접근할 수 있습니다.
프로덕션 환경에 배포할 수 있는 사용자 수를 제한해야 하는 경우, 별도의 프로젝트를 생성하고 CD 권한을 원래 프로젝트에서 분리하여 접근을 방지하는 새로운 권한 모델을 구성할 수 있습니다.
CD 프로젝트를 개발 프로젝트와 다중 프로젝트 파이프라인을 사용하여 연결할 수 있습니다.
.gitlab-ci.yml
변경 방지
.gitlab-ci.yml
파일은 애플리케이션을 프로덕션 서버에 배포하는 규칙을 포함할 수 있습니다.
이 배포는 일반적으로 Merge Request를 푸시한 후 자동으로 실행됩니다.
개발자가 .gitlab-ci.yml
을 변경하지 못하도록 하려면, 다른 저장소에 정의할 수 있습니다.
이 구성은 완전히 다른 권한 집합을 가진 다른 프로젝트의 파일을 참조할 수 있습니다(배포를 위한 프로젝트 분리와 유사하게 separating a project for deployments).
이 시나리오에서는 .gitlab-ci.yml
이 공개적으로 접근 가능하지만, 다른 프로젝트에서 적절한 권한이 있는 사용자만 편집할 수 있습니다.
자세한 내용은 Custom CI/CD configuration path를 참조하세요.
배포 전에 승인 요구
배포를 프로덕션 환경으로 승격하기 전에 전담 테스트 그룹과 교차 확인하는 것은 안전성을 보장하는 효과적인 방법입니다.
자세한 내용은 Deployment Approvals를 참조하세요.