워크스페이스 게이트웨이와 리버스 프록시

LabPod은 플랫폼 UI와 API를 워크스페이스 앱에서 의도적으로 분리합니다. 노트북, 확장 기능, 컨테이너 이미지가 제공하는 JavaScript가 브라우저의 LabPod 세션으로 플랫폼 API를 호출하지 못하게 하기 위한 경계입니다.

짝을 이루는 포트

기본 LABPOD_PORT=24680 구성에서는 다음 포트를 사용합니다.

브라우저 origin	포트	제공하는 경로
플랫폼	24680	로그인, LabPod UI, /api/*
워크스페이스 게이트웨이	24681	/ws/<workspace-id>/... 앱 트래픽만

연구자는 https://labpod.example:24680처럼 플랫폼 주소에서 시작합니다. JupyterLab, Code, RStudio 또는 직접 선언한 앱을 열면 LabPod이 브라우저를 워크스페이스 게이트웨이 origin으로 리디렉션합니다. 게이트웨이는 플랫폼 UI, 로그인, API 경로를 거부합니다.

LAN 방화벽이나 VPN에서 두 포트를 모두 허용하세요. 인접 게이트웨이 포트가 막혔거나 다른 프로세스가 사용 중이거나 플랫폼 리스너로 잘못 전달되면 LabPod 대시보드는 열려도 워크스페이스 앱은 열 수 없습니다.

리버스 프록시 규칙

리버스 프록시는 브라우저에서 구분되는 두 origin을 제공해야 합니다. 두 호스트명, 두 외부 포트, 또는 둘 다 사용할 수 있습니다. /api/*와 /ws/*를 하나의 공개 호스트명과 포트 조합으로 전달하면 안 됩니다.

기본 포트 쌍을 브라우저에 그대로 보이게 하는 구성의 예는 다음과 같습니다.

https://labpod.example:24680  ->  http://127.0.0.1:24680  # 플랫폼 UI와 API
https://labpod.example:24681  ->  http://127.0.0.1:24681  # 워크스페이스 게이트웨이만

서로 다른 공개 호스트명을 사용해도 됩니다. 어느 경우든 두 origin에서 WebSocket upgrade를 전달해야 합니다. 원래 Host와 HTTPS scheme 헤더는 그 신뢰할 수 있는 프록시에서 온 경우에만 보존하세요. LabPod 리스너에 클라이언트가 직접 접근하지 못할 때만 LABPOD_TRUST_PROXY_HEADERS=true를 설정합니다.

워크스페이스 호스트명을 플랫폼 포트로 보내거나 플랫폼 호스트명의 /ws/ 경로를 같은 origin으로 되돌리는 catch-all 규칙을 만들면 안 됩니다. 플랫폼은 origin을 분리하기 위해 워크스페이스 경로를 게이트웨이로 리디렉션합니다.

SSH와 LabPod Connect

원격 접근에서는 SSH만 공개하세요. LabPod Connect는 구성한 플랫폼 포트와 인접한 워크스페이스 게이트웨이 포트를 한 쌍으로 포워딩합니다. LabPod Connect를 실행하는 컴퓨터에서는 두 로컬 포트가 모두 비어 있어야 합니다. 직접 HTTP와 HTTPS 연결도 워크스테이션 패널 안에서 같은 두 origin 모델을 사용합니다.

문제 해결

앱 Start가 성공했는데 Open이 실패한다면 다음을 확인하세요.

1. 브라우저나 데스크톱 클라이언트에서 플랫폼과 게이트웨이 포트 모두에 연결할 수 있는지 확인합니다.
2. 프록시가 WebSocket upgrade를 전달하고 두 origin을 유지하는지 확인합니다.
3. 앱 워크스페이스 카드의 Show technical details를 확인합니다. 준비 상태 오류에는 주소와 HTTP 상태가 표시됩니다. 런처 경로 prefix가 잘못된 경우 재시도로 해결되지 않으므로 런처 설정을 수정하거나 템플릿 안내를 따라야 합니다.

로컬 사용자가 인증 게이트웨이를 우회하지 못하게 하는 호스트 루프백 보호는 보안 및 강화에서 설명합니다.