스프링서버 EC2에 배포하기

아키텍쳐 구성

과정

1. 작성한 코드 깃헙에 올리기

2. 깃헙과 트래비스CI를 연동해서 빌드 및 테스트하기

3. 트래비스CI에서 빌드된 파일 S3에 업로드하기

4. codedeploy가 S3에서 빌드파일을 EC2에 배포 및 자동 실행해주기

 

 

1. 작성한 코드 깃헙에 올리기

깃헙 레파지토리를 생성하고 로컬과 연결한 상황에서 시작

- git add -A

- git commit -m "any message"

- git push

 

 

2. 깃헙과 트래비스CI를 연동해서 빌드 및 테스트하기

- 연동하고 싶은 계정으로 트래비스CI에 로그인하자

- 트래비스CI의 settings의 Legacy Service integration에서 연동하고 싶은 레퍼지토리를 선택하자

 

 

(너무나도 놀랍게도 이러면 연동이 끝난다.)

 

- 레파지토리의 최상단에 .travis.yml을 작성하자

 

-- branches only main으로 main으로 커밋된 경우에만 빌드를 진행한다.

-- cache directories : 트래비스CI는 의존 라이브러리 한정으로 캐싱을 지원해 빌드 속도를 개선한다.

-- before_install : 실제 빌드진행은 gradlew이 담당한다. 이때 트래비스CI의 리눅스 환경에서 gradlew의 실행권한이

없는 경우가 있다. 실행 권한을 추가해주자.

 

빌드를 무사히 마친 경우 기분 좋은 녹색화면이 나타난 걸 확인할 수 있다. 다만, 내 경우 테스트가 계속 실패해서 20번 정도 커밋을 했었다.(이때 포기하고 싶었다) 테스트 환경의 application.yml을 잘 작성해주고 문제를 해결했다.

 

 

3. 트래비스CI에서 빌드된 파일 S3에 업로드하기

사실 이 부분부터가 블로그에 정리를 하게 된 주된 이유다. 너무 낯선 작업이고 잊기 쉬우니 잘 복기해보자. 참고로 AWS계정은 이미 만들어둔 상태다.

 

- S3 버킷 생성하기 -> 크게 어렵지 않으니 그냥 잘 만들자

- IAM 사용자 생성하기 :

외부 API 또는 aws서비스 내에서 aws서비스를 이용하고자 할 때 그 권한이 필요하다. 지금은 트래비스CI에서 aws S3에 쓰기 권한을 갖기 위한 IAM을 생성한다.

 

 

우선 프로그래밍 방식으로 체크한다.

다음으로 넘어가 권한설정의 기존정책 직접 연결에서 AmazonS3FullAccess, AwsCodeDeployFullAccess를 체크하자

 

사용자 만들기를 누른 후 생성 된 access key와 password를 꼭 메모해두고 넘어가자

 

- 빌드 완료 후 S3로 업로드할 수 있도록 .travis.yml에 명령 스크립트를 추가하자

깃헙에 푸시하고 S3를 확인해보면 원하는 zip파일이 업로드 된 걸 확인할 수 있다.

참고로 $AWS_ACCESS_KEY는 미리 설정해둔 환경변수인데, 등록하기 매우 쉬우니 넘어가자.

 

 

4. codedeploy가 S3에서 빌드파일을 EC2에 배포 및 자동 실행해주기

이쯤에서 왜 트래비스CI에서 S3에 빌드파일을 업로드하고 codedeploy를 도입해야 했는지를 생각해보자. 이유는 간단하다. 트래비스CI는 정말 딱 빌드 후 업로드까지 하기 때문이다. 아직 공부하진 않았지만 젠킨스는 CI/CD를 모두 지원하는 모양이다.(물론 서버가 별도로 필요하다는 단점) 반면 트래비스CI는 통합에만 열려 있어 배포 자동화는 codedeploy에게 맡겨야 하고, 그 중간 다리 역할을 해줄 저장소가 S3라고 생각하면 된다.(S3에 저장하고 그 파일을 배포환경에 놓고 실행) (참고로 codedeploy를 이용해 EC2에 배표할 때는 비용이 부과되지 않는다)

 

- codedeploy 생성 후 배포그룹을 생성하고 그 그룹에 내가 만든 EC2를 넣자

- .travis.yml에 codedeploy가 처리할 작업을 추가하자

bucket에 S3에서 생성한 bucket을 적어주자

key에는 S3 버킷에 생성된 zip파일의 이름을 적어주자

application에 생성한 codedeploy의 이름을 적어주자

deployment_group에 아까 EC2를 추가한 그룹이름을 적어주자

 

- .travis.yml과 같은 위치에 appspec.yml을 작성하자

위 before_deploy를 보면 미리 작성해둔 deploy.sh를 같이 저장해서 S3로 업로드하는 걸 알 수 있다. 결국 codedeploy를 통해 이 deploy.sh가 실행되게 해서 자동배포 작업을 진행한다.

 

- deploy.sh 작성

다른 내용은 잘 집중하면 이해하기 어려운 내용은 없다. 여기서, jar파일을 실행하는 과정이 어려웠다.  처음 내 코드는 @Value($cloud.key)와 같이 application.yml을 직접 읽어 값을 주입했다. 당연히 jar파일 생성 시(빌드 시) 이 값은 미리 주입된다고 생각했다. 근데 application.yml에는 IAM정보나 DB정보와 같은 민감한 정보가 들어 있었다. 당연히 github에 올릴 때는 application.yml을 ignore해줬다. 근데 어떻게 빌드가 잘 되었을까? 알고보니 설정파일을 읽는 시점은 런타임 시점인 듯하다. 즉, 빌드와는 무관한 파일인 거다. 그래서 서버에 직접 application.yml을 작성하고 스크립트로 실행 시에 둘을 합치는 작업을 하는 것이다.(공부 더필요)

 

 

정리

포스트맨을 이용해 EC2에 배포한 서버에 접근해봤다. 결과는 성공이었고 오랜만에 감동을 느꼈다. 그동안 토비의 스프링을 읽으면서 내공을 쌓는 데 시간을 많이 써서 그런지 눈으로 확인할 수 있는 작업을 하니 좋았다. 4일이라는 시간동안 정말 많은 오류메세지를 만났지만, 그만큼 AWS에 익숙해질 수 있었다. 늘 그렇지만 하기 전에는 너무나도 높아보이는 벽이 막상 오르고 나면 별로 높지 않다고 느낀다.

 

물론 이렇게 가벼운 정도로 배포를 했다고 배포에 득도했다는 건 절대 아니다. 다만, 이제 이 경험을 확장하기는 충분한 것 같다. 혼자했으면 3달 이상 걸렸을 것 같은 작업인데

스프링 부트와 AWS로 혼자 구현하는 웹 서비스

라는 책을 통해 거의 99% 도움을 받았다. 너무 감사하다.