업그레이드와 이전 버전 마이그레이션

2.x 버전 간 업그레이드

1. 데이터베이스를 백업합니다(plugins/, configure/도 함께).
2. 서비스를 중지합니다: bin/shutdown.sh.
3. 새 버전 릴리스 패키지의 lib/와 bin/로 이전 것을 교체합니다.
4. 서비스를 시작합니다: bin/startup.sh. Liquibase가 새 버전의 데이터베이스 마이그레이션을 자동으로 실행하며, 레디니스 프로브는 마이그레이션이 완료된 뒤에야 200을 반환합니다.

클러스터를 업그레이드할 때는 예전 버전과 새 버전이 동시에 읽고 쓰지 않도록, 새 버전을 시작하기 전에 모든 인스턴스를 중지합니다. 이미 배포된 마이그레이션은 수정되지 않으며, 모든 버전은 지원하는 전체 데이터베이스에서 "이전 버전으로부터 업그레이드"를 검증합니다.

1.x에서 마이그레이션

1.x는 데이터를 다른 테이블 구조에 저장하며, 2.x는 이를 읽지 않습니다. 마이그레이션 방법은 새 데이터베이스에 2.x를 설치하고 초기화를 완료한 뒤, 서비스를 중지하고 이전 데이터베이스의 계정, 역할, 메뉴를 특정 테넌트로 가져오는 것입니다.

# 먼저 리허설: 보고서만 생성하고 기록하지 않음
bin/import-legacy.sh --source-url jdbc:mysql://old-db:3306/authx --source-user authx --tenant default
# 보고서를 확인한 뒤 실제로 가져오기
bin/import-legacy.sh --source-url jdbc:mysql://old-db:3306/authx --source-user authx --tenant default --apply

두 명령은 모두 logs/legacy-import-report.json을 작성합니다. 보고서에는 이미(또는 앞으로) 생성될 내용, 건너뛴 내용과 그 이유, 예전 객체에 대응하는 새 ID가 나열됩니다. 이전 데이터베이스의 JDBC 드라이버는 drivers/에 넣고, 비밀번호는 GRANTFORGE_LEGACY_SOURCE_PASSWORD로 제공합니다(제공하지 않으면 스크립트가 물어봅니다). 가져오기를 반복 실행하면 누락된 내용만 보충됩니다.

가져오기 규칙:

• 계정은 기존 비밀번호를 유지하며, 최초 로그인 시 새 해시 알고리즘으로 자동 교체됩니다. 2.x 사용자 이름 규칙(알파벳, 숫자 또는 ._@-로 3–64자)에 맞지 않거나, 비밀번호가 없거나, 사용자 이름이 이미 다른 테넌트에서 사용 중인 계정은 건너뜁니다.
• 역할은 이름을 유지하며, 코드는 소문자로 변환됩니다(GLY → gly).
• 메뉴는 legacy 애플리케이션의 리소스가 됩니다: # 주소의 메뉴는 그룹이 되고, 다른 주소는 페이지가 되며, 페이지 아래의 메뉴는 버튼이 됩니다. 메뉴 주소와 그 HTTP 메서드는 API 리소스 api:<메서드>:<경로>가 되며, *로 끝나는 주소는 <경로>/**가 되어 문자 접두사가 아니라 경로 단위로 매칭됩니다. 보고서에 하나씩 나열되므로 확인할 수 있습니다.
• 명시적 권한 부여만 마이그레이션됩니다: 1.x에서는 메뉴로 등록된 주소를 누구나 접근할 수 있었지만, 2.x에서는 그렇지 않습니다.