InfoGrab Docs

보호된 환경

요약

환경은 테스트 및 프로덕션 목적 모두에 사용될 수 있습니다. 배포 잡은 다른 역할을 가진 다른 사용자가 실행할 수 있으므로, 특정 환경을 권한이 없는 사용자로부터 보호할 수 있는 것이 중요합니다. 기본적으로 보호된 환경은 적절한 권한을 가진 사람만 배포할 수 있도록 하여 환경을 안전하게 유지합니다.

환경은 테스트 및 프로덕션 목적 모두에 사용될 수 있습니다.

배포 잡은 다른 역할을 가진 다른 사용자가 실행할 수 있으므로, 특정 환경을 권한이 없는 사용자로부터 보호할 수 있는 것이 중요합니다.

기본적으로 보호된 환경은 적절한 권한을 가진 사람만 배포할 수 있도록 하여 환경을 안전하게 유지합니다.

Note

GitLab 관리자는 보호된 환경을 포함한 모든 환경을 사용할 수 있습니다.

환경을 보호하거나 보호 해제하려면 최소한 Maintainer 역할이 있어야 합니다. 또한 external_url, tier, description과 같은 환경 속성을 업데이트하려면 배포 허용 목록에도 포함되어 있어야 합니다.

환경 보호#

사전 조건:

  • 승인자 그룹에 배포 허용 권한을 부여할 때, 보호된 환경을 구성하는 사용자는 추가할 승인자 그룹의 직접 멤버여야 합니다. 그렇지 않으면 그룹 또는 하위 그룹이 드롭다운 목록에 표시되지 않습니다. 자세한 내용은 이슈 #345140을 참조하세요.
  • 승인자 그룹 또는 프로젝트에 승인자 권한을 부여할 때, 기본적으로 승인자 그룹 또는 프로젝트의 직접 멤버만 이러한 권한을 받습니다. 승인자 그룹 또는 프로젝트의 상속된 멤버에게도 이러한 권한을 부여하려면:
    • 그룹 상속 활성화 확인란을 선택합니다.
    • API를 사용합니다.

환경을 보호하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.

  2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.

  3. 보호된 환경을 확장합니다.

  4. 환경 보호를 선택합니다.

  5. 환경 목록에서 보호할 환경을 선택합니다.

  6. 배포 허용 목록에서 배포 액세스를 부여할 역할, 사용자 또는 그룹을 선택합니다. 다음 사항을 고려하세요:

    • 두 가지 역할 중에서 선택할 수 있습니다:
      • Maintainer: Maintainer 역할을 가진 모든 프로젝트 사용자에게 액세스를 허용합니다.
      • Developer: Maintainer 및 Developer 역할을 가진 모든 프로젝트 사용자에게 액세스를 허용합니다.
    • 이미 프로젝트에 초대된 그룹도 선택할 수 있습니다. Reporter 역할로 프로젝트에 추가된 초대 그룹은 배포 전용 액세스를 위한 드롭다운 목록에 표시됩니다.
    • 특정 사용자도 선택할 수 있습니다. 사용자는 배포 허용 목록에 표시되려면 Developer, Maintainer 또는 Owner 역할이 있어야 합니다.
  7. 승인자 목록에서 배포 액세스를 부여할 역할, 사용자 또는 그룹을 선택합니다. 다음 사항을 고려하세요:

    • 두 가지 역할 중에서 선택할 수 있습니다:
      • Maintainer: Maintainer 역할을 가진 모든 프로젝트 사용자에게 액세스를 허용합니다.
      • Developer: Maintainer 및 Developer 역할을 가진 모든 프로젝트 사용자에게 액세스를 허용합니다.
    • 이미 프로젝트에 초대된 그룹만 선택할 수 있습니다.
    • 사용자는 승인자 목록에 표시되려면 Developer, Maintainer 또는 Owner 역할이 있어야 합니다.
  8. 승인 규칙 섹션에서:

    • 이 숫자가 규칙의 멤버 수보다 작거나 같은지 확인합니다.
    • 이 기능에 대한 자세한 내용은 배포 승인을 참조하세요.
  9. 보호를 선택합니다.

이제 보호된 환경이 보호된 환경 목록에 표시됩니다.

API를 사용하여 환경 보호#

또는 API를 사용하여 환경을 보호할 수 있습니다:

  1. 환경을 생성하는 CI가 있는 프로젝트를 사용합니다. 예를 들어:

    stages:
      - test
      - deploy
    
    test:
      stage: test
      script:
        - 'echo "Testing Application: ${CI_PROJECT_NAME}"'
    
    production:
      stage: deploy
      when: manual
      script:
        - 'echo "Deploying to ${CI_ENVIRONMENT_NAME}"'
      environment:
        name: ${CI_JOB_NAME}
    
  2. UI를 사용하여 새 그룹을 생성합니다. 예를 들어, 이 그룹은 protected-access-group이라고 하며 그룹 ID는 9899826입니다. 참고로 이 단계의 나머지 예시에서는 이 그룹을 사용합니다.

    새 프로젝트 버튼이 강조 표시된 보호된 액세스 그룹 인터페이스.

  3. API를 사용하여 Reporter로 그룹에 사용자를 추가합니다:

    $ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
           --data "user_id=3222377&access_level=20" "https://gitlab.com/api/v4/groups/9899826/members"
    
    {"id":3222377,"name":"Sean Carroll","username":"sfcarroll","state":"active","avatar_url":"https://gitlab.com/uploads/-/system/user/avatar/3222377/avatar.png","web_url":"https://gitlab.com/sfcarroll","access_level":20,"created_at":"2020-10-26T17:37:50.309Z","expires_at":null}
    
  4. API를 사용하여 Reporter로 프로젝트에 그룹을 추가합니다:

    $ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
           --request POST "https://gitlab.com/api/v4/projects/22034114/share?group_id=9899826&group_access=20"
    
    {"id":1233335,"project_id":22034114,"group_id":9899826,"group_access":20,"expires_at":null}
    
  5. API를 사용하여 보호된 환경 액세스가 있는 그룹을 추가합니다:

    curl --header 'Content-Type: application/json' --request POST --data '{"name": "production", "deploy_access_levels": [{"group_id": 9899826}]}' \
         --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.com/api/v4/projects/22034114/protected_environments"
    

이제 그룹에 액세스 권한이 부여되고 UI에서 확인할 수 있습니다.

그룹 멤버십을 통한 환경 액세스#

사용자는 그룹 멤버십의 일환으로 보호된 환경에 대한 액세스 권한을 부여받을 수 있습니다. Reporter 역할을 가진 사용자는 이 방법으로만 보호된 환경에 대한 액세스 권한을 부여받을 수 있습니다.

배포 브랜치 액세스#

Developer 역할을 가진 사용자는 다음 방법 중 하나를 통해 보호된 환경에 대한 액세스 권한을 받을 수 있습니다:

  • 개별 기여자로서, 역할을 통해.
  • 그룹 멤버십을 통해.

사용자가 프로덕션에 배포된 브랜치에 대한 push 또는 머지 액세스 권한도 있는 경우, 다음 권한이 부여됩니다:

보호된 환경에 대한 배포 전용 액세스 {#deployment-only-access-to-protected-environments}#

보호된 환경에 대한 액세스는 부여받았지만 배포된 브랜치에 대한 push 또는 머지 액세스가 없는 사용자는 환경 배포만 허용됩니다. Reporter 역할로 프로젝트에 추가된 초대 그룹은 배포 전용 액세스를 위한 드롭다운 목록에 표시됩니다.

배포 전용 액세스를 추가하려면:

  1. 아직 존재하지 않는 경우, 보호된 환경에 대한 액세스 권한을 부여받을 멤버가 있는 그룹을 생성합니다.
  2. Reporter 역할로 그룹을 프로젝트에 초대합니다.
  3. 환경 보호의 단계를 따릅니다.

환경 수정 및 보호 해제#

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

  • 배포 허용 목록 및 승인 규칙을 포함한 보호 설정을 언제든지 업데이트합니다.
  • 해당 환경의 보호 해제를 선택하여 보호된 환경의 보호를 해제합니다.

보호된 환경에서 external_url, tier, description과 같은 환경 속성을 업데이트하려면 사용자가 배포 허용 목록에도 포함되어 있어야 합니다.

환경의 보호가 해제되면 모든 액세스 항목이 삭제되며, 환경이 다시 보호되는 경우 다시 입력해야 합니다.

승인 규칙이 삭제된 후, 이전에 승인된 배포는 배포를 승인한 사람을 표시하지 않습니다. 배포를 승인한 사람에 대한 정보는 프로젝트 감사 이벤트에서 계속 확인할 수 있습니다. 새 규칙이 추가되면 이전 배포는 배포 승인 옵션 없이 새 규칙을 표시합니다. 이슈 506687은 승인 규칙이 삭제된 경우에도 배포의 전체 승인 기록을 표시하도록 제안합니다.

자세한 내용은 배포 안전성을 참조하세요.

그룹 수준 보호된 환경#

일반적으로 대규모 기업 조직에는 개발자와 운영자 사이에 명시적인 권한 경계가 있습니다. 개발자는 코드를 빌드하고 테스트하며, 운영자는 애플리케이션을 배포하고 모니터링합니다. 그룹 수준 보호된 환경을 통해 운영자는 개발자로부터 중요한 환경에 대한 액세스를 제한할 수 있습니다. 그룹 수준 보호된 환경은 프로젝트 수준 보호된 환경을 그룹 수준으로 확장합니다.

배포 권한은 다음 표에 나타낼 수 있습니다:

환경 개발자 운영자 카테고리
개발 허용됨 허용됨 하위 환경
테스트 허용됨 허용됨 하위 환경
스테이징 허용 안 됨 허용됨 상위 환경
프로덕션 허용 안 됨 허용됨 상위 환경

(참조: 위키피디아의 배포 환경)

그룹 수준 보호된 환경 이름#

프로젝트 수준 보호된 환경과 달리, 그룹 수준 보호된 환경은 이름으로 배포 티어를 사용합니다.

그룹은 고유한 이름을 가진 많은 프로젝트 환경으로 구성될 수 있습니다. 예를 들어, 프로젝트-A는 gprd 환경을 갖고 프로젝트-B는 Production 환경을 가지므로, 특정 환경 이름을 보호하는 것은 확장성이 좋지 않습니다. 배포 티어를 사용하면 두 환경 모두 production 배포 티어로 인식되어 동시에 보호됩니다.

그룹 수준 멤버십 구성#

히스토리
  • 운영자는 GitLab 15.3에서 원래 Maintainer+ 역할에서 Owner+ 역할이 필요하도록 변경되었으며, 이 역할 변경은 group_level_protected_environment_settings_permission이라는 플래그와 함께 도입되었습니다. 기본적으로 활성화됨.
  • GitLab 15.4에서 기능 플래그가 제거됨.

그룹 수준 보호된 환경의 효과를 극대화하려면 그룹 수준 멤버십이 올바르게 구성되어야 합니다:

  • 운영자는 최상위 그룹에서 Owner 역할을 부여받아야 합니다. 그들은 그룹 수준 보호된 환경, 그룹 수준 러너, 그룹 수준 클러스터를 포함하여 그룹 수준 설정 페이지에서 상위 환경(예: 프로덕션)에 대한 CI/CD 구성을 유지 관리할 수 있습니다. 이러한 구성은 읽기 전용 항목으로 하위 프로젝트에 상속됩니다. 이를 통해 운영자만 조직 전체 배포 규칙 세트를 구성할 수 있습니다.
  • 개발자는 최상위 그룹에서 Developer 역할 이하로만 부여받거나, 하위 프로젝트에서 명시적으로 Owner 역할을 부여받아야 합니다. 그들은 최상위 그룹의 CI/CD 구성에 액세스할 수 없으므로, 운영자는 중요한 구성이 개발자에 의해 실수로 변경되지 않도록 보장할 수 있습니다.
  • 하위 그룹 및 하위 프로젝트의 경우:
    • 하위 그룹의 경우, 상위 그룹이 그룹 수준 보호된 환경을 구성한 경우 하위 그룹은 이를 재정의할 수 없습니다.
    • 프로젝트 수준 보호된 환경은 그룹 수준 설정과 결합될 수 있습니다. 그룹 수준 및 프로젝트 수준 환경 구성이 모두 존재하는 경우, 배포 잡을 실행하려면 사용자가 두 규칙 모두에서 허용되어야 합니다.
    • 최상위 그룹의 프로젝트 또는 하위 그룹에서, 개발자는 하위 환경(예: testing)을 조정하기 위해 안전하게 Maintainer 역할을 부여받을 수 있습니다.

이 구성이 있는 경우:

  • 사용자가 프로젝트에서 배포 잡을 실행하려고 하고 환경에 배포가 허용되면 배포 잡이 진행됩니다.
  • 사용자가 프로젝트에서 배포 잡을 실행하려고 하지만 환경에 배포가 허용되지 않으면 배포 잡이 오류 메시지와 함께 실패합니다.

그룹 아래의 중요한 환경 보호#

그룹 수준 환경을 보호하려면 환경에 .gitlab-ci.yml에서 올바른 deployment_tier가 정의되어 있어야 합니다.

UI 사용#

히스토리
  1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.
  3. 보호된 환경을 확장합니다.
  4. 환경 목록에서 보호할 환경의 배포 티어를 선택합니다.
  5. 배포 허용 목록에서 배포 액세스를 부여할 하위 그룹을 선택합니다.
  6. 보호를 선택합니다.

API 사용#

REST API를 사용하여 그룹 수준 보호된 환경을 구성합니다.

배포 승인#

보호된 환경은 배포 전에 수동 승인을 요구하는 데도 사용할 수 있습니다. 자세한 내용은 배포 승인을 참조하세요.

문제 해결#

Reporter가 다운스트림 파이프라인에서 보호된 환경에 배포하는 트리거 잡을 실행할 수 없음#

보호된 환경에 대한 배포 전용 액세스를 가진 사용자는 trigger 키워드가 있는 잡을 실행할 수 없을 수 있습니다. 이는 잡에 보호된 환경과 연결하기 위한 environment 키워드 정의가 없기 때문에, 잡이 일반 CI/CD 권한 모델을 사용하는 표준 잡으로 인식됩니다.

trigger 키워드로 environment 키워드 지원에 대한 자세한 내용은 이 이슈를 참조하세요.

보호된 환경

Tier: Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

환경은 테스트 및 프로덕션 목적 모두에 사용될 수 있습니다. 배포 잡은 다른 역할을 가진 다른 사용자가 실행할 수 있으므로, 특정 환경을 권한이 없는 사용자로부터 보호할 수 있는 것이 중요합니다. 기본적으로 보호된 환경은 적절한 권한을 가진 사람만 배포할 수 있도록 하여 환경을 안전하게 유지합니다.

환경은 테스트 및 프로덕션 목적 모두에 사용될 수 있습니다.

배포 잡은 다른 역할을 가진 다른 사용자가 실행할 수 있으므로, 특정 환경을 권한이 없는 사용자로부터 보호할 수 있는 것이 중요합니다.

기본적으로 보호된 환경은 적절한 권한을 가진 사람만 배포할 수 있도록 하여 환경을 안전하게 유지합니다.

Note

GitLab 관리자는 보호된 환경을 포함한 모든 환경을 사용할 수 있습니다.

환경을 보호하거나 보호 해제하려면 최소한 Maintainer 역할이 있어야 합니다. 또한 external_url, tier, description과 같은 환경 속성을 업데이트하려면 배포 허용 목록에도 포함되어 있어야 합니다.

환경 보호#

사전 조건:

  • 승인자 그룹에 배포 허용 권한을 부여할 때, 보호된 환경을 구성하는 사용자는 추가할 승인자 그룹의 직접 멤버여야 합니다. 그렇지 않으면 그룹 또는 하위 그룹이 드롭다운 목록에 표시되지 않습니다. 자세한 내용은 이슈 #345140을 참조하세요.
  • 승인자 그룹 또는 프로젝트에 승인자 권한을 부여할 때, 기본적으로 승인자 그룹 또는 프로젝트의 직접 멤버만 이러한 권한을 받습니다. 승인자 그룹 또는 프로젝트의 상속된 멤버에게도 이러한 권한을 부여하려면:
    • 그룹 상속 활성화 확인란을 선택합니다.
    • API를 사용합니다.

환경을 보호하려면:

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.

  2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.

  3. 보호된 환경을 확장합니다.

  4. 환경 보호를 선택합니다.

  5. 환경 목록에서 보호할 환경을 선택합니다.

  6. 배포 허용 목록에서 배포 액세스를 부여할 역할, 사용자 또는 그룹을 선택합니다. 다음 사항을 고려하세요:

    • 두 가지 역할 중에서 선택할 수 있습니다:
      • Maintainer: Maintainer 역할을 가진 모든 프로젝트 사용자에게 액세스를 허용합니다.
      • Developer: Maintainer 및 Developer 역할을 가진 모든 프로젝트 사용자에게 액세스를 허용합니다.
    • 이미 프로젝트에 초대된 그룹도 선택할 수 있습니다. Reporter 역할로 프로젝트에 추가된 초대 그룹은 배포 전용 액세스를 위한 드롭다운 목록에 표시됩니다.
    • 특정 사용자도 선택할 수 있습니다. 사용자는 배포 허용 목록에 표시되려면 Developer, Maintainer 또는 Owner 역할이 있어야 합니다.
  7. 승인자 목록에서 배포 액세스를 부여할 역할, 사용자 또는 그룹을 선택합니다. 다음 사항을 고려하세요:

    • 두 가지 역할 중에서 선택할 수 있습니다:
      • Maintainer: Maintainer 역할을 가진 모든 프로젝트 사용자에게 액세스를 허용합니다.
      • Developer: Maintainer 및 Developer 역할을 가진 모든 프로젝트 사용자에게 액세스를 허용합니다.
    • 이미 프로젝트에 초대된 그룹만 선택할 수 있습니다.
    • 사용자는 승인자 목록에 표시되려면 Developer, Maintainer 또는 Owner 역할이 있어야 합니다.
  8. 승인 규칙 섹션에서:

    • 이 숫자가 규칙의 멤버 수보다 작거나 같은지 확인합니다.
    • 이 기능에 대한 자세한 내용은 배포 승인을 참조하세요.
  9. 보호를 선택합니다.

이제 보호된 환경이 보호된 환경 목록에 표시됩니다.

API를 사용하여 환경 보호#

또는 API를 사용하여 환경을 보호할 수 있습니다:

  1. 환경을 생성하는 CI가 있는 프로젝트를 사용합니다. 예를 들어:

    stages:
      - test
      - deploy
    
    test:
      stage: test
      script:
        - 'echo "Testing Application: ${CI_PROJECT_NAME}"'
    
    production:
      stage: deploy
      when: manual
      script:
        - 'echo "Deploying to ${CI_ENVIRONMENT_NAME}"'
      environment:
        name: ${CI_JOB_NAME}
    
  2. UI를 사용하여 새 그룹을 생성합니다. 예를 들어, 이 그룹은 protected-access-group이라고 하며 그룹 ID는 9899826입니다. 참고로 이 단계의 나머지 예시에서는 이 그룹을 사용합니다.

    새 프로젝트 버튼이 강조 표시된 보호된 액세스 그룹 인터페이스.

  3. API를 사용하여 Reporter로 그룹에 사용자를 추가합니다:

    $ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
           --data "user_id=3222377&access_level=20" "https://gitlab.com/api/v4/groups/9899826/members"
    
    {"id":3222377,"name":"Sean Carroll","username":"sfcarroll","state":"active","avatar_url":"https://gitlab.com/uploads/-/system/user/avatar/3222377/avatar.png","web_url":"https://gitlab.com/sfcarroll","access_level":20,"created_at":"2020-10-26T17:37:50.309Z","expires_at":null}
    
  4. API를 사용하여 Reporter로 프로젝트에 그룹을 추가합니다:

    $ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
           --request POST "https://gitlab.com/api/v4/projects/22034114/share?group_id=9899826&group_access=20"
    
    {"id":1233335,"project_id":22034114,"group_id":9899826,"group_access":20,"expires_at":null}
    
  5. API를 사용하여 보호된 환경 액세스가 있는 그룹을 추가합니다:

    curl --header 'Content-Type: application/json' --request POST --data '{"name": "production", "deploy_access_levels": [{"group_id": 9899826}]}' \
         --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.com/api/v4/projects/22034114/protected_environments"
    

이제 그룹에 액세스 권한이 부여되고 UI에서 확인할 수 있습니다.

그룹 멤버십을 통한 환경 액세스#

사용자는 그룹 멤버십의 일환으로 보호된 환경에 대한 액세스 권한을 부여받을 수 있습니다. Reporter 역할을 가진 사용자는 이 방법으로만 보호된 환경에 대한 액세스 권한을 부여받을 수 있습니다.

배포 브랜치 액세스#

Developer 역할을 가진 사용자는 다음 방법 중 하나를 통해 보호된 환경에 대한 액세스 권한을 받을 수 있습니다:

  • 개별 기여자로서, 역할을 통해.
  • 그룹 멤버십을 통해.

사용자가 프로덕션에 배포된 브랜치에 대한 push 또는 머지 액세스 권한도 있는 경우, 다음 권한이 부여됩니다:

보호된 환경에 대한 배포 전용 액세스 {#deployment-only-access-to-protected-environments}#

보호된 환경에 대한 액세스는 부여받았지만 배포된 브랜치에 대한 push 또는 머지 액세스가 없는 사용자는 환경 배포만 허용됩니다. Reporter 역할로 프로젝트에 추가된 초대 그룹은 배포 전용 액세스를 위한 드롭다운 목록에 표시됩니다.

배포 전용 액세스를 추가하려면:

  1. 아직 존재하지 않는 경우, 보호된 환경에 대한 액세스 권한을 부여받을 멤버가 있는 그룹을 생성합니다.
  2. Reporter 역할로 그룹을 프로젝트에 초대합니다.
  3. 환경 보호의 단계를 따릅니다.

환경 수정 및 보호 해제#

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

  • 배포 허용 목록 및 승인 규칙을 포함한 보호 설정을 언제든지 업데이트합니다.
  • 해당 환경의 보호 해제를 선택하여 보호된 환경의 보호를 해제합니다.

보호된 환경에서 external_url, tier, description과 같은 환경 속성을 업데이트하려면 사용자가 배포 허용 목록에도 포함되어 있어야 합니다.

환경의 보호가 해제되면 모든 액세스 항목이 삭제되며, 환경이 다시 보호되는 경우 다시 입력해야 합니다.

승인 규칙이 삭제된 후, 이전에 승인된 배포는 배포를 승인한 사람을 표시하지 않습니다. 배포를 승인한 사람에 대한 정보는 프로젝트 감사 이벤트에서 계속 확인할 수 있습니다. 새 규칙이 추가되면 이전 배포는 배포 승인 옵션 없이 새 규칙을 표시합니다. 이슈 506687은 승인 규칙이 삭제된 경우에도 배포의 전체 승인 기록을 표시하도록 제안합니다.

자세한 내용은 배포 안전성을 참조하세요.

그룹 수준 보호된 환경#

일반적으로 대규모 기업 조직에는 개발자와 운영자 사이에 명시적인 권한 경계가 있습니다. 개발자는 코드를 빌드하고 테스트하며, 운영자는 애플리케이션을 배포하고 모니터링합니다. 그룹 수준 보호된 환경을 통해 운영자는 개발자로부터 중요한 환경에 대한 액세스를 제한할 수 있습니다. 그룹 수준 보호된 환경은 프로젝트 수준 보호된 환경을 그룹 수준으로 확장합니다.

배포 권한은 다음 표에 나타낼 수 있습니다:

환경 개발자 운영자 카테고리
개발 허용됨 허용됨 하위 환경
테스트 허용됨 허용됨 하위 환경
스테이징 허용 안 됨 허용됨 상위 환경
프로덕션 허용 안 됨 허용됨 상위 환경

(참조: 위키피디아의 배포 환경)

그룹 수준 보호된 환경 이름#

프로젝트 수준 보호된 환경과 달리, 그룹 수준 보호된 환경은 이름으로 배포 티어를 사용합니다.

그룹은 고유한 이름을 가진 많은 프로젝트 환경으로 구성될 수 있습니다. 예를 들어, 프로젝트-A는 gprd 환경을 갖고 프로젝트-B는 Production 환경을 가지므로, 특정 환경 이름을 보호하는 것은 확장성이 좋지 않습니다. 배포 티어를 사용하면 두 환경 모두 production 배포 티어로 인식되어 동시에 보호됩니다.

그룹 수준 멤버십 구성#

히스토리
  • 운영자는 GitLab 15.3에서 원래 Maintainer+ 역할에서 Owner+ 역할이 필요하도록 변경되었으며, 이 역할 변경은 group_level_protected_environment_settings_permission이라는 플래그와 함께 도입되었습니다. 기본적으로 활성화됨.
  • GitLab 15.4에서 기능 플래그가 제거됨.

그룹 수준 보호된 환경의 효과를 극대화하려면 그룹 수준 멤버십이 올바르게 구성되어야 합니다:

  • 운영자는 최상위 그룹에서 Owner 역할을 부여받아야 합니다. 그들은 그룹 수준 보호된 환경, 그룹 수준 러너, 그룹 수준 클러스터를 포함하여 그룹 수준 설정 페이지에서 상위 환경(예: 프로덕션)에 대한 CI/CD 구성을 유지 관리할 수 있습니다. 이러한 구성은 읽기 전용 항목으로 하위 프로젝트에 상속됩니다. 이를 통해 운영자만 조직 전체 배포 규칙 세트를 구성할 수 있습니다.
  • 개발자는 최상위 그룹에서 Developer 역할 이하로만 부여받거나, 하위 프로젝트에서 명시적으로 Owner 역할을 부여받아야 합니다. 그들은 최상위 그룹의 CI/CD 구성에 액세스할 수 없으므로, 운영자는 중요한 구성이 개발자에 의해 실수로 변경되지 않도록 보장할 수 있습니다.
  • 하위 그룹 및 하위 프로젝트의 경우:
    • 하위 그룹의 경우, 상위 그룹이 그룹 수준 보호된 환경을 구성한 경우 하위 그룹은 이를 재정의할 수 없습니다.
    • 프로젝트 수준 보호된 환경은 그룹 수준 설정과 결합될 수 있습니다. 그룹 수준 및 프로젝트 수준 환경 구성이 모두 존재하는 경우, 배포 잡을 실행하려면 사용자가 두 규칙 모두에서 허용되어야 합니다.
    • 최상위 그룹의 프로젝트 또는 하위 그룹에서, 개발자는 하위 환경(예: testing)을 조정하기 위해 안전하게 Maintainer 역할을 부여받을 수 있습니다.

이 구성이 있는 경우:

  • 사용자가 프로젝트에서 배포 잡을 실행하려고 하고 환경에 배포가 허용되면 배포 잡이 진행됩니다.
  • 사용자가 프로젝트에서 배포 잡을 실행하려고 하지만 환경에 배포가 허용되지 않으면 배포 잡이 오류 메시지와 함께 실패합니다.

그룹 아래의 중요한 환경 보호#

그룹 수준 환경을 보호하려면 환경에 .gitlab-ci.yml에서 올바른 deployment_tier가 정의되어 있어야 합니다.

UI 사용#

히스토리
  1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.
  3. 보호된 환경을 확장합니다.
  4. 환경 목록에서 보호할 환경의 배포 티어를 선택합니다.
  5. 배포 허용 목록에서 배포 액세스를 부여할 하위 그룹을 선택합니다.
  6. 보호를 선택합니다.

API 사용#

REST API를 사용하여 그룹 수준 보호된 환경을 구성합니다.

배포 승인#

보호된 환경은 배포 전에 수동 승인을 요구하는 데도 사용할 수 있습니다. 자세한 내용은 배포 승인을 참조하세요.

문제 해결#

Reporter가 다운스트림 파이프라인에서 보호된 환경에 배포하는 트리거 잡을 실행할 수 없음#

보호된 환경에 대한 배포 전용 액세스를 가진 사용자는 trigger 키워드가 있는 잡을 실행할 수 없을 수 있습니다. 이는 잡에 보호된 환경과 연결하기 위한 environment 키워드 정의가 없기 때문에, 잡이 일반 CI/CD 권한 모델을 사용하는 표준 잡으로 인식됩니다.

trigger 키워드로 environment 키워드 지원에 대한 자세한 내용은 이 이슈를 참조하세요.