지난 글에서는 애플리케이션 코드만으로는 재현할 수 없었던 DB스키마를 Mybatis 매퍼와 실제 Oracle DB를 대조해가며
SQL 파일로 복원하는 과정을 정리했다.
이번 글에서는 그렇게 준비한 Dockerfile, docker-compose.yml, 스키마/시드 SQL 을 로컬 PC에서
실제로 docekr compose up을 한번 돌려보는 과정을 정리한다. 순서대로 하나씩 문제를 풀어나가는 과정을 정리했다.
문제 1. Docker Desktop이 아예 안 키지는 문제 ( BIOS AMD SVM )
Docker Desktop을 설치하고 실행했는데 가상화 관련 오류로 아예 켜지지않았다. Docker Desktop은 WSL2 기반으로 동작하고,
WSL2는 다시 하드웨어 가상화 기능이 필요한데, 내 PC는 BIOS에서 AMD의 가상화기능(SVM)이 꺼져있는 상태였다.
BIOS로 들어가서 SVM Mode를 Enabled로 바꾸고 나서 문제가 해결됐다. 개발PC에서는 신경쓸일이 없던 설정이라,
Docker를 쓰려면 OS 레벨이아니라 하드웨어 레벨에서부터 가상화가 필요하다는 걸 이번에 처음 체감했다.
문제 2. WSL2 설치가 wsl --install 에서 멈춘다
BIOS 설정을 바꾼다음에 WSL2 자체가 설치되어 있지않아서 wsl --install 을 실행했는데,
설치 과정이 특정단계에서 계속 멈추는 상황이 발생했다.
찾아보니 wsl --install 이 자동으로 켜줘야 할 Windows 선택적 기능("Linux용 Windows 하위시스템", "가상 머신 플랫폼") 이
아직 활성화 되지않는 상태에서 커널 업데이트 페키지부터 실행하려다보니 생긴문제였다.
제어판의 windows 기능 켜기/끄기에서 두기능을체크했고, dism /online / get-featureinfo 두 기능의 상태가 사용으로
바뀐것을 확인했다.
이상태에서 다시 wsl --install을 실행하니 정상적으로 설치가 되었다.
문제3. DB포트 1521 충돌
WSL2 문제를 해결하고 docker compose up 을 실행했더니 이번엔 Oracle DB 컨테이너가
포트 바인딩에 실패했다. 원인은 전에 로컬에서 쓰던 1521포트가 컨테이너의 OracleXE 포트도 1521이라
충돌한 것이었다.
호스트쪽 포트를 1522바꾸는 걸로 해결했다
docker-compose.yml
oracle-db:
ports:
- "1522:1521" <-- 수정
문제 4. Oracle 컨테이너가 계속 죽었다가 반복 ( ORA - 01157 )
포트까지 정리하고 나니 이번엔 Oracle 컨테이너가 뜨는 것 같다가 ORA-01157 에러를 내면서 계속 재시작을 반복하는
문제가 생겼다.
정확한 내부원인은 끝까지 특정하지 못했지만, -faststarts 태그가 걸려있던 이미지를 gvenzl/oracle-xe:21-slim을 faststart
을빼자 더이상 재현되지않고 정상적으로 초기화됐다.
문제 5. 로그인이 안된다
DB까지 정상적으로 뜨고 스키마/ 시드 SQL도 실행했는데, 정작 데모계정 testuser/1234 로 시도하니 로그인 정보가
없습니다라고 에러가났다.
DB에 직접 접속해서 확인해보니 USERS.USER_PASSWORD에 저장된 BCrpt 해시가 실제로 1234를 해싱한 값과
맞지않는 값이었다. sqlplus로 접속해서 새로 생성한 BCrypt해시로 직접 UPDATE해서 해결했다.
추가로 update에 떠있는 DB도 고쳤지만 02_seed.sql에도 해시값을 맞게 바꿔서 나중에 볼륨을 초기화해도 같은 문제가
재발하지 않도록 했다.
sqlplus 재접속시 서비스명을 빼먹고 실행한적이있는데 그러면 CDB$ROOT에 붙어버려서 TRACKER 스키마 자체가
안보이는 문제도있었다 UPDATE가 ORA-00942: table or view does not exist 에러로 실패해서 처음엔 당황했는데,
SHOWCON_NAME으로 확인해보니 CDB$ROOT에붙어있는걸 확인했다. 서비스명을 제대로 @XEPDB1을 붙여서
다시 접속하니 해결됐다.
문제 6. 로그인은 되는데 Dashboard가 전부 0으로 나온다
로그인까지는 성공했는데, 이번엔 Dashboard 화면의 모든 통계가 0으로 나왔다.
데이터가 아예 없는건 아니었는데
원인은 DemoDataSeeder가 실행되지않은것으로 추청했다.
DemoDataSeeder는 @Profile("seed")로 지정되어있는데 컨테이너는 SPRING_PROFILES_ACTIVE=prod
만 활성화된 상태로 떠 있어서 시더 자체가 동작하지않았던 것이었다.
docker-composer.yml
backend:
enviroment:
SPRING_PROFILES_ACTIVE: prod, seed
프로파일은 prod, seed로 바꾸고 다시 올리니 데모 데이터가 정상적으로 채워지고 Dashboard 수치도 제대로 나왔다.
마무리
여기까지 정리하고 나서 다시 docker compose up -d를 실행하니 , 전체 컨테이너가 모두 healthy로 뜨고
로그인 데모데이터 모두 정상적으로 동작했다.
느낀점
문제가 계층별로 하나씩 드러났다. 처음에는 하드웨어 가상화(BIOIS) -> WSL2 -> Docker 네트워크/포트 -> 이미지 초기화 ->
데이터 적합성 -> Spring 프로파일 설정 순으로 , 순서대로 밑에문제를 해결해야 그 다음 계층의 문제가 보이는 식이었다.
그리고 docker compose down -v가 컨테이너뿐 아니라 볼륨까지 지운다는걸 알고나니 DB 관련 수정은 지금 떠 있는 DB 뿐 아니라 시드 SQL 에도 같이 반영해둬야 나중에 볼륨을 초기화해도 같은 문제가 재발하지않는다는것도 배웠다.
Oracle Cloud에 실제로 배포할 때도 면접관이 접속했을때 데모데이터가 바로 보여야하기때문에 seed프로파일은 계속 켜둔채로
배포하기로 했다. DemoDateSeeder는 실행될때마다 기존 데이터를 지우고 다시 채우는 방식으로 만들워뒀기 때문에,
컨테이너가 재시작될때마다 그시점까지 쌓인 데이터까지 함께 초기화된다는 것을 알고 그렇게 진행하기로 했다.
다음 편 에서는 이렇게 로컬에서 검증한 구성을 Oracle Cloud Always Free VM에 실제로 올리는 과정을 정리할 예정이다.