작업 공간

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

작업 공간은 GitLab에서 코드에 대한 가상 샌드박스 환경입니다.

작업 공간을 사용하여 GitLab 프로젝트를 위한 격리된 개발 환경을 생성하고 관리할 수 있습니다.

이러한 환경은 서로 다른 프로젝트가 서로干扰하지 않도록 보장합니다.

각 작업 공간에는 특정 프로젝트의 요구에 맞게 사용자 정의할 수 있는 자체 종속성, 라이브러리 및 도구 세트가 포함되어 있습니다.

클릭 가능한 데모는 GitLab 작업 공간을 참조하세요.

작업 공간 및 프로젝트

작업 공간은 프로젝트에 스코프가 설정됩니다.

작업 공간을 생성할 때, 다음을 수행해야 합니다:

  • 특정 프로젝트에 작업 공간을 할당합니다.
  • devfile가 있는 프로젝트를 선택합니다.

작업 공간은 GitLab API와 상호작용할 수 있으며, 현재 사용자 권한에 의해 정의된 접근 수준을 갖습니다.
실행 중인 작업 공간은 사용자 권한이 나중에 취소되더라도 사용자에게 계속 액세스할 수 있습니다.

프로젝트에서 작업 공간 관리하기

프로젝트에서 작업 공간을 관리하려면:

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

경고:
작업 공간을 종료하면 해당 작업 공간의 모든 저장되지 않거나 커밋되지 않은 데이터가 삭제되며 복구할 수 없습니다.

작업 공간과 관련된 리소스 삭제하기

작업 공간을 종료하면 작업 공간과 관련된 모든 리소스가 삭제됩니다.
실행 중인 작업 공간과 관련된 프로젝트, 에이전트, 사용자 또는 토큰을 삭제하면:

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

고아 리소스를 정리하려면 관리자가 Kubernetes에서 작업 공간을 수동으로 삭제해야 합니다.

이슈 414384는 이 동작을 변경할 것을 제안합니다.

에이전트 수준에서 작업 공간 관리하기

에이전트와 관련된 모든 작업 공간을 관리하려면:

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

경고:
작업 공간을 종료하면 해당 작업 공간의 모든 저장되지 않거나 커밋되지 않은 데이터가 삭제되며 복구할 수 없습니다.

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

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

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

  • agent-id를 사용하여 에이전트가 속한 프로젝트를 반환합니다.
  • Query.workspaces를 사용하여 다음을 반환합니다:

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 문서를 참조하세요.

다른 예제는 examples 프로젝트를 참조하세요.

이 컨테이너 이미지는 데모 목적으로만 사용됩니다.

자신의 컨테이너 이미지를 사용하려면 임의 사용자 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 문서를 참조하세요.

워크스페이스 추가 기능

워크스페이스에서는 기본적으로 VS Code용 GitLab Workflow 확장이 구성되어 있습니다.

이 확장을 사용하면 문제를 보고하고, 병합 요청을 생성하며, CI/CD 파이프라인을 관리할 수 있습니다.

이 확장은 또한 GitLab Duo Code Suggestions 및 GitLab Duo Chat와 같은 AI 기능을 지원합니다.

자세한 내용은 VS Code용 GitLab Workflow 확장을 참조하세요.

확장 마켓플레이스

상태: Beta
  • GitLab 16.9에서 allow_extensions_marketplace_in_workspace라는 플래그와 함께 베타로 도입됨. 기본적으로 비활성화됨.

이 기능의 사용 가능성은 기능 플래그에 의해 제어됩니다.

자세한 내용은 이력을 참조하세요.

allow_extensions_marketplace_in_workspace가 활성화되면, 워크스페이스에서 확장 마켓플레이스를 사용할 수 있습니다.

관리자는 최상위 그룹에 대해 플래그를 활성화하거나 비활성화할 수 있습니다.

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

개인 액세스 토큰

워크스페이스를 생성할 때, write_repository 및 api 권한이 있는 개인 액세스 토큰이 제공됩니다.

이 토큰은 워크스페이스를 시작할 때 프로젝트를 초기 복제하고, VS Code용 GitLab Workflow 확장을 구성하는 데 사용됩니다.

워크스페이스에서 수행하는 모든 Git 작업은 이 토큰을 사용하여 인증 및 인가를 수행합니다.

워크스페이스를 종료하면 토큰이 취소됩니다.

GIT_CONFIG_COUNT, GIT_CONFIG_KEY_n, 및 GIT_CONFIG_VALUE_n
환경 변수는 워크스페이스에서 Git 인증에 사용됩니다.

이 변수에 대한 지원은 Git 2.31에서 추가되었으므로, 워크스페이스 컨테이너에서 사용하는 Git 버전은 2.31 이상이어야 합니다.

클러스터의 포드 상호 작용

워크스페이스는 Kubernetes 클러스터의 포드로 실행됩니다.

GitLab은 포드가 서로 상호 작용하는 방식에 대해 어떤 제한도 두지 않습니다.

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

네트워크 접근 및 작업 공간 권한 부여

클라이언트는 Kubernetes 제어 플레인에 대한 네트워크 접근을 제한할 책임이 있습니다.

왜냐하면 GitLab은 API에 대한 통제를 가지고 있지 않기 때문입니다.

오직 작업 공간 생성자만 해당 작업 공간 및 작업 공간에서 노출된 모든 엔드포인트에 접근할 수 있습니다.

작업 공간 생성자는 OAuth를 통한 사용자 인증 후에만 작업 공간에 접근할 수 있는 권한이 부여됩니다.

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

작업 공간을 중지하면 해당 작업 공간에 대한 컴퓨팅 리소스는 제로로 축소됩니다.

하지만, 작업 공간을 위해 프로비저닝된 볼륨은 여전히 존재합니다.

프로비저닝된 볼륨을 삭제하려면 작업 공간을 종료해야 합니다.

임의 사용자 ID

자신의 컨테이너 이미지를 제공할 수 있으며, 이는 어떤 리눅스 사용자 ID로도 실행될 수 있습니다.

GitLab이 컨테이너 이미지에 대한 리눅스 사용자 ID를 예측하는 것은 불가능합니다.

GitLab은 컨테이너 내에서 파일을 생성, 업데이트 또는 삭제하기 위해 리눅스 루트 그룹 ID 권한을 사용합니다.

Kubernetes 클러스터에서 사용되는 컨테이너 런타임은 모든 컨테이너가 기본 리눅스 그룹 ID가 0이 되도록 해야 합니다.

임의 사용자 ID를 지원하지 않는 컨테이너 이미지가 있는 경우, 작업 공간 내에서 파일을 생성, 업데이트 또는 삭제할 수 없습니다.

임의 사용자 ID를 지원하는 컨테이너 이미지를 만들려면, 임의 사용자 ID를 지원하는 사용자 정의 작업 공간 이미지 만들기를 참조하세요.

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