[Spring Boot] Travis CI 배포 자동화 (1)

1. Travis CI 배포 자동화

1) CI & CD

코드 버전 관리를 하는 VCS 시스템에 푸시를 하면 자동으로 테스트와 빌드가 수행되어 안정적인 배포 파일 과정을 만드는 과정을 CI (Continuous Integration)라고 지칭하며, 이 블드 결과를 자동으로 운영 서버에 무중단 배포까지 진행되는 과정을 CD (Continuous Deployment)라고 한다.

 

일반적으로 CI만 구축되어 있지 않고, CD도 함께 구축된 경우가 대부분이다. 여러 개발자가 개발한 코드가 합쳐져야 할때마다 병합하는 날짜를 선정하여 코드를 합치는 수작업을 해결하기 위해 등장했다. 이러한 불편함을 해결하고자, 개발자 각자가 원격 저장소에 푸시할 때마다 코드가 병합되고 테스트 코드와 빌드가 자동으로 진행되도록하여 개발에만 집중할 수 있도록 CI가 등장하였고, 서버에 개발자가 수동으로 배포하는 일 없이 자동으로 배포되도록 CD가 등장했다.

 

CI에는 4가지 규칙이 있다. 그 중, 테스팅 자동화는 가장 중요한 규칙으로, 지속적으로 통합하기 위해 완전한 상태임을 보장하기 위한 테스트 코드가 구현되어야 한다.

모든 소스 코드가 살아 있고(현재 실행되고) 누구든 현재의 소스에 접근할 수 있는 단일 지점을 유지할 것

빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용할 수 있게 할 것

테스팅을 자동화하여 단일 명령어로 언제든지 시스템에 대한 건전한 테스트를 수트를 실행할 수 있게 할 것

누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 있게 할 것

2) Travis CI

Travis CI는 깃허브에서 제공하는 무료 CI 서비스이다. 젠킨스는 설치형 CI 도구로, EC2 인스턴스가 필요하며, AWS의 CodeBuild의 경우 빌드 시간만큼 요금이 부과되는 구조이기에 대부분 오픈소스 웹 서비스인 Travis CI를 사용한다.

 

Travis 홈페이지(travis-ci.org/)에서 깃허브 계정으로 로그인한 뒤, 설정창으로 이동하고, 적용할 저장소를 찾아 활성화한다. 활성화가 완료되면 해당 저장소 빌드 히스토리 페이지로 이동해본다.

Travis CI

3) 프로젝트 설정

Travis CI의 상세 설정은 build.gradle과 같은 위치에 .travis.yml 파일을 생성하여 구성한다. yml(YAML) 확장자는 JSON에서 괄호를 제거한 형태로, 사람이 다루기 쉽게 구성되어있다.

어노테이션 및 코드	설명
branches	Travis CI를 어느 브랜치가 푸시될 때 수행할지 지정한다.
cache	Gradle을 통해 의존성을 받게 될 경우, 이를 해당 디렉토리에 캐시하여, 같은 의존성은 다음 배포 때부터 다시 받지 않도록 한다.
script	마스터 브랜치에 푸시되었을 때 수행하는 명령어이다.
notification	Travis CI 실행 완료 시 자동으로 알람이 가도록 설정한다.

language: java
jdk:
  - openjdk8

branches:
  only:
    - master

# Travis CI 서버 홈
cache:
  directories:
    - '$HOME/.m2/repository'
    - '$HOME/.gradle/'

script: "./gradlew clean build"

# CI 실행 완료 시 메일 알람
notifications:
  email:
    recipients:
      - [이메일 주소]

4) Travis CI 빌드 확인

Travis CI 설정 파일을 구성한 후, 마스터에 푸시한뒤, 빌드가 성공한것인지 이메일을 확인한다.

Travis 빌드 확인

5) 전체적인 구조

AWS CodeDeploy에는 저장 기능이 탑재되어있지 않기에, Travis CI가 빌드한 결과물을 받아서 CodeDeploy가 가져갈 수 있도록 보관할 장소인 S3와 연동한다. CodeDeploy는 빌드 및 배포도 가능하나 빌드 없이 배포만 필요한 경우, 대응하기 어렵다. 빌드와 배포를 분리하면 이전에 만든 Jar를 재사용하면 되지만, CodeDeploy가 모든 것을 하게 될 경우 항상 빌드를 하게 되니 확장성이 떨어진다.

전체적인 구조

6) IAM 사용자

AWS의 경우, 외부 서비스가 접근하기위한 권한을 가진 키를 생성하여 사용해야한다. IAM을 통해 Travis CI가 AWS의 S3와 CodeDeploy에 접근할 수 있도록 한다. 이 후, Travis CI에 AWS_ACCESS_KEY, AWS_SECRET_KEY를 변수로하여 발급받은 키 정보를  등록한다.

IAM 사용자

7) S3

JAR 파일을 관리할 S3 서비스를 구성한다. 기본으로 구성하되, 모든 퍼블릭 액세스가 차단되어 있어야 한다.

S3

8) .travis.yml

Travis CI에서 빌드하여 만든 JAR 파일을 S3에 올릴 수 있도록 코드를 추가한다. 추가가 완료되면 깃허브로 푸시하여 자동 빌드를 확인한다.

어노테이션 및 코드	설명
before_deploy	deploy 명령어가 실행되기 전에 수행되며, CodeDeploy는 JAR 파일을 인식하지 못하기 때문에 JAR+기타 설정 파일들을 모아 압축한다.
zip -r [프로젝트명]	현재 위치의 모든 파일을 압축한다. (반드시 본인의 프로젝트 이름이여야 한다.)
mkdir -p deploy	Travis CI가 실행 중인 위치에서 생성한다.
mv [프로젝트명].zip deploy/[프로젝트명].zip	압축파일을 deploy 디렉토리 하위에 이동한다.
deploy	S3 파일 업로드 및 CodeDeploy 배포 등 외부 서비스와 연동될 내용을 작성한다.
local_dir: deploy	deploy 디렉토리를 지정하여 해당 위치의 파일들만 S3로 전송하도록 한다.

...

before_deploy: 
  - zip -r SpringbootProject *
  - mkdir -p deploy
  - mv SpringbootProject.zip deploy/SpringbootProject.zip
    
deploy: 
  - provider: s3
    access_key_id: $AWS_ACCESS_KEY # Travis repo 설정 값
    secret_access_key: $AWS_SECRET_KEY
    bucket: springbootprojectbucket
    region: ap-northeast-2
    skip_cleanup: true
    acl: private # zip 파일 접근 설정
    local_dir: deploy # before_deploy에서 생성한 디렉토리
    wait-until-deployed: true
    
...

.travis.yml

8) IAM 역할

CodeDeploy를 이용하기 전에 배포 대상인 EC2가 CodeDeploy를 연동받을 수 있도록 역할을 추가한다. 이전에 추가한 사용자는 단순히 AWS 서비스외에 사용할 수 있는 권한을 설정하는 장소라면, 역할은 AWS 서비스(EC2, CodeDeploy, S3)에만 할당할 수 있는 권한이다. 역할 설정이 완료되면 EC2 인스턴스에 적용 후 재부팅해준다.

IAM 역할

9) CodeDeploy 에이전트

EC2에 접속하여 에이전트를 설치한다.

// 설치파일 내려받기
aws s3 cp s3://aws-codedeploy-ap-northeast-2/latest/install . --region ap-northeast-2

// 실행 권한 추가
chmod +x ./install

// install 파일로 설치 진행
sudo ./install auto

// 에이전트 동작 상태 확인
sudo service codedeploy-agent status

CodeDeploy 에이전트

루비 언어가 설치안되어 문제가 발생할 경우 루비를 설치해준다.

sudo yum install ruby

10) IAM 역할 추가

CodeDeploy는 권한이 하나이기에 선택 없이 넘아가면 된다.

IAM 역할 추가

---

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