워크스페이스를 위한 Kubernetes용 GitLab 에이전트 구성
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
워크스페이스 인프라를 설정할 때, 워크스페이스를 지원하도록 Kubernetes용 GitLab 에이전트를 구성해야 합니다. 튜토리얼: Kubernetes용 GitLab 에이전트 설정의 설정 단계를 완료해야 합니다. 에이전트 구성에 remote_development 모듈이 활성화되어 있어야 하며, 이 모듈의 필수 필드가 올바르게 설정되어 있어야 합니다.
히스토리
- 기능 플래그
remote_development_feature_flag가 GitLab 16.0에서 GitLab.com 및 GitLab Self-Managed에서 활성화됨. - GitLab 16.7에서 일반적으로 사용 가능해짐. 기능 플래그
remote_development_feature_flag가 제거됨.
워크스페이스 인프라를 설정할 때, 워크스페이스를 지원하도록 Kubernetes용 GitLab 에이전트를 구성해야 합니다. 이 가이드는 Kubernetes 클러스터에 GitLab 에이전트가 이미 설치되어 있다고 가정합니다.
필수 요건:
-
튜토리얼: Kubernetes용 GitLab 에이전트 설정의 설정 단계를 완료해야 합니다.
-
에이전트 구성에
remote_development모듈이 활성화되어 있어야 하며, 이 모듈의 필수 필드가 올바르게 설정되어 있어야 합니다.[!note] 활성 워크스페이스가 있는 에이전트에서
remote_development모듈을 비활성화하면 해당 워크스페이스를 사용할 수 없게 됩니다. 자세한 내용은 워크스페이스 설정을 참조하세요. -
에이전트는 워크스페이스를 만드는 목적으로 그룹에서 허용되어야 합니다. 워크스페이스 생성 중에 사용자는 워크스페이스 프로젝트의 부모 그룹과 연결된 허용된 에이전트를 선택할 수 있습니다.
-
워크스페이스 생성자는 에이전트의 프로젝트에 대한 Developer 권한이 있어야 합니다.
워크스페이스를 만들기 위한 그룹에서 에이전트 권한 부여#
히스토리
- 새 권한 부여 전략이 GitLab 17.2에서 도입됨.
새 권한 부여 전략은 레거시 권한 부여 전략을 대체합니다. 그룹 소유자와 관리자는 그룹에서 워크스페이스를 호스팅하는 클러스터 에이전트를 제어할 수 있습니다.
예를 들어 워크스페이스 프로젝트의 경로가 top-level-group/subgroup-1/subgroup-2/workspace-project인 경우 top-level-group, subgroup-1 또는 subgroup-2 그룹에 구성된 에이전트를 사용할 수 있습니다.
소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
accTitle: 워크스페이스를 위한 에이전트 권한 부여 계층
accDescr: 워크스페이스 프로젝트는 계층의 모든 부모 그룹에서 에이전트에 대한 액세스를 상속합니다.
topGroup[최상위 그룹, 허용된 에이전트 1]
subgroup1[서브그룹 1, 허용된 에이전트 2]
subgroup2[서브그룹 2, 허용된 에이전트 3]
wp(워크스페이스 프로젝트, 에이전트 1, 2 & 3 모두 사용 가능)
topGroup --> subgroup1
subgroup1 --> subgroup2
subgroup2 --> wp
class wp active;</code></pre></details></div>
특정 그룹(예: subgroup-1)에 클러스터 에이전트를 허용하면 해당 그룹의 모든 프로젝트에서 워크스페이스를 만드는 데 사용할 수 있습니다.
클러스터 에이전트가 워크스페이스를 호스팅할 수 있는 위치를 결정하므로 허용된 그룹의 범위를 신중하게 고려하세요.
그룹의 워크스페이스에 클러스터 에이전트 허용#
필수 요건:
- 워크스페이스 인프라를 설정해야 합니다.
- 인스턴스에 대한 관리자 액세스 권한이 있거나 그룹에 대한 Owner 권한이 있어야 합니다.
그룹의 워크스페이스에 클러스터 에이전트를 허용하려면:
- 상단 표시줄에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
- 왼쪽 사이드바에서 설정 > 워크스페이스를 선택합니다.
- 그룹 에이전트 섹션에서 모든 에이전트 탭을 선택합니다.
- 사용 가능한 에이전트 목록에서 차단됨 상태의 에이전트를 찾고 허용을 선택합니다.
- 확인 대화 상자에서 에이전트 허용을 선택합니다.
GitLab이 선택한 에이전트의 상태를 허용됨으로 업데이트하고 허용된 에이전트 탭에 에이전트를 표시합니다.
그룹의 워크스페이스에서 허용된 클러스터 에이전트 제거#
필수 요건:
- 워크스페이스 인프라를 설정해야 합니다.
- 인스턴스에 대한 관리자 액세스 권한이 있거나 그룹에 대한 Owner 권한이 있어야 합니다.
그룹에서 허용된 클러스터 에이전트를 제거하려면:
- 상단 표시줄에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
- 왼쪽 사이드바에서 설정 > 워크스페이스를 선택합니다.
- 그룹 에이전트 섹션에서 허용된 에이전트 탭을 선택합니다.
- 허용된 에이전트 목록에서 제거하려는 에이전트를 찾고 차단을 선택합니다.
- 확인 대화 상자에서 에이전트 차단을 선택합니다.
GitLab이 선택한 에이전트의 상태를 차단됨으로 업데이트하고 허용된 에이전트 탭에서 에이전트를 제거합니다.
Note
그룹에서 허용된 클러스터 에이전트를 제거해도 에이전트를 사용하는 실행 중인 워크스페이스가 즉시 중지되지 않습니다. 실행 중인 워크스페이스는 자동으로 종료되거나 수동으로 중지될 때 중지됩니다.
인스턴스의 워크스페이스에 클러스터 에이전트 허용#
히스토리
- GitLab 18.2에서 도입됨.
필수 요건:
- 워크스페이스 인프라를 설정해야 합니다.
- 원격 개발이 활성화된 에이전트가 있어야 합니다.
- 인스턴스에 대한 관리자 액세스 권한이 있어야 합니다.
인스턴스의 워크스페이스에 클러스터 에이전트를 허용하려면:
- 오른쪽 상단 모서리에서 관리자를 선택합니다.
- 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
- 워크스페이스에 사용 가능한 에이전트를 펼칩니다.
- 워크스페이스가 활성화된 에이전트 목록에서 허용할 에이전트를 찾고 가용성 토글을 선택합니다.
인스턴스의 워크스페이스에서 허용된 클러스터 에이전트 제거#
히스토리
- GitLab 18.2에서 도입됨.
필수 요건:
- 인스턴스에 대한 관리자 액세스 권한이 있어야 합니다.
인스턴스에서 허용된 클러스터 에이전트를 제거하려면:
- 오른쪽 상단 모서리에서 관리자를 선택합니다.
- 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
- 워크스페이스에 사용 가능한 에이전트를 펼칩니다.
- 허용된 에이전트 목록에서 제거하려는 에이전트를 찾고 가용성 토글을 해제합니다.
Note
인스턴스에서 허용된 클러스터 에이전트를 제거해도 에이전트를 사용하는 실행 중인 워크스페이스가 즉시 중지되지 않습니다. 실행 중인 워크스페이스는 자동으로 종료되거나 수동으로 중지될 때 중지됩니다.
레거시 에이전트 권한 부여 전략#
GitLab 17.1 이하에서는 그룹에서 에이전트의 가용성이 워크스페이스를 만들기 위한 필수 요건이 아니었습니다.
다음 두 가지 조건이 모두 충족되는 경우 워크스페이스 프로젝트의 최상위 그룹에 있는 에이전트를 사용하여 워크스페이스를 만들 수 있습니다:
- 원격 개발 모듈이 활성화되어 있어야 합니다.
- 최상위 그룹에 대한 Developer, Maintainer 또는 Owner 권한이 있어야 합니다.
예를 들어 워크스페이스 프로젝트의 경로가 top-level-group/subgroup-1/subgroup-2/workspace-project인 경우
top-level-group 및 그 서브그룹에 구성된 에이전트를 사용할 수 있습니다.
원격 개발을 사용하여 사용자 액세스 구성#
user_access 모듈을 구성하여 GitLab 자격 증명으로 연결된 Kubernetes 클러스터에 액세스할 수 있습니다.
이 모듈은 remote_development 모듈과 독립적으로 구성되고 실행됩니다.
동일한 에이전트에서 user_access와 remote_development를 모두 구성할 때는 주의해야 합니다.
remote_development 클러스터는 사용자 자격 증명(예: 개인 액세스 토큰)을 Kubernetes 시크릿으로 관리합니다.
user_access에서 잘못 구성하면 이 개인 데이터가 Kubernetes API를 통해 액세스 가능해질 수 있습니다.
user_access 구성에 대한 자세한 내용은 Kubernetes 액세스 구성을 참조하세요.
관련 주제#
