Chapter 09. 코드가 푸시되면 자동으로 배포해 보자 - Travis CI 배포 자동화 (2)

9.3 Travis CI와 AWS S3연동하기

 

S3랑 AWS에서 제공하는 일종의 파일 서버이다. 이미지 파일을 비롯한 정적 파일들을 관리하거나 지금 진행하는 것처럼 배포 파일들을 관리하는 등의 기능을 지원한다. 보통 이미지 업로드를 구현한다면 이 S3을 이용하여 구현하는 경우가 많다. S3를 비롯한 AWS 서비스와 Travis CI를 연동하게 되면 전체 구조는 다음과 같다.

Travis CI 연동시 구조

첫 번째 단계로 Tavis CI와 S3을 연동한다. 실제 배포는 AWS CodeDeploy라는 서비스를 이용한다. 하지만, S3 연동이 먼저 필요한 이유는 Jar 파일을 전달하기 위해서이다.

CodeDeploy는 저장 기능이 없다. 그래서 Travis CI가 빌드한 결과물을 받아서 CodeDeploy가 가져갈 수 있도록 보관할 수 있는 공간이 필요하다. 보통 이럴 때 AWS S3을 이용한다.

 

Travis CI와 AWS S3연동을 진행해 보자

 

AWS Key 발급

일반적으로 AWS 서비스에 외부 서비스가 접근할 수 없다. 그러므로 접근 가능한 권한을 가진 Key를 생성해서 사용해야 한다. AWS에서는 이러한 인증과 관련된 기능을 제공하는 서비스로 IAM(Identity and Access Management)이 있다. IAM은 AWS에서 제공하는 서비스의 접근 방식과 권한을 관리한다. 이 IAM을 통해 Travis CI가 AWS의 S3와 CodeDeploy에 접근할 수 있도록 해보겠다. AWS 웹 콘솔에서 IAM을 검색해서 이동한다. IAM 페이지 왼쪽 사이드 바에서 [사용자 -> 사용자 추가]버튼을 차례로 클릭한다.

IAM 검색 후, IAM 사용자 추가

 

생성할 사용자의 이름과 엑세스 유형을 선택한다. 엑세스 유형은 프로그래밍 방식 엑세스이다.

 

권한 설정 방식은 3개 중 [기존 정책 직접 연결]을 선택한다.

 

화면 아래 정책 검색 화면에서 s3full로 검색하여 체크하고 다음 권한으로 CodeDeployFull을 검색하여 체크한다.

S3 권한

CodeDeploy 권한

실제 서비스 회사에서는 권한도 S3와 CodeDeploy를 분리해서 관리하기도 하지만, 여기서는 간단하게 둘을 합쳐서 관리한다. 2개의 권한이 설정되었으면 다음으로 넘어간다.

 

태그는 Name 값을 지정하는데, 본인이 인지 가능한 정도의 이름으로 만든다.

 마지막으로 본인이 생성한 권한 설정 항목을 확인한다.

 

 

Travis CI에 키 등록

TravisCI의 설정화면으로 이동해 Environment Variables 항목을 본다.

여기에 AWS_ACCESS_KEY, AWS_SECRET_KEY를 변수로 해서 IAM 사용자에서 발급받은 키 값들을 등록한다.

• AWS_ACCESS_KEY : 엑세스 키 ID
• AWS_SECRET_KEY : 비밀 엑세스 키

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

그럼 이제 이 키를 사용해 Jar를 관리할 S3 버킷을 생성한다.

 

S3 버킷 생성

다음으로 S3에 관해 설정을 진행한다.  AWS의 S3 서비스는 일종의 파일 서버이다. 순수하게 파일들을 저장하고 접근권한을 관리, 검색 등을 지원하는 파일 서버의 역할을 한다.

S3은 보통 게시글을 쓸 때 나오는 첨부파일 등록을 구현할 때 많이 이용한다. 파일 서버의 역할을 하기 때문인데, Travis CI에서 생성된 Build 파일을 저장하도록 구성한다. S3에 저장된 Build 파일은 이후 AWS의 CodeDeploy에서 ㅂ포할 파일로 가져가도록 구성할 예정이다.

• AWS서비스에서 S3를 검색해 이동하고 버킷을 생성한다.
• 원하는 버킷ㅁㅇ을 작성한다. 이 버컷에 배포할 Zip 파일이 모여있는 장소임을 의미하도록 짓는 것이 좋다.
• 다음으로 넘어가서 버전관리를 설정한다 별다른 설정을 할 것이 없으니 바로 넘어간다.
• 다음으로는 버킷으 ㅣ보안과 권한 설정 부분이다. 퍼블릭 액세스를 열어두는 사람이 있지만, 모든 차단을 해야한다. 현재 프로젝트야 이미 깃허브에 오픈소스로 풀려있으니 문제 없지만 실제 서비스에서 할 때는 Jar파일이 퍼블릴=ㄱ일 경우 누구나 내려받을 수 있어 코드나 설정값, 주요키 값들이 다 탈취될 수 있다.
• 퍼블릭이 아니더라도 우리는 IAM 사용자로 발급받은 키를 사용하니 접근이 가능하다. 그러므로 모든 액세스를 차단하는 설정을 체크한다.
• 버킷이 생성되면 버킷 목록에서 확인할 수 있다.

 

travis.tml 추가

Travis CI에서 빌드하여 만든 Jar 파일을 S3에 올릴 수 있도로고 9.2절에서 만든 .travis.yml에 다음 코드를 추가한다.

...
before_deploy: 
  - zip -r springboot-study-websevice *
  - mkdir -p deploy
  - mv springboot-study-websevice.zip deploy/springboot-study-websevice.zip

deploy: 
  provider: s3
  access_key_id: $AWS_ACCESS_KEY
  secret_access_key: $AWS_SECRET_KEY
  
  bucket: springboot-study-build
  region: ap-northeast-2
  skip_cleanup : true
  acl : private #zip 파일 접근을 private로
  local_dir: deploy
  wait-until-deployed :true
  ...

① before_deploy
 - deploy 명령어가 실행되기 전에 수행된다.
 - CodeDeploy는 Jar파일은 인식하지 못하므로 Jar+기타 설정 파일들을 모아 압축(zip)합니다.

② zip -r springboot-study-websevice
 - 현재 위치의 모든 파일을 zip -r springboot-study-websevice 이름으로 압축한다.
 - 명령어의 마지막 위치는 본인의 프로젝트와 이름이어야한다.

③ mkdir -p deploy
 - deploy라는 디렉토리를 Travis CI가 실행 중인 위치에서 생성한다.

④ mv springboot-study-websevice.zip deploy/springboot-study-websevice.zip
 - springboot-study-websevice.zip 파일을 deploy/springboot-study-websevice.zip으로 이동시킨다.

⑤ deploy
 - S3로 파일 업로드 혹은 CodeDeploy로 배포 등 외부 서비스와 연동될 행위들을 선언한다.

⑥ local_dir: deploy
 - 앞에서 생성한 deploy 디렉토리를 지정한다.
 - 해당 위피의 파일들만 S3으로 전송한다.

 

설정이 다 되었으면 깃허브로 푸시한다. Travis CI에서 자동으로 빌드가 진행되는 것을 확인하고, 모든 빌드가 성공하는지 확인한다 .

 

 

출처 : 스프링 부트와 AWS로 혼자 구현하는 웹 서비스 [이동욱 지음]