2022. 3. 2. 13:30ㆍ개발/실습
이번 포스팅도 전체 과정 보다는 발생했던 에러와 해결법을 위주로 작성합니다. 사용했던 Shell Script 및 appspec.xml은 아래의 저장소를 참고바랍니다.
게시판 어플리케이션 배포를 위해 아래와 같은 배포 아키텍쳐를 구성했다.
1. 개발자는 Github 저장소에 소스코드를 Push한다.
2~3. Jenkins에선 Github의 빌드요청이 들어오면 S3에 소스코드를 전달한다.
4. Jenkins에서 CodeDeploy로 배포요청을 한다.
5. CodeDeploy는 S3에 있는 소스코드를 가져온다.
6. CodeDeploy는 EC2에 소스코드를 보내면서 배포명세서(appspec.yml)에 작성된 스크립트를 실행하면서 배포작업을 수행한다.
발생했던 문제점
1. Jenkins 시스템 설정에서 생성한 credential이 Item에서 보이지 않을때
아래처럼 Jenkins의 시스템 설정에서 Github에 대한 연결을 설정했다. 이후 Item을 만들어 아래의 connect-github Credential을 그대로 사용하려고 했는데 Item에선 전혀 조회가 되지 않았다.
Item의 소스 코드 관리 탭에서 직접 별도의 username with password 형태의 credential을 하나 만들어 문제를 해결했다.
Credentials를 확인해봐도 Scope나 domain이 모두 같음에도 Item에서는 Secret Text 형태의 Credential은 조회가 되지 않아 문제의 원인이 무엇인지 구글링 해봤다.
아래의 Stackoverflow의 답변에 따르면 Github의 PAT(Personal Access Token)를 사용하는 Secret text방식의 Credential은 password를 대체할 순 있어도 username과 password를 대체할수 없다고 한다. Jenkins에서 Github의 소스를 가져오려면 username과 password가 필요하기 때문에 Credential을 username with password로 만들라는 뜻.
2. 배포용 EC2에서 발생한 please check if this instance was started with an IAM instance profile. 에러
CodeDeploy에 S3에 대한 Access 권한이 있는 역할을 부여했는데도 배포 EC2에서 아래와 같은 에러가 발생했다. 원인은 배포 EC2에서 CodeDeploy와 S3에 대한 Access 권한을 부여하지 않아서 발생한것. 배포 EC2에 권한을 부여함으로써 문제를 해결했다.
EC2에 역할을 부여 했는데도 같은 에러가 반복된다면 codeDeploy-agent를 재시작하면 된다. IAM변경 전부터 codeDeploy-agent가 실행되어 있으면 변경 사항을 제대로 반영하지 못하는 경우가 있기떄문이다.
3. 배포시 TImeOut이 발생한 경우
EC2의 프리티어는 성능 스펙이 그렇게 높지 않기 떄문에 Gradle Build시 1분 이상 시간이 소모되는 경우가 많다. 이때는 ApplicationStart 단계에서 ScriptTimeOut이 발생할 수 있다.
appspec.xml에서 ApplicationStart의 TimeOut을 300초로 늘려서 문제를 해결했다.
4. 'hibernate_sequence' is not sequence 에러 발생
EC2에 배포를 완료하고 나서 회원가입과 게시글 작성을 하려고하면 'hibernate_sequence' is not sequence 에러가 발생했다. 한참을 고생하면서 찾아봤는데 시퀀스 테이블인 hibernate_sequence의 컬럼 구조가 MariaDB의 시퀀스 테이블의 모습이 아니었다. 회원가입이나 게시글을 작성할때 시퀀스 테이블을 통해 ID를 채번하는데 MariaDB형태의 시퀀스가 아니다 보니까 위와 같은 에러가 발생했던것. 코드 배포전에 Dialect를 설정했었는데 이 과정에서 문제가 있었던것 같다.
hibernate_sequence 테이블을 MariaDB 형태에 맞게 컬럼을 수정해서 문제를 해결했다.
흔한 경우는 아니겠지만 위와 같은 문제는 Test과정에서 걸러졌어야 하는데 Test시에 별도의 H2 DB를 사용하다보니 제대로된 Test 검증이 되지 않았다. 다음번 플젝을 할때는 실제 개발에 사용된 DB에 붙어서 Test를 수행하고 RollBack을 하는 방식으로 Test를 해야할듯하다.
또한 아래 블로그의 포스팅처럼 특별한 케이스가 아니면 Spring Boot가 알아서 Dialect를 선택할 수 있도록 해주는게 좋을 것같다.
그 밖에 참고했던 사이트
Jenkins 설치시 Requires: daemonize 에러가 발생하는 경우
Amazon Linux에 Java를 설치하기
Javac(자바 컴파일러) 설치하기
Amazon Linux에 Git 설치하기
Gradle을 통한 Build시 Plain Jar 생성 방지
View 경로를 찾지 못할때
'개발 > 실습' 카테고리의 다른 글
nginX 무중단 배포 실습 (0) | 2022.03.09 |
---|---|
게시판 실습 복기 (ft. Spring Security, Junit ) (0) | 2022.02.25 |
GraphViz를 통해 함수 호출 그래프 그리기 (0) | 2021.10.13 |