Workspaces

Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, Self-Managed, GitLab Dedicated
  • GitLab 15.11에 도입되었으며, 기본적으로 비활성화된 remote_development_feature_flag이라는 플래그와 함께 도입되었습니다.
  • GitLab 16.0에서 GitLab.com 및 self-managed에서 활성화되었습니다.
  • GitLab 16.7에서 일반적으로 사용 가능해졌습니다. 피쳐 플래그 remote_development_feature_flag이 제거되었습니다.

워크스페이스는 GitLab에서 코드의 가상 보안 영역입니다. 워크스페이스를 사용하여 GitLab 프로젝트의 격리된 개발 환경을 생성하고 관리할 수 있습니다. 이러한 환경은 서로 간섭하지 않도록 하며 서로 다른 프로젝트 간에 분리됩니다.

각 워크스페이스에는 해당 프로젝트의 특정 요구 사항을 충족시키기 위해 사용자 정의할 수 있는 종속성, 라이브러리 및 도구의 고유한 세트가 포함됩니다.

클릭하여 데모를 보려면 GitLab 워크스페이스를 참조하세요.

Workspaces and projects

워크스페이스는 프로젝트에 대해 범위가 지정됩니다. 워크스페이스를 생성할 때 다음을 수행해야 합니다:

  • 워크스페이스를 특정 프로젝트에 할당합니다.
  • Devfile이 포함된 프로젝트를 선택합니다.

워크스페이스는 현재 사용자 권한에 따라 정의된 액세스 수준으로 GitLab API와 상호 작용할 수 있습니다. 실행 중인 워크스페이스는 사용자의 권한이 나중에 취소되더라도 사용자에게 계속해서 액세스할 수 있습니다.

프로젝트에서 워크스페이스 관리

프로젝트에서 워크스페이스를 관리하려면 다음을 수행하세요:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 오른쪽 상단에서 편집을 선택합니다.
  3. 드롭다운 목록에서 여러분의 워크스페이스 아래에서 다음을 수행할 수 있습니다:
    • 기존 워크스페이스를 다시 시작, 중지 또는 종료할 수 있습니다.
    • 새로운 워크스페이스를 생성할 수 있습니다.

경고: 워크스페이스를 종료하면 해당 워크스페이스에 있는 미저장 또는 커밋되지 않은 데이터가 삭제되어 복구할 수 없습니다.

워크스페이스와 관련된 리소스 삭제

워크스페이스를 종료하면 해당 워크스페이스와 관련된 모든 리소스가 삭제됩니다. 실행 중인 워크스페이스에 연결된 프로젝트, 에이전트, 사용자 또는 토큰을 삭제하면:

  • 워크스페이스가 사용자 인터페이스에서 삭제됩니다.
  • Kubernetes 클러스터에서 실행 중인 워크스페이스 리소스는 고아가 되며 자동으로 삭제되지 않습니다.

고아가 된 리소스를 정리하려면 관리자가 Kubernetes에서 워크스페이스를 수동으로 삭제해야 합니다.

Issue 414384에서 이 동작을 변경하기로 제안되었습니다.

에이전트 수준에서 워크스페이스 관리

에이전트와 관련된 모든 워크스페이스를 관리하려면 다음을 수행하세요:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 운영 > Kubernetes 클러스터를 선택합니다.
  3. 원격 개발용으로 구성된 에이전트를 선택합니다.
  4. 워크스페이스 탭을 선택합니다.
  5. 목록에서 기존 워크스페이스를 다시 시작, 중지 또는 종료할 수 있습니다.

경고: 워크스페이스를 종료하면 해당 워크스페이스에 있는 미저장 또는 커밋되지 않은 데이터가 삭제되어 복구할 수 없습니다.

실행 중인 워크스페이스에서 에이전트 식별

여러 에이전트가 포함된 배포에서 실행 중인 워크스페이스에서 에이전트를 식별할 수 있습니다.

실행 중인 워크스페이스에서 연결된 에이전트를 식별하려면 다음 GraphQL 엔드포인트 중 하나를 사용하세요:

Devfile

Devfile은 GitLab 프로젝트의 필요한 도구, 언어, 런타임 및 기타 구성 요소를 지정하여 개발 환경을 정의하는 파일입니다.

워크스페이스에는 devfile 지원이 내장되어 있습니다. 기본 위치는 .devfile.yaml이지만 사용자 정의 위치를 지정할 수 있습니다. devfile은 정의된 사양으로 개발 환경을 자동으로 구성하는 데 사용됩니다.

이렇게 하면 기계나 플랫폼에 관계없이 일관되고 재현 가능한 개발 환경을 생성할 수 있습니다.

유효성 검증 규칙

  • schemaVersion은 2.2.0이어야 합니다.
  • devfile은 적어도 하나의 구성 요소를 가져야 합니다.
  • components에 대해:
    • 이름은 gl-로 시작해서는 안 됩니다.
    • container 및 volume만 지원됩니다.
  • commands에 대해 ID는 gl-로 시작해서는 안 됩니다.
  • events에 대해:
    • 이름은 gl-로 시작해서는 안 됩니다.
    • preStart만 지원됩니다.
  • parent, projects, starterProjects는 지원되지 않습니다.
  • variables에 대해 키는 gl-, gl_, GL-, 또는 GL_로 시작해서는 안 됩니다.

container 구성 요소 유형

container 구성 요소 유형을 사용하여 워크스페이스의 실행 환경으로 컨테이너 이미지를 정의할 수 있습니다. 기본 이미지, 종속성 및 기타 설정을 지정할 수 있습니다.

container 구성 요소 유형은 다음 스키마 속성만 지원합니다:

속성 설명
image 워크스페이스에 사용할 컨테이너 이미지의 이름.
memoryRequest 컨테이너가 사용할 수 있는 최소 메모리 양.
memoryLimit 컨테이너가 사용할 수 있는 최대 메모리 양.
cpuRequest 컨테이너가 사용할 수 있는 최소 CPU 양.
cpuLimit 컨테이너가 사용할 수 있는 최대 CPU 양.
env 컨테이너에서 사용할 환경 변수. 이름은 gl-로 시작해서는 안 됩니다.
endpoints 컨테이너에서 노출할 포트 매핑. 이름은 gl-로 시작해서는 안 됩니다.
volumeMounts 컨테이너에 장착할 스토리지 볼륨.

구성 예시

다음은 예시 devfile 구성입니다. 

schemaVersion: 2.2.0
variables:
  registry-root: registry.gitlab.com
components:
  - name: tooling-container
    attributes:
      gl/inject-editor: true
    container:
      image: "{{registry-root}}/gitlab-org/remote-development/gitlab-remote-development-docs/ubuntu:22.04"
      env:
        - name: KEY
          value: VALUE
      endpoints:
        - name: http-3000
          targetPort: 3000

자세한 내용은 devfile documentation를 참조하세요. 다른 예시는 examples projects를 참조하세요.

이 컨테이너 이미지는 데모 용도로만 사용됩니다. 사용자 고유의 컨테이너 이미지를 사용하려면 임의의 사용자 ID를 참조하세요.

작업 영역 컨테이너 요구 사항

기본적으로 작업 영역은 devfile의 gl/inject-editor 속성이 지정된 컨테이너에 GitLab VS Code fork를 주입하고 시작합니다. GitLab VS Code fork가 주입된 작업 영역 컨테이너는 다음 시스템 요구 사항을 충족해아합니다.

  • 시스템 아키텍처: AMD64
  • 시스템 라이브러리:
    • glibc 2.28 이상
    • glibcxx 3.4.25 이상

이 요구 사항은 Debian 10.13 및 Ubuntu 20.04에서 테스트되었습니다. 자세한 내용은 VS Code documentation를 참조하세요.

작업 영역 추가 기능

GitLab Workflow 확장 프로그램은 기본적으로 작업 영역에 구성됩니다.

이 확장 프로그램을 사용하여 이슈를 보거나 병합 요청을 생성하고 CI/CD 파이프라인을 관리할 수 있습니다. 또한, 이 확장 프로그램은 GitLab Duo Code Suggestions 및 GitLab Duo Chat과 같은 AI 기능을 제공합니다.

자세한 내용은 GitLab Workflow extension for VS Code를 참조하세요.

확장 마켓플레이스

Status: Beta
  • GitLab 16.9에서 beta로 introduced되었습니다. 기본적으로 allow_extensions_marketplace_in_workspace라는 플래그로 사용이 비활성화되어 있습니다.
이 기능의 사용 가능성은 피처 플래그에 의해 제어됩니다. 자세한 내용은 히스토리를 참조하세요.

allow_extensions_marketplace_in_workspace가 활성화되면 작업 영역에서 확장 마켓플레이스를 사용할 수 있습니다. 관리자는 최상위 그룹에서만 플래그를 활성화 또는 비활성화할 수 있습니다.

확장 마켓플레이스는 Open VSX Registry에 연결됩니다.

개인 액세스 토큰

작업 영역을 생성할 때, write_repository 및 api 권한이 있는 개인 액세스 토큰이 제공됩니다. 이 토큰은 작업 영역을 시작하는 동안 프로젝트를 초기 클론하고, GitLab Workflow 확장 프로그램을 구성하는 데 사용됩니다.

작업 영역에서 수행하는 모든 Git 작업은 이 토큰을 사용하여 인증 및 권한 부여를 받습니다. 작업 영역을 종료하면 토큰이 철회됩니다.

GIT_CONFIG_COUNT, GIT_CONFIG_KEY_n, 그리고 GIT_CONFIG_VALUE_n과 같은 환경 변수는 작업 영역에서의 Git 인증에 사용됩니다. 이러한 변수들의 지원은 Git 2.31에서 추가되었으므로, 작업 영역 컨테이너에서 사용하는 Git 버전은 2.31 이상이어야 합니다.

클러스터에서의 Pod 상호 작용

작업 영역은 쿠버네티스 클러스터의 Pod로 실행됩니다. GitLab은 Pod끼리 상호 작용하는 방법에 대한 제한을 부과하지 않습니다.

이 요구 사항 때문에 클러스터 내의 다른 컨테이너와 이 기능을 격리시키고 싶을 수 있습니다.

네트워크 액세스 및 작업 영역 인증

Kubernetes 제어 평면에 대한 네트워크 액세스를 제한하는 것은 클라이언트의 책임입니다. GitLab은 API에 대해 제어권을 갖지 않기 때문에 이제한을 시행할 수 없습니다.

작업 영역 및 해당 작업 영역에 노출된 엔드포인트에 액세스할 수 있는 권한은 작업 영역 생성자에게만 있습니다. 작업 영역 생성자는 OAuth로 사용자 인증 이후에만 작업 영역에 액세스할 수 있습니다.

컴퓨팅 리소스 및 볼륨 스토리지

작업 영역을 중지하면 해당 작업 영역의 컴퓨팅 리소스가 제로로 축소됩니다. 그러나 작업 영역에 할당된 볼륨은 여전히 존재합니다.

할당된 볼륨을 삭제하려면 작업 영역을 종료해야 합니다.

임의의 사용자 ID

임의의 Linux 사용자 ID로 실행될 수 있는 컨테이너 이미지를 제공할 수 있습니다.

GitLab은 컨테이너 이미지의 Linux 사용자 ID를 예측할 수 없습니다. GitLab은 쿠버네티스 클러스터에서 사용되는 컨테이너 런타임이 모든 컨테이너에 대한 기본 Linux 그룹 ID가 0임을 보장해야 합니다.

임의의 사용자 ID를 지원하지 않는 컨테이너 이미지를 사용하고자 하는 경우, 작업 영역에서 파일을 생성하거나 업데이트하는 등의 작업을 할 수 없습니다. 임의의 사용자 ID를 지원하는 컨테이너 이미지를 만들려면 임의의 사용자 ID를 지원하는 사용자 지정 작업 영역 이미지 만들기를 참조하세요.

자세한 내용은 OpenShift documentation를 참조하세요.