워크스페이스를 사용하여 GitLab 프로젝트를 위한 격리된 개발 환경을 만들고 관리할 수 있습니다. 각 워크스페이스에는 자체 의존성, 라이브러리, 도구 집합이 포함되며, 각 프로젝트의 요구 사항에 맞게 커스터마이즈할 수 있습니다.

워크스페이스 인프라 설정#

워크스페이스를 만들기 전에 인프라를 한 번만 설정해야 합니다. 클라우드 제공업체와 관계없이 워크스페이스 인프라를 설정하려면 다음을 수행해야 합니다:

1. Kubernetes용 GitLab 에이전트가 지원하는 Kubernetes 클러스터를 설정합니다. 지원되는 Kubernetes 버전을 참고합니다.
2. Kubernetes 클러스터의 자동 확장이 활성화되어 있는지 확인합니다.
3. Kubernetes 클러스터에서:
   1. 각 워크스페이스에 볼륨이 동적으로 프로비저닝될 수 있도록 기본 스토리지 클래스가 정의되어 있는지 확인합니다.
4. Kubernetes용 GitLab 에이전트 설정 튜토리얼의 모든 단계를 완료합니다.
5. 선택 사항. 워크스페이스에서 컨테이너 빌드 및 실행.
6. 선택 사항. 프라이빗 컨테이너 레지스트리 지원 구성.
7. 선택 사항. 워크스페이스에 대한 sudo 접근 구성.

AWS를 사용하는 경우 GitLab의 OpenTofu 튜토리얼을 활용할 수 있습니다. 자세한 내용은 AWS에서 워크스페이스 인프라 설정 튜토리얼을 참고합니다.

워크스페이스 만들기#

사전 요구 사항:

• 워크스페이스 인프라를 설정해야 합니다.
• 워크스페이스 프로젝트와 에이전트 프로젝트에 대한 Developer, Maintainer, Owner 권한이 있어야 합니다.

워크스페이스가 시작되기까지 몇 분이 걸릴 수 있습니다. 워크스페이스를 열려면 Preview 아래에서 해당 워크스페이스를 선택합니다. 터미널에도 접근할 수 있으며 필요한 의존성을 설치할 수 있습니다.

워크스페이스 시작 진행 상황 모니터링#

워크스페이스를 시작하면 워크스페이스 로그를 확인하여 초기화 작업과 postStart 이벤트의 진행 상황을 모니터링할 수 있습니다. 자세한 내용은 워크스페이스 로그 디렉터리를 참고합니다.

플랫폼 호환성#

워크스페이스의 플랫폼 요구 사항은 개발 환경의 필요에 따라 달라집니다.

기본적인 워크스페이스 기능의 경우, 워크스페이스는 기반 운영 체제와 관계없이 Kubernetes용 GitLab 에이전트를 지원하는 모든 linux/amd64 Kubernetes 클러스터에서 실행됩니다.

플랫폼 요구 사항에 맞는 방법을 선택하려면 워크스페이스에 대한 sudo 접근 구성을 참고합니다.

워크스페이스에서 컨테이너 빌드 및 실행#

개발 환경에서는 런타임 중 의존성을 관리하고 사용하기 위해 컨테이너를 빌드하고 실행해야 하는 경우가 많습니다. 워크스페이스에서 컨테이너를 빌드하고 실행하려면 워크스페이스에 대한 sudo 접근 구성을 참고합니다.

프라이빗 컨테이너 레지스트리 지원 구성#

프라이빗 컨테이너 레지스트리의 이미지를 사용하려면:

1. Kubernetes에서 이미지 풀 시크릿을 만듭니다.
2. 이 시크릿의 name과 namespace를 Kubernetes용 GitLab 에이전트 구성에 추가합니다.

자세한 내용은 image_pull_secrets를 참고합니다.

워크스페이스에 대한 sudo 접근 구성#

개발 환경에서는 런타임 중 의존성을 설치, 구성, 사용하기 위해 sudo 권한이 필요한 경우가 많습니다. 플랫폼 요구 사항에 맞는 방법을 선택합니다:

사전 요구 사항:

• 컨테이너 이미지가 임의 사용자 ID를 지원해야 합니다. sudo 접근이 구성되어 있더라도 devfile에 사용된 컨테이너 이미지는 사용자 ID 0으로 실행할 수 없습니다.

Sysbox 사용#

Sysbox는 컨테이너 격리를 개선하고 컨테이너가 가상 머신과 동일한 워크로드를 실행할 수 있게 하는 컨테이너 런타임입니다.

Sysbox로 sudo 접근을 구성하려면:

1. Kubernetes 클러스터에 Sysbox를 설치합니다.

2. Kubernetes용 GitLab 에이전트를 구성합니다:

   • 기본 런타임 클래스를 설정합니다. default_runtime_class에 Sysbox의 런타임 클래스를 입력합니다. 예를 들면 sysbox-runc 입니다.
   • 권한 상승을 활성화합니다. allow_privilege_escalation을 true로 설정합니다.
   • Sysbox에 필요한 어노테이션을 구성합니다. annotations를 {"io.kubernetes.cri-o.userns-mode": "auto:size=65536"}로 설정합니다.

Kata Containers 사용#

Kata Containers는 경량 가상 머신의 표준 구현입니다. 컨테이너처럼 동작하면서도 가상 머신 수준의 워크로드 격리와 보안을 제공합니다.

Kata Containers로 sudo 접근을 구성하려면:

1. Kubernetes 클러스터에 Kata Containers를 설치합니다.

2. Kubernetes용 GitLab 에이전트를 구성합니다:

   • 기본 런타임 클래스를 설정합니다. default_runtime_class에 Kata Containers의 런타임 클래스를 입력합니다. 예를 들면 kata-qemu 입니다.
   • 권한 상승을 활성화합니다. allow_privilege_escalation을 true로 설정합니다.

사용자 네임스페이스 사용#

사용자 네임스페이스는 컨테이너 사용자를 호스트 사용자로부터 격리합니다.

사용자 네임스페이스로 sudo 접근을 구성하려면:

1. Kubernetes 클러스터에서 사용자 네임스페이스를 구성합니다.

2. Kubernetes용 GitLab 에이전트를 구성합니다:

   • use_kubernetes_user_namespaces를 true로 설정합니다.
   • allow_privilege_escalation을 true로 설정합니다.

SSH로 워크스페이스에 연결#

사전 요구 사항:

• devfile에 지정된 이미지에 SSH 접근을 활성화해야 합니다. 자세한 내용은 워크스페이스 컨테이너 이미지 업데이트를 참고합니다.
• GitLab 워크스페이스 프록시를 가리키는 TCP 로드 밸런서를 구성해야 합니다. 자세한 내용은 DNS 레코드 업데이트를 참고합니다.

SSH 클라이언트로 워크스페이스에 연결하려면:

1. gitlab-workspaces-proxy-ssh 서비스의 외부 IP 주소를 확인합니다:

   kubectl -n gitlab-workspaces get service gitlab-workspaces-proxy-ssh
   

2. 워크스페이스 이름을 확인합니다:

   1. 상단 바에서 Search or go to를 선택합니다.
   2. Your work를 선택합니다.
   3. Workspaces를 선택합니다.
   4. 연결할 워크스페이스의 이름을 복사합니다.

3. 다음 명령을 실행합니다:

   ssh <workspace_name>@<ssh_proxy_IP_address>
   

4. 비밀번호에는 최소 read_api 스코프를 가진 개인 액세스 토큰을 입력합니다.

TCP 로드 밸런서를 통해 gitlab-workspaces-proxy에 연결하면 gitlab-workspaces-proxy가 사용자 이름(워크스페이스 이름)을 확인하고 GitLab과 통신하여 다음을 검증합니다:

• 개인 액세스 토큰
• 워크스페이스에 대한 사용자 접근 권한

워크스페이스 컨테이너 이미지 업데이트#

사용자 지정 워크스페이스 이미지는 두 가지 방법으로 업데이트할 수 있습니다.

워크스페이스 이미지가 워크스페이스 기본 이미지를 기반으로 하는 경우 SSH 지원이 이미 구성되어 있어 바로 사용할 수 있습니다. 이 방식은 이미지에 필요한 워크스페이스 구성이 모두 갖춰지도록 보장합니다. 자세한 내용은 사용자 지정 워크스페이스 이미지 만들기를 참고합니다.

워크스페이스 기본 이미지를 사용하지 않으려면 자체 기본 이미지에서 빌드할 수 있습니다. 이 경우 런타임 이미지에서 SSH 지원을 직접 구성합니다:

1. 런타임 이미지에 sshd를 설치합니다.
2. 비밀번호 없이 컨테이너에 접근할 수 있도록 gitlab-workspaces라는 사용자를 만듭니다.

다음은 SSH 구성 예시입니다:

FROM golang:1.20.5-bullseye

# Install `openssh-server` and other dependencies
RUN apt update \
    && apt upgrade -y \
    && apt install openssh-server sudo curl git wget software-properties-common apt-transport-https --yes \
    && rm -rf /var/lib/apt/lists/*

# Permit empty passwords
RUN sed -i 's/nullok_secure/nullok/' /etc/pam.d/common-auth
RUN echo "PermitEmptyPasswords yes" >> /etc/ssh/sshd_config

# Generate a workspace host key
RUN ssh-keygen -A
RUN chmod 775 /etc/ssh/ssh_host_rsa_key && \
    chmod 775 /etc/ssh/ssh_host_ecdsa_key && \
    chmod 775 /etc/ssh/ssh_host_ed25519_key

# Create a `gitlab-workspaces` user
RUN useradd -l -u 5001 -G sudo -md /home/gitlab-workspaces -s /bin/bash gitlab-workspaces
RUN passwd -d 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

# Allow sign-in access to `/etc/shadow`
RUN chmod 775 /etc/shadow

USER gitlab-workspaces

관련 주제#

• 튜토리얼: Kubernetes용 GitLab 에이전트 설정
• 워크스페이스 설정
• 워크스페이스 문제 해결
• GitLab 원격 개발 워크스페이스 빠른 시작 가이드
• GitLab에서 온디맨드 클라우드 기반 개발 환경을 위한 인프라 설정