Files
document-haness/docs/TechLog/tech-log-studio/only-visible-after-deploying/concept/concept-deploying-without-a-registry.md
T
DongHyeonkaandClaude Opus 5 0650d91def docs(TechLog): 설명 뒤에 붙은 평가·예고·되풀이를 걷어낸다
rewriting-technical-prose-naturally 를 서브에이전트 셋으로 나눠 56편에 적용했다.
ai-tells.md 의 첫 절대로 다른 표현으로 바꾸는 대신 문장을 통째로 지웠다.

  설명한 것의 중요성을 다시 평가하는 꼬리   19
  이미 설명한 것을 추상어로 되풀이           19
  독자에게 읽는 법을 지시하거나 오해를 가정   9
  자료가 뒷받침하지 않는 덧붙인 이득          4

문서군 전체의 문형 편중도 풀었다 — 함께 27→7(한 묶음), 그대로 22→12(두 묶음),
하게 된다 1→0. 한 편에서 세 번 반복되던 「같은 병이 ~에서도 났다」와 두 기록에
같은 문장으로 있던 세 쌍을 갈랐다.

계약 제목 「여덟 자리」가 본문의 「여덟 곳」과 어긋나 있었다. 제목이 spatial-metaphor
규칙에도 걸리므로 계약과 기록을 함께 「여덟 곳」으로 맞췄다.

검사 넷 전부 통과한다 — check_prose 56편 error 0 · check_body PASS ·
check_evidence --repo 문제 없음 · verify-tech-log-tree error 0 warn 0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 16:03:16 +09:00

3.1 KiB

kind, slug, title, topic, topicName, project, status, basisVersion, sourceRevision, source
kind slug title topic topicName project status basisVersion sourceRevision source
CONCEPT deploying-without-a-registry 레지스트리 없이 tar 를 import 하는 배포 경로 only-visible-after-deploying 배포해 봐야 드러난 것 TechLog 게시 전 k3s + containerd · hyeonworks.com 단일 배포 단위 · 2026-09 시점 tech-log@2026-09-02
final/document.md#§1.3
final/document.md#§12.2

레지스트리 없이 tar 를 import 하는 배포 경로

이 사이트는 이미지 레지스트리를 쓰지 않는다. 로컬에서 빌드한 이미지를 tar 로 말아 서버에 올리고, 클러스터 안에 일회성 Job 을 띄워 컨테이너 런타임으로 import 한 뒤 이미지 태그를 바꾼다. 이 경로 때문에 빌드 인자와 파일 권한이 배포에서만 드러난다.

관계

  • 배포 인자를 빠뜨려 배포본이 존재하지 않는 주소를 불렀다 이 경로에서 빌드 인자가 어떻게 새는지가 그 기록에 있다.
  • 컨테이너는 healthy 였고 SPA 가 부팅에 필요한 파일 하나만 403 이었다 이미지 안의 권한이 배포에서 드러난 사건이다.
  • 배포 전에 사람이 돌려야 하는 것과 그 함정 이 경로에서 사람이 기억해야 하는 것들이 그 기준에 있다.

본문

레지스트리를 쓰지 않는다

로컬 docker build  →  docker save | gzip  →  scp dh-server:/tmp/deploy.tar.gz
  →  kube-system 의 containerd import Job  →  kubectl set image

공개 Hub 는 소스가 들어간 이미지라 쓸 수 없다. k3s 의 containerd 소켓은 root 전용이라 사용자 셸에서 닿지 않는다. 그래서 클러스터 안에 일회성 Job 을 띄워 tar 를 import 한다.

배포 단위가 하나다

배포 단위는 hyeonworks.com 하나이고 서브도메인을 쓰지 않는다. 공개는 /, API 는 /api 다.

무엇이 이미지 안에서 굳는가

빌드 인자는 이미지에 굳는다. 런타임 환경 변수가 아니므로 배포한 뒤에 바꿀 수 없고, 잘못 넣으면 다시 빌드해서 다시 올려야 한다.

프론트 이미지가 요구하는 인자는 이만큼이다.

APP_PROFILE=production
VITE_ROUTER_BASE_PATH=/
RUNTIME_API_BASE_URL=https://hyeonworks.com/     ← 빠뜨리면 api.example.com
VITE_BUILD_ID / VITE_COMMIT_SHA / RELEASE_ID
CI_RUNNER_IMAGE=node@sha256:…                    ← 반드시 @sha256 다이제스트
SOURCE_DATE_EPOCH

백엔드 이미지는 Dockerfile 이 src/ 아래에 있고 RELEASE_VERSION·BUILD_VERSION·GIT_SHA·SOURCE_URL 을 받는다. 태그는 짧은 SHA 일곱 자이고 배포된 것과 맞춰야 한다.

빌드 산출물에 커밋 해시가 들어간다

백엔드 빌드 산출물 이름에 커밋 해시가 들어간다. 작업 트리가 더러우면 해시가 달라져 stale 산출물 검사가 멈춘다. 커밋한 뒤에 빌드를 돌려야 한다.

이 경로가 늦게 알려 주는 것

컨테이너 안의 파일 권한, nginx 가 서빙하기로 한 파일 목록, 빌드에 굳은 주소는 전부 이 단계 뒤에 드러난다.