템플릿 및 공유 마운트

템플릿

템플릿이 정의하는 것:

사용할 컨테이너 이미지.
사용 가능한 런처 (앱)와 시작 방법.
기본 리소스 제안 (CPU, 메모리).
선택적 템플릿별 환경 변수.

전역 vs. 사용자 소유 템플릿

유형	소유자	볼 수 있는 사람
전역	`root` (관리자)	모든 사용자
사용자 소유	일반 사용자	해당 사용자만

관리자는 /admin/templates에서 전역 템플릿을 관리합니다. 일반 사용자의 Templates 페이지는 My templates를 먼저 열며 Template gallery, My images, My build history 탭도 함께 제공합니다. 기존의 별도 사용자 Images 페이지와 탐색 항목은 제거되었습니다.

Template gallery에는 관리자가 아직 활성화하거나 빌드하지 않은 항목을 포함해 모든 기본 제공 템플릿이 표시됩니다. 준비된 템플릿으로 워크스페이스를 만들거나 Clone & customize를 선택해 비공개 사본을 만들 수 있습니다. Dockerfile 기반 템플릿은 편집 가능한 빌드 컨텍스트를 사용자의 작업 디렉터리에 복사하고, 레지스트리 이미지 기반 템플릿은 기존 이미지 참조를 유지합니다.

My images는 먼저 이미지 이름, 크기, 생성 날짜와 활성 컨테이너의 Not checked 상태를 표시합니다. Manage를 선택하면 활성 컨테이너, 디스크 회수, 공유, 삭제, 추적되지 않는 컨테이너 확인을 불러옵니다. 이 확인 없이도 Make template을 사용할 수 있습니다. 또한 Podman 이미지 목록 확인이 오래 걸리더라도 사용자가 자신의 작업을 먼저 볼 수 있도록 재사용 가능한 전역 프리셋보다 My templates를 먼저 표시합니다.

전역 템플릿 생성 또는 편집

관리자 Templates 페이지: 활성화/비활성화 상태가 있는 템플릿 목록, 새 템플릿 양식

/admin/templates → 새 템플릿을 여세요.
이름, 컨테이너 이미지 참조 (예: docker.io/pytorch/pytorch:2.3.0-cuda12.1-cudnn8-runtime), 리소스 기본값을 입력합니다. 이미지 참조에는 docker.io, ghcr.io, quay.io, nvcr.io처럼 registry host를 명시해야 합니다. python:3.11처럼 registry가 빠진 이름은 호스트의 Podman search-registry 정책에 따라 출처가 달라질 수 있으므로 거부됩니다.
앱 런처를 추가합니다. 일반적인 앱은 재사용 가능한 카탈로그에서 런처 가져오기로 복사하는 것을 권장합니다. 특정 템플릿에만 필요한 앱은 수동 런처 항목을 사용하세요. 앱을 시작하는 명령은 ${HOST_PORT}에 바인딩해야 하며, 보통 ${AUTH_TOKEN} 또는 ${BASE_PATH}를 앱에 전달합니다.
저장합니다. 활성화한 템플릿은 모든 사용자의 워크스페이스 생성 다이얼로그에 즉시 나타납니다.

기본 제공 템플릿은 활성화 또는 비활성화만 해도 이후의 제공 업데이트를 계속 받습니다. 정의를 편집하면 관리자 버전으로 고정됩니다. Reset to shipped defaults는 활성화 상태나 승인한 약관을 바꾸지 않고 기본 정의를 복원합니다. 업그레이드해도 관리자가 의도적으로 비활성화한 기본 템플릿을 켜지 않습니다.

RStudio와 R ML 템플릿 업그레이드

이번 릴리스 후에는 기본 제공 RStudio Server 이미지를 다시 build하세요. 새 이미지는 워크스페이스 게이트웨이를 통해 열리고 RStudio 세션을 워크스페이스의 영속 홈에 유지합니다. 관리자가 이전에 RStudio 런처를 수정했다면 여전히 strip path prefix를 켜야 할 수 있습니다.

R ML JupyterLab 이미지도 다시 build하면 문서에 적힌 기계 학습 패키지와 JupyterLab 및 R의 Python bridge가 함께 쓰는 Python 인터프리터를 받습니다. 기본값은 CPU 우선이므로 필요한 경우에만 GPU를 선택하세요. 이 템플릿에는 torch, keras 같은 R 딥러닝 패키지가 없으며 한 번 설치하는 방법은 README를 따르세요.

기존 템플릿의 이미지를 업데이트하려면 (새 버전을 풀한 후):

관리자 UI에서 템플릿을 엽니다.
이미지 필드를 편집합니다.
저장합니다. 이 템플릿으로 생성된 새 워크스페이스는 새 이미지를 사용하며, 기존에 실행 중인 워크스페이스는 영향을 받지 않습니다.

재사용 가능한 런처 카탈로그

root 관리자는 /admin/launchers에서 재사용 가능한 런처 정의를 관리합니다.

각 카탈로그 런처는 앱 이름, 레이블, 컨테이너 포트, 프로토콜, 명령 템플릿, 준비 상태 경로, probe 명령, 설치 힌트, 선택적 시작 필드, LabPod가 proxy prefix를 제거할지 여부를 정의합니다. 카탈로그 런처를 템플릿으로 가져오면 LabPod는 해당 정의를 템플릿에 복사합니다. 이후 카탈로그를 수정해도 기존 템플릿은 자동으로 바뀌지 않습니다.

JupyterLab, TensorBoard, MLflow, code-server, RStudio, MATLAB, ComfyUI 같은 공통 앱은 카탈로그를 사용하세요. 한 템플릿에만 필요한 앱은 수동 템플릿 포트를 사용하면 됩니다.

복합 워크스페이스 이미지

LabPod에는 JupyterLab, code-server, TensorBoard, MLflow, Aim, 웹 터미널을 하나의 컨테이너에 담는 이미지용 opt-in 복합 템플릿이 포함되어 있습니다.

PyTorch Demo 템플릿이 그런 복합 이미지의 완성형입니다. 공개 ghcr.io/labpod/pytorch-demo 이미지(기본 cpu, GPU 태그 cu121/cu126/cu129)를 pull하므로 아무것도 빌드하지 않고 활성화할 수 있으며, 데모 노트북은 첫 시작 시 시드됩니다.

CUDA Composite Workspace 는 직접 빌드하는 옵션입니다. 사이트에 맞는 복합 이미지를 빌드하거나 pull한 다음, 비활성화된 그 템플릿이 해당 태그를 가리키도록 편집하고 활성화하세요.

내보내기 및 가져오기

사용자는 자신의 템플릿을 번들 (매니페스트 + 이미지 다이제스트 참조가 있는 TAR)로 내보내어 다른 배포본과 공유할 수 있습니다. 관리자도 동일한 방식으로 전역 템플릿을 내보낼 수 있습니다.

템플릿 상세 페이지 → 내보내기. UI에서 가져오기: 템플릿 → 가져오기 → 번들 업로드 또는 번들 URL 입력 → 미리보기 → 확정.

관리자는 CLI로 호스트에 있는 번들을 가져올 수도 있습니다:

Ubuntu / Debian Rocky / RHEL / AlmaLinux / Fedora

sudo labpod admin template import ./template.tar --global
sudo labpod admin template import ./template.tar --owner alice

# Run these as root
labpod admin template import ./template.tar --global
labpod admin template import ./template.tar --owner alice

CLI로 가져온 템플릿은 검토할 수 있도록 비활성화 상태로 생성됩니다. Dockerfile이 포함된 번들은 가져오기 과정에서 이미지 빌드 서비스가 필요하므로 웹 UI에서 가져오세요.

공유 마운트

공유 마운트는 LabPod가 모든 워크스페이스에 바인드 마운트하는 호스트 디렉토리입니다. 일반적으로 대용량 읽기 전용 데이터셋이나 공유 쓰기 가능 디렉토리에 사용합니다.

공유 마운트 생성

/admin/shared-mounts → 새 마운트:

이름: UI에 표시되는 레이블 (예: datasets).
호스트 경로: 마운트할 호스트 디렉토리 (예: /data/datasets).
컨테이너 경로: 워크스페이스 내부에서 표시될 위치 (예: /data).
읽기 전용: 기본으로 체크됨; 쓰기 가능한 공유를 위해서는 체크를 해제하세요.

마운트는 새 워크스페이스에 적용됩니다. 기존에 실행 중인 워크스페이스는 중지하고 재시작할 때까지 영향을 받지 않습니다.

허용 경로 제한

기본적으로 관리자는 모든 호스트 경로를 구성할 수 있습니다. 허용되는 루트를 제한하려면:

# /etc/labpod/labpod.env에서:
LABPOD_SHARED_MOUNT_ROOTS=/data,/datasets

이 설정으로 민감한 시스템 디렉토리를 실수로 마운트하는 일을 막습니다.

내장 `/shared` 마운트

설치 스크립트가 root 소유 디렉토리로 /shared를 생성합니다. LabPod는 사용자마다 /shared/<username>을 자동으로 생성합니다 (다른 사용자가 읽을 수 있음). 덕분에 사용자끼리 데이터를 가볍게 공유할 수 있습니다. 예를 들어 사용자 Alice는 자신의 워크스페이스 안에서 /shared/bob/을 읽을 수 있습니다.

공유 이미지 원본

대형 CUDA 이미지는 각 사용자의 루트리스 이미지 저장소로 복사됩니다. 관리자가 전역 템플릿 이미지를 pull하거나 build하면 LabPod이 root 소유의 원본 사본을 보관하고, 사용자가 Pull을 선택하면 새로 다운로드하지 않고 그 원본에서 개인 사본을 만듭니다. 워크스페이스는 항상 소유자 이미지 저장소에서 실행하며 관리자 저장소를 직접 사용하지 않습니다.

관리자가 Dockerfile 기반 템플릿을 아직 build하지 않았다면 연구자가 관리자에게 준비를 요청해야 합니다. 개인 사본을 비우면 즉시 디스크는 확보되지만 다음 워크스페이스 시작 전에는 해당 사용자가 다시 Pull해야 합니다.

root 관리자는 /admin/images에서도 이미지를 관리할 수 있습니다. 공유 이미지 pull, pull/build 이벤트 확인, 공유 및 사용자별 이미지 저장소 확인, dangling layer prune, 특정 tagged image 삭제, compliance 검사에 사용하는 registry terms allowlist 관리가 가능합니다. /admin/compliance 페이지는 EULA 또는 약관 동의가 필요한 템플릿과 registry를 보여줍니다.

특정 이미지 태그를 shared store 또는 사용자의 rootless store에서 제거해야 할 때는 Storage → Delete images를 사용합니다. 이 작업은 dangling untagged layer만 제거하는 Prune보다 강합니다. LabPod는 active container가 이미지를 사용 중이면 삭제를 막고, 중지된 워크스페이스가 아직 이미지를 참조하면 경고합니다. 삭제 후에는 이미지가 다시 pull되거나 rebuild되기 전까지 해당 워크스페이스가 다음 시작 시 실패할 수 있습니다.