Workspaces

Tier: 프리미엄, 얼티밋 Offering: GitLab.com, 자체 관리, GitLab Dedicated
  • GitLab 15.11에서 도입됐으며 기본적으로 비활성화된 remote_development_feature_flag라는 플래그가 있습니다.
  • GitLab 16.0에서 GitLab.com 및 자체 관리에서 활성화됐습니다.
  • GitLab 16.7에서 일반적으로 사용 가능해졌습니다. 기능 플래그 remote_development_feature_flag가 제거됐습니다.

워크스페이스는 GitLab의 코드를 위한 가상 샌드박스 환경입니다. 워크스페이스를 사용하여 GitLab 프로젝트의 격리된 개발 환경을 생성하고 관리할 수 있습니다. 이러한 환경을 통해 다른 프로젝트가 서로 간섭하지 않도록 보장할 수 있습니다.

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

워크스페이스와 프로젝트

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

  • 워크스페이스를 특정 프로젝트에 할당합니다.
  • .devfile.yaml 파일이 있는 프로젝트를 선택합니다.

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

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

프로젝트에서 워크스페이스를 관리하려면:

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

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

워크스페이스와 관련된 데이터 삭제

프로젝트, 에이전트, 사용자 또는 워크스페이스와 관련된 토큰을 삭제하면:

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

고아가 남은 리소스를 정리하려면 관리자가 쿠버네티스에서 워크스페이스를 수동으로 삭제해야 합니다.

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

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

에이전트와 관련된 모든 워크스페이스를 관리하려면:

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

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

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

여러 에이전트가 있는 배포에서 실행 중인 워크스페이스에서 에이전트를 식별하려는 경우:

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

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

Devfile

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

워크스페이스는 devfile을 내장하고 있습니다. GitLab 구성 파일에서 프로젝트에 대한 devfile을 지정할 수 있습니다. 이 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를 참조하십시오.

GitLab VS Code 포크

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

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

이 요구 사항은 Debian 10.13 및 Ubuntu 20.04에서 테스트되었습니다. 더 많은 정보는 VS Code 문서에서 확인하십시오.

개인 액세스 토큰

작업 공간을 생성할 때 write_repository 권한이 있는 개인 액세스 토큰이 제공됩니다. 이 토큰은 작업 공간을 시작하는 동안 프로젝트를 초기에 복제하는 데 사용됩니다.

작업 공간에서 수행하는 모든 Git 작업은 이 토큰을 사용하여 인증과 권한 부여를 받습니다. 작업 공간을 종료하면 토큰이 취소됩니다.

클러스터 내의 Pod 상호작용

작업 공간은 Kubernetes 클러스터의 Pod로 실행됩니다. GitLab은 Pod가 서로 상호작용하는 방식에 대해 제한을 부과하지 않습니다.

이 요구 사항으로 인해 클러스터 내의 다른 컨테이너들로부터 이 기능을 격리하고 싶을 수 있습니다.

네트워크 액세스 및 작업 공간 인증

Kubernetes 제어 플레인에 대한 네트워크 액세스를 제한하는 것은 클라이언트의 책임입니다. GitLab은 API에 대한 제어를 갖고 있지 않기 때문에 이 작업이 필요합니다.

작업 공간 및 해당 작업 공간에서 노출된 엔드포인트에 대한 액세스는 작업 공간 생성자만 할 수 있습니다. 작업 공간 생성자는 OAuth로 사용자를 인증한 후에만 작업 공간에 대한 권한을 얻게 됩니다.

컴퓨팅 리소스 및 볼륨 저장

작업 공간을 중지하면 해당 작업 공간의 컴퓨팅 리소스가 0으로 축소됩니다. 그러나 작업 공간에 대해 확보된 볼륨은 여전히 존재합니다.

확보된 볼륨을 삭제하려면 작업 공간을 종료해야 합니다.

임의의 사용자 ID

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

GitLab은 컨테이너 이미지의 Linux 사용자 ID를 예측하는 것이 불가능합니다. GitLab은 Kubernetes 클러스터에서 사용되는 컨테이너 런타임이 모든 컨테이너에 대해 기본 Linux 그룹 ID를 0으로 보장해야 한다. 또한, 임의의 사용자 ID를 지원하지 않는 컨테이너 이미지가 있는 경우 해당 작업 공간에서 파일을 만들거나 업데이트하거나 삭제할 수 없습니다.

임의 사용자 ID를 지원하는 컨테이너 이미지를 만들려면 임의 사용자 ID를 지원하는 사용자 지정 작업 공간 이미지 생성를 참조하십시오.

더 많은 정보는 OpenShift 문서를 참조하십시오.

관련 주제