[AWS/Travis CI] Travis CI 배포 자동화 (1) - 깃허브 연동 / .travis.yml 작성 / Travis CI와 AWS S3 연동

참고 : 

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

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

6) 스프링부트로 웹 서비스 출시하기 - 6. TravisCI & AWS CodeDeploy로 배포 자동화 구축하기

6) 스프링부트로 웹 서비스 출시하기 - 6. TravisCI & AWS CodeDeploy로 배포 자동화 구축하기

 

• CI (Continuous Integration - 지속적 통합)
  • 코드 버전 관리를 하는 VCS 시스템에 Push가 되면 자동으로 테스트와 빌드가 수행되어 안정적인 배포 파일을 만드는 과정
  • 머지를 수작업으로 하다 보면 생산성이 좋을 수 없으므로 코드가 통합되는 환경(CI)이 구축됨
  • 개발자 각자가 원격 저장소로 푸시할 때마다 코드를 병합하고 테스트 코드와 빌드를 수행하면서 자동으로 코드가 통합되어 더는 수동으로 코드를 통합할 필요가 없어짐
  • 개발자가 개발에만 집중할 수 있게 됨
• CD (Continous Deployment - 지속적 배포)
  • 이 빌드 결과를 자동으로 운영 서버에 무중단 배포까지 진행되는 과정
  • 한두대의 서버에 개발자가 수동으로 배포할 수 있지만, 수십대 수백대의 서버에 배포를 해야 하거나 긴박하게 당장 배포해야 하는 상황에서는 수동 배포 불가능
  • 배포를 자동화하므로 개발자가 개발에만 집중
• 마틴 파울러가 말하는 CI의 4가지 규칙
  • 모든 소스 코드가 살아있고(현재 실행되고) 누구든 현재의 소스에 접근할 수 있는 단일 지점을 유지할 것
  • 빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용할 수 있게 할 것
  • 테스팅을 자동화해서 단일 명령어로 언제든지 시스템에 대한 건전한 테스트 수트를 실행할 수 있게 할 것
  • 누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것
• 지속적으로 통합하기 위해서는 이 프로젝트가 완전한 상태임을 보장하기 위해 테스트 코드가 구현되어 있어야만 함
  • 테스트 코드 작성, TDD 관련 강의 : 백명석님의 클린코더스 - TDD편

 

---

Travis CI 연동하기

• Travis CI는 깃허브에서 제공하는 무료 CI 서비스
• Jenkins는 설치형이라서 이를 위한 EC2 인스턴스가 하나 더 필요함
• Travis CI는 오픈소스 웹서비스
  • AWS에서 Travis CI와 같은 CI 도구로 CodeBuild를 제공. 하지만 빌드 시간만큼 요금이 부과되는 구조라서 초기에 사용하기에는 부담스러움.
  • 실제 서비스되는 EC2, RDS, S3 외에는 비용 부분을 최소화하는 것이 좋음

 

아래 웹사이트에 접속해서 깃허브 계정으로 로그인하자

https://www.travis-ci.com/

Travis CI | Test and Deploy With Confidence

 

오른쪽 상단의 프로필 이미지를 클릭하고 Settings를 선택한다

 

Activate 선택

 

Approve & Install 선택

 

해당되는 깃허브 레퍼지토리 선택

저장소 빌드 히스토리 페이지로 이동한다.

Travis CI 웹사이트에서의 설정은 이것으로 끝!

 

 

---

프로젝트 설정

이제 상세 설정을 해보자.

프로젝트 루트 디렉토리에 .travis.yml 파일을 생성한다

• YAML은 쉽게 말해 JSON에서 괄호를 제거한 것
• 익숙하지 않은 독자라도 읽고 쓰기 편함
• Travis CI, AWS의 CodeDeploy 설정도 YAML 파일을 통해서 한다

 

나는 한 프로젝트에서 스프링부트와 리액트를 함께 사용하므로 아래와 같이 .travis.yml 파일을 작성했다.

우선 develop 브랜치에 푸시될 때 수행되게 했고

gradle을 통해 받은 의존성과 npm의 node_modules를 캐시해서 같은 의존성은 다음 배포 때부터 다시 받지 않도록 설정했다

chmod +x gradlew는 gradlew가 실행권한이 없다고 해서 실행 권한을 허용하는 명령어를

script에 추가했는데 안 돼서 before_script에 작성했고 그래도 안 돼서 install에 작성했더니 됐다.

branches:
  only: 
    - develop

jobs:
  include:
  - language: java
    jdk: openjdk11
    cache:
      directories:
        - $HOME/.gradle/caches/
        - $HOME/.gradle/wrapper/
    install:
      - chmod +x gradlew
    script: 
      - ./gradlew clean build
  - language: node_js
    node_js: 14
    cache: npm
    before_script:
      - cd frontend
      - npm install
    script: 
      - npm run build

 

아래 글을 참고해서 슬랙 알림받기 설정 추가

• Travis CI에서 Slack 연동해서 빌드 notification 받기
• travis에서 slack 연동 암호화 하기

 

Travis CI에 접속해서 해당 깃허브 레퍼지토리의 내역을 확인하니 성공한 것을 확인할 수 있었다.

 

---

Travis CI와 AWS S3 연동하기

• S3는 AWS에서 제공하는 일종의 파일 서버
  • 이미지 파일을 비롯한 정적 파일들을 관리하거나 배포 파일들을 관리
  • 이미지 업로드를 구현할 때 S3를 이용하여 구현하는 경우가 많음
• 전체 프로세스는 다음과 같다

Travis CI와 S3 연동

• 실제 배포는 AWS CodeDeploy를 이용함
• CodeDeploy는 저장 기능이 없어서 CodeDeploy가 가져갈 수 있도록 보관할 수 있는 공간이 필요함
• 이 때, AWS S3를 이용하며 그러므로 배포 파일을 전달하기 위해서는 Travis CI와 S3의 연동이 먼저 필요하다
  
  • CodeDeploy가 깃허브 코드를 가져오는 기능을 지원하므로 빌드도 하고 배포도 할 수 있음
  • 하지만 이러면 빌드 없이 배포만 필요할 때는 대응하기 어려움
    • 빌드와 배포가 분리되어 있으면 -> 예전에 빌드되어 만들어진 배포용 파일을 재사용하면 됨
    • 빌드와 배포가 합쳐져 있으면 -> 항상 빌드를 하게 되니 확장성이 많이 떨어짐

• 외부에서 AWS 서비스에 접근하려면 접근 권한을 가진 Key를 생성해야 함
• IAM(Identify and Access Management)
  • AWS에서 제공하는 서비스의 접근 방식과 권한을 관리
• AWS IAM 페이지 왼쪽 메뉴의 Users 선택 - Add users 선택

• 적당한 이름으로 지어주고 액세스 유형은 프로그래밍 방식 액세스로 체크한다.

• AmazonS3FullAccess 권한과 AWSCodeDeployFullAccess 권한에 체크한다
  • 참고로 실제 서비스 회사에서는 두 권한을 분리해서 관리하기도 함

• 태그는 Name 값을 지정하고 본인이 인지 가능한 정도로 짓는다

• 작성한 내용을 확인하고 Create users 클릭

• 이제 이 키를 Travis CI에 등록하자

 

---

Travis CI에 키 등록

More options를 클릭하고 Settings 클릭

아래와 같이 액세스 키 ID와 비밀 액세스 키를 환경변수로 등록한다

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

 

---

S3 버킷 생성

• AWS S3는 일종의 파일 서버. 파일들을 저장하고 접근 권한을 관리, 검색 등을 지원하는 파일 서버의 역할.
• S3는 보통 게시글을 쓸 때 나오는 첨부파일 등록을 구현할 때 많이 이용
• 여기서는 Travis CI에서 생성된 Build 파일을 저장하도록 구성할 것
  • S3에 저장된 Build 파일은 이후 AWS의 CodeDeploy에서 배포할 파일로 가져가도록 구성할 것

 

S3 서비스에서 버킷을 생성한다

 

이 버킷에 배포할 zip 파일이 모여있는 장소임을 의미하도록 짓는다

 

버킷의 보안과 권한 설정과 관련하여 퍼블릭 액세스를 닫고 모든 차단으로 설정해야 한다

깃허브에 모두 오픈소스로 풀려있으면 문제가 없지만

실제 서비스에서 할 때는 Jar 파일이 퍼블릭일 경우 누구나 내려받을 수 있어 코드나 설정값, 주요키값들이 다 탈취될 수 있음

퍼블릭이 아니더라도 IAM 사용자로 발급받은 키를 사용하니 접근 가능.

따라서 모든 액세스를 차단하는 설정에 체크한다.

 

나머지는 그대로 두고 버킷을 생성하면 다음과 같이 S3 버킷 목록에서 확인 가능하다.

 

---

.travis.yml 추가

S3가 생성되었으니 이 S3로 배포 파일을 전달해보자.

내 프로젝트에 맞게 .travis.yml에 아래의 코드를 추가했다.

참고로 $AWS_ACCESS_KEY와 $AWS_SCRET_KEY는 위에서 travis에 등록한 AWS 보안 관련 환경변수이다.

나는 main 브랜치를 푸시할 때가 아닌, develop 브랜치를 푸시할 때 AWS에 배포가 일어나도록 할 예정이므로

S3 업로드와 관련하여 develop 브랜치에 권한을 추가하는 코드를 넣었다.

before_deploy:
  - zip -r project-jikji *
  - mkdir -p deploy
  - mv project-jikji.zip deploy/project-jikji.zip

deploy:
  - provider: s3
    access_key_id: $AWS_ACCESS_KEY
    secret_access_key: $AWS_SECRET_KEY
    bucket: project-jikji-build
    region: ap-northeast-2
    skip_cleanup: true
    acl: private
    local_dir: deploy
    wait-until-deployed: true
    on: 
      branch: develop

 

성공하면 Travis CI에 다음과 같이 출력된다.

 

AWS S3에서는 다음과 같이 확인할 수 있다.

 

여기까지 Travis CI와 S3 연동이 완료되었다.