Skip to content

배포 및 초기화 절차 ​

소스와 플랫폼 설정 ​

  • 공통 애플리케이션 소스와 drizzle/ migration은 모든 플랫폼에서 동일하게 사용합니다.
  • 플랫폼 전용 설정 파일은 두지 않습니다 — 재유입은 server/platformNeutrality.test.ts 가 막습니다.
  • 온프레미스 Docker 실행은 Dockerfile과 docker-compose.onprem.yml을 사용합니다.
  • 두 플랫폼 모두 pnpm build와 pnpm start를 사용하고 healthcheck는 /를 확인합니다.
  • 비밀값은 Git에 저장하지 않고 각 플랫폼의 Variables/Environment에서 관리합니다.

깨끗한 DB에서 처음 설치 ​

  1. 전용 테스트 DB의 연결 URL과 DB 이름을 확인합니다.
  2. DATABASE_URL, PORTAL_CONSOLE_ADMIN_BOOTSTRAP_TOKEN, JWT_SECRET을 설정합니다.
  3. 암호화 기능을 사용할 경우 PORTAL_CONSOLE_ENVELOPE_MASTER_KEY도 설정합니다.
  4. pnpm install --frozen-lockfile을 실행합니다.
  5. pnpm build를 실행합니다.
  6. 서버를 시작하고 / healthcheck가 200인지 확인합니다.
  7. /admin에서 최초 관리자 계정을 생성하고 로그인합니다.

완전 초기화가 필요한 테스트 DB에서만 다음 명령을 사용합니다.

powershell
$env:PORTAL_CONSOLE_RESET_DATABASE_URL = $env:DATABASE_URL
$env:PORTAL_CONSOLE_RESET_DATABASE_NAME = "directory_dev"
pnpm db:reset

이 명령은 대상 DB의 모든 테이블과 Drizzle migration history를 삭제합니다. 이후 pnpm start가 drizzle/meta/_journal.json 순서대로 schema를 한 번만 생성합니다. 운영 DB에는 실행하지 않습니다.

온프레미스 설치 ​

  1. PortalConsole 소스를 고객사 서버에 배포합니다.
  2. .env.onprem.example을 .env로 복사하고 모든 change-this 값을 변경합니다.
  3. MYSQL_PASSWORD, MYSQL_ROOT_PASSWORD, PORTAL_CONSOLE_ADMIN_BOOTSTRAP_TOKEN, JWT_SECRET을 고객사 비밀 저장소에서 주입합니다.
  4. 다음 명령으로 MySQL과 Directory Service를 시작합니다.
powershell
docker compose -f docker-compose.onprem.yml up -d --build
  1. http://localhost:3000/이 200인지 확인하고 /admin에서 최초 관리자 계정을 생성합니다.
  2. 운영 DB에는 pnpm db:reset을 실행하지 않습니다. 재설치 테스트가 필요하면 별도의 DB와 별도의 compose volume을 사용합니다.
  3. 문서 라이브러리는 오브젝트 스토리지가 없으면 로컬 파일시스템(컨테이너 /app/var/doc-library)에 보관됩니다. compose 가 이 경로를 호스트(PORTAL_CONSOLE_DOC_LIBRARY_HOST_PATH, 기본 ./data/doc-library)에 마운트하므로 컨테이너를 다시 만들어도 게시된 문서가 유지됩니다 — 백업 대상에 이 경로를 포함합니다. R2 전환·복구 절차는 DOCUMENT_LIBRARY_STORAGE.md 참고.

반복 테스트 순서 ​

  1. healthcheck 확인
  2. 최초 관리자 생성
  3. 관리자 로그인 및 로그아웃
  4. 서버 재시작 후 로그인 재확인
  5. 같은 bootstrap 요청을 다시 보내 이미 설정된 상태가 안정적으로 거부되는지 확인
  6. 포털 설정, API Key, 암호화 기능을 순서대로 확인
  7. 실패 시 관리형 클라우드/배포 런타임 로그에서 trpc_error, http_error, express_error를 확인

브랜치 운영 ​

  • main: 운영 배포 브랜치
  • develop: 통합 테스트 브랜치
  • 기능 작업은 feature/<name>에서 진행하고 develop을 거쳐 main으로 병합합니다.
  • 관리형 클라우드와 관리형 클라우드 운영 서비스는 main을 바라보게 하고, 테스트 서비스가 필요할 때만 develop을 별도 서비스로 연결합니다.