이 글은 '스프링부트와 AWS로 혼자 구현하는 웹 서비스 - 이동욱(jojoldu)'을 공부하며 작성한 글로 생략된 내용은 책을 구매해서 확인하는 것을 권장합니다.
참고 소스코드 깃허브 https://github.com/jojoldu/freelec-springboot2-webservice
http://www.yes24.com/Product/Goods/83849117
스프링 부트와 AWS로 혼자 구현하는 웹 서비스 - YES24
가장 빠르고 쉽게 웹 서비스의 모든 과정을 경험한다. 경험이 실력이 되는 순간!이 책은 제목 그대로 스프링 부트와 AWS로 웹 서비스를 구현한다. JPA와 JUnit 테스트, 그레이들, 머스테치, 스프링
www.yes24.com
이 책의 9장에 해당하는 Travis CI 배포 자동화 과정 중 Travis CI와 프로젝트, Travis CI와 AWS S3 연동 과정을 정리한 글이다.
24시간 365일 운영되는 서비스에서 배포 환경 구축은 필수다.
개발자의 코드가 실시간으로 병합되고, 테스트가 수행되는 환경, master 브랜치가 푸시되면 배포가 자동으로 이뤄지는 화경이 되어야 한다.
CI / CD
8장에서 프로젝트를 EC2에 배포했는데, 이때 스크립트를 개발자가 직접 실행해주어야 했었다.
이를 개선하기 위해 CI / CD 환경을 구축한다.
CI (Continuous Integration)
- 지속적 통합, 코드 버전을 관리하는 VCS 시스템(Git, SVN 등)에 푸시가 되면 자동으로 테스트와 빌드가 수행되어 안정적인 배포 파일을 만드는 과정
CD (Continuous Deployment)
- 지속적인배포, 위 빌드 결과를 자동으로 운영 서버에 무중단 배포까지 진행되는 과정
보통 CI와 CD가 함께 구축된다.
CI / CD 등장 배경
현재 웹 서비스는 하나의 프로젝트를 여러 개발자가 함꼐 개발을 진행한다.
그렇기에 각자가 개발한 코드를 합쳐야 할 때마다 큰 일 -> Merge하는 날을 정해 합지는 일만 진행 -> 생산성 감소
이 문제를 해결하기 위해 지속해서 코드가 통합되는 환경 - CI 구축
수 십, 수 백 대의 서버에 수동으로 배포 불가능 -> 지속적인 배포 CD 구축
* 주의할 점: CI 도구 도입이 Ci를 하고있다는 의미는 아니다.
CI 4가지 규칙 https://www.martinfowler.com/articles/originalContinuousIntegration.htm
- 모든 소스 코드가 실행될 수 있고, 누구든 현재의 소스에 접근할 수 있는 단일 지점을 유지할 것
- 빌드 프로세스를 자동화해서 누구든 빌드하는 단일 명령어를 사용할 수 있게 할 것
- 테스팅을 자동화해서 단일 명령어로 언제든지 시스템에 대한 테스트를 실행할 수 있게 할 것
- 누구나 현재 실행파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것
가장 중요! -> 테스팅 자동화 (프로젝트가 완전한 상태임을 보장하기 위해 테스트 코드 구현 필수)
Travis CI 연동
Travis CI
- 깃허브에서 제공하는 무료 CI 서비스
1. Travis CI 웹서비스 설정
https://www.travis-ci.com/에 깃허브 계정으로 로그인 후 프로젝트 선택 CI 활성화
2. 프로젝트 설정
Travis CI의 상세한 설정은 프로젝트에 존재하는 .travis.yml 파일로 할 수 있다.
yml 파일 확장자 - YAML(야믈)이라고 한다.
YAML - JSON에서 괄호를 제거한 것
2-1. 프로젝트의 build.gradle과 같은 위치에 .travis.yml 생성
language: java
jdk:
- openjdk11
branches:
only:
- main
# Travis CI 서버의 Home
cache:
directories:
- '$HOME/.m2/repository'
- '$HOME/.gradle'
script: "./gradlew clean build"
# CI 실행 완료시 메일로 알람
notifications:
email:
recipients:
- 본인이메일- bracnches: Travis CI를 어느 브랜치가 푸시될 때 수행할 지 지정 (나는 main 브랜치라 main으로 작성)
- cache: 그레이들을 통해 의존성을 받게 되면 이를 해당 디렉토리에 캐시 -> 같은 의존성은 다음 배포때부터 다시 받지 않음
- script: main 브랜치에 푸시되었을 때 실행할 명령어
- notifications: Travis CI 실행 완료시 알람이 가도록 설정
2-2. 작성한 파일 main 브랜치에 커밋과 푸시하기
푸시했으나 Travis CI 반응없는 문제 발생
Travis CI를 들어가면 아래와 같은 문구가 뜨는데, plan 사용자 수가 초과했다고 나온다.
책이 나온 때와 달리 지금은 free plan을 선택해서 결제 카드를 등록하면 10k credit을 제공해주는 방식으로 바뀌었다.
크레딧을 다 사용하고 나면 상위 플랜으로 바꿔주어햐 한다고 한다.
plan 가입 후 카드로 1달러가 결제되는데, 이는 수 일이 지나면 자동으로 취소된다.
setting -> plan 에서 plan 선택 및 카드 등록 진행
다시 .travis.yml 파일을 커밋푸시해주면
실패한다.
graldew에 권한을 부여하지 않아서 실행을 못 시키고 있다. 권한을 추가한다.
# 빌드 전 gradlew 권한 추가
before_install:
- chmod +x gradlew
다시 .travis.yml 파일을 푸시하고 나서 잠시 후에 보면 (빌드 결과가 나오는데 약간의 시간이 필요)
성공했다!
이제 travis CI와 프로젝트 연동이 완료되었다.
Travis CI와 AWS S3 연동
S3
- AWS에서 제공하는 일종의 파일서버
- 정적파일 관리 및 배포 파일 관리 등의 기능 지원
- 보통 이미지 업로드시 이용
Travis CI 연동시 구조
출처: AWS와 스프링 부트로 혼자 구현하는 웹 서비스
실제 배포는 AWSCodeDeploy라는 서비스를 이용하지만, S3 연동이 먼저 필요한 이유는 Jar 파일 전달을 위해서다.
CodeDeploy에는 저장 기능이 없기 때문에, Travis CI가 빌드한 결과물을 받아 CodeDeploy가 가져갈 수 있게끔 보관해줄 공간이 필요 -> AWS S3를 사용
* CodeDeploy는 빌드, 배포 모두 가능하지만 빌드와 배포는 분리하는 것을 추천
-> 빌드와 배포를 다 CodeDeploy가 한다면 배포만 필요시 대응하기 어렵고, 사용할 때마다 항상 빌드를 해줘야 하기 때문에 확장성이 떨어진다.
1. AWS Key 발급
AWS 서비스에 외부 서비스가 접근하기 위해 접근할 수 있는 권한을 가진 Key가 필요하다.
책과는 방식이 조금 다르다.
IAM(Identity and Access Management)
- AWS에서 제공하는 서비스의 접근 방식과 권한을 관리하는 도구
IAM을 사용해 외부 서비스인 Travis CI가 AWS의 S3와 CodeDeploy에 접근할 수 있게 해줘야 한다.
AWS 웹콘솔 -> IAM -> 왼쪽 사이드바 사용자 -> 사용자 추가
사용자 세부 정보 지정
사용자 이름 - springboot-travis-deploy
책과 다르게 액세스 유형으로 프로그래밍 방식 액세스로 선택하는 부분이 없어서 밑줄 친 문구를 확인하고 IAM 사용자 생성으로 진행했다.
권한설정
직접 정책 연결, 권한 정책 s3full, codedeployf 검색해서 선택
이 프로젝트에서는 S3와 CodeDeploy를 합쳐서 관리한다.
검토 및 생성
태그로 Name 값으로 사용자 이름을 작성해서 추가했다.
권한 요약
1-2. 생성된 사용자 이름 클릭 -> 보안 자격 증명 -> 액세스 키만들기 -> CLI 선택
공부용으로 진행하는 거라 설명 태그를 springboot라고 했다. 안해도 문제없다.
액세스 키가 생성되면 .csv 파일을 다운로드 받는다.
화면을 나가면 확인이 어려우니 꼭 파일을 다운받아 보관하자. 분실할 경우에는 새 액세스 키를 발급받아야 한다.
2. Travis CI 등록
Travis CI 설정 화면 More options -> setting -> 키 등록
아래로 내리면 Environment Vatiables
액세스키와 비밀 액세스 키를 추가한다.
NAME: AWS_ACCESS_KEY, VALUE: 액세스키
NAME: SECRET_KEY, VALUE: 비밀액세스키
여기에 등록해둔 키는 .travis.yml에서 $AWS_ACCESS_KEY, $AWS_SECRET_KEY라는 이름으로 사용 가능하다.
다음으로 이 키를 사용해서 Jar 파일을 관리할 S3 버킷을 생성해야 한다.
3. S3 버킷 생성
S3는 파일들을 저장하고 접근 권한을 관리,검색등을 지원하는 파일서버의 역할을 한다.
ex) 게시글에 첨부파일 등록 구현하는 경우
Travis CI에서 생성된 Build파일을 S3에 저장되도록 구성해야 한다.
저장된 Build 파일은 이후 AWS의 CodeDeploy에서 배포할 파일로 가져가도록 구성될 예정!
3-1. AWS -> S3 검색 후 이동 -> 버킷만들기 -> 웒하는 버킷명 작성
버킷명은 배포할 Zip 파일이 모여있는 장소라는 의미로 짓는 것을 추천한다고 한다.
3-2. 아래로 가서 모든 퍼블릭 액세스 차단을 체크한다.
Jar 파일이 public일 경우 액세스를 차단하지 않으면 누구나 나 내려받을 수 있게 되버린다. (코드, 설정 값, 주요키값 등)
이 프로젝트를 private로 했더라도 액세스를 차단하지 않으면 IAM 사용자로 발급받은 키를 사용시 접근이 가능해진다.
S3 생성이 끝났다.
.travis.yml 코드 추가
Travis CI가 빌드한 결과물(Jar 파일)을 S3에 올릴 수 있도록 코드를 추가한다.
language: java
jdk:
- openjdk11
branches:
only:
- main
# 빌드 전 gradlew 권한 추가
before_install:
- chmod +x gradlew
# Travis CI 서버의 Home
cache:
directories:
- '$HOME/.m2/repository'
- '$HOME/.gradle'
script: "./gradlew clean build"
before_deploy:
- zip -r springboot-webservice *
- mkdir -p deploy
- mv springboot-webservice.zip deploy/springboot-webservice.zip
deploy:
- provider: s3
access_key_id: $AWS_ACCESS_KEY # Travis repo settings에 설정된 값
secret_access_key: $AWS_SECRET_KEY # Travis repo settings에 설정된 값
bucket: springbootweb-build # S3 버킷
region: ap-northeast-2
skip_cleanup: true
acl: private # zip 파일 접근을 private으로
local_dir: deploy # before_deploy에서 생성한 디렉토리
wait-until-deployed: true
# CI 실행 완료시 메일로 알람
notifications:
email:
recipients:
- 본인이메일- before_deploy: deploy 명령어가 실행되기전에 수행, CodeDeploy는 Jar 파일은 인식하지 못하기 때문에 Jar+기타 설정 파일들을 모아 압축한다.
- zip -r 프로젝트이름: 현재 위치의 모든 파일을 프로젝트이름으로 압축한다.
- mkdir -p deploy: deploy라는 디렉토리를 Travis CI가 실행중인 위치에서 생성한다.
- mv 프로젝트이름.zip deploy/프로젝트이름.zip: 프로젝트이름.zip 파일을 deploy/프로젝트이름.zip으로 이동시킨다.
- deploy: S3로 파일 업로드 혹은 CodeDeploy로 배포 등 외부 서비스와 연동될 행위들 선언
- local_dir: deploy
- 앞에서 생성한 deploy 디렉토리를 지정, 해당 위치의 파일들만 S3로 전송한다.
수정된 .travis.yml 파일을 깃허브로 푸시
푸시 후 Travis CI에서 Could not parse 에러가 발생했다면 문법 오류가 있었다는 말이다.
https://www.yamllint.com/로 들어가서 코드를 복붙하고 GO를 누르기 추천!
어느 부분의 문법에 잘못되었는지를 보여준다.
푸시하면 S3 버킷에 파일이 업로드된다!
하지만 나는 올라가지 않았다..
Travis CI에서 빌드 로그를 보니
내 브랜치가 main이기 때문에 업로드하지 않았다고 나온다.
travis가 기본적으로 deployment를 master 브랜치에서 가능하도록 하고 있기 때문에 발생하는 문제라고 한다.
main도 가능하도록 수정한다.
.travis.yml 파일
밑줄 친 부분을 추가하고 다시 깃허브에 푸시한다.
Travis CI에 들어가서 로그를 보면 성공
S3 버킷에도 업로드 성
'스프링부트와 AWS로 혼자 구현하는 웹서비스' 카테고리의 다른 글
| 24시간 365일 중단 없는 서비스 - 무중단 배포 (0) | 2023.04.17 |
|---|---|
| Travis CI 배포 자동화 - Travis CI와 AWS S3, CodeDeploy 연동 (0) | 2023.04.13 |
| EC2 서버에 프로젝트 배포하기 - 스프링부트 프로젝트로 RDS 접근 및 EC2에서 소셜 로그인 (0) | 2023.03.29 |
| EC2 서버에 프로젝트 배포하기 - EC2에 프로젝트 Clone 및 배포 스크립트 작성(외부 Security 파일 등록) (0) | 2023.03.27 |
| AWS에 데이터베이스 환경 구축 - 내 PC에서 RDS 접속과 RDS와 EC2의 연동 확인 (0) | 2023.03.15 |
댓글