This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
ongoing @vtak @grzesiek @michelle-chen @adebayo_a devops create 2022-11-15

원격 개발

요약

원격 개발은 GitLab에서 호스팅되는 코드를 작성하는 더 일관된 사용자 경험을 제공하는 새로운 아키텍처로, 향후 순수 브라우저 기반 작업 공간 및 기존에 실행 중인 VM/컨테이너에 연결하거나 GitLab에서 호스팅된 VM/컨테이너를 사용하는 기능을 추가로 제공할 수도 있습니다.

웹 IDE 및 원격 개발

원격 개발 !== 웹 IDE 를 명확하게 구분할 필요가 있습니다. 이 두 가지는 서로 의존하지는 않지만 동일하게 동작할 수 있도록 목표로 함께 사용될 수 있습니다.

웹 IDE를 사용하여 의존성을 설치하거나 리포지터리를 클론하지 않고 웹 브라우저에서 직접 프로젝트에 변경 사항을 커밋할 수 있습니다. 그러나 웹 IDE에는 코드 컴파일, 테스트 실행 또는 IDE에서 실시간 피드백 생성을 위한 네이티브 런타임 환경이 없습니다. 더 전체적인 IDE 경험을 위해 웹 IDE를 적절히 구성하여 실행 중인 원격 개발 공간과 결합할 수 있습니다.

장기 비전

로컬 개발 환경이 없는 Sasha와 같은 새로 온 소프트웨어 개발자로서 다음을 수행할 수 있어야 합니다:

  • GitLab.com 또는 Self-Managed형 리포지터리로 이동합니다.
  • 해당 리포지터리의 현재 작업 공간 디렉터리을 제공하는 버튼을 클릭합니다.
  • 새 작업 공간을 생성하거나 디렉터리에서 기존 작업 공간을 선택할 수 있는 버튼을 클릭합니다.
  • 작업 공간을 위한 다양한 옵션을 선택할 수 있는 구성 마법사를 따릅니다(메모리/CPU).
  • 웹 IDE에서 작업 공간을 시작하고, 1분 이내에 완전히 인터랙티브한 터미널 패널을 사용할 수 있습니다.
  • 코드 변경, 테스트 실행, 터미널 출력에 따라 문제 해결 및 새 변경 사항을 커밋할 수 있습니다.
  • 로컬로 리포지터리를 클론하거나 로컬 개발 환경을 매뉴얼으로 업데이트하지 않고 모든 종류의 MR을 제출할 수 있어야 합니다.

용어

원격 개발 아키텍처의 컴포넌트 및 속성을 나타내는 다음 용어를 사용합니다.

원격 개발

원격 개발은 클라우드에서 안전한 개발 환경을 사용하여 로컬 머신을 통해 웹 브라우저나 클라이언트 기반 솔루션을 통해 소프트웨어 제품을 개발하는 것을 가능하게 합니다.

원격 개발 속성

  • 로컬 머신 구성에 영향을 주지 않고 개발 환경을 분리합니다.
  • 새 기여자가 시작하기 쉽도록 하고 모든 사용자가 일관된 환경에서 작업할 수 있도록 합니다.
  • 사용할 수 없는 도구나 런타임을 사용하거나 그들의 다중 버전을 관리합니다.
  • 여러 기계나 위치에서 기존 개발 환경에 액세스합니다.

비권장 동의어: 웹용 VS Code, 원격 개발 확장, 브라우저 전용 웹IDE, 클라이언트 전용 웹IDE

작업 공간

코드 작성, 빌드, 테스트, 실행 및 디버그하는 데 필요한 모든 도구 및 의존성을 제공하는 컨테이너/VM 기반 개발자 머신입니다.

작업 공간 속성

  • 작업 공간은 기본적으로 서로 분리되어 있어야 하며 컴포넌트의 수명주기를 관리해야 합니다. 이 분리는 다중 계층 구조일 수 있습니다: 네임스페이스 분리, 네트워크 분리, 리소스 분리, 노드 분리, 컨테이너 동산화 등 (참조).
  • 작업 공간은 프로젝트 구성요소 및 편집기 구성요소를 포함해야 합니다.
  • 작업 공간은 클라우드 기반 개발 환경을 지원하는 자원의 조합이어야 합니다.
  • 작업 공간은 제공된 리소스 양에 제약을 받습니다.

웹 IDE

웹용 VS Code - 현재의 레거시 웹 IDE를 대체합니다.

웹 IDE 속성

GitLab 본문의 컨텍스트에 민감한 웹 IDE를 부트스트랩하는 패키지로, 다음과 같은 작업을 웹 IDE에서 수행할 수 있도록 구성할 수 있다:

  • Microsoft의 VS Code 위에 구축되며, VS Code 프로젝트의 GitLab 포크에서 VS Code 기능을 사용자 정의하고 추가합니다.
  • 브라우저만 사용하는 대신 워크스페이스에 연결되도록 구성할 수 있어야 합니다. 워크스페이스에 연결된 경우 사용자는 다음과 같은 기능을 웹 IDE에서 수행해야 합니다:
    • 로컬 머신과 다른 OS에서 편집, 빌드 또는 디버깅을 수행합니다.
    • 로컬 머신보다 크거나 더 특화된 하드웨어를 사용하여 개발합니다.
    • 충돌을 피하고, 보안을 개선하며, 온보딩을 빠르게 하기 위해 개발 환경을 분리합니다.

데스크톱용 원격 개발 확장

데스크톱 IDE에 플러그인되어 작업 공간에 연결하는 기능입니다.

데스크톱용 원격 개발 확장 속성

  • 작업 공간에서 임의의 폴더를 열 수 있어야 합니다.
  • 데스크톱 IDE에 중립적이어야 합니다.
  • 로컬 파일이나 API에 액세스할 수 있어야 합니다.

목표

일관된 경험

조직은 자사의 SaaS 플랫폼에서 로컬 GitLab 인스턴스와 동일한 사용자 경험을 가져야 합니다. 사용자의 개발 환경을 추상화하여 로컬 머신 구성에 영향을 미치지 않도록 해야 합니다. 또한 배포되는 운영 체제에서 개발하거나 크고 특화된 하드웨어를 사용하는 것을 지원해야 합니다.

주요 목표 중 하나는 개발 팀 구성원 개개인이 특화된 로컬 구성을 제외한 동일한 개발 경험을 가져야 합니다. 또한 새로운 기여자가 시작하기 쉽고 모든 사람이 일관된 환경으로 유지되도록 해야 합니다.

가용성 증가

작업 공간은 단일 또는 여러 팀에서 여러 기계 및 위치에서 기존 개발 환경에 액세스할 수 있어야 합니다. 로컬 OS에서 사용할 수 없는 도구나 런타임을 사용하거나 그들의 다중 버전을 관리할 수 있어야 합니다.

또한 원격 개발 작업 공간은 [Cells의 기능을 활용할 수 있다면] (../../../architecture/blueprints/cells/index.md) 재해 복구를 구현하는 방법을 제공할 수 있습니다.

확장성

조직이 확장을 시작할 때, 복잡한 워크플로를 필요로 하는 추가 유형의 프로젝트를 지원해야 하는 필요성을 빨리 깨닫게 됩니다. 원격 개발 작업 공간은 복잡한 머신 구성, 의존성 관리 및 데이터 미리 채우기 문제의 부담을 추상화하여 이러한 문제를 해결하기 위해 목표를 설정합니다.

다른 프로젝트의 서로 다른 기능에 작업하는 것을 용이하게 하기 위해 원격 개발은 각 사용자가 빠른 문맥 전환을 가능케 하도록 여러 작업 공간을 프로비저닝할 수 있어야 합니다.

결국 사용자들은 작업 공간의 컴퓨팅 코어, 메모리 및 기타 리소스를 더 많이 사용하여 작업 공간을 수직으로 확장할 수 있어야 합니다. 사용자가 현재 2 CPU 및 4 GB RAM 작업 공간으로 작업 중이지만 더 많은 CPU가 필요하다고 판단할 경우 작업 공간에서 클릭하거나 CLI 명령으로 컴퓨팅 레이어를 업그레이드할 수 있어야 합니다.

내장된 보안 및 기업용 준비도

원격 개발이 가상 데스크톱 인프라 솔루션을 대체할 수 있게 되면, 안전하고 기업 요건을 지원해야 합니다. 이러한 요건은 역할 기반 액세스 제어 및 모든 소스 코드를 개발자 머신에서 제거할 수 있는 기능을 포함합니다.

프로젝트 및 개발자 온보딩 빠르게하기

브라우저에서 실행되는 설치 필요 없는 개발 환경으로, 원격 개발은 팀에 가입하여 프로젝트에 기여할 수 있도록 누구에게나 쉽게 만듭니다.

지역

GitLab.com은 미국에만 호스팅됩니다. 다른 지역의 기관들은 로컬 SaaS 제공에 대한 수요를 제기했습니다. 사용자의 작업 공간이 서로 다른 지역에 배포될 수 있도록 함으로써 다른 지역에 작업 공간을 배포할 수 있는 능력이 데이터 리포지터리 및 규정 준수 문제를 해결하는 데 도움이 되기도 합니다.

시장 분석

넓은 시선을 갖고 시장 분석을 실시해 다른 사람들이 오픈 소스 라이브러리, 통합 또는 파트너십 기회로 우리에게 무엇을 제공할 수 있는지 이해하려고 했습니다. 가능한 경쟁 업체/경로/파트너십 각각을 조사하는 문제 집합으로 이 작업을 분해했습니다.

Che vs DevWorkspace Operator vs custom-built solution

Che를 백엔드로 사용하여 원격 개발을 가속화하는 것에 대한 조사를 한 후, 우리는 최종적으로 DevWorkspace Operator를 사용하여 자체적으로 비롯한 사용자 정의 솔루션을 작성하기로 결정했습니다.

우리가 자체적으로 사용자 정의 솔루션을 작성하기로 결정한 몇 가지 이점은 다음과 같습니다:

  • 우리는 기본 DevWorkspace Operator를 계속 사용하고 그 위에 더욱 구축할 수 있습니다.
  • 앞으로 devfile 외에도 다른 구성 지원을 쉽게 추가할 수 있습니다.
  • 우리는 사용할 기술 스택을 선택할 수 있습니다 (예를 들어, Che에 사용된 traefik 대신에 NGINX를 탐사하거나 Kubernetes용 GitLab 에이전트를 사용하는 등).

우리가 DevWorkspace Operator를 사용하여 자체적으로 사용자 정의 솔루션을 작성한 후, 우리는 DevWorkspace Operator의 의존성과 이로써 인한 Cert Manager의 수평적인 의존성을 제거하기로 결정했습니다.

아키텍처 세부 정보

원격 개발은 GitLab Kubernetes용 에이전트 프로젝트 내의 모듈로 제공됩니다. 이 아키텍처의 전반적인 목표는 Kubernetes 클러스터에서 실행되는 모든 원격 개발 워크스페이스의 실제 상태가 사용자에 의해 설정된 원하는 상태와 조화롭게 조정되는 것입니다.

이를 위해 다음과 같이 실행됩니다:

  1. 워크스페이스의 원하는 상태는 GitLab UI 또는 API에서 사용자 조작으로부터 얻어지고 Rails 데이터베이스에 영구적으로 저장됩니다.
  2. 에이전트와 Rails 사이에 조화 반복이 있으며, 다음을 수행합니다:
    • 에이전트를 통해 Kubernetes 클러스터에서 워크스페이스의 실제 상태를 검색하고 이를 Rails에 송신하여 영구적으로 저장합니다.
    • Rails는 실제 상태와 원하는 상태를 비교하고, 모든 워크스페이스에 대해 실제 상태를 원하는 상태에 맞게 조정할 수 있도록 조치합니다.

시스템 설계

GitLab Kubernetes용 에이전트를 사용한 원격 개발 구조

  • 이 다이어그램에서 Kubernetes API는 표시되지 않았지만, 에이전트를 통해 워크스페이스가 관리되고 있다고 가정합니다.
  • 각 Kubernetes 클러스터에서의 컴포넌트의 수는 임의로 설정되었습니다.

Rails와 에이전트 간 통신의 고수준 개요

Rails와 에이전트 간의 메시지 유형

에이전트는 다양한 유형의 메시지를 보내어 서로 다른 정보를 캡처할 수 있습니다. 에이전트가 보낸 메시지 유형에 따라 Rails가 적절히 응답합니다.

다양한 메시지 유형은 다음과 같습니다:

  • prerequisites (아직 구현되지 않음) - 에이전트가 시작하거나 다시 시작하거나 리더 선출 이후에 첫 번째 메시지로 레일스에 보내는 메시지입니다.
    • 에이전트가 수행하는 동작:
      • Kubernetes 클러스터에서 사용 가능해야 하는 Kubernetes 리소스를 가져옵니다.
    • 레일스가 수행하는 동작:
      • Kubernetes 클러스터에 있어야 하는 gitlab-workspaces-proxy의 Kubernetes 매니페스트를 전송합니다.
  • reconcile - 레일스에 현재 워크스페이스 상태를 영구적으로 저장하기 위해 보내는 메시지입니다. update_type 필드에는 full과 partial이라는 두 가지 업데이트 유형이 지정되며, 두 업데이트 유형에 대해 페이로드 스키마는 동일합니다.
    • full
      • 에이전트가 수행하는 동작:
        • 에이전트가 관리하는 Kubernetes 클러스터의 모든 워크스페이스의 현재 상태를 전송합니다.
        • 일관성을 유지하기 위해, 에이전트는 다음에서 이 메시지를 보냅니다.
          • 에이전트가 시작하거나 다시 시작한 때
          • 리더 선출 이후
          • 구성에 따라 주기적으로 (full_sync_interval 구성(기본값: 1시간마다 한 번)에 따라)
          • 에이전트 구성이 업데이트될 때
      • 레일스가 수행하는 동작:
        • PostgreSQL을 현재 상태로 업데이트하고, 에이전트가 관리하는 모든 워크스페이스와 레일스가 PostgreSQL에 영구적으로 저장한 마지막 리소스 버전을 응답합니다.
        • 영구적으로 저장한 리소스 버전은 레일스에서 해당 워크스페이스의 업데이트가 성공적으로 처리되었음을 에이전트에게 확인해줍니다.
        • 이 영구적으로 저장한 리소스 버전은 partial 업데이트 유형의 reconcile 메시지에 대해 에이전트에서 레일스로 보내지는 최신 워크스페이스 변경 사항을 보내는 데 도움이 됩니다.
    • partial
      • 에이전트가 수행하는 동작:
        • PostgreSQL에 아직 영구적으로 저장되지 않은 최신 워크스페이스 변경 사항을 레일스로 전송합니다.
        • 이 영구적으로 저장된 리소스 버전은 에이전트에서 레일스로 보내지는 최신 워크스페이스 변경 사항을 도와줍니다.
      • 레일스가 수행하는 동작:
        • PostgreSQL을 현재 상태로 업데이트하고, 에이전트에 응답하여 Kubernetes 클러스터에 생성/업데이트/삭제할 워크스페이스 및 렠일스가 PostgreSQL에 영구적으로 저장한 마지막 리소스 버전을 보냅니다.
        • 생성/업데이트/삭제할 워크스페이스는 원하는 상태 업데이트 시각 >= 에이전트 정보 보고 시각 필터를 사용하여 계산됩니다.
        • 영구적으로 저장한 리소스 버전은 레일스에서 해당 워크스페이스의 업데이트가 성공적으로 처리되었음을 에이전트에게 확인해줍니다.

이벤트 기반 폴링 vs 전체 또는 일부 조정

초기에는 에이전트에게 다음 조정 루프를 기다리지 않고 즉시 폴링하도록 지시하는 것이 바람직하다고 여겨졌습니다. 이로 인해 다음과 같은 이점이 생깁니다:

  1. 필요에 따라 전체 결제를 트리거할 수 있는 기능을 제공하며, 이를 통해 에이전트의 모듈 상태를 필요에 따라 복구/재설정할 수 있습니다.
  2. 아키텍처를 이벤트 기반 및 실시간으로 만드는 것 외에도, 조정 폴링 간격을 증가시킴으로써 인프라 부하를 줄일 수 있습니다.

그러나 잠재적인 해결책을 평가한 결과, 실현 가능한 옵션의 복잡성을 감안할 때 특히 이러한 기능을 정당화하는 경우는 매우 적다는 결론이 나왔습니다. 대부분의 경우에는 최종적으로 상태를 조정하는 것이 대부분 충분하며, 이를 위해서는 주기적으로 수행되는 전체 조정을 통해 간단히 실현할 수 있습니다(일부 조정에 비해 더 긴 간격으로).

자세한 내용은 이슈 및 결론 코멘트에서 확인할 수 있습니다.

워크스페이스 상태

  • CreationRequested - 워크스페이스의 초기 상태; 사용자의 생성 요청이 있지만 아직 처리되지 않은 상태
  • Starting - 사용 준비가 진행 중인 상태
  • Running - 사용 가능한 상태
  • Stopping - 축소가 진행 중인 상태
  • Stopped - 지속적인 리포지터리는 사용 가능하지만 워크스페이스는 축소된 상태
  • Failed - Kubernetes 자원은 agentk에 의해 적용되었지만 다양한 이유(예: 컨테이너 충돌)로 준비되지 않은 상태
  • Error - Kubernetes 자원이 agentk에 의해 적용되지 못함
  • RestartRequested - 사용자가 워크스페이스 재시작을 요청했지만 아직 성공적으로 이루어지지 않은 상태
  • Terminating - 사용자가 워크스페이스를 종료 요청했고, 이 동작은 시작되었지만 아직 완료되지 않은 상태
  • Terminated - 지속적인 리포지터리가 삭제되고 워크스페이스는 축소된 상태
  • Unknown - 워크스페이스의 실제 상태를 이해할 수 없는 상태

가능한 actual_state 값

actual_state 값은 에이전트가 청취하고 Rails로 보내는 Kubernetes 배포 변경의 status 속성에서 결정됩니다.

다음 다이어그램은 actual_state 값이 워크스페이스 레코드의 status 값에 따라 파생되는 흐름을 전형적으로 나타냅니다. status는 서로 다른 조건에 따라 워크스페이스의 actual_state를 파생시키기 위해 구문 분석됩니다.

그러나 어떤 상태라도 에이전트로부터 이유 없는 전이 status 업데이트가 있었을 경우(빠른 전이, 이벤트를 보내지 못한 실패 등) 해당 상태들 중 하나가 건너뛰어질 수 있습니다.

가능한 desired_state 값

desired_state 값은 사용자가 Rails에게 요청하고 Rails가 에이전트로 보내는 값입니다.

desired_state는 ‘Running’, ‘Stopped’, ‘Terminated’, ‘RestartRequested’의 값만을 가지며, actual_state의 하위 집합입니다. Rails의 상태 조정 로직은 워크스페이스가 회복할 수 없는 상태가 아닌 한 계속하여 actual_state를desired_state 값으로 전환시킵니다.

desired_state에는 actual_state의 유효한 값이 아닌 ‘RestartRequested’라는 추가 지원되는 상태가 있습니다. 이 값은 ‘actual_state’로 유효한 값이 아닙니다. 이 값은 Rails가 시작된 워크스페이스를 재시작하기 위해 요구됩니다. 이 값은 ‘Stopped’의 status가 받아지면 자동으로 ‘Running’으로 변경될 것입니다. 이는 워크스페이스가 재시작 요청이 성공적으로 진행 중이거나 완료되었음을 나타냅니다. 워크스페이스를 재시작하는 데 실패한 경우 ‘Stopped’ 상태가 절대로 받아지지 않는다면 ‘desired_state’는 ‘RestartRequested’로 남게되며 새로운 ‘desired_state’가 지정될 때까지 그 상태를 유지합니다.

워크스페이스에 환경 변수 및 파일 주입

CI와 마찬가지로 워크스페이스에 환경 변수와 파일을 주입해야 하는 필요가 있습니다. 이러한 환경 변수와 파일은 매번 시작/재시작할 때 동일한 값이 주입되도록 워크스페이스 생성 시의 값으로 고정될 것입니다. 따라서 ci_job_variables와 유사한 새 데이터베이스 테이블이 필요합니다. 이 테이블에는 다음과 같은 열이 포함됩니다 -

  • key - 환경 변수 또는 파일의 이름을 저장합니다.
  • encrypted_value - 환경 변수 또는 파일의 암호화된 값 저장
  • encrypted_value_iv - 암호화에 사용된 초기화 벡터를 저장
  • workspace_id - 환경 변수 또는 파일이 주입될 워크스페이스를 참조
  • variable_type - 이 데이터가 환경 변수 또는 파일로 주입되어야 하는지 여부를 저장

암호화를 수행하기 위해 GitLab 인스턴스 레벨의 비밀 키가 사용됩니다. 환경 변수 및 파일에 대한 데이터는 Rails 측에서 필요할 때에만 에이전트로 전송됩니다.

  • 사용자로부터 새 워크스페이스 생성 요청이 수신되고 에이전트가 부분 조정 요청을 시작할 때
  • 에이전트가 전체 조정 요청을 시작할 때

자세한 구현 내용에 대한 자세한 내용은 에픽에서 확인할 수 있습니다.

Rails에서 워크스페이스 변수를 복호화하는 데 잠재적인 성능 문제를 고려해야하며, 얼마나 많은 요청 시간이 수신할 수 없게 길어지는지에 대한 벤치마킹을 수행해야 합니다.

예) 100개의 워크스페이스에 대한 조정 요청에 대한 20개의 암호화된 값 == 단일 요청에 2000개의 복호화

벤치마킹에 대한 자세한 내용은 이슈에서 확인할 수 있습니다.

프로젝트에서 워크스페이스를 생성하면 그룹/하위 그룹/프로젝트 계층 구조에서 정의된 Settings > CI/CD > Variables 아래에 있는 변수를 상속받게 됩니다. 이 측면은 CI/CD 및 워크스페이스 모두에서 상속될 Variables을 정의할 수 있도록 일반화될 것입니다. 사용자는 그룹/하위 그룹/프로젝트 사용자 계층에서 생성한 각 워크스페이스로 주입될 환경 변수 및 파일을 정의할 수 있을 것입니다. 워크스페이스를 생성하는 동안 사용자는 그룹/하위 그룹/프로젝트로부터 상속된 환경 변수 또는 파일을 재정의할 수 있을 것입니다.

제안드린 내용과 관련된 자세한 정보는 이슈에서 확인할 수 있습니다.

작업 공간 내에서의 Git 작업

새 작업 공간이 생성되면 해당 작업 공간을 생성한 사용자에 연결된 새 개인 액세스 토큰이 생성됩니다. 이 개인 액세스 토큰은 작업 공간의 수명주기에 묶이며, 작업 공간 내에서 개인 프로젝트를 복제하고 기타 여러 작업을 보다 손쉽게 지원하기 위해 작업 공간에 파일로 삽입됩니다. 사용자 정의 Git 자격 증명 도우미를 사용합니다.

임시 토큰(JWTs/OAuth/OIDC 등)을 사용하는 것에 대한 조사는 각 작업 공간의 개인 액세스 토큰을 JWT 토큰으로 대체하려는 필요성을 드러냈습니다. 해당 기능이 제공되면 각 작업 공간의 개인 액세스 토큰이 JWT 토큰으로 대체될 것입니다.

작업 공간 사용자 트래픽의 인증 및 권한 부여

특정 사용자만 작업 공간에 액세스할 수 있어야 합니다. 현재로서는 작업 공간을 생성한 사용자/소유자로 이를 제한하고 있습니다. 작업 공간이 생성된 후에는 사용자가 연결할 수 있도록 네트워크에 노출되어야 합니다. 따라서 작업 공간으로 들어오는 모든 트래픽에 대해 인증 및 권한 부여되어야 합니다. gitlab-workspaces-proxy는 Kubernetes 클러스터에서 실행 중인 작업 공간의 발견, 인증 및 권한 부여를 처리합니다.

다음과 같은 작업을 수행합니다.

  1. 작업 공간 발견 - 프록시는 Kubernetes 서비스 리소스의 라벨을 기반으로 자동으로 작업 공간을 발견합니다. 프록시는 Kubernetes API를 감시하여 서비스 리소스의 생성/업데이트/삭제를 확인합니다. 서비스 리소스가 생성되면 프록시는 해당 서비스를 상위로 사용하도록 자동으로 구성합니다. 따라서 Kubernetes 서비스 계정과 서비스 리소스를 감시, 디렉터리 및 가져오는 역할을 허용하는 역할이 필요합니다.
  2. 인증 - 사용자 인증을 위해 GitLab과 함께 OAuth 2.0 플로우를 사용합니다. GitLab은 식별 공급자로 작동합니다. 고객이 GitLab에 로그인하기 위해 타사 SSO 서비스를 사용하는 경우, 해당 플로우는 자동으로 해당 제공자로 인증을 위임합니다. 인증의 복잡성 중 하나는 각 작업 공간이 고유의 도메인에서 제공되므로 GitLab 앱의 리디렉션 URI를 특정 작업 공간으로 설정할 수 없다는 사실입니다. 따라서 OAuth 2.0 플로우에서 올바른 작업 공간으로 리디렉션하기 위해 상태를 설정해야 합니다.
  3. 권한 부여 - 프록시는 사용자의 자격 증명을 사용하여 GitLab GraphQL 엔드포인트에 호출합니다. 해당 엔드포인트는 사용자가 작업 공간에 액세스할 수 있는지를 확인하고 그에 따라 404 또는 200을 반환합니다.
  4. 세션 관리 - 프록시는 상태 없이 구성되며 캐시나 데이터베이스와 같은 추가 타사 소프트웨어 없이 배포되며, 따라서 세션을 관리하기 위해 서명된 JWT를 사용합니다. JWT는 프록시가 시작될 때 제공된 키를 사용하여 서명됩니다.

주어진 도메인의 Kubernetes 클러스터로 들어오는 모든 트래픽은 gitlab-workspaces-proxy로 전달되며, 이후 해당 트래픽을 서비스하는 방법을 결정합니다.

워크스페이스에서 웹 IDE에 액세스

현재, 실행 중에 워크스페이스 내에 삽입된 편집기로 GitLab의 VS Code 포크만 지원합니다. 에디터 인젝터는 GitLab의 VS Code 서버를 포함하는 컨테이너 이미지입니다. 에디터 인젝터에는 이 서버를 워크스페이스로 복사하고 서버를 시작하는 스크립트가 포함되어 있습니다.

에디터 인젝터는 WebUI와 익스텐션 호스트(VS Code 백엔드)를 패키징합니다. 현재, 워크스페이스에도 WebUI를 패키징합니다. 이는 GitLab의 VS Code 에디터를 두 가지 방법으로 사용할 수 있음을 의미합니다.

  • 워크스페이스 URL을 직접 액세스하고 번들로 제공된 WebUI를 사용합니다.
  • WebIDE를 통해 워크스페이스에 액세스합니다(번들로 제공된 WebUI는 무시합니다).

워크스페이스용 컨테이너 이미지 빌드

컨테이너 내의 모든 파일을 수정하고 실행할 수 있도록 파일 그룹 권한에 의존합니다. 따라서, 워크스페이스를 생성할 때 임의의 Linux 사용자를 사용하여 컨테이너를 실행합니다. 사용하려는 컨테이너 이미지가 임의의 사용자 ID를 지원하지 않는 경우 아래 스니펫을 사용하여 고유한 이미지를 빌드할 수 있습니다. 이 스니펫은 참고용으로만 제공됩니다. 컨테이너 내에서 루트 Linux 그룹 권한에 의존하는 다른 위치가 있는 경우 해당 파일과 폴더에 원하는 루트 Linux 그룹 권한이 있는지 확인하세요. 

FROM IMAGE_OF_YOUR_CHOICE

RUN useradd -l -u 33333 -G sudo -md /home/gitlab-workspaces -s /bin/bash -p gitlab-workspaces gitlab-workspaces

ENV HOME=/home/gitlab-workspaces

WORKDIR $HOME

RUN mkdir -p /home/gitlab-workspaces && chgrp -R 0 /home && chmod -R g=u /etc/passwd /etc/group /home

USER gitlab-workspaces

이 결정에 대해 자세히 알아보려면 해당 이슈를 확인하세요.

링크