[혼자 구현하는 웹서비스] 9-1. 코드가 푸시되면 자동으로 배포해 보자 - Travis CI 배포 자동화 (1)

*이 글은 '스프링 부트와 AWS로 혼자 구현하는 웹 서비스' (프리렉, 이동욱 저) 를 공부하며 내용을 정리한 글입니다.

*내용을 따라가며 쓴 글이라 책과 흐름이 겹칠 수 있으나, 최대한 내용을 이해한 후 저의 글로 옮겼습니다.

*이 글은 8-1. EC2 서버에 프로젝트를 배포해 보자 (MariaDB)에서 이어집니다.

 

0. 개요

1. CI & CD 소개

2. Travis CI 연동하기

3. Travis CI와 AWS S3 연동하기

 

0. 개요

앞서 우리의 프로젝트를 EC2 서버에 배포해 보았다. 이걸로 끝인가? 아니다.

실제 현업에서 운영되는 프로젝트는 배포가 끝이 아니라 시작이다. 수많은 내용 변경과 이슈가 있을 것이고, 이를 수정하여 다시 배포하는 과정을 반복하게 된다.

이를 매번 직접 하는 것은, 개발자의 입장에서 매우 번거로운 일이다. 다행히 이를 자동으로 진행되도록 구성할 수 있다.

배포 자동화라고 하는데, GitHub와 같은 형상 관리 툴에 commit하면 바로 반영되는 것이다. Travis CI, Jenkins 등의 배포 자동화 툴이 존재한다.

1. CI & CD 소개

앞서 말한 배포 자동화를 이해하기에 앞서, CI & CD 개념에 대해 이해하고 가도록 하자.

CI는 continuous integration의 약자이다. 번역하자면 '끊임없는 병합'이라고 할 수 있겠다.

CI란, Git와 같은 코드 버전 관리를 하는 시스템에 push를 하면, 자동으로 테스트와 빌드가 수행되도록 하여, 안정적인 배포 파일을 만드는 과정을 의미한다.

CD는, continuous deployment의 약자이다. '끊임없는 배포' 라고 할 수 있다.

즉, CI를 통해 얻은 빌드 결과를 자동으로 운영 서버에 무중단 배포까지 진행되는 과정을 CD라고 한다.

 

이게 왜 중요할까?

지금처럼 혼자 만들고 혼자 진행하는 프로젝트라면 사실 크게 중요하지 않다.

좀 귀찮지만, 변경한 내역을 push하고, 직접 테스트와 빌드를 수행한 후, 배포하면 된다.

하지만 현업에서 과연 단 1명이 웹 서비스를 개발 및 운영하는 경우가 있을까? 없진 않겠지만, 거의 없을 것이다.

여러 개발자가 함께 개발하고 운영하는 웹 서비스에서, 각자 작성한 코드를 합치고, 테스트하고, 빌드하는 것은 쉬운 일이 아니다. 잘못하면 코드 병합 중 꼬이는 경우가 생길 수도 있고, 빌드 중에 문제가 생길 수도 있다.

하지만 이 과정을 매 push마다 알아서 수행되도록 자동화 한다면?

개발할 때 가장 좋은 것은 개발만 하는 것이다. CI는 이것을 추구하는 개념이라고 할 수 있다. 알아서 테스트 및 빌드가 되니까, 개발에만 집중할 수 있다.

 

CD의 경우도 마찬가지이다. 현업에서, 웹 서비스의 규모가 커지면, 수십, 수백 대의 서버에 배포를 하게 된다. 마찬가지로 이것 역시 매번 직접 하는 것은 가능은 하지만, 별로 하고 싶은 일은 아니다.

이것 역시 자동으로 진행되면 그만큼 개발에 집중할 수 있을 것이고, CD는 이를 충족하기 위한 개념이다.

 

2. Travis CI 연동하기

Travis CI는 GitHub에서 제공하는 오픈 소스 무료 CI 서비스이다.

무료라는 것 외에 가장 큰 장점은, 별도의 설치가 필요 없다는 점이다. 앞서 언급한 Jenkins는 설치형이므로, 우리와 같은 작은 프로젝트에서 도입하기에는 약간 부담이 되는 것이 사실이다.

 

https://travis-ci.com 에 접속하고 GitHub 계정으로 로그인을 하자.

 

접속 후, GitHub Integration을 선택하자.

요금 선택을 하라고 나오는데, 가장 왼쪽의 Free Trial을 선택하면 된다.

이후 아래와 같은 화면을 볼 수 있다.

Trial Plan을 선택하고, 결제 정보 등 필요한 정보를 입력하자. 무료 플랜이므로 실제로 결제가 진행되지는 않는다.

VAT ID의 경우 간단하게 test를 입력해도 된다.

 

우측 상단의 프로필을 클릭하고, settings로 들어간다.

Activate GitHub Apps... 를 클릭하고, 아래와 같은 화면을 볼 수 있다.

 

Only select repositories를 선택하고, 우리의 프로젝트를 선택한 후 아래의 Approve & Install을 눌러 주자.

 

아래처럼 프로젝트 저장소가 보이면 된다.

이러면 travis ci 사이트에서의 설정은 끝이다.

 

상세한 설정은 우리의 프로젝트 내에서 설정할 수 있다.

.travis.yml 파일을 생성하고, 설정 내용을 작성하면 된다.

 

build.gradle과 같은 디렉토리에 .travis.yml을 생성한 후, 아래와 같이 입력하자.

 

language: java
jdk:
  - openjdk8

branches:
  only:
    - master

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

script: "./gradlew clean build"

#CI 실행 완료 시 메일로 알림
notifications:
  email:
    recipients:
      - '실행 시 알림을 받을 이메일 주소'

 

설정을 완료하였으면, git에 push한 후 Travis CI 페이지를 확인해 보자.

 

웹사이트 내에서 작업이 Queued -> Building 으로 진행되며 위와 같이 변한다.

빌드가 완료되면 위와 같은 화면을 볼 수 있고, 이메일을 받을 수 있다.

 

이메일에는 빌드 결과 및 커밋 메세지가 포함되어 있다.

 

3. Travis CI와 AWS S3 연동하기

AWS의 S3은 일종의 파일 서버이다. 정적 파일 (이미지, 첨부파일 등)을 관리하거나, 방금처럼 배포 파일을 관리하는 등의 기능을 지원한다. 따라서 보통 이미지 업로드를 구현한다면 S3을 이용하여 구현하는 경우가 많다.

AWS S3 및 다른 서비스와 Travis CI를 연동하게 되면, 아래와 같은 구조를 가진다.

 

출처: https://smpark1020.tistory.com/m/236

우선 Travis CI와 S3를 연동하자. 이게 필요한 이유는...

실제 배포는 AWS CodeDeploy라는 서비스를 이용할 것인데, 배포를 하기 위해서는 Travis CI로부터 생성된 jar 파일을 전달해야 한다.

이 파일 저장 기능을 위해 S3를 사용한다.

 

AWS Key 발급

일반적으로 AWS 서비스에는 외부 서비스가 접근할 수 없다. 보안을 생각하면 당연한 일인데, 아무나 접근할 수 있다면 누군가 우리의 AWS 서비스를 이용해 암호화폐를 채굴하려 들 것이다.

따라서 접근 권한을 가진 key를 사용해야 한다. AWS는 이러한 인증과 관련된 기능을 제공하는 서비스로 IAM (Identity and Access Management) 가 있다.

IAM은 AWS에서 제공하는 서비스의 접근 방식과 권한을 관리한다. 이를 이용해 Travis CI가 AWS의 S3과 CodeDeploy에 접근할 수 있도록 해 보자.

 

AWS 콘솔에서 IAM을 검색한다.

 

위와 같은 화면이 나타난다.

좌측의 액세스 관리 -> 사용자 를 선택한다.

그리고 '사용자 추가' 를 선택해 주자.

 

생성할 사용자의 이름과 액세스 유형을 선택하게 된다.

우리가 선택할 액세스 유형은 '프로그래밍 방식 액세스' 이다.

 

 

다음, 권한 설정 방식은 '기존 정책 직접 연결' 을 선택한다.

 

 

정책 필터 칸에서 s3full을 검색하고 AmazonS3FullAccess를 선택, CodeDeployFull을 검색하여 체크해 준다.

실제 서비스 회사에서는 S3과 CodeDeploy 권한을 분리해서 관리하기도 하지만, 여기서는 함께 관리하기로 한다.

 

태그 추가에서는 간단한 Name 값을 지정한다. 알아볼 수 있는 이름 정도면 충분하다.

 

 

마지막으로, 앞서 설정한 내용을 한 번 검토해 준다.

 

(시간이 지남에 따라 내용이 바뀔 수 있으므로) 위와 비슷한 내용이 나오면 된다.

최종 사용자 생성을 누르면, 액세스 키와 비밀 키가 발급된다. 이 키를 Travis CI에서 사용할 것이다.

 

Travis CI에 키 등록

Travis CI를 열고 설정 화면으로 들어가자.

 

설정 화면 스크롤을 내리다 보면 Envorinment variables라는 항목이 있다.

여기에 Name을 AWS_ACCESS_KEY, AWS_SECRET_KEY로 각각 하여 VALUE에 앞서 발급받은 공개 키, 비밀 키를 넣는다.

 

 

여기에 등록된 값은 이제 .travis.yml 파일에서 $AWS_ACCESS_KEY, $AWS_SECRET_KEY 라는 이름으로 사용할 수 있다.

다음으로, 이 키를 이용하여 jar를 관리할 S3 버킷을 생성해 보자.

 

S3 버킷 생성

앞서 언급한 것처럼, AWS S3은 파일 서버 역할을 한다. 파일을 저장하고, 접근 권한 관리, 검색 등을 지원한다.

AWS 서비스에서 S3을 검색하고, '버킷 만들기' 를 클릭하여 생성한다.

 

 

생성된 버킷은 목록에서 확인할 수 있다.

 

마지막으로, .travis.yml 파일을 수정하자.

Travis CI에서 빌드하여 만든 파일을 S3에 담도록 설정한다.

 

before_deploy:
  - zip -r springboot-web-practise *
  - mkdir -p deploy
  - mv springboot-web-practise.zip deploy/springboot-web-practise.zip

deploy:
  - provider: s3
    access_key_id: $AWS_ACCESS_KEY
    secret_access_key: $AWS_SECRET_KEY
    bucket: kchung1995-springboot-build
    region: ap-northeast-2
    skip_cleanup: true
    acl: private
    local_dir: deploy
    wait-until-deployed: true

 

위 내용을 이전에 작성한 내용의 script 아래에, notifications 위에 추가해 주면 된다.

 

저장하고 GitHub에 push해 보자. 정상적으로 빌드되는지 확인하도록 한다.

 

위처럼 나타나면 정상적으로 빌드된 것이다.

AWS S3을 확인해 보면 Travis CI가 빌드하여 얻은 jar 파일을 업로드한 것을 확인할 수 있다.