Wrapper Offline Refresh Apply¶

이 문서는 Wrapper가 Hub와 즉시 통신하기 어려운 환경에서, schema register와 runtime refresh 결과를 로컬 storage에 선반영하는 절차를 정리한다.

과거 hubId 기반 export-config 절차는 현재 6.x runtime 기준의 canonical 절차가 아니다. 현재 기준은 alias로 schema/mapping 그룹을 정하고, Hub가 발급한 tenantId로 Wrapper runtime을 인증하는 모델이다.

Scope¶

이 절차는 다음 상황에서 사용한다.

Wrapper가 Hub와 즉시 연결될 수 없는 환경
제한망 또는 승인 절차 때문에 설정 반영을 수동 단계로 나눠야 하는 환경
장애 복구 또는 초기 반입 시 온라인 refresh 이전에 로컬 storage를 준비해야 하는 환경

이 문서는 정책의 원본을 바꾸는 절차가 아니라, Hub 원본을 Wrapper 로컬 스냅샷으로 반영하는 절차를 다룬다.

Current Identifiers¶

Identifier	Meaning
`alias`	같은 DB/schema와 정책 매핑을 공유하는 논리 그룹
`tenantId`	Hub가 발급한 개별 Wrapper runtime credential
`policyCode`	runtime 암복호화 요청의 정책 식별자

tenantId는 X-DADP-Tenant-Id header에 사용되는 runtime credential이다. 다른 alias 또는 다른 tenant의 파일을 섞으면 Wrapper가 잘못된 runtime snapshot을 읽을 수 있다.

What the Local Storage Contains¶

Wrapper runtime storage에는 일반적으로 다음 파일이 들어간다.

proxy-config.json
policy-mappings.json
schema/cache 보조 파일

proxy-config.json은 tenantId, alias, runtimeVersion, runtime Hub URL, Engine endpoint와 runtime option을 담는다. 정책 원본은 여전히 Hub에 있고, 이 파일은 실행 사본이다.

Step 1. Prepare Alias and Schema¶

먼저 대상 alias를 확정한다.

dadp wrapper schema collect --alias orders-db ...
dadp wrapper schema register --alias orders-db ...

schema register 결과에는 Hub가 발급하거나 재사용한 tenantId가 포함된다. CLI는 이 값을 Wrapper storage의 proxy-config.json에 저장한다.

Step 2. Resolve Wrapper Storage Directory¶

현재 Wrapper 6.x 기준 runtime storage는 wrapper library directory와 alias에서 파생된다.

<wrapper-lib-dir>/dadp/wrapper/<alias>

예:

/opt/customer-app/lib/dadp/wrapper/orders-db

운영자는 애플리케이션이 실제로 읽을 수 있는 경로와 CLI가 기록한 경로가 같은지 확인해야 한다.

Step 3. Apply Runtime Refresh¶

Hub에서 정책 매핑과 endpoint 구성을 완료한 뒤 refresh를 수행한다.

dadp wrapper refresh --alias orders-db

runtime refresh는 다음 Hub runtime API와 같은 의미를 가진다.

GET /hub/api/v1/runtime/wrappers/{tenantId}/refresh?version={runtimeVersion}
X-DADP-Tenant-Id: {tenantId}

refresh 결과는 Wrapper storage에 반영된다.

Step 4. Move Storage When Offline¶

제한망에서 CLI를 실행한 위치와 애플리케이션 서버가 다르면, alias-scoped storage directory 전체를 애플리케이션 서버의 같은 구조로 옮긴다.

cp -a /tmp/dadp/wrapper/orders-db /opt/customer-app/lib/dadp/wrapper/orders-db

파일 하나만 임의 이름으로 복사하는 방식보다, alias directory 전체를 보존하는 방식이 더 안전하다.

Step 5. Restart or Re-bootstrap Wrapper¶

파일을 배치했다고 해서 즉시 반영이 끝난 것은 아니다. Wrapper가 local storage를 읽는 시점은 bootstrap 또는 refresh 흐름이다.

운영 기준의 순서는 다음과 같다.

schema register 또는 refresh 수행
alias-scoped storage directory 확인
필요 시 storage directory 이동
Wrapper 또는 애플리케이션 재기동
bootstrap 로그와 보호 동작 확인

Verification¶

적용 성공 여부는 파일 존재만으로 판단하지 않는다. 다음 신호를 함께 확인한다.

proxy-config.json에 기대한 tenantId와 alias가 있다.
policy-mappings.json이 최신 mapping version을 담고 있다.
Wrapper bootstrap 로그가 같은 storage directory를 읽는다.
애플리케이션 JDBC 경로에서 기대한 정책이 적용된다.

Operational Notes¶

수동 반영 환경에서는 Hub 원본 변경 시점과 Wrapper local storage 반영 시점을 함께 기록한다.
tenantId가 다른 파일을 잘못 넣으면 runtime 인증과 refresh가 실패할 수 있다.
alias가 다르면 schema/mapping 그룹이 달라진다.
local storage는 정책 원본이 아니라 실행 보조 사본이다.