워크스페이스를 위한 Kubernetes용 GitLab 에이전트 구성

워크스페이스를 지원하도록 Kubernetes용 GitLab 에이전트를 구성합니다.

히스토리 기능 플래그 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 그룹에 구성된 에이전트를 사용할 수 있습니다. Mermaid 다이어그램 (15줄) 소스 코드 보기 %%{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> 특정 그룹(예: subgrou