b24014/BaronSSO
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
BaronSSO/baron-sso/docs/baronsso_work_timeline_report.md

30 KiB
Raw Permalink Blame History

Baron SSO 작업 타임라인 보고서

1. 보고 목적

본 문서는 2026-06-10 기준 Baron SSO 저장소에 대해 진행한 분석 및 로컬 실행 준비 작업의 흐름을 시간 순서대로 정리한 보고서입니다. 사용자의 지시 내용, 확인한 사항, 발생한 문제, 검증 방법, 해결 결과 및 현재 잔여 이슈를 함께 기록합니다.

2. 작업 개요

  • 대상 저장소: Baron SSO
  • 작업 목적:
    • 시스템 구조 분석
    • 문서화
    • 로컬 브라우저 실행 방법 파악
    • 로컬 .env 구성
    • Docker 기반 실행 준비
    • 현재 환경의 미비점 식별

3. 타임라인별 작업 내역

단계 1. 저장소 구조 및 시스템 성격 분석 요청

사용자 지시

  • 코드 파일들을 먼저 분석하고, docs 디렉토리에 Baron SSO 구조 분석 문서를 생성해 달라는 요청
  • 문서 파일명: baronsso_structure_analysis.md
  • 포함 내용:
    • 어떤 시스템인지
    • 아키텍처가 어떻게 되어 있는지
    • 개발 기술 스택 요약

수행한 작업

  • 저장소의 핵심 문서와 설정 파일을 확인함
  • 주요 확인 대상:
    • README.md
    • docker-compose.yaml
    • compose.infra.yaml
    • compose.ory.yaml
    • backend/go.mod
    • adminfront/package.json
    • devfront/package.json
    • orgfront/package.json
    • userfront/pubspec.yaml
    • pnpm-workspace.yaml

확인 결과

  • Baron SSO는 단순 로그인 페이지가 아니라 멀티테넌트 SSO/IAM 운영 플랫폼 성격의 시스템으로 판단됨
  • 핵심 아키텍처는 self-hosted Ory Stack(Kratos, Hydra, Keto, Oathkeeper)을 중심으로 구성됨
  • Baron Backend는 Go + Fiber 기반 비즈니스/운영 API 서버 역할
  • 프론트엔드는 역할별로 분리되어 있음
    • userfront: Flutter 기반 사용자 UI
    • adminfront: React/Vite 기반 관리자 UI
    • devfront: React/Vite 기반 개발자 UI
    • orgfront: React/Vite 기반 조직/시각화 UI
  • 데이터 저장소로 PostgreSQL, ClickHouse, Redis 사용
  • Docker Compose 기반 멀티 서비스 구조임

산출물

  • docs/baronsso_structure_analysis.md 생성 완료

검증

  • 생성된 Markdown 파일에 대해 오류 진단 수행
  • 결과: 오류 없음

해결/결론

  • 시스템 구조 분석 및 문서화 작업 완료

단계 2. 브라우저에서 어떤 주소를 띄워야 하는지 확인 요청

사용자 지시

  • 분석 결과를 바탕으로 브라우저에서 어떤 창을 띄워야 하는지 알려 달라는 요청

수행한 작업

  • 실행 절차와 노출 포트를 확인하기 위해 다음 자료를 검토함
    • Makefile
    • README.md의 실행 절차 섹션
    • 각 frontend의 README/패키지 구성

확인 결과

  • 기본 사용자 화면은 userfront
  • 로컬 브라우저 기본 진입 주소는 http://localhost:5000
  • 추가 접속 대상은 다음과 같음
    • http://localhost:5173: adminfront
    • http://localhost:5174: devfront
    • http://localhost:5175: orgfront
    • http://localhost:3000/health: backend health check

문제점

  • 샘플 환경변수 파일의 일부 URL이 운영/스테이징 도메인 기준이어서 그대로 사용할 경우 로컬 로그인 리다이렉트가 꼬일 가능성이 있었음

확인 방법

  • .env.sample의 URL 관련 항목과 README의 callback 규칙을 대조함

해결/결론

  • 로컬에서는 localhost 기준 URL로 재정의해야 한다는 결론 도출

단계 3. Laragon 하위 배치 필요 여부 및 현재 환경 미비점 점검 요청

사용자 지시

  • Laragon 디렉토리 하위에 위치시켜야 하는지
  • 현재 환경 셋팅에서 부족한 점이 무엇인지 확인해 달라는 요청

수행한 작업

  • 실제 로컬 환경의 도구 설치 상태를 점검함
  • 점검 대상:
    • Docker
    • make
    • bash
    • go
    • flutter
    • node
    • pnpm
    • git
    • .env 존재 여부
    • config/.generated/auth-config.env 존재 여부
    • Docker 엔진 파이프 상태

확인 결과

  • 설치/확인됨:
    • Docker CLI
    • bash
    • node
    • git
  • 미설치 또는 미확인:
    • make
    • go
    • flutter
    • pnpm
  • 당시 기준 .env 없음
  • 당시 기준 config/.generated/auth-config.env 없음
  • 당시 Docker 엔진 연결이 정상 동작하지 않았음

문제점

  • Docker 클라이언트는 있었으나 엔진 연결이 불안정하거나 미기동 상태였음
  • 실행에 필요한 .env와 auth config 생성 파일이 없음
  • 로컬 네이티브 개발 도구 일부가 누락되어 있었음

확인 방법

  • PowerShell에서 각 명령어의 존재 여부와 버전 확인
  • Docker 연결 확인

해결/결론

  • Laragon 하위에 둘 필요는 없고, 본 프로젝트는 이미 Docker Compose 기반으로 구성되어 있으므로 별도 Laragon 환경은 불필요하다고 판단
  • 핵심 미비점은 Laragon이 아니라 Docker 엔진 상태, .env, auth config, 네트워크/레지스트리 접근성이라는 점을 정리

단계 4. 포트포워딩만 하면 되는지, 현재 상태 기준 작업 순서 정리 요청

사용자 지시

  • Docker는 설치돼 있는 것 같고 포트포워딩만 하면 될 것 같은데, 현재 상황을 파악해서 작업 순서를 알려 달라는 요청

수행한 작업

  • 현재 포트 사용 현황과 환경 파일 존재 여부를 재확인함
  • 확인 포트:
    • 3000
    • 5000
    • 5173
    • 5174
    • 5175
    • 5432
    • 6389
    • 8123

확인 결과

  • 대부분 포트는 비어 있었음
  • 5432는 이미 다른 프로세스가 점유 중이었음
  • .env와 config/.generated/auth-config.env는 여전히 없었음

문제점

  • Baron SSO의 PostgreSQL 기본 포트와 기존 로컬 PostgreSQL 또는 다른 서비스 포트가 충돌할 가능성이 있었음
  • 포트포워딩만으로 해결되는 상황이 아니라, 리다이렉트 URL과 auth config 생성이 선행되어야 했음

확인 방법

  • PowerShell의 포트 점유 확인 명령 사용

해결/결론

  • DB_PORT를 5433으로 조정하는 방향을 제안함
  • 실행 전에 .env와 config/.generated/auth-config.env를 반드시 준비해야 한다고 정리함

단계 5. .env.sample 기준으로 로컬 .env 초안 정리 요청

사용자 지시

  • .env.sample을 참조해서 로컬 실행용 .env를 정리해 달라는 요청

수행한 작업

  • .env.sample을 기반으로 운영 도메인을 모두 localhost 기준으로 바꾸는 로컬용 설정 초안을 작성함

핵심 반영 사항

  • USERFRONT_URL=http://localhost:5000
  • OATHKEEPER_PUBLIC_URL=http://localhost:5000
  • HYDRA_PUBLIC_URL=http://localhost:5000/oidc
  • KRATOS_BROWSER_URL=http://localhost:5000/auth
  • KRATOS_UI_URL=http://localhost:5000
  • ADMINFRONT_URL=http://localhost:5173
  • DEVFRONT_URL=http://localhost:5174
  • ORGFRONT_URL=http://localhost:5175
  • DB_PORT=5433

문제점

  • 기존 .env.sample에는 운영 도메인 기준 URL이 들어 있어 로컬 테스트에 그대로 쓰기 부적절했음

확인 방법

  • .env.sample의 URL/콜백 관련 항목을 로컬 실행 목적에 맞게 재해석함

해결/결론

  • 로컬 .env 초안 확정

단계 6. 실제 .env 생성 및 auth config 생성 요청

사용자 지시

  • 위에서 정리한 로컬 .env를 실제로 적용해 바로 진행해 달라는 요청

수행한 작업

  • 저장소 루트에 .env 파일 생성
  • 내용은 localhost 기반, DB_PORT=5433, 로컬 callback 기반으로 구성

산출물

  • 루트 .env 생성 완료

문제점 1

  • scripts/auth_config.sh build 실행 시 WSL 경로 인코딩 문제 발생
  • 경로에 한글/공백이 포함되어 있어 WSL 변환 경로에서 cd가 실패함

확인 방법 1

  • WSL bash 경유 실행
  • Git Bash 경유 실행
  • 경로 문자열 확인

해결 1

  • PowerShell에서 저장소 디렉토리로 먼저 이동한 뒤, 현재 작업 디렉터리를 Git Bash가 그대로 상속받도록 실행 방식 변경
  • 그 결과 경로 이동 문제 없이 스크립트 실행 성공

검증 결과

  • scripts/auth_config.sh build 성공
  • 생성 파일:
    • config/.generated/auth-config.env

추가 확인 내용

  • 스크립트 출력 기준 정상 생성 로그 확인
  • hydra_url_match_mode: mapped_match
  • admin/dev/org callback 인식 확인

해결/결론

  • .env와 auth-config.env 생성 완료

단계 7. Docker 네트워크 준비 및 스택 기동 시도

사용자 지시

  • 로컬 실행을 바로 진행하는 방향으로 계속 작업

수행한 작업

  • Docker Compose에서 요구하는 외부 네트워크를 생성함
  • 생성/확인한 네트워크:
    • baron_net
    • ory-net
    • hydranet
    • kratosnet
    • public_net

이후 수행한 작업

  • 아래 명령과 동일한 방식으로 infra + Ory stack 기동 시도
    • docker compose --env-file .env --env-file config/.generated/auth-config.env -f compose.infra.yaml -f compose.ory.yaml up -d

문제점

  • Docker Hub 레지스트리 이미지 pull 단계에서 실패
  • 핵심 오류:
    • lookup registry-1.docker.io: no such host

확인 방법

  • Docker Compose pull 로그 확인
  • 오류 메시지로 DNS/프록시/레지스트리 접근 문제 판단

해결 상태

  • 아직 완전 해결되지 않음
  • 현재는 Docker Desktop이 외부 레지스트리(registry-1.docker.io)에 접근하지 못하는 상태로 판단됨

현재 판단

  • 문제의 본질은 포트포워딩이 아니라 Docker Desktop 네트워크 또는 사내 프록시/DNS 설정임

단계 8. 사내 프록시 주소 정보가 .env.sample에 있는지 확인 요청

사용자 지시

  • 사내 프록시 주소 정보가 .env.sample 파일에 있는지 확인해 달라는 요청

수행한 작업

  • .env.sample과 저장소 전체에서 다음 키워드를 검색함
    • proxy
    • HTTP_PROXY
    • HTTPS_PROXY
    • NO_PROXY
    • http_proxy
    • https_proxy
    • no_proxy

확인 결과

  • .env.sample에는 사내 HTTP/HTTPS 프록시 주소 관련 변수는 없음
  • .env.sample의 Proxy/Handoff 섹션은 서비스 내부 공개 URL 라우팅 목적이지, 회사망 프록시 설정 목적이 아님

문제점

  • 사용자가 필요로 한 것은 Docker Desktop이 외부 인터넷에 접속하기 위한 프록시 설정이었지만, 저장소 .env에는 해당 정보가 없음

확인 방법

  • .env.sample 직접 검색
  • 전체 저장소 텍스트 검색

해결/결론

  • 사내 프록시 주소는 저장소 내부 파일보다 다음 위치에서 확보해야 한다고 정리함
    • Docker Desktop 설정
    • Windows 환경변수
    • 사내 네트워크 문서 또는 IT 인프라팀 제공 정보

단계 9. 최근 터미널 수동 명령 실행 내역 반영

사용자 수행 명령

  • PowerShell Extension 터미널에서 cd baron-sso 실행

실행 당시 정보

  • 작업 전 현재 디렉터리: C:\Users\user\Desktop\안건 파일\code_test
  • 명령 실행 후 대상 디렉터리: C:\Users\user\Desktop\안건 파일\code_test\baron-sso
  • 종료 코드: 0

확인 결과

  • 사용자가 저장소 루트 디렉터리로 정상 진입한 것으로 확인됨

보고 의미

  • 이후 Docker Compose 명령, .env 확인, 설정 파일 검토 등의 후속 작업을 저장소 루트 기준으로 수행할 수 있는 상태가 되었음을 보여주는 실행 이력임

단계 10. Docker Desktop 재시작 이후 infra + Ory stack 재기동 및 1차 실패 분석

사용자 지시

  • Docker Desktop을 다시 재시작했으니 현재 어디까지 진행됐는지 확인하고, 이어서 바로 진행해 달라는 요청

수행한 작업

  • Docker 엔진 상태 확인
  • docker pull alpine:latest로 외부 레지스트리 접근 재검증
  • infra + Ory stack 재기동 시도
  • 실패 컨테이너 로그와 이미지 단독 실행 결과 확인

확인 결과

  • Docker Desktop 엔진 자체는 정상 동작함
  • docker pull alpine:latest 성공으로 Docker Hub 접근 문제는 해소된 것으로 확인됨
  • 그러나 stack 기동 과정에서 아래 이미지들이 exec format error로 실패함
    • postgres:17-trixie
    • clickhouse/clickhouse-server:latest

문제점

  • 초기에는 DNS/프록시 문제로 추정했으나, 재시작 후에는 이미지 태그 호환성 문제가 실제 실패 원인으로 드러남
  • 특히 Ory Postgres와 ClickHouse가 기동 전에 즉시 종료되어 이후 Ory 서비스 전체가 연쇄적으로 생성 상태에 머무름

확인 방법

  • docker compose ... up -d 로그 확인
  • docker logs ory_postgres
  • docker run --rm postgres:17-trixie postgres --version
  • docker run --rm clickhouse/clickhouse-server:latest clickhouse-server --version

해결

  • 저장소 내 다른 템플릿과 CI 사용 태그를 대조함
  • 로컬 실행용 태그를 다음과 같이 조정함
    • ORY_POSTGRES_TAG=17-alpine
    • CLICKHOUSE_TAG=24.6
  • 관련 반영 파일:
    • .env
    • .env.sample
    • compose.infra.yaml
    • compose.ory.yaml

검증 결과

  • postgres:17-alpine 단독 실행 성공
  • clickhouse/clickhouse-server:24.6 단독 실행 성공
  • 재기동 시 ory_postgres, baron_clickhouse, ory_clickhouse가 정상 기동됨

해결/결론

  • Docker Desktop 재시작 후 네트워크 문제는 해소되었고, 실제 잔여 문제는 일부 이미지 태그 선택 문제였음

단계 11. Oathkeeper 생성물 누락 및 Ory 설정 검증 실패 수정

사용자 지시

  • stack 기동을 계속 진행하여 실제 서비스가 올라오게 해 달라는 요청

수행한 작업

  • ory_oathkeeper 실패 로그 확인
  • config/.generated/ory/oathkeeper 디렉터리 상태 확인
  • Ory 설정 렌더 스크립트 재실행
  • 이후 Kratos/Hydra 실패 로그 추가 분석

확인 결과

  • ory_oathkeeper는 /etc/config/oathkeeper/entrypoint.sh를 찾지 못해 시작 실패
  • 원인은 config/.generated/ory/oathkeeper 디렉터리가 비어 있었기 때문임
  • scripts/render_ory_config.sh 실행 시 Windows CRLF 개행 때문에 .env source 단계에서 오류 발생
  • 이를 우회해 렌더링 후에는 Oathkeeper 생성물이 정상 생성됨
  • 그 다음 단계에서 Kratos/Hydra가 아래 설정 검증 오류로 종료됨
    • Kratos: selfservice.allowed_return_urls 항목 중 []가 배열 값으로 들어감
    • Hydra: SECRETS_SYSTEM 길이가 16자 미만이라 검증 실패

문제점

  • .generated/ory 산출물이 빠져 있으면 compose 설정이 맞아도 Oathkeeper가 시작되지 않음
  • 로컬 .env 값 중 KRATOS_ALLOWED_RETURN_URLS_EXTRA=[]가 의도와 다르게 실제 배열 항목으로 렌더됨
  • Hydra가 DB 비밀번호(orysecret)를 시스템 시크릿으로 재사용하고 있었는데, 길이 정책을 만족하지 못함

확인 방법

  • docker logs ory_oathkeeper
  • docker logs ory_kratos
  • docker logs ory_hydra
  • 렌더된 config/.generated/ory/kratos/kratos.yml 확인

해결

  • LF 개행 임시 파일을 사용해 scripts/render_ory_config.sh를 재실행하여 config/.generated/ory 재생성
  • .env에서 KRATOS_ALLOWED_RETURN_URLS_EXTRA를 빈 값으로 정리
  • .env에 HYDRA_SYSTEM_SECRET 추가
  • compose.ory.yaml에서 Hydra가 SECRETS_SYSTEM=${HYDRA_SYSTEM_SECRET:-${ORY_POSTGRES_PASSWORD}}를 사용하도록 수정
  • .env.sample에도 동일 정책 반영

검증 결과

  • 생성 파일 확인:
    • config/.generated/ory/oathkeeper/entrypoint.sh
    • config/.generated/ory/oathkeeper/oathkeeper.yml
    • config/.generated/ory/oathkeeper/rules*.json
  • 재기동 후 ory_kratos, ory_hydra, ory_keto, ory_oathkeeper, ory_vector 정상 기동
  • ory_stack_check와 baron-sso-init-rp-1이 Exited (0)로 완료됨

추가 확인 내용

  • Hydra RP 초기화 결과로 아래 클라이언트 등록 성공 확인
    • adminfront
    • devfront
    • orgfront
    • oathkeeper-introspect

해결/결론

  • Ory stack 전체가 초기화와 내부 readiness 검증까지 통과함

단계 12. app stack 기동 시 backend DB 포트 오설정 문제 수정

사용자 지시

  • 다음 작업을 계속 진행해 로컬 브라우저 접속까지 가능하게 해 달라는 요청

수행한 작업

  • docker-compose.yaml 기준 app stack 서비스 확인
  • backend, userfront, adminfront, devfront, orgfront 기동 시도
  • 실패한 backend 로그 확인

확인 결과

  • adminfront, devfront, orgfront는 먼저 기동됨
  • backend는 PostgreSQL 연결 단계에서 즉시 종료됨
  • 핵심 오류:
    • dial tcp ... postgres:5433: connect: connection refused

문제점

  • 루트 .env의 DB_PORT=5433은 호스트 포트 충돌 회피용 값인데, backend 컨테이너 내부에서도 그대로 사용되고 있었음
  • 컨테이너 내부 네트워크에서는 postgres:5432로 붙어야 하므로, 호스트 노출 포트와 컨테이너 내부 접속 포트를 분리해야 했음

확인 방법

  • docker logs baron_backend
  • docker-compose.yaml의 backend environment 확인
  • backend 코드에서 DB_PORT 사용 위치 확인

해결

  • docker-compose.yaml의 backend 환경변수에 DB_PORT=5432를 명시적으로 추가하여 컨테이너 내부 접속 포트를 고정함

검증 결과

  • 재기동 후 baron_backend가 healthy 상태로 전환됨
  • 이어서 baron_userfront도 정상 기동됨

해결/결론

  • 호스트 포트 회피용 설정과 컨테이너 내부 서비스 포트를 분리하여 backend 기동 문제 해결

단계 13. 로컬 브라우저 진입 주소 최종 검증

사용자 지시

  • 지금 상태에서 실제 접속 가능한지까지 확인해 달라는 요청

수행한 작업

  • app-facing 컨테이너 상태 확인
  • localhost 주소별 HTTP 응답 확인

확인 결과

  • 정상 기동 확인 서비스
    • baron_backend
    • baron_userfront
    • baron_adminfront
    • baron_devfront
    • baron_orgfront
    • baron_gateway
  • baron_gateway도 최종적으로 healthy 상태 확인
  • HTTP 응답 코드 확인 결과
    • http://localhost:5000 -> 200
    • http://localhost:5173 -> 200
    • http://localhost:5174 -> 200
    • http://localhost:5175 -> 200

실패했던 부분

  • 초기에는 baron_gateway가 baron_userfront could not be resolved 오류로 unhealthy 상태였음
  • 이는 userfront가 아직 뜨지 않았기 때문이며, app stack이 정상 기동된 뒤 해소됨

해결/결론

  • Baron SSO 로컬 실행 스택이 브라우저 접속 가능한 상태까지 도달함

단계 14. Docker Desktop 제거 후 WSL Docker 환경 재점검

사용자 지시

  • 기존 Docker Desktop을 제거하고 WSL에 Docker를 설치했으니 다시 작업을 이어가 달라는 요청

수행한 작업

  • Windows PowerShell과 WSL Ubuntu 양쪽에서 Docker CLI/엔진 상태를 재확인함
  • 기존 Baron SSO 관련 컨테이너, 네트워크, 볼륨 존재 여부를 점검함
  • 저장소 내부 .env, 생성된 auth config, compose 파일은 그대로 유지되는지 확인함

확인 결과

  • Windows PowerShell 기준으로는 docker가 PATH에 없어 직접 실행되지 않았음
  • WSL Ubuntu 내부에는 /usr/bin/docker가 존재했고 Docker 엔진도 정상 응답했음
  • 다만 새 WSL Docker 엔진에는 기존 Baron SSO 컨테이너/네트워크가 남아 있지 않았음
  • 저장소 내부의 .env, config/.generated/auth-config.env, 렌더된 Ory 설정 파일은 유지되고 있었음

문제점

  • 런타임 리소스는 초기화되었지만 저장소 설정 파일은 남아 있어, 환경 자체를 다시 만드는 것이 아니라 WSL 엔진 기준으로 stack만 재기동해야 하는 상태였음

확인 방법

  • PowerShell과 WSL에서 각각 Docker 명령 실행 가능 여부 확인
  • docker ps -a, docker network ls로 기존 리소스 상태 점검

해결/결론

  • 이후 작업은 Windows Docker Desktop 기준이 아니라 WSL Ubuntu 내부 Docker 엔진 기준으로 진행하기로 정리함

단계 15. Debian trixie-slim 기반 이미지 정책 반영

사용자 지시

  • Docker를 Debian trixie (slim) 베이스 이미지 기반으로 맞출 수 있는 부분은 반영해 달라는 요청

수행한 작업

  • 저장소 내 커스텀 이미지 Dockerfile과 helper 서비스 이미지를 검토함
  • 외부 공식 이미지와 저장소 내부에서 직접 빌드하는 이미지를 구분해 수정 범위를 정함
  • backend, gateway, adminfront, devfront, orgfront, userfront 및 일부 helper 컨테이너를 trixie/trixie-slim 기반으로 조정함
  • userfront의 기본 빌드 타깃을 production으로 사용하도록 .env.sample 정책도 맞춤

확인 결과

  • 다음 커스텀 이미지들은 Debian trixie 또는 trixie-slim 기반으로 전환 가능했음
    • backend/Dockerfile
    • gateway/Dockerfile
    • adminfront/Dockerfile
    • devfront/Dockerfile
    • orgfront/Dockerfile
    • userfront/Dockerfile
  • helper 서비스도 다음과 같이 조정함
    • compose.ory.yaml의 oathkeeper_logs_init, ory_stack_check
    • docker-compose.yaml의 infra_check
  • 반면 다음 외부 공식 이미지는 저장소 안에서 베이스 OS를 직접 통제할 수 없었음
    • postgres
    • redis
    • clickhouse/clickhouse-server
    • oryd/*
    • ghcr.io/cirruslabs/flutter

문제점

  • Alpine 전용 패키지 설치 명령과 Nginx 설정 경로를 Debian 계열에 맞게 바꿔야 했음
  • userfront의 기존 Brotli 설정은 Debian 패키지 nginx 기본 구성과 맞지 않았음

확인 방법

  • 관련 Dockerfile 및 compose 설정 검토
  • docker compose config와 실제 이미지 빌드로 변경 타당성 확인

해결

  • Alpine 기반 apk 사용 구문을 apt-get 기반으로 변경
  • Debian nginx 경로에 맞게 userfront 설정 파일 복사 위치를 /etc/nginx/conf.d/default.conf로 조정
  • userfront/nginx.conf에서 Debian 기본 nginx와 맞지 않는 Brotli 설정 제거
  • healthcheck에 필요한 도구를 포함할 수 있도록 Debian 패키지 설치 구성 정리

검증 결과

  • WSL Docker 기준으로 커스텀 이미지 빌드 성공 확인
  • 주요 빌드 대상:
    • baron-sso-backend
    • baron-sso-gateway
    • baron-sso-adminfront
    • baron-sso-devfront
    • baron-sso-orgfront
    • baron-sso-userfront

해결/결론

  • 저장소 내부에서 제어 가능한 범위에 대해서는 Debian trixie-slim 정책을 반영했고, 외부 공식 이미지는 예외로 유지함

단계 16. WSL Docker 기준 전체 stack 복구 및 최종 정상화

사용자 지시

  • trixie-slim 반영 이후 실제 기동까지 계속 진행해 달라는 요청

수행한 작업

  • WSL Docker 엔진에 Baron SSO 외부 네트워크를 재생성함
  • infra + Ory stack, app stack을 WSL 기준으로 다시 기동함
  • 기동 중 실패 컨테이너 로그와 health 상태를 점검하고 문제를 국소 수정함

확인 결과

  • 초기 재기동 시 ory_clickhouse가 시작 직후 종료됨
  • baron_userfront, baron_gateway는 실제 응답은 가능했지만 healthcheck가 unhealthy 상태였음
  • 원인 분석 결과:
    • docker/ory/clickhouse/init.sql의 TTL 식이 ClickHouse 24.6에서 DateTime64(3)와 호환되지 않았음
    • Debian 기반으로 바뀐 gateway, userfront 이미지에는 healthcheck가 사용하는 wget이 빠져 있었음

문제점

  • Ory 로그 저장소 초기화 SQL이 새 ClickHouse 버전 제약과 맞지 않아 Ory용 ClickHouse가 안정적으로 올라오지 못했음
  • gateway/userfront는 서비스 자체는 떠 있었지만 healthcheck 도구 부재 때문에 compose 상에서 비정상으로 표시됐음

확인 방법

  • docker logs ory_clickhouse
  • docker inspect baron_gateway, docker inspect baron_userfront
  • Invoke-WebRequest http://localhost:5000
  • WSL 기준 docker ps 상태 확인

해결

  • docker/ory/clickhouse/init.sql의 TTL 식을 TTL toDateTime(timestamp) + INTERVAL 30 DAY로 수정
  • gateway/Dockerfile, userfront/Dockerfile에 wget 설치를 추가
  • 수정된 이미지/서비스만 다시 빌드 및 재기동하여 영향 범위를 최소화함

검증 결과

  • 최종 컨테이너 상태 확인:
    • baron_gateway healthy
    • baron_userfront healthy
    • baron_backend healthy
    • ory_clickhouse running
    • ory_hydra, ory_keto, ory_kratos, ory_oathkeeper, ory_vector 정상 실행
  • HTTP 응답 코드 확인 결과
    • http://localhost:5000 -> 200
    • http://localhost:5173 -> 200
    • http://localhost:5174 -> 200
    • http://localhost:5175 -> 200

추가 확인 내용

  • http://localhost:4457/health/alive는 404를 반환했으며, 이는 public proxy 포트가 일반 앱 health endpoint를 그대로 노출하는 용도가 아님을 보여줌
  • Baron/Ory 주요 서비스는 WSL Docker 기준으로 다시 정상화됨

해결/결론

  • WSL Docker와 Debian trixie-slim 반영 이후에도 Baron SSO 로컬 실행 스택을 다시 브라우저 접속 가능한 상태까지 복구 완료함

4. 현재까지 생성/변경된 주요 파일

  • docs/baronsso_structure_analysis.md
  • docs/baronsso_docker_container_roles.md
  • .env
  • config/.generated/auth-config.env
  • config/.generated/ory/kratos/kratos.yml
  • config/.generated/ory/hydra/hydra.yml
  • config/.generated/ory/keto/keto.yml
  • config/.generated/ory/oathkeeper/entrypoint.sh
  • config/.generated/ory/oathkeeper/oathkeeper.yml
  • compose.infra.yaml
  • compose.ory.yaml
  • docker-compose.yaml
  • .env.sample
  • backend/Dockerfile
  • gateway/Dockerfile
  • adminfront/Dockerfile
  • devfront/Dockerfile
  • orgfront/Dockerfile
  • userfront/Dockerfile
  • userfront/nginx.conf
  • docker/ory/clickhouse/init.sql

5. 현재까지 확인된 주요 문제 목록

5.1 로컬 환경 및 설정 문제

  • 초기에는 .env가 없었음
  • 초기에는 config/.generated/auth-config.env가 없었음
  • 5432 포트가 이미 사용 중이었음
  • make, go, flutter, pnpm이 로컬에 없음
  • 로컬 .env의 일부 값이 컨테이너 내부 접속 포트와 외부 노출 포트를 혼용하고 있었음

5.2 경로 처리 문제

  • 저장소 경로에 한글/공백이 있어 WSL 경유 bash 실행 시 경로 변환 실패 발생
  • Windows CRLF 개행 때문에 Bash가 .env를 직접 source할 때 오류 발생

5.3 Docker 이미지 및 런타임 문제

  • postgres:17-trixie가 로컬 Docker 환경에서 exec format error로 실패
  • clickhouse/clickhouse-server:latest가 로컬 Docker 환경에서 exec format error로 실패
  • config/.generated/ory/oathkeeper 산출물 누락 시 Oathkeeper 시작 실패
  • Kratos allowed return URLs 렌더링 값 오류
  • Hydra system secret 길이 부족 오류
  • Docker Desktop 제거 후 Windows 기준 docker PATH와 WSL Docker 엔진 기준 실행 환경이 분리됨
  • ClickHouse 24.6에서 Ory init SQL의 TTL 식이 DateTime64(3)와 호환되지 않았음
  • Debian trixie-slim 전환 후 gateway/userfront healthcheck에 필요한 wget이 누락되었음

5.4 현재 남아 있는 참고 사항

  • gateway는 userfront가 떠 있기 전에는 unhealthy가 될 수 있음
  • DB_PORT=5433은 호스트 접속용이며, backend 컨테이너 내부 접속은 5432 고정이 필요함

6. 현재까지 해결된 항목

  • Baron SSO 구조 분석 문서 작성 완료
  • 로컬 실행용 .env 작성 완료
  • config/.generated/auth-config.env 생성 완료
  • Docker 네트워크 생성 완료
  • 기본 서비스 포트 점검 완료
  • DB 포트 충돌 회피안(5433) 반영 완료
  • Docker Hub 접근 정상화 확인 완료
  • 로컬 호환 태그 기준 Ory Postgres/ClickHouse 기동 완료
  • config/.generated/ory 재생성 완료
  • Ory stack 전체 기동 및 readiness 검증 완료
  • Hydra RP 초기화 완료
  • backend DB 포트 오설정 수정 완료
  • app stack 기동 완료
  • localhost 브라우저 진입 주소 응답 확인 완료
  • WSL Docker 기준 런타임 재기동 및 네트워크 복구 완료
  • Debian trixie-slim 기반 커스텀 이미지 전환 완료
  • ClickHouse TTL 호환성 수정 완료
  • gateway/userfront healthcheck 정상화 완료

7. 현재 미해결 항목

  • 현 시점 기준 치명적 미해결 항목 없음
  • 다만 실제 로그인/회원가입/OIDC callback까지 포함한 사용자 시나리오 E2E 검증은 아직 별도로 수행하지 않음

8. 다음 권장 작업 순서

  1. 브라우저에서 http://localhost:5000에 접속해 실제 로그인/회원가입 흐름 검증
  2. admin/dev/org front에서 OIDC redirect 및 callback 정상 동작 확인
  3. 필요 시 현재 로컬 실행용 수정사항을 README 또는 운영 문서에 반영
  4. 필요 시 .env의 로컬 전용 값과 배포 전용 값을 분리하는 정책 정리

9. 최종 요약

이번 작업에서는 Baron SSO 저장소 구조 분석과 문서화에서 출발해, 로컬 .env 및 auth config 생성, Docker 네트워크 준비, infra + Ory stack 기동, app stack 기동, 브라우저 접속 검증, 이후 WSL Docker 환경 전환과 Debian trixie-slim 기반 이미지 정책 반영까지 순차적으로 완료했습니다. 진행 중에는 Docker Desktop 재시작 이후 레지스트리 접근 문제, 이미지 태그 호환성 문제, Ory 생성물 누락, Kratos/Hydra 설정 검증 오류, backend DB 포트 오설정, WSL 전환 후 런타임 리소스 재생성, ClickHouse TTL 호환성 문제, gateway/userfront healthcheck 도구 누락 문제가 순차적으로 드러났습니다. 각 문제는 로그, compose 설정, 렌더 결과, 실제 HTTP 응답을 기준으로 원인을 확인한 뒤 태그 조정, 설정 재생성, Dockerfile 수정, compose 환경변수 보정, 국소 재기동으로 해결했습니다. 최종적으로 WSL Docker 기준에서도 http://localhost:5000, http://localhost:5173, http://localhost:5174, http://localhost:5175가 모두 200 응답을 반환하는 상태까지 복구했습니다.

Reference in New Issue View Git Blame Copy Permalink