[Preview] 컨테이너 생성에 역할을 붙여 프리뷰와 빌드를 가른다 [ #332 ] - #356
Merged
Merged
Conversation
#332 1단계. 뒤따르는 격리 작업이 프리뷰만 골라 바꿀 수 있게 하는 준비다. 지금은 프리뷰 2곳과 빌드 4곳이 같은 생성 경로를 구분 없이 쓴다. 그래서 프리뷰 쪽 격리 정책을 손대면 배포 빌드까지 함께 흔들린다 — 바꿀 때마다 배포 파이프라인 전체를 다시 검증해야 한다는 뜻이고, 그래서 아무도 손대지 않게 된다. 역할을 갈라 두면 빌드 경로는 한 줄도 안 바뀌므로 재검증할 것이 없어진다. 기본값을 두지 않았다. 새 호출부가 생기면 무엇인지 고르게 강제한다 — 기본값이 있으면 고르지 않은 것과 고른 것이 구분되지 않고, 잘못 고른 쪽이 조용히 돈다. 역할이 지금 실제로 가르는 것: - 빌드 컨테이너는 포트를 게시하지 않는다. 아무것도 서빙하지 않고 저장소를 받아 산출물만 꺼내고 버린다. getMappedPort 호출부를 전부 확인했더니 프리뷰 경로뿐이라, 지금까지 게시한 포트는 연결하는 쪽 없이 면만 늘리고 있었다 - qeploy.role 라벨이 붙는다. 운영자가 docker ps 에서 둘을 갈라 볼 수 있다 격리 정책(cap-drop·no-new-privileges·메모리·PID 상한)은 역할과 무관하게 그대로다 — 빌드도 사용자 저장소의 코드를 돌린다. 테스트 1680건 통과. 역할별 포트 게시 여부와 라벨을 계약으로 고정했다. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013y8USoCXTsRTATAhy88M93
This was referenced Sep 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#332 1단계. 이슈가 "이것부터" 라고 지목한 단계이고, 위험을 가장 크게 줄이는 한 걸음이다.
왜
프리뷰 2곳과 빌드 4곳이 같은 생성 경로를 구분 없이 쓴다. 그래서 프리뷰 쪽 격리 정책을 손대면 배포 빌드까지 함께 흔들린다 — 바꿀 때마다 배포 파이프라인 전체를 재검증해야 한다는 뜻이고, 그래서 아무도 손대지 않게 된다.
가르고 나면 뒤따르는 작업(2·3단계: 워크스페이스 소유자를
node로)이 빌드 경로를 한 줄도 건드리지 않는다.PREVIEWPreviewSessionService·ProjectPreviewServiceBUILDNativeBuildService·DockerImageBuildService·WebImageBuildService·FrontendStaticHostingAdapter기본값을 두지 않았다
새 호출부가 생기면 무엇인지 고르게 강제한다. 기본값이 있으면 고르지 않은 것과 고른 것이 구분되지 않고, 잘못 고른 쪽이 조용히 돈다 — 이 저장소에서 반복된 실패 형태다.
역할이 지금 실제로 가르는 것
빌드 컨테이너는 포트를 게시하지 않는다. 아무것도 서빙하지 않고 저장소를 받아 산출물만 꺼내고 버린다.
getMappedPort호출부를 전부 확인했더니 프리뷰 경로뿐이라, 지금까지 게시한 포트는 연결하는 쪽 없이 면만 늘리고 있었다.qeploy.role라벨이 붙어 운영자가docker ps에서 둘을 갈라 볼 수 있다.격리 정책(
cap-drop ALL·no-new-privileges·메모리·PID 상한)은 역할과 무관하게 그대로다 — 빌드도 사용자 저장소의 코드를 돌린다.검증
qeploy.role=build, 프리뷰는 루프백 포트가 있고qeploy.role=preview, 격리 정책은 양쪽 동일다음
2단계(워크스페이스를 처음부터
node소유로) · 3단계(exec 기본 사용자 뒤집기)로 이어집니다. 3단계에서 템플릿 씨딩과 diff 기준 커밋도 root 필요 목록에 들어갑니다 — 이슈 본문 목록에 빠져 있어 그때 채우겠습니다.🤖 Generated with Claude Code
https://claude.ai/code/session_013y8USoCXTsRTATAhy88M93