Workspaces

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

작업 공간은 GitLab의 코드를 위한 가상 격리 환경입니다. 작업 공간을 사용하여 GitLab 프로젝트의 격리된 개발 환경을 만들고 관리할 수 있습니다. 이러한 환경은 서로 간섭하지 않도록 보장합니다.

각 작업 공간에는 해당 프로젝트의 특정 요구 사항을 충족하기 위해 사용자 지정할 수 있는 의존성, 라이브러리 및 도구 세트가 포함되어 있습니다.

Workspaces 및 프로젝트

작업 공간은 프로젝트에 제한됩니다. 작업 공간을 생성할 때 다음을 수행해야 합니다:

  • 작업 공간을 특정 프로젝트에 할당합니다.
  • .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 설명서를 참조하십시오. 다른 예시는 examples 프로젝트를 참조하십시오.

이 컨테이너 이미지는 데모 목적으로 제공됩니다. 사용자 고유의 컨테이너 이미지를 사용하려면 임의 사용자 ID를 참조하십시오.

GitLab VS Code fork

기본적으로 워크스페이스는 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을 참조하십시오.

Personal access token

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

워크스페이스에서 수행하는 모든 Git 작업은이 토큰을 사용하여 인증 및 승인을받습니다. 워크스페이스를 종료하면 토큰이 취소됩니다.

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

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

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

네트워크 액세스 및 워크스페이스 승인

Kubernetes 제어 플레인에 대한 네트워크 액세스를 제한하는 것은 클라이언트의 책임입니다. GitLab이 API를 제어하지 않기 때문에 워크스페이스 프로덕션자 만이 워크스페이스 및 해당 워크스페이스에 노출 된 엔드 포인트에 액세스 할 수 있습니다. 워크스페이스 프로덕션자는 OAuth로 사용자를 인증 한 후에 워크스페이스에 액세스 할 수 있습니다.

컴퓨팅 리소스 및 볼륨 저장

워크스페이스를 중지하면 해당 워크스페이스에 대한 컴퓨팅 리소스가 제로로 축소됩니다. 그러나 워크스페이스에 할당 된 볼륨은 여전히 존재합니다.

할당 된 볼륨을 삭제하려면 워크스페이스를 종료해야합니다.

임의 사용자 ID

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

GitLab이 컨테이너 이미지의 Linux 사용자 ID를 예측하는 것은 불가능합니다. GitLab은 Kubernetes 클러스터에서 사용되는 컨테이너 런타임이 모든 컨테이너에 대해 기본 Linux 그룹 ID를 0으로 설정하도록해야합니다. 컨테이너 이미지가 임의의 사용자 ID를 지원하지 않는 경우 워크 스페이스에서 파일을 생성, 업데이트 또는 삭제 할 수 없습니다. 임의의 사용자 ID를 지원하는 컨테이너 이미지를 만들려면 임의 사용자 ID를 지원하는 사용자 정의 워크스페이스 이미지 만들기를 참조하십시오.

자세한 정보는 OpenShift documentation를 참조하십시오.

관련 주제