Workspaces

Tier: Premium, Ultimate 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 프로젝트의 격리된 개발 환경을 생성하고 관리할 수 있습니다. 이러한 환경은 서로 간섭하지 않도록 보장합니다.

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

워크스페이스와 프로젝트

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

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

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

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

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

  1. 좌측 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 오른쪽 상단에서 편집을 선택합니다.
  3. 드롭다운 디렉터리에서 귀하의 워크스페이스에서 다음을 수행할 수 있습니다:
    • 기존 워크스페이스를 다시 시작, 중지 또는 종료합니다.
    • 새로운 워크스페이스를 생성합니다.
caution
워크스페이스를 종료하면 해당 워크스페이스에있는 저장되지 않거나 커밋되지 않은 데이터가 삭제되어 복구할 수 없습니다.

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

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

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

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

Issue 414384에서 이 동작을 변경하는 것을 제안하고 있습니다.

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

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

  1. 좌측 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 운영 > 쿠버네티스 클러스터를 선택합니다.
  3. 원격 개발용으로 구성된 에이전트를 선택합니다.
  4. 워크스페이스 탭을 선택합니다.
  5. 디렉터리에서 기존 워크스페이스를 다시 시작, 중지 또는 종료할 수 있습니다.
caution
워크스페이스를 종료하면 해당 워크스페이스에있는 저장되지 않거나 커밋되지 않은 데이터가 삭제되어 복구할 수 없습니다.

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

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

실행 중인 워크스페이스와 관련된 에이전트를 식별하려면 다음 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 documentation을 참조하십시오. 다른 예시는 examples projects를 참조하십시오.

이 컨테이너 이미지는 데모용입니다. 사용자 고유의 컨테이너 이미지를 사용하려면 임의의 사용자 ID를 참조하십시오.

워크스페이스 컨테이너 요구 사항

기본적으로 워크스페이스는 컨테이너에 GitLab VS Code fork를 삽입하고 시작합니다. GitLab VS Code 포크가 삽입된 워크스페이스 컨테이너는 다음 시스템 요구 사항을 충족해야 합니다:

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

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

개인 액세스 토큰

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

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

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

작업 공간은 Kubernetes 클러스터에서 Pod로 실행됩니다. GitLab은 Pod가 서로 상호 작용하는 방식에 대해 어떤 제약도 가하지 않습니다.

이 요구사항 때문에 클러스터 내 다른 컨테이너에서 이 기능을 분리하고 싶을 수 있습니다.

네트워크 액세스 및 작업 공간 권한

Kubernetes 제어 평면으로의 네트워크 액세스를 제한하는 것은 클라이언트의 책임입니다. GitLab은 API에 대한 제어권을 갖고 있지 않기 때문입니다.

작업 공간 및 해당 작업 공간에 노출된 어떠한 엔드포인트에도 작업 공간 생성자만 액세스할 수 있습니다. 작업 공간 생성자는 OAuth로 사용자 인증 후에만 작업 공간에 액세스할 수 있습니다.

컴퓨팅 리소스 및 볼륨 리포지터리

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

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

임의의 사용자 ID

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

GitLab은 컨테이너 이미지의 Linux 사용자 ID를 예측할 수 없습니다. GitLab은 컨테이너 내의 파일을 생성, 업데이트 또는 삭제하기 위해 Linux 루트 그룹 ID 권한을 사용합니다. Kubernetes 클러스터에서 사용하는 컨테이너 런타임은 모든 컨테이너에 대해 기본 Linux 그룹 ID가 0임을 보장해야 합니다.

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

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

관련 주제