Fix local Docker startup configuration
This commit is contained in:
@@ -98,7 +98,8 @@ BACKEND_URL=${USERFRONT_URL}
|
|||||||
OATHKEEPER_PUBLIC_URL=${USERFRONT_URL}
|
OATHKEEPER_PUBLIC_URL=${USERFRONT_URL}
|
||||||
|
|
||||||
# ory-stack 변수들
|
# ory-stack 변수들
|
||||||
ORY_POSTGRES_TAG=17-trixie
|
ORY_POSTGRES_TAG=17-alpine
|
||||||
|
CLICKHOUSE_TAG=24.6
|
||||||
ORY_POSTGRES_USER=ory
|
ORY_POSTGRES_USER=ory
|
||||||
ORY_POSTGRES_PASSWORD=EuBV5ywvXFehkggHQrnYo5727MseEi6i9
|
ORY_POSTGRES_PASSWORD=EuBV5ywvXFehkggHQrnYo5727MseEi6i9
|
||||||
ORY_POSTGRES_DB=ory
|
ORY_POSTGRES_DB=ory
|
||||||
@@ -142,6 +143,7 @@ KRATOS_UI_URL=http://localhost:5000
|
|||||||
HYDRA_ADMIN_URL=http://hydra:4445
|
HYDRA_ADMIN_URL=http://hydra:4445
|
||||||
# Oathkeeper가 /oidc 경로를 Hydra Public API로 라우팅합니다.
|
# Oathkeeper가 /oidc 경로를 Hydra Public API로 라우팅합니다.
|
||||||
HYDRA_PUBLIC_URL=${OATHKEEPER_PUBLIC_URL}/oidc
|
HYDRA_PUBLIC_URL=${OATHKEEPER_PUBLIC_URL}/oidc
|
||||||
|
HYDRA_SYSTEM_SECRET=change-me-to-at-least-16-characters
|
||||||
# 선택: Hydra 화면 핸드오프 URL을 USERFRONT_URL 기준 기본값과 다르게 둘 때만 설정합니다.
|
# 선택: Hydra 화면 핸드오프 URL을 USERFRONT_URL 기준 기본값과 다르게 둘 때만 설정합니다.
|
||||||
# HYDRA_LOGIN_URL=https://sso.hmac.kr/login
|
# HYDRA_LOGIN_URL=https://sso.hmac.kr/login
|
||||||
# HYDRA_CONSENT_URL=https://sso.hmac.kr/consent
|
# HYDRA_CONSENT_URL=https://sso.hmac.kr/consent
|
||||||
@@ -149,7 +151,7 @@ HYDRA_PUBLIC_URL=${OATHKEEPER_PUBLIC_URL}/oidc
|
|||||||
|
|
||||||
# Kratos allowed_return_urls 확장 목록 (콤마 구분, 선택)
|
# Kratos allowed_return_urls 확장 목록 (콤마 구분, 선택)
|
||||||
# 기본값은 KRATOS_UI_URL, USERFRONT_URL, 각 callback URL을 자동 포함합니다.
|
# 기본값은 KRATOS_UI_URL, USERFRONT_URL, 각 callback URL을 자동 포함합니다.
|
||||||
KRATOS_ALLOWED_RETURN_URLS_EXTRA=[]
|
KRATOS_ALLOWED_RETURN_URLS_EXTRA=
|
||||||
KRATOS_ALLOWED_RETURN_URLS_JSON=["http://localhost:5000","http://localhost:5000/","https://sso.hmac.kr","https://sso.hmac.kr/","https://sso.hmac.kr/ko","https://sso.hmac.kr/ko/","https://sso.hmac.kr/en","https://sso.hmac.kr/en/","https://sso.hmac.kr/auth/callback","https://sso.hmac.kr/ko/auth/callback","https://sso.hmac.kr/en/auth/callback","http://localhost:5173/auth/callback","http://localhost:5174/auth/callback","http://localhost:5175/auth/callback","https://sso.hmac.kr/orgfront/auth/callback"]
|
KRATOS_ALLOWED_RETURN_URLS_JSON=["http://localhost:5000","http://localhost:5000/","https://sso.hmac.kr","https://sso.hmac.kr/","https://sso.hmac.kr/ko","https://sso.hmac.kr/ko/","https://sso.hmac.kr/en","https://sso.hmac.kr/en/","https://sso.hmac.kr/auth/callback","https://sso.hmac.kr/ko/auth/callback","https://sso.hmac.kr/en/auth/callback","http://localhost:5173/auth/callback","http://localhost:5174/auth/callback","http://localhost:5175/auth/callback","https://sso.hmac.kr/orgfront/auth/callback"]
|
||||||
|
|
||||||
# Oathkeeper JWKS (내부 통신용)
|
# Oathkeeper JWKS (내부 통신용)
|
||||||
|
|||||||
@@ -25,7 +25,7 @@ services:
|
|||||||
restart: always
|
restart: always
|
||||||
|
|
||||||
clickhouse:
|
clickhouse:
|
||||||
image: clickhouse/clickhouse-server:latest
|
image: clickhouse/clickhouse-server:${CLICKHOUSE_TAG:-24.6}
|
||||||
container_name: baron_clickhouse
|
container_name: baron_clickhouse
|
||||||
restart: always
|
restart: always
|
||||||
volumes:
|
volumes:
|
||||||
|
|||||||
@@ -94,7 +94,7 @@ services:
|
|||||||
- URLS_LOGIN=${HYDRA_LOGIN_URL:-${USERFRONT_URL}/login}
|
- URLS_LOGIN=${HYDRA_LOGIN_URL:-${USERFRONT_URL}/login}
|
||||||
- URLS_CONSENT=${HYDRA_CONSENT_URL:-${USERFRONT_URL}/consent}
|
- URLS_CONSENT=${HYDRA_CONSENT_URL:-${USERFRONT_URL}/consent}
|
||||||
- URLS_ERROR=${HYDRA_ERROR_URL:-${USERFRONT_URL}/error}
|
- URLS_ERROR=${HYDRA_ERROR_URL:-${USERFRONT_URL}/error}
|
||||||
- SECRETS_SYSTEM=${ORY_POSTGRES_PASSWORD}
|
- SECRETS_SYSTEM=${HYDRA_SYSTEM_SECRET:-${ORY_POSTGRES_PASSWORD}}
|
||||||
volumes:
|
volumes:
|
||||||
- ./config/.generated/ory/hydra:/etc/config/hydra
|
- ./config/.generated/ory/hydra:/etc/config/hydra
|
||||||
command: serve -c /etc/config/hydra/hydra.yml all --dev
|
command: serve -c /etc/config/hydra/hydra.yml all --dev
|
||||||
@@ -170,7 +170,7 @@ services:
|
|||||||
- public_net
|
- public_net
|
||||||
|
|
||||||
ory_clickhouse:
|
ory_clickhouse:
|
||||||
image: clickhouse/clickhouse-server:latest
|
image: clickhouse/clickhouse-server:${CLICKHOUSE_TAG:-24.6}
|
||||||
container_name: ory_clickhouse
|
container_name: ory_clickhouse
|
||||||
environment:
|
environment:
|
||||||
- CLICKHOUSE_USER=${ORY_CLICKHOUSE_USER:-ory}
|
- CLICKHOUSE_USER=${ORY_CLICKHOUSE_USER:-ory}
|
||||||
|
|||||||
@@ -28,6 +28,7 @@ services:
|
|||||||
- KETO_READ_URL=${KETO_READ_URL:-http://keto:4466}
|
- KETO_READ_URL=${KETO_READ_URL:-http://keto:4466}
|
||||||
- KETO_WRITE_URL=${KETO_WRITE_URL:-http://keto:4467}
|
- KETO_WRITE_URL=${KETO_WRITE_URL:-http://keto:4467}
|
||||||
- DB_HOST=postgres
|
- DB_HOST=postgres
|
||||||
|
- DB_PORT=5432
|
||||||
- CLICKHOUSE_HOST=clickhouse
|
- CLICKHOUSE_HOST=clickhouse
|
||||||
- CLICKHOUSE_PORT=${CLICKHOUSE_PORT_NATIVE:-9000}
|
- CLICKHOUSE_PORT=${CLICKHOUSE_PORT_NATIVE:-9000}
|
||||||
- CLICKHOUSE_USER=${CLICKHOUSE_USER:-baron}
|
- CLICKHOUSE_USER=${CLICKHOUSE_USER:-baron}
|
||||||
|
|||||||
238
baron-sso/docs/baronsso_structure_analysis.md
Normal file
238
baron-sso/docs/baronsso_structure_analysis.md
Normal file
@@ -0,0 +1,238 @@
|
|||||||
|
# Baron SSO 구조 분석
|
||||||
|
|
||||||
|
## 1. 이 시스템은 무엇인가
|
||||||
|
|
||||||
|
Baron SSO는 계열사 또는 화이트라벨 대상 서비스들의 로그인, 권한, 애플리케이션 연동을 중앙에서 관리하는 통합 인증/인가 허브입니다. 저장소의 설명과 구성 파일을 보면 단순 로그인 화면이 아니라 다음 역할을 함께 수행하는 IAM 플랫폼에 가깝습니다.
|
||||||
|
|
||||||
|
- 사용자 인증과 계정 수명주기 관리
|
||||||
|
- OAuth2/OIDC 기반 SSO와 RP(Relying Party) 연동
|
||||||
|
- 권한 정책 및 접근 제어 관리
|
||||||
|
- 관리자용 운영 화면, 개발자용 RP 관리 화면, 조직도/조직 컨텍스트 화면 제공
|
||||||
|
- 감사 로그 수집과 운영 데이터 관리
|
||||||
|
|
||||||
|
핵심적으로는 Ory Stack을 자체 호스팅하고, Baron Backend가 비즈니스 규칙과 운영 기능을 담당하며, 여러 프론트엔드가 역할별 UI를 제공합니다.
|
||||||
|
|
||||||
|
## 2. 전체 아키텍처 요약
|
||||||
|
|
||||||
|
현재 저장소는 하나의 애플리케이션이 아니라, 인증 인프라와 여러 사용자 인터페이스를 함께 운영하는 멀티 서비스 구조입니다.
|
||||||
|
|
||||||
|
### 2.1 주요 계층
|
||||||
|
|
||||||
|
1. Ory 기반 IAM 계층
|
||||||
|
2. Baron 자체 백엔드 계층
|
||||||
|
3. 역할별 프론트엔드 계층
|
||||||
|
4. 게이트웨이 및 인프라 계층
|
||||||
|
5. 데이터 저장소 및 로깅 계층
|
||||||
|
|
||||||
|
### 2.2 구성 요소별 역할
|
||||||
|
|
||||||
|
#### Ory Stack
|
||||||
|
|
||||||
|
`compose.ory.yaml` 기준으로 다음 컴포넌트를 별도 컨테이너로 운영합니다.
|
||||||
|
|
||||||
|
- Kratos: 사용자 인증, 계정, self-service flow
|
||||||
|
- Hydra: OAuth2/OIDC 서버, 로그인/동의 흐름, 토큰 발급
|
||||||
|
- Keto: 권한 관계 및 정책 기반 접근 제어
|
||||||
|
- Oathkeeper: 프록시형 접근 제어 게이트
|
||||||
|
|
||||||
|
즉, Baron SSO의 인증/인가 핵심은 Ory를 기반으로 하고, Baron 코드는 그 위에서 비즈니스 로직과 운영 기능을 덧씌우는 구조입니다.
|
||||||
|
|
||||||
|
#### Backend
|
||||||
|
|
||||||
|
`backend`는 Go Fiber 기반 API 서버이며, 저장소 README 설명대로 Ory Stack과 여러 프론트엔드 사이의 주된 비즈니스 백엔드 역할을 수행합니다.
|
||||||
|
|
||||||
|
역할은 다음과 같이 해석할 수 있습니다.
|
||||||
|
|
||||||
|
- 프론트엔드가 호출하는 자체 API 제공
|
||||||
|
- Ory Admin/Public API와 연동하여 로그인, 동의, RP 관련 흐름 제어
|
||||||
|
- 감사 로그 적재
|
||||||
|
- 테넌트, 사용자, 운영 데이터 처리
|
||||||
|
- 외부 연동 기능 처리
|
||||||
|
|
||||||
|
`docker-compose.yaml`에서도 각 웹 프론트엔드가 `API_PROXY_TARGET=http://baron_backend:3000`으로 이 백엔드를 바라보도록 구성되어 있습니다.
|
||||||
|
|
||||||
|
#### 프론트엔드 계층
|
||||||
|
|
||||||
|
역할이 나뉜 여러 UI가 함께 존재합니다.
|
||||||
|
|
||||||
|
- `userfront`: 최종 사용자용 로그인/인증 UI, Flutter 기반
|
||||||
|
- `adminfront`: 관리자용 운영 UI, React/Vite 기반
|
||||||
|
- `devfront`: 개발자용 RP 및 연동 관리 UI, React/Vite 기반
|
||||||
|
- `orgfront`: 조직/컨텍스트 시각화 및 관리 성격의 UI, React/Vite 기반
|
||||||
|
|
||||||
|
프론트엔드가 분리되어 있다는 점은 이 시스템이 단일 로그인 페이지 수준이 아니라, 사용자 포털과 운영 포털을 함께 포함하는 플랫폼임을 보여줍니다.
|
||||||
|
|
||||||
|
#### Gateway
|
||||||
|
|
||||||
|
`gateway`는 Nginx 기반 컨테이너이며 외부 진입점 역할을 담당합니다. `compose.infra.yaml`에서 `public_net`에 연결되어 있고, `USERFRONT_PORT`를 외부로 노출합니다. 따라서 사용자가 처음 접근하는 표면은 게이트웨이 또는 Oathkeeper를 포함한 프록시 계층을 통해 노출되는 구조로 볼 수 있습니다.
|
||||||
|
|
||||||
|
#### 데이터 및 부가 인프라
|
||||||
|
|
||||||
|
저장소에는 인증 인프라용 저장소와 서비스 메타데이터용 저장소가 분리되어 있습니다.
|
||||||
|
|
||||||
|
- PostgreSQL: Baron 메타데이터 저장 및 Ory 데이터 저장소
|
||||||
|
- ClickHouse: 감사 로그 및 이벤트성 데이터 적재
|
||||||
|
- Redis: 캐시/세션성 또는 보조 저장소 용도
|
||||||
|
- Promtail, Blackbox Exporter, Vector: 로그/모니터링/전송 보조 구성
|
||||||
|
|
||||||
|
### 2.3 구조도
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart LR
|
||||||
|
User[User / Admin / Developer] --> Gateway[Nginx Gateway / Public Entry]
|
||||||
|
User --> WebApps[Frontends]
|
||||||
|
|
||||||
|
subgraph Frontend Layer
|
||||||
|
UF[userfront\nFlutter]
|
||||||
|
AF[adminfront\nReact + Vite]
|
||||||
|
DF[devfront\nReact + Vite]
|
||||||
|
OF[orgfront\nReact + Vite]
|
||||||
|
end
|
||||||
|
|
||||||
|
Gateway --> UF
|
||||||
|
AF --> BE
|
||||||
|
DF --> BE
|
||||||
|
OF --> BE
|
||||||
|
UF --> BE
|
||||||
|
|
||||||
|
subgraph Service Layer
|
||||||
|
BE[Baron Backend\nGo + Fiber]
|
||||||
|
end
|
||||||
|
|
||||||
|
subgraph IAM Layer
|
||||||
|
KR[Ory Kratos]
|
||||||
|
HY[Ory Hydra]
|
||||||
|
KE[Ory Keto]
|
||||||
|
OK[Ory Oathkeeper]
|
||||||
|
end
|
||||||
|
|
||||||
|
BE --> KR
|
||||||
|
BE --> HY
|
||||||
|
BE --> KE
|
||||||
|
OK --> KR
|
||||||
|
OK --> HY
|
||||||
|
OK --> KE
|
||||||
|
|
||||||
|
subgraph Data Layer
|
||||||
|
PG[(PostgreSQL)]
|
||||||
|
CH[(ClickHouse)]
|
||||||
|
RD[(Redis)]
|
||||||
|
end
|
||||||
|
|
||||||
|
BE --> PG
|
||||||
|
BE --> CH
|
||||||
|
BE --> RD
|
||||||
|
KR --> PG
|
||||||
|
HY --> PG
|
||||||
|
KE --> PG
|
||||||
|
```
|
||||||
|
|
||||||
|
## 3. 개발 기술 스택 정리
|
||||||
|
|
||||||
|
### 3.1 백엔드
|
||||||
|
|
||||||
|
- Language: Go 1.26.2
|
||||||
|
- Web Framework: Fiber v2
|
||||||
|
- ORM/DB access: GORM, PostgreSQL driver, `lib/pq`
|
||||||
|
- IAM/OIDC 관련: `coreos/go-oidc`, `golang.org/x/oauth2`, `go-jose`
|
||||||
|
- Cache/infra: Redis, ClickHouse
|
||||||
|
- Test: Testify, Testcontainers
|
||||||
|
- 기타 연동: AWS SDK v2, SES
|
||||||
|
|
||||||
|
즉, 백엔드는 Go 기반의 API 서버이면서 IAM 흐름을 직접 제어하는 오케스트레이션 계층입니다.
|
||||||
|
|
||||||
|
### 3.2 사용자 프론트엔드
|
||||||
|
|
||||||
|
`userfront/pubspec.yaml` 기준 스택은 다음과 같습니다.
|
||||||
|
|
||||||
|
- Framework: Flutter
|
||||||
|
- Language runtime: Dart SDK 3.10+
|
||||||
|
- State management: Riverpod
|
||||||
|
- Routing: go_router
|
||||||
|
- 기타: easy_localization, qr_flutter, mobile_scanner, shared_preferences
|
||||||
|
|
||||||
|
이를 보면 `userfront`는 웹 중심 React 앱이 아니라 Flutter 기반의 사용자 인증 UI이며, QR 로그인, 다국어, 로컬 상태 저장 등의 기능을 염두에 둔 구조입니다.
|
||||||
|
|
||||||
|
### 3.3 운영/관리 프론트엔드
|
||||||
|
|
||||||
|
`adminfront`, `devfront`, `orgfront`는 공통적으로 현대적인 React 프론트엔드 스택을 사용합니다.
|
||||||
|
|
||||||
|
- Framework: React 19
|
||||||
|
- Build tool: Vite 8
|
||||||
|
- Language: TypeScript 6
|
||||||
|
- Styling: Tailwind CSS, tailwindcss-animate
|
||||||
|
- UI primitives: Radix UI
|
||||||
|
- Data fetching/cache: TanStack Query
|
||||||
|
- Form/validation: react-hook-form, zod
|
||||||
|
- Auth client: oidc-client-ts, react-oidc-context
|
||||||
|
- HTTP client: axios
|
||||||
|
- Test: Vitest, Playwright
|
||||||
|
- Lint/format: Biome
|
||||||
|
|
||||||
|
`orgfront`는 여기에 `@xyflow/react`를 사용하고 있어 조직 구조나 컨텍스트 시각화 성격의 기능이 포함된 것으로 보입니다.
|
||||||
|
|
||||||
|
### 3.4 공통/모노레포 구성
|
||||||
|
|
||||||
|
- Package manager: pnpm workspace
|
||||||
|
- 공통 패키지: `common`
|
||||||
|
- 공통 리소스: `locales`
|
||||||
|
- 코드 품질: Biome
|
||||||
|
|
||||||
|
즉, 프론트엔드는 모노레포 형태로 운영되며 공통 UI/설정/로케일 자산을 공유합니다.
|
||||||
|
|
||||||
|
### 3.5 인프라 및 배포
|
||||||
|
|
||||||
|
- Container orchestration: Docker Compose
|
||||||
|
- Reverse proxy: Nginx
|
||||||
|
- IAM platform: Ory Kratos, Hydra, Keto, Oathkeeper
|
||||||
|
- Database: PostgreSQL
|
||||||
|
- Analytics/Audit store: ClickHouse
|
||||||
|
- Cache: Redis
|
||||||
|
- Observability: Promtail, Vector, Blackbox Exporter
|
||||||
|
|
||||||
|
## 4. 이 저장소에서 보이는 설계 특징
|
||||||
|
|
||||||
|
### 4.1 멀티테넌트 운영 시스템 성격
|
||||||
|
|
||||||
|
README와 `seed-tenant.csv`, 테넌트 import/export 관련 문서 이름들로 보아 이 시스템은 단일 서비스용 로그인 서버가 아니라, 여러 조직과 테넌트를 관리하는 멀티테넌트 IAM 운영 시스템입니다.
|
||||||
|
|
||||||
|
### 4.2 인증과 운영 기능의 분리
|
||||||
|
|
||||||
|
인증 그 자체는 Ory Stack이 맡고, Baron Backend와 각 Frontend가 다음을 담당합니다.
|
||||||
|
|
||||||
|
- 비즈니스 규칙 적용
|
||||||
|
- 운영 UI 제공
|
||||||
|
- 테넌트/사용자 관리
|
||||||
|
- RP 등록 및 OIDC 연동 관리
|
||||||
|
- 감사 로그와 운영성 기능
|
||||||
|
|
||||||
|
이 구조는 범용 IAM 엔진과 도메인 특화 운영 시스템을 분리한 설계로 볼 수 있습니다.
|
||||||
|
|
||||||
|
### 4.3 감사와 추적 가능성을 중시
|
||||||
|
|
||||||
|
ClickHouse, Promtail, Vector, 감사 로그 관련 README 설명을 보면 운영 추적성과 감사 가능성을 중요한 요구사항으로 두고 있습니다. 특히 로그인/권한/관리자 작업의 추적을 고려한 구조로 해석됩니다.
|
||||||
|
|
||||||
|
### 4.4 역할별 UI 분리
|
||||||
|
|
||||||
|
최종 사용자, 운영 관리자, 개발자, 조직 관리 성격의 UI가 분리되어 있어 권한과 업무 맥락에 따라 화면을 구분하는 B2B 운영 시스템의 전형적인 구조를 가집니다.
|
||||||
|
|
||||||
|
## 5. 한 줄 요약
|
||||||
|
|
||||||
|
Baron SSO는 Ory Stack을 자체 호스팅 기반으로 사용하면서, Go 백엔드와 여러 역할별 프론트엔드를 결합해 구성한 멀티테넌트 SSO/IAM 운영 플랫폼입니다. 기술적으로는 Go + Fiber, Flutter, React + Vite + TypeScript, PostgreSQL, ClickHouse, Redis, Docker Compose, Ory 생태계를 중심으로 구성되어 있습니다.
|
||||||
|
|
||||||
|
## 6. 분석 시 참고한 주요 근거 파일
|
||||||
|
|
||||||
|
- `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`
|
||||||
|
|
||||||
|
## 7. 주의사항
|
||||||
|
|
||||||
|
루트 README의 일부 프로젝트 구조 설명은 현재 저장소의 실제 구성과 완전히 일치하지 않을 수 있습니다. 예를 들어 `adminfront`, `devfront`, `orgfront`는 실제로 React/Vite 기반 패키지이고, `userfront`는 별도의 Flutter 애플리케이션입니다. 따라서 현재 구조 분석은 README 서술보다 실제 매니페스트와 compose 파일을 우선 기준으로 정리했습니다.
|
||||||
588
baron-sso/docs/baronsso_work_timeline_report.md
Normal file
588
baron-sso/docs/baronsso_work_timeline_report.md
Normal file
@@ -0,0 +1,588 @@
|
|||||||
|
# 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 로컬 실행 스택이 브라우저 접속 가능한 상태까지 도달함
|
||||||
|
|
||||||
|
## 4. 현재까지 생성/변경된 주요 파일
|
||||||
|
|
||||||
|
- `docs/baronsso_structure_analysis.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`
|
||||||
|
|
||||||
|
## 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 길이 부족 오류
|
||||||
|
|
||||||
|
### 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 브라우저 진입 주소 응답 확인 완료
|
||||||
|
|
||||||
|
## 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 기동, 그리고 브라우저 접속 검증까지 순차적으로 완료했습니다. 진행 중 Docker Desktop 재시작 이후 레지스트리 접근 문제는 해소되었고, 이후에는 이미지 태그 호환성 문제, Ory 생성물 누락, Kratos/Hydra 설정 검증 오류, backend DB 포트 오설정 문제가 순차적으로 드러났습니다. 각 문제는 로그와 렌더 결과를 기준으로 원인을 확인한 뒤 태그 조정, 설정 재생성, 환경값 수정, compose 환경변수 보정으로 해결했습니다. 최종적으로 `http://localhost:5000`, `http://localhost:5173`, `http://localhost:5174`, `http://localhost:5175`가 모두 `200` 응답을 반환하는 상태까지 도달했습니다.
|
||||||
Reference in New Issue
Block a user