InfoGrab DocsInfoGrab Docs

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

요약

워크스페이스 인프라를 설정할 때는 워크스페이스를 지원하도록 Kubernetes용 GitLab 에이전트를 구성해야 합니다. Kubernetes용 GitLab 에이전트 설정 튜토리얼의 설정 단계를 모두 마쳐야 합니다. 에이전트 구성에서 remote_development 모듈이 활성화돼 있어야 하고, 이 모듈의 필수 필드가 올바르게 설정돼 있어야 합니다.

워크스페이스 인프라를 설정할 때는 워크스페이스를 지원하도록 Kubernetes용 GitLab 에이전트를 구성해야 합니다. 이 가이드는 Kubernetes 클러스터에 GitLab 에이전트가 이미 설치돼 있다고 가정합니다.

필수 조건:

  • Kubernetes용 GitLab 에이전트 설정 튜토리얼의 설정 단계를 모두 마쳐야 합니다.

  • 에이전트 구성에서 remote_development 모듈이 활성화돼 있어야 하고, 이 모듈의 필수 필드가 올바르게 설정돼 있어야 합니다.

    [!note] 활성 워크스페이스가 있는 에이전트에서 remote_development 모듈을 비활성화하면 해당 워크스페이스는 사용할 수 없게 됩니다. 자세한 내용은 워크스페이스 설정을 참고합니다.

  • 워크스페이스를 만들려면 해당 그룹에서 에이전트가 허용돼 있어야 합니다. 워크스페이스를 만들 때 사용자는 워크스페이스 프로젝트의 상위 그룹에 연결된 허용 에이전트를 선택할 수 있습니다.

  • 워크스페이스를 만드는 사용자는 에이전트가 속한 프로젝트에 대해 Developer 권한이 있어야 합니다.

워크스페이스를 만들기 위한 그룹에서 에이전트 권한 부여#

히스토리
  • 새로운 권한 부여 전략이 GitLab 17.2에서 도입되었습니다.

새로운 권한 부여 전략은 레거시 권한 부여 전략을 대체합니다. 그룹 Owner와 관리자는 어떤 클러스터 에이전트가 그룹의 워크스페이스를 호스팅할지 제어할 수 있습니다.

예를 들어 워크스페이스 프로젝트의 경로가 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: Agent authorization hierarchy for workspaces
    accDescr: Workspace projects inherit access to agents from all parent groups in the hierarchy.
topGroup[Top-Level Group, allowed Agent 1]
subgroup1[Subgroup 1, allowed Agent 2]
subgroup2[Subgroup 2, allowed Agent 3]
wp(Workspace Project, Agent 1, 2 & 3 all available)

topGroup --> subgroup1
subgroup1 --> subgroup2
subgroup2 --> wp

class wp active;</code></pre></details></div>

subgroup-1 같은 특정 그룹에 클러스터 에이전트를 허용하면, 그 그룹 아래의 모든 프로젝트에서 워크스페이스를 만드는 데 해당 에이전트를 사용할 수 있습니다. 허용할 그룹의 범위는 클러스터 에이전트가 워크스페이스를 호스팅할 수 있는 위치를 결정하므로 신중하게 정합니다.

그룹의 워크스페이스에 클러스터 에이전트 허용#

필수 조건:

그룹의 워크스페이스에 클러스터 에이전트를 허용하려면 다음과 같이 진행합니다:

  1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Settings > Workspaces를 선택합니다.
  3. Group agents 섹션에서 All agents 탭을 선택합니다.
  4. 사용 가능한 에이전트 목록에서 상태가 Blocked 인 에이전트를 찾아 Allow를 선택합니다.
  5. 확인 대화 상자에서 Allow agent를 선택합니다.

GitLab은 선택한 에이전트의 상태를 Allowed로 갱신하고, 해당 에이전트를 Allowed agents 탭에 표시합니다.

그룹의 워크스페이스에서 허용된 클러스터 에이전트 제거#

필수 조건:

그룹에서 허용된 클러스터 에이전트를 제거하려면 다음과 같이 진행합니다:

  1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Settings > Workspaces를 선택합니다.
  3. Group agents 섹션에서 Allowed agents 탭을 선택합니다.
  4. 허용된 에이전트 목록에서 제거할 에이전트를 찾아 Block을 선택합니다.
  5. 확인 대화 상자에서 Block agent를 선택합니다.

GitLab은 선택한 에이전트의 상태를 Blocked로 갱신하고, 해당 에이전트를 Allowed agents 탭에서 제거합니다.

Note

그룹에서 허용된 클러스터 에이전트를 제거해도 그 에이전트를 사용해 실행 중인 워크스페이스가 즉시 중지되지는 않습니다. 실행 중인 워크스페이스는 자동으로 종료되거나 수동으로 중지될 때 멈춥니다.

인스턴스의 워크스페이스에 클러스터 에이전트 허용#

히스토리
  • GitLab 18.2에서 도입되었습니다.

필수 조건:

인스턴스의 워크스페이스에 클러스터 에이전트를 허용하려면 다음과 같이 진행합니다:

  1. 오른쪽 위에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Available agents for workspaces를 확장합니다.
  4. 워크스페이스가 활성화된 에이전트 목록에서 허용할 에이전트를 찾아 사용 가능 토글을 선택합니다.

인스턴스의 워크스페이스에서 허용된 클러스터 에이전트 제거#

히스토리
  • GitLab 18.2에서 도입되었습니다.

필수 조건:

  • 인스턴스에 대한 관리자 액세스 권한이 있어야 합니다.

인스턴스에서 허용된 클러스터 에이전트를 제거하려면 다음과 같이 진행합니다:

  1. 오른쪽 위에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Available agents for workspaces를 확장합니다.
  4. 허용된 에이전트 목록에서 제거할 에이전트를 찾아 사용 가능 토글을 해제합니다.
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 Secret으로 관리합니다. user_access 구성이 잘못되면 이 비공개 데이터가 Kubernetes API를 통해 노출될 수 있습니다.

user_access 구성에 대한 자세한 내용은 Kubernetes 액세스 구성을 참고합니다.

관련 주제#

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

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

요약

워크스페이스 인프라를 설정할 때는 워크스페이스를 지원하도록 Kubernetes용 GitLab 에이전트를 구성해야 합니다. Kubernetes용 GitLab 에이전트 설정 튜토리얼의 설정 단계를 모두 마쳐야 합니다. 에이전트 구성에서 remote_development 모듈이 활성화돼 있어야 하고, 이 모듈의 필수 필드가 올바르게 설정돼 있어야 합니다.

워크스페이스 인프라를 설정할 때는 워크스페이스를 지원하도록 Kubernetes용 GitLab 에이전트를 구성해야 합니다. 이 가이드는 Kubernetes 클러스터에 GitLab 에이전트가 이미 설치돼 있다고 가정합니다.

필수 조건:

  • Kubernetes용 GitLab 에이전트 설정 튜토리얼의 설정 단계를 모두 마쳐야 합니다.

  • 에이전트 구성에서 remote_development 모듈이 활성화돼 있어야 하고, 이 모듈의 필수 필드가 올바르게 설정돼 있어야 합니다.

    [!note] 활성 워크스페이스가 있는 에이전트에서 remote_development 모듈을 비활성화하면 해당 워크스페이스는 사용할 수 없게 됩니다. 자세한 내용은 워크스페이스 설정을 참고합니다.

  • 워크스페이스를 만들려면 해당 그룹에서 에이전트가 허용돼 있어야 합니다. 워크스페이스를 만들 때 사용자는 워크스페이스 프로젝트의 상위 그룹에 연결된 허용 에이전트를 선택할 수 있습니다.

  • 워크스페이스를 만드는 사용자는 에이전트가 속한 프로젝트에 대해 Developer 권한이 있어야 합니다.

워크스페이스를 만들기 위한 그룹에서 에이전트 권한 부여#

히스토리
  • 새로운 권한 부여 전략이 GitLab 17.2에서 도입되었습니다.

새로운 권한 부여 전략은 레거시 권한 부여 전략을 대체합니다. 그룹 Owner와 관리자는 어떤 클러스터 에이전트가 그룹의 워크스페이스를 호스팅할지 제어할 수 있습니다.

예를 들어 워크스페이스 프로젝트의 경로가 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: Agent authorization hierarchy for workspaces
    accDescr: Workspace projects inherit access to agents from all parent groups in the hierarchy.
topGroup[Top-Level Group, allowed Agent 1]
subgroup1[Subgroup 1, allowed Agent 2]
subgroup2[Subgroup 2, allowed Agent 3]
wp(Workspace Project, Agent 1, 2 &amp; 3 all available)

topGroup --&gt; subgroup1
subgroup1 --&gt; subgroup2
subgroup2 --&gt; wp

class wp active;</code></pre></details></div>

subgroup-1 같은 특정 그룹에 클러스터 에이전트를 허용하면, 그 그룹 아래의 모든 프로젝트에서 워크스페이스를 만드는 데 해당 에이전트를 사용할 수 있습니다. 허용할 그룹의 범위는 클러스터 에이전트가 워크스페이스를 호스팅할 수 있는 위치를 결정하므로 신중하게 정합니다.

그룹의 워크스페이스에 클러스터 에이전트 허용#

필수 조건:

그룹의 워크스페이스에 클러스터 에이전트를 허용하려면 다음과 같이 진행합니다:

  1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Settings > Workspaces를 선택합니다.
  3. Group agents 섹션에서 All agents 탭을 선택합니다.
  4. 사용 가능한 에이전트 목록에서 상태가 Blocked 인 에이전트를 찾아 Allow를 선택합니다.
  5. 확인 대화 상자에서 Allow agent를 선택합니다.

GitLab은 선택한 에이전트의 상태를 Allowed로 갱신하고, 해당 에이전트를 Allowed agents 탭에 표시합니다.

그룹의 워크스페이스에서 허용된 클러스터 에이전트 제거#

필수 조건:

그룹에서 허용된 클러스터 에이전트를 제거하려면 다음과 같이 진행합니다:

  1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
  2. 왼쪽 사이드바에서 Settings > Workspaces를 선택합니다.
  3. Group agents 섹션에서 Allowed agents 탭을 선택합니다.
  4. 허용된 에이전트 목록에서 제거할 에이전트를 찾아 Block을 선택합니다.
  5. 확인 대화 상자에서 Block agent를 선택합니다.

GitLab은 선택한 에이전트의 상태를 Blocked로 갱신하고, 해당 에이전트를 Allowed agents 탭에서 제거합니다.

Note

그룹에서 허용된 클러스터 에이전트를 제거해도 그 에이전트를 사용해 실행 중인 워크스페이스가 즉시 중지되지는 않습니다. 실행 중인 워크스페이스는 자동으로 종료되거나 수동으로 중지될 때 멈춥니다.

인스턴스의 워크스페이스에 클러스터 에이전트 허용#

히스토리
  • GitLab 18.2에서 도입되었습니다.

필수 조건:

인스턴스의 워크스페이스에 클러스터 에이전트를 허용하려면 다음과 같이 진행합니다:

  1. 오른쪽 위에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Available agents for workspaces를 확장합니다.
  4. 워크스페이스가 활성화된 에이전트 목록에서 허용할 에이전트를 찾아 사용 가능 토글을 선택합니다.

인스턴스의 워크스페이스에서 허용된 클러스터 에이전트 제거#

히스토리
  • GitLab 18.2에서 도입되었습니다.

필수 조건:

  • 인스턴스에 대한 관리자 액세스 권한이 있어야 합니다.

인스턴스에서 허용된 클러스터 에이전트를 제거하려면 다음과 같이 진행합니다:

  1. 오른쪽 위에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Available agents for workspaces를 확장합니다.
  4. 허용된 에이전트 목록에서 제거할 에이전트를 찾아 사용 가능 토글을 해제합니다.
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 Secret으로 관리합니다. user_access 구성이 잘못되면 이 비공개 데이터가 Kubernetes API를 통해 노출될 수 있습니다.

user_access 구성에 대한 자세한 내용은 Kubernetes 액세스 구성을 참고합니다.

관련 주제#