개발하는 감자
[AWS EC2] 테스트 서버 에러 기록 본문
✅ 테스트 서버
API 1차 개발 완료 후, 프론트 분들이 테스트와 함께 개발하실 수 있도록 테스트 서버를 만들어 달라는 요청을 받았다.
많은 클라우드 서비스가 있지만, 시간이 없는 관계로 전에 한번 경험했던 EC2를 사용해 테스트 서버를 배포했다.
( 그때의 수많은 시행착오를 기억하지 못했다.. )
서버는 그냥 간단하게 EC2에 Nginx를 설치해 배포했고 80번 포트로 요청했을 때, spring 서버인 8080포트로 연결되도록 설정해 주었다.
✅ 과정, 시행착오
1. 먼저, EC2를 만들고, ssh 를 통해 연결해 주었다.
이 과정은 예전 수업 자료를 통해 해주었고, ssh 연결 도중
WARNING UNPROTECTED PRIVATE KEY FILE
권한이 너무 많이 열려있어 발생하는 에러로, 해당 블로그를 참고해 해결해 주었다.
2. ssh 연결 후, spring 파일을 불러오기 위해 git clone을 이용해 불러왔다.
이후의 과정은 해당 블로그를 참고해 진행했다.
3. sudo ./gradlew build
환경 : java 19 설치, gradle을 Test 제외 명령어 실행을 위해 sudo apt install gradle ( 이때 이렇게 대충 설치하면 안 됐었다..! ) 로 설치
- gradlew build 후에 에러들
1. command not found, permission denied
command not found로 에러가 발생해 해당 명령어에 관해 설치를 해줘야 하는 줄 알았는데, 권한이 없어 나오는 에러였다.
해당 블로그에 나온 명령어를 통해 해결했다.
2. 무한 로딩
처음에는 무한 로딩을 서버 종료 후 다시 키는 방안으로 해결해 진행을 했는데, 후에는 이러한 방식으로도 진행이 되지 않아 해결 방법을 찾아보았다. 프리티어 사용 시에 메모리 부족으로 인해 자주 발생하는 경우라고 한다.
https://sundries-in-myidea.tistory.com/102
해당 블로그를 통해 해결 후, 무한 로딩 현상은 없어졌다.
3. 잘못된 자바 버전 설치
프로젝트에 쓰인 자바가 17 이었는데, 19 버전으로 자바를 설치해 오류가 나타났다.
해당 글을 참고해 자바 19 삭제 후, 자바 17 버전으로 다시 깔아주었다.
프로젝트에 사용된 자바 버전은 build.gradle에서 확인할 수 있다.
자바 버전 확인을 intellij 설정에 project structure에서 진행했는데, 버전 확인을 잘못된 방법으로 한 것 같다.
버전 오류 때문에 해당 오류도 발생한 것 같다.
no locally installed toolchains match and toolchain download repositories have not been configured.
java.io.FileNotFoundException: /home/ubuntu/Backend/.gradle/8.8/fileHashes/fileHashes.lock (Permission denied)
→ 이 오류의 경우에는 검색했을 때 gradle 파일의 권한을 변경하라는 해결 방법을 보았었는데, 자바 버전이 맞지 않아서 이거나, gradle 버전이 맞지 않아서 발생했던 것 같다.
4. Test 코드 오류 (aws Execution failed for task ':test')
test 관련 오류가 뜨는 것 같아 Test 관련 코드를 제외하고 빌드 하는 명령어가 참고해 진행하던 블로그에 명시되어 있어, 해당 명령어를 실행했다.
하지만 이 명령어 또한 오류가 발생했다.
처음에는 org.springframework.boot.autoconfigure.jdbc.DataSourceProperties$DataSourceBeanCreationException at DataSourceProperties.java:186
오류를 보고 Database 연결이 되지 않아 생긴 문제 같아 mysql 서버를 설치하고, 프로젝트에 맞는 스키마와 테이블을 만들어줬다.
mysql 설치는
https://noanomal.tistory.com/328
해당 블로그를 참고해 진행했다.
하지만 mysql 설치 후에도 해결되진 않았다.
다음으로는 gradle의 버전을 프로젝트에 맞게 재설치 해주었다.
해당 에러가 발생했는지 확실하진 않지만, 테스트 제외 명령어에서 발생한 오류도 gradle의 버전을 바꾸니 해결이 됐다.
Could not create service of type PluginResolutionStrategyInternal using BuildScopeServices.createPluginResolutionStrategy().
→ gradle 버전과 자바 버전이 맞지 않아 발생한 오류인 것 같다.
sudo apt install gradle 명령어를 통해 gradle을 설치했는데, 이를 통해 설치되는 버전은 4.4.1 이라고 한다.
먼저 프로젝트에 설치된 gradle의 버전을 확인하기 위해
프로젝트 폴더 > gradle > gradle-wrapper-properties 에서 gradle의 버전을 확인해 주었다.
다음으로 이 블로그를 참고해 설치했던 gradle을 모두 삭제해 주었다.
https://velog.io/@coral2cola/Ubuntu-%ED%8C%A8%ED%82%A4%EC%A7%80-%EC%82%AD%EC%A0%9C%ED%95%98%EA%B8%B0
다음으로 이 블로그를 참고해 맞는 버전으로 설치를 다시 해주었다.
→ 성공적으로 명령어가 잘 실행됐다..!
5. contextLoads() FAILED
test 코드를 제외하고 나서는 빌드가 잘 실행될 줄 알았는데, 또 다른 에러가 발생했다.
이때 당시에 빨리 테스트 서버를 올려 프론트 분들께 전달을 드렸어야 하는 상황이라, 해당 오류는 해결할 생각을 하지 못하고 다른 방식으로 서버를 배포했다.
다시 구글링을 해보니 세부 오류까지 같은 블로그를 찾았는데,
https://soobysu.tistory.com/118
SpringBootTest 어노테이션 설정을 추가해 주면 해결되는 것 같다..!
분명 Test 코드를 제외하고 빌드를 했는데 왜 이 부분에서 에러가 났는지는 모르겠다..
4. gradlew build를 로컬에서 진행 후에 실행 파일을 EC2로 전송
EC2에서 git clone을 해서 코드를 가져오는 게 gitignore된 파일들 때문에 자잘한 에러가 나는 것 같아서, 로컬에서 빌드 진행 후에 실행파일을 전송하는 방식으로 진행하기로 다시 결론지었다.
로컬에서 빌드 할 때도 에러가 발생했는데, 테스트 코드 관련 에러인 것 같아 테스트 코드를 아예 삭제 후에 다시 빌드 해 주었더니 바로 빌드를 성공했다.
해당 실행 파일을 EC2로 scp를 사용해 전송을 해주면 된다.
scp 사용을 위해 참고한 블로그이다.
한번 permission denied 가 떴는데, ec2 public ip 를 잘못 설정해 주어 발생한 에러였다.
5. 전송이 끝난 후에는 nginx 설치, 리버스 프록시 설정을 해주었다.
https://yewon-lee.tistory.com/entry/AWS-Spring-Boot3-EC2-%EB%B0%B0%ED%8F%AC
해당 과정을 위해 참고한 블로그이다.
6. 실행 파일 실행, 포스트맨에서 API 호출해 보기
잘 호출되는 것을 확인할 수 있었다..!
처음 호출했을 경우에는
Failed to parse multipart servlet request 에러가 발생했는데, 해당 api에서는 multipartfile이 전송되고 있지도 않았고, 코드에서도 선언은 되어있었지만 쓰이는 부분은 없었다.
찾아보니 multipart 설정과 관련된 에러 같았고, 설정해 준 파일을 확인해 보니
spring.servlet.multipart.location = /
임시 폴더를 지정해 주는 설정에서 / 으로 지정되어 있었다.
해당 경로에서는 파일을 생성하지 못하도록 권한이 설정되어 있다. 따라서 경로를 /home/temp로 바꿔주니 잘 실행이 되었다.
7. 터미널이 꺼져도 실행파일이 실행되도록 nohup으로 실행
실행파일을 실행시킨 채로 터미널을 계속 둘 수도 없었기에, nohup으로 실행해 터미널이 꺼져도 서버가 실행되는 동안 해당 파일이 실행되도록 했다.
https://computing-jhson.tistory.com/126
실행 방법이 설명되어 있는 블로그이다.
✅ 깨닫게 된 점
항상 클라우드 서버를 통해 배포할 경우에는 로컬과 환경을 맞춰주어야 한다는 사실을 기억하고 있어야 할 것 같다.
버전 문제로 생긴 에러들이 너무 많고, 빼앗긴 시간이 너무 많아 처음부터 버전 확인을 철저하게 하고 설치를 해주어야 할 것 같다.
'프로젝트 > Tripture' 카테고리의 다른 글
[카카오 로그인 API] 401 Unauthorized: [no body] 에러 (0) | 2024.07.15 |
---|