Travis CI를 이용한 CI/CD 환경 구성 실습 (1)

* Travis CI는 유료로 전환되었다!

회원가입 하면 한달 무료 체험을 할 수 있게 해주니 한달 안에 최대한 많은 것을 해보자

 

* <스프링 부트와 AWS로 혼자 구현하는 웹 서비스> 책을 굉장히 많이 참고했습니다

 

** Jenkins를 활용한 CI/CD 구축은 아래에!!

https://sedangdang.tistory.com/286

---

 

# CI란 무엇인가??

Continuous Integration (지속적 통합)

 

<내용 추가좀>

 

 

대표적인 툴로 Jenkins가 있다. (왜냐면 무료다!!)

나도 젠킨스를 사용해보고 싶지만 내가 참고한 책에서는 Travis CI를 사용하고 있어서 일단 Travis를 먼저 사용해보고 CI/CD 개념이 잡힌다면 나중에 따로 젠킨스를 사용해봐야겠다.

이외에도 GitLab 이라는 툴이 최근 뜨고 있다고 하니 이거를 배워봐도 괜찮을 것 같다.

 

 

# CD란 무엇인가??

Continuous Deployment || Continuous Delivery

 

<내용 추가좀>

 

 

결국 CI/CD란 무엇인가?

로컬에서 개발한 내용을 깃허브에 push 하면 자동화된 빌드/배포 과정을 거쳐 애플리케이션 실행까지 한방에 되게끔 만들어주는 것이다!

 

깃허브에 push한 다음에 또 ec2 켜서 프로젝트 폴더까지 이동해서 git pull 한 다음에 또 gradlew build 하고 애플리케이션 실행시키고.. 근데 마침 또 수정된 게 있어서 깃허브에 push 한 다음에 또 ec2 켠 다음에 git pull 하고....

 

이렇게 번거로운 과정을 그냥 git push 한방에 애플리케이션 실행까지 되도록 만들어주는 것이 CI/CD의 위대함이다

 

CI/CD를 세팅하는 과정은 지금껏 내가 배워왔던 개발과는 살짝 다른 분야라 굉장히 낯설고 또 진입장벽이 느껴졌다. 

이게 바로 애플리케이션 개발과 DevOps의 차이인가??

아무튼 그래서 CI/CD 구성을 블로깅과 같이 천천히 해보면서 진행 과정을 상세하게 남겨보려고 한다!

 

 

# 1. Travis CI와 Github 레포지토리 연결

Travis CI 회원가입/로그인 -> Settings -> Migrate 탭

 

 

Repository Accsss -> Only Select Repositories 눌러서 Travis가 CI 관리 해줬으면 하는 특정 리포지토리만 선택해서 연동한다

 

 

저장을 하고 다시 돌아와보면 Repositories 목록에 내 깃허브 리포지토리들이 잘 들어가 있는 것을 확인할 수 있다.

 

 

 

# 2. CI 해보기

< .travis.yml 파일 >

프로젝트의 최상단에 .travis.yml 설정 파일을 만든다. (build.gradle이랑 같은 위치 거기)

language: java
jdk:
  - openjdk11

# 어느 브랜치에 push될 때 수행할 것인지?
branches:
  only:
    - main # main branch에 push 될 때만 CI를 수행해라

# CI를 통해 빌드할때마다 gradle || maven 을 통한 의존 라이브러리를 전부 빌드하는 것은 비효율적이다
# 그래서 Travis가 내부적으로 캐싱을 해두도록 설정할 수 있다.
cache:
  directories:
    - '$HOME/.m2/repository' # maven 사용하는 경우
    - '$HOME/.gradle' # gradle 사용하는 경우

# main branch에 push 되었을 때 수행할 명령어
script: "./gradlew clean build"

# CI 완료 시 메일로 알람 (선택사항)
notifications:
  email:
    recipients:
      - [원하는 이메일 주소]

 

이를 작성하고 commit & push를 해보면 Travis가 이를 인식해서 작업이 돌아가는 것을 확인할 수 있다!

굉장히 신기하다!

 

작업중!

성공시 모습

 

 

* ./gradlew: Permission denied 에러가 뜨는 경우

-> 말 그대로 ./gradlew 파일에 권한이 없어서 그렇다.

그냥 chmod +x로 해보면 권한이 안바뀌는데, git bash나 터미널을 이용해서 아래 코드를 입력하면 권한이 바뀐다. 권한 바꾼 다음에 같이 push 해주면 됨.

git update-index --chmod=+x gradlew

(참고) https://stackoverflow.com/questions/33820638/travis-yml-gradlew-permission-denied

 

644 -> 755로 권한이 잘 바뀐것을 확인할 수 있따

* 644 = rw - r - r,   755 = rwx-rx-rx  --> others도 실행 가능(eXecute)

 

 

깃허브와 Travis를 연동하고 나면 생기는 차이점이 또 있는데 바로 깃허브 커밋 이력 옆에 체크 / 실패 표시가 생긴다

 

 

뭔가 되게 있어보인다. 뭔가 전문적인 개발을 하는 것 같은 느낌적인 느낌이 생긴다.

 

 

 

# 3. Travis CI와 AWS S3 연동하기

Travis CI에서 빌드에 성공했다면 똑같이 결과물로 .jar 파일이 만들어졌을 것이다. 그럼 이 결과물을 실행시켜야 하지 않을까?

하지만 안타깝게도 Travis는 CI 전용 툴이라 jar 파일을 배포할 수 없다. 그렇기에 jar 파일을 AWS EC2로 옮긴 다음에 거기에서 배포해보는 식으로 진행해 보도록 한다.

 

Travis에 있는 실행 파일을 어떻게 AWS EC2로 옮길까?

옛날에 했던것 처럼 EC2 콘솔에서 직접 git pull 한 다음에 빌드를 해도 물론 되긴 하겠지만 우리는 CI/CD까지 자동화를 목표로 하고 있기 때문에 다른 방법을 사용한다.

 

AWS S3이라는 것을 이용해볼건데, S3이란 Simple Storage Service 의 약자로써 말 그대로 저장소를 제공해주는 서비스이다.

 

 

# 3-1. IAM 설정 및 액세스 키 발급

AWS는 기본적으로 Travis와 같은 외부 서비스가 접근할 수 없다. 하지만 인증키를 이용한다면 접근을 가능하게 만들어줄 수 있다. 이 인증키를 생성/관리하는 곳이 IAM(Identity and Access Management)이다

 

IAM -> 사용자 -> 사용자 추가 클릭

 

 

외부 서비스(Travis)가 S3, CodeDeploy에 Full Access 할 수 있는 권한을 부여

 

 

태그는 솔직히 뭐하는데 쓰는지 모르겠다. IAM 사용자가 굉장히 많아졌을 때 서로 구분할 수 있게 해주는 용도로 보인다.

근데 우리는 많아봐야 한두개 쓸거니까 굳이 안써줘도 될 것 같다.

 

마지막 검토 이후 사용자를 추가하게 되면 해당 사용자에 대한 공개키 / 비밀키 (액세스 키)를 보여준다

이때 비밀 키는 키 발급 시점에 딱 한번만 볼 수 있으니 꼭 다른 곳에 저장을 해두던가 해야한다.

(엑셀 파일로 저장해둘 수 있다)

 

하지만 기어코 비밀키를 까먹었다면 사용자 -> 보안 자격 증명 탭에서 액세스 키를 새로 발급받을 수 있다.

(동시에 최대 2개만 발급 가능) -- 이때도 키 발급 시점 딱 한번만 비밀 키 값을 확인할 수 있으니 조심해야 한다.

 

 

 

마지막으로, Travis에 가서 해당 액세스 키 정보를 환경변수에 저장해주고 AWS S3에 접근 가능하도록 만들어주면 된다.

 

해당 리포지토리 -> More Options -> Settings

 

 

 

* 이 환경변수 정보들도 한번 입력하면 다시 해당 값을 볼 수가 없다

** Add 옆에 Display value in build log 활성화 시키면 안된다

 

 

# 3-2. S3 버킷 생성

버킷이란 우리 말로 양동이인데, 저장소를 생성한다고 생각하면 된다. 새 폴더를 만든다고 봐도 될듯.

 

버킷 만들기에서 버킷을 만들면 된다.

주의해야 할 점으로 "이 버킷의 퍼블릭 액세스 차단 설정"은 "모든 퍼블릭 액세스 차단"으로 설정해두자

 

 

# 3-3. 코드 추가

# Travis CI에서 Build한 Jar 파일을 S3에 올리는 과정
# Travis는 디렉토리 단위로만 업로드 가능하다
before_deploy:
  - mkdir -p before-deploy # 디렉토리 생성 
  - cp build/libs/*.jar before-deploy/ # 배포에 필요한 파일만 꼽아서 복사 (executable jar)
  - cd before-deploy && zip -r smartnotice * # 위치 이동 후 내부 파일 전체 압축
  - cd ../ && mkdir -p deploy # 상위 디렉토리로 이동 후 deploy 디렉토리 생성
  - mv before-deploy/smartnotice.zip deploy/smartnotice.zip # 파일 위치 옮기기

deploy:
  - provider: s3
    access_key_id: $AWS_ACCESS_KEY # Travis 웹에서 설정한 환경변수 사용
    secret_access_key: $AWS_SECRET_KEY
    bucket: my-springboot-build
    region: ap-northeast-2
    skip_cleanup: true
    acl: private
    local_dir: deploy # 해당 위치의 파일들만 s3으로 전송한다
    wait-until-deployed: true
    on:
      branch: main # main branch 허용

위의 코드를 기존 .travis.yml 코드에 추가한다.

전체 코드는 아래에 V

language: java
jdk:
  - openjdk11
# 어느 브랜치에 push될 때 수행할 것인지?
branches:
  only:
    - main # main branch에 push 될 때만 CI를 수행해라
# Travis CI Server Home
cache:
  directories:
    - '$HOME/.m2/repository'
    - '$HOME/.gradle'
# main branch에 push 되었을 때 수행할 명령어
script: "./gradlew clean build"

# Travis CI에서 Build한 Jar 파일을 S3에 올리는 과정
# Travis는 디렉토리 단위로만 업로드 가능하다
before_deploy:
  - mkdir -p before-deploy # 디렉토리 생성 
  - cp build/libs/*.jar before-deploy/ # 배포에 필요한 파일만 꼽아서 복사 (스크립트 + executable jar)
  - cd before-deploy && zip -r smartnotice * # 위치 이동 후 내부 파일 전체 압축
  - cd ../ && mkdir -p deploy # 상위 디렉토리로 이동 후 deploy 디렉토리 생성
  - mv before-deploy/smartnotice.zip deploy/smartnotice.zip # 파일 위치 옮기기

deploy:
  - provider: s3
    access_key_id: $AWS_ACCESS_KEY # Travis 웹에서 설정한 환경변수 사용
    secret_access_key: $AWS_SECRET_KEY
    bucket: my-springboot-build
    region: ap-northeast-2
    skip_cleanup: true
    acl: private
    local_dir: deploy # 해당 위치의 파일들만 s3으로 전송한다
    wait-until-deployed: true
    on:
      branch: main # main branch 허용

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

 

대체 저 before_deploy 설정 안에서 뭔 짓거리를 하는건가 싶은데

배포에 필요한 파일 (jar) 만 딱 뽑아서 before-deploy라는 폴더에 복사해넣고 이를 zip 파일로 압축시킨 다음에 deploy라는 폴더에 넣어놓는 과정이다.

GUI로 볼 수 있었으면 이해가 한방에 될텐데 코드로만 보려니까 이해가 잘 안되긴 한다.

 

그리고 저기 zip -r smartnotice 뒤에 " * " 꼭 붙여줘야된다

 

 

* Skipping a deployment with the s3 provider because this branch is not permitted: main 에러 발생하는 경우

- travis가 기본적으로 deployment를 master branch에서만 가능하도록 제한하고 있기 때문에 발생하는 문제

-> .travis.yml 설정 파일에 on: branch: main 옵션을 추가하게 되면 main branch에 push되는 것도 정상적으로 된다.

(on: all_branches: true 옵션을 적으면 모든 브랜치에 대해 허용도 가능하)

 

이후 git commit & push를 해보면????

 

 

짠!!

jar이 압축되어있는 zip 파일이 S3 버킷에 잘 올라가있는 것을 확인할 수 있다!!

 

 

어쩌다보니 글이 굉장히 길어져서 남은 내용은 다음으로 넘긴다