Spring Boot 애플리케이션 배포 #2

park2348190·2021년 4월 30일
0

SimpleBBS

목록 보기
2/3

서론

지난번에 언급한 SimpleBBS 프로젝트를 웹에 배포했다. 언급했듯이 main 브랜치에 자동 배포를 설정해두었기 때문에 develop에서 main으로 Pull Request를 생성, 머지와 동시에 자동으로 배포가 이루어졌다.

본론

첫번째 문제

그런데 처음에는 아래처럼 빌드가 실패했다.

> Task :compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> Could not target platform: 'Java SE 11' using tool chain: 'JDK 8 (1.8)'.

관련 에러를 검색해보니 Gradle, 정확히는 그래들에서 지원하는 자바 버전과 JDK 버전이 호환되지 않아 발생하는 에러였다. 하지만 로컬에서 테스트할 때는 문제없이 작동한 데다 처음보는 에러라서 많이 헤맸는데 이는 Heroku 쪽 설정 문제였다.

일단 Jar 파일로 빌드하는 Spring Boot와 Gradle로 프로젝트가 구성되어 있기 때문에 별도로 WAR 설정이나 그래들 설정 코드를 작성해 줄 필요는 없었다. 그러나 이 SimpleBBS 프로젝트를 생성할 때 자바 버전을 11로 설정했기 때문에 Heroku에서 자바 11을 사용하려면 이 문서처럼 system.properties라는 별도의 설정 파일을 작성해줘야 했다.

java.runtime.version=11

위처럼 자바 버전을 11로 명시한 파일을 프로젝트에 추가하면 Heroku에서는 OpenJDK 11을 이용하여 애플리케이션을 실행하게 된다.

-----> Installing JDK 11... done
-----> Building Gradle app...

...

> Task :build

BUILD SUCCESSFUL in 22s

다시 빌드한 결과 정상적으로 빌드되는 것을 볼 수 있었다.

두번째 문제

그래서 첫번째 문제를 해결한 후 다시 애플리케이션을 실행시켜봤는데 이번에는 애플리케이션이 아예 작동하지도 않았다.
일단 Heroku에서 친절하게 로그를 확인할 수 있는 방법을 알려줘서 명령 프롬프트에 해당 커맨드를 입력한 결과 다음처럼 에러가 발생해서 애플리케이션이 아예 실행조차 안된 것을 볼 수 있었다.
자바의 스택 트레이스가 복잡하게 나열되어 있었지만 그 중 다음과 같은 한 문장이 눈에 띄었다.

2021-04-30T19:02:48.498397+00:00 app[web.1]: Caused by: org.hibernate.HibernateException: Access to DialectResolutionInfo cannot be null when 'hibernate.dialect' not set

프로젝트에서는 Spring Data JPA를 사용하고 있었으며 이는 JPA의 구현체인 Hibernate를 사용하는데 거기서 hibernate.dialect가 설정되지 않았기 때문에 발생하는 문제라고 알리고 있다. 그래서 MariaDB에 대한 dialect를 조사하여 설정 파일(application.properties)에 추가하여 해결할 수 있었다.

spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MariaDBDialect

그런데 기존에 로컬에서 테스트할 때는 따로 dialect를 지정해주지 않아도 잘 동작했는데 왜 이런 것일까? 아무래도 Heroku 환경과 내 로컬 컴퓨터 환경에는 뭔가 차이가 있던 것이라고 추측할 수 밖에 없다.
실제로 로그를 확인해보면 로컬 환경에서는 위처럼 자동으로 dialect를 잡아주는 것을 볼 수 있다. 그러나 서버측 로그에는 이런 과정이 없기 때문에 위처럼 설정 파일에 MariaDB의 dialect를 추가해주면 다음처럼 실행되는 것을 볼 수 있다.

결론

여러가지 시행착오를 거쳐 위처럼 SimpleBBS를 웹에 배포할 수 있게 되었다.

확실히 로컬에서 테스트하는 것과 실제로 배포하는 것은 환경에 따라 여러가지 예상치 못한 문제가 발생할 수 있다는 것을 알게 되는 경험이었다.

실제로 배포하기 전에, 정확히는 외부에 공개할 버전을 배포하기 전에 내부에서만 접근할 수 있는 곳에 먼저 배포한 후 문제가 없으면 외부에도 공개하는 방식으로 프로세스를 바꾸는 것도 고려해봐야 할 것이다.

관련에서 스테이지 서버라는 게 있는데 아마 이와 부합할지도 모른다.

profile
YUKI.N > READY?

관심 있을 만한 포스트

0개의 댓글