2.3 KiB
2.3 KiB
sourcehub.nexpa-ai.com 교체 절차
0. 원칙
3.8은 Production Candidate입니다. 실제 운영 Credentials를 넣기 전에는 production_ready=false가 정상입니다.
기존 3.2 사이트를 바로 덮어쓰기 전에 DB/파일 백업과 별도 포트 검증을 먼저 수행합니다.
1. 기존 서버 백업
- 현재 SourceHub 소스 디렉터리 전체 백업
- DB 백업
- 업로드 파일/첨부 파일 백업
- 현재 Nginx/Reverse Proxy 설정 백업
3.8 자체 백업 도구:
python scripts/backup.py --out backups
2. Production 환경파일
.env.production.example → .env.production 복사 후 모든 CHANGE_ME 교체.
필수 Gate:
- PostgreSQL
- MinIO
- ClamAV
- NEXPA Core OIDC
- Secure Session Cookie
- CSRF
- HSTS
- Session/Download Secret
배포 Executor는 초기 전환 시 disabled 유지 권장.
3. DB Migration
alembic upgrade head
4. 신규 버전 별도 기동
docker compose -f docker-compose.production.yml up -d --build
SourceHub 3.8 컨테이너는 127.0.0.1:18000에만 노출합니다.
기존 SourceHub(python3)가 호스트 8000을 사용 중이므로 병렬 기동 시 8000을 재사용하지 않습니다.
Gitea는 deploy/gitea/docker-compose.yml 기준 127.0.0.1:3200(웹), 2222(SSH)입니다.
5. 내부 검증
/health200- 로그인 전
/→ NEXPA Core 로그인 화면만 표시 /static/index.html→ 404- OIDC 로그인
- 7개 Current Baseline 확인
- 파일 업로드 → ClamAV → SHA-256 → R1
- R2 추가 시 R1 유지
- 만료형 다운로드 URL 확인
- 역할별 승인 권한 확인
- Gitea 바인딩 확인
- Production 배포 Gate 확인
6. Nginx 전환
deploy/nginx-sourcehub.conf를 서버 환경에 맞게 적용.
인증서 경로 확인 후 Nginx config test를 수행합니다.
7. 최종 전환
기존 3.2 프로세스를 중단하고 3.8 upstream으로 교체.
8. 전환 후 30분 점검
- 4xx/5xx 로그
- OIDC callback
- MinIO 저장
- ClamAV 응답
- PostgreSQL connection
- 파일 다운로드
- 감사 로그
Rollback
문제 발생 시 Nginx upstream을 기존 서비스로 복귀하고, 필요한 경우:
python scripts/restore.py --db <backup> --storage <storage-backup> --yes-really-restore
PostgreSQL/MinIO 운영환경은 pg_restore 및 MinIO versioning/replication 절차를 우선 사용합니다.