내가 만든 토이프로젝트를 AWS 를 통해서 EC2 에서 접속하는 것 까지 완료했다. 이어서 수동으로 빌드와 테스트했던 것을 자동화 시켜보자,
즉 배포를 자동화 해보자
TravisCI & AWS CodeDeploy로 배포 자동화 구축하기
CI - Continuous Integration, 지속적인 통합
코드 버전 관리를 하는 VCS 시스템에 PUSH가 되면 자동으로 Test, Build가 수행되고 Build 결과를 운영 서버에 배포까지 자동으로 진행되는 이 과정을 CI (지속적 통합)이라고 합니다.
CI의 4가지 규칙
- 모든 소스 코드가 살아있고(현재 실행되고) 어느 누구든 현재의 소스를 접근할 수 있는 단일 지점을 유지할 것
- 빌드 프로세스를 자동화시켜서 어느 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용할 수 있게 할 것
- 테스팅을 자동화시켜서 단일 명령어를 통해서 언제든지 시스템에 대한 건전한 테스트 수트를 실핼할 수 있게 할 것
- 누구나 현재 실행 파일을 얻으면 지금까지 최고의 실행파일을 얻었다는 확신을 하게 만들 것
여기서 중요한것은 테스팅을 자동화한다는 것입니다.
지속적으로 통합하기 위해선 무엇보다 이 프로젝트가 완전한 상태임을 보장하기 위해 테스트 코드가 구현되어야 한다는 것입니다.
우리는 TravisCI 를 사용할 것입니다.
Travis는 지나가다 라는 의미로 검색해보니 관문 지킴이나 다리의 통행료 징수원을 위한 이름 이라고 합니다.
또한 TravisCI는 GitHub에서 제공하는 무료 툴 이라고 합니다.
TravisCI에 들어가서 회원가입하고 Repository를 활성화시킨 모습입니다.
TravisCI가 빌드&테스트와 인식을 하기위해서는 .travis.yml 파일이 필요합니다. 이때 이 파일의 위치는 build.gradle과 동일선에 위치하게합니다.
.travis.yml
language: java
jdk:
- openjdk8
branches:
only:
- main #오직 main 브랜치에서 push 될때만
# Travis CI 서버의 Home
#Gradle을 통해 의존성을 받게 되면 이를 해당 디렉토리에 캐시하여, 같은 의존성은 다음 배포때부터 다시 받지 않도록 설정합니다.
cache:
directories:
- '$HOME/.m2/repository'
- '$HOME/.gradle'
#master 브랜치에 PUSH 되었을때 수행하는 명령어입니다.
#여기선 프로젝트 내부에 둔 gradlew을 통해 clean & build 를 수행합니다
script: "./gradlew clean build"
# CI 실행 완료시 메일로 알람
notifications:
email:
recipients:
- qkrtprjs456@gmail.com
#travis 확인4코드는 제가 공부하고있는 블로그에서 가져왔고 각각 코드의 의미는 주석처리해놓았습니다.
알아보니
before_install, before_build와 같은 다른 의미를 갖는 코드도 많았지만 일단 위에있는 코드로 진행해본 후에 적용시켜보자
코드를 작성하고 커밋후 푸쉬 해주고 확인해봤는데
라는 오류가 발생했다 해석해보면 권한 거부됨 뜻이다. gradlew 를 실행시키는 권한이 없어서 발생한 오류라는 생각이 들어서
before_install:
- chmod +x gradlew라는 코드를 추가해주었다 설치전에 실행권한을 주는 코드다.
수정후 다시 진행해보면
올바르게 성공한 것을 확인할 수 있다 다음 진행하자!
AWS Code Deploy 연동하기
테스트와 빌드를 자동화시켯따면 이번에는 배포까지 자동화를 시켜보자
배포를 자동화시키기위해서는 AWS Code Deploy를 사용하자
AWS Code Deploy 까지 적용시키면 전체 구조는
이렇게 됩니다!
실제 배포는 AWS CodeDeploy라는 서비스를 이용하지만 Jar 파일을 전달하기위해서 S3이 먼저 필요합니다.
CodeDeploy는 저장 기능이 없기때문에 TravisCI가 빌드한 결과를 CodeDeploy가 가져갈 수 있게 S3의 공간을 사용합니다.
추가로 CodeDeploy에서 빌드와 배포를 한번에 할 수 있지만 빌드없이 배포만 필요한 경우를 대응하기 어렵다. 한번에 처리한다면 배포를 할때마다 빌드를 해줘야되므로 확장성이 떨어진다. 그래서 빌드와 배포는 분리하는 것을 추천한다.
우선 적으로 Travis CI와 AW3를 연동시켜야한다.
AWS서비스는 외부에서 사용할 수 없으므로 사용할 수 있게 권한을 갖는 key를 생성한다.
Travis CI가 사용할 수 있는 AWS Code Deploy용 계정을 하나 추가하겠습니다.
AWS에서 IAM 가서 사용자 추가
Travis CI에 키등록
Travis CI 해당 repository 설정에서 환경변수에 AWS에서 사용자 추가로 만들어놓은 키값 추가
S3 버킷 생성
simple storage service - 순수하게 파일들을 저장하고 접근 권환을 관리, 검색 등을 지원하는 파일 서버의 역할
파일 서버의 역할을 하기때문에 Travis CI에서 생성된 build 파일을 저장하기위해 구성
Travis CI -> S3 -> AWS CodeDeploy
AWS 들어가서 S3의 버킷을 생성
S3를 완성했기때문에 배포 파일을 S3로 전달
travis CI에서 빌드하여 만든 JAR 파일을 S3에 올릴 수 있도록
.travis.yml 코드 수정
language: java
jdk:
- openjdk8
branches:
only:
- main #오직 main 브랜치에서 push 될때만
# Travis CI 서버의 Home
#Gradle을 통해 의존성을 받게 되면 이를 해당 디렉토리에 캐시하여, 같은 의존성은 다음 배포때부터 다시 받지 않도록 설정합니다.
cache:
directories:
- '$HOME/.m2/repository'
- '$HOME/.gradle'
#master 브랜치에 PUSH 되었을때 수행하는 명령어입니다.
#여기선 프로젝트 내부에 둔 gradlew을 통해 clean & build 를 수행합니다
before_install:
- chmod +x gradlew
script:
- ./gradlew clean build
before_deploy:
#deploy 명령이 실행되기 전에 수행, CodeDeploy는 Jar파일은 인식하지 못하기때문에 Jar+ 기타 설정 파일을 하나로 압축
- zip -r springboot-webservice * #현재 모든 파일을 압축
- mkdir -p deploy #deploy라는 파일을 Travis CI 가 실행중인 위치에 생성
- mv springboot-webservice.zip deploy/springboot2-webservice.zip
#압축한 파일을 deply/ 밑으로 이동
#S3로 파일 업로드 혹은 CodeDeploy로 배포 등 외부 서비스와 연동될 행위들을 선언
deploy:
- provider: s3
access_key_id: $AWS_ACCESS_KEY #Travis Repo에 설정된값
secret_access_key: $AWS_SECRET_KEY
bucket: springboot-webservice-deploy #만들어놓은 S3 버킷
region: ap-northeast-2
skip_cleanup: true
acl: private
local_dir: deploy #해당 위치 파일을 S3로 전송
wait-until-deployed: true
# CI 실행 완료시 메일로 알람
notifications:
email:
recipients:
- qkrtprjs456@gmail.comSkipping a deployment with the s3 provider because this branch is not permitted: main 오류 발생
main에서 허용하지 않는다는 오류 발생
.travis.yml에
on: all_branches: true #해당 라인 추가모든 브런치에게 권한을 허용한다는 코드 추가
정상적으로 S3의 버킷으로 이동!
