Travis CI 배포 자동화

CI와 CD

CI : Continuous-integration 지속적 통합으로 안정적인 배포를 만드는 과정이다.
CD : Continuous-Deployment 지속적인 배포로 CI의 빌드결과를 자동으로 운영 서버에 배포되는 과정이다.
CI/CD종류는 travis, 젠킨스, 버디 등이 있다.
나는 인턴일때 젠킨스를..2달정도 써보고, 현재 travis로 사용해본것이 전부이다.
기존 실무에서는 개발자들이 새벽이나 주말 10시 이후 사용자가 없을때 배포하면서 빌드상태를 확인
하였다.(이부분 역시도 개발에 비 효율적이다.)
CI도구를 도입했을때 규칙이 있다.
1. 모든 소스 코드가 살아 있고 누구든 현재의 소스에 접근 할 수 있는 단일 지점을 유지
2. 빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용
3. 테스팅을 자동화해서 단일 명령어로 언제든지 시스템에 대한 건전한 테스트 수트를 실행
4. 누구나 현재 실행 파일을 얻으면 지금까지 가장 와전한 실행 파일을 얻었다고 확신

Travis CI 연동하기

travis는 github에서 제공하는 무료 CI 서비스이다.
젠킨스는 별도의 인스턴스가 필요하지만 travis는 웹 서비스 형태여서 테스트모드에서는 가장 적합한것 같다.
1. travis 접속
https://travis-ci.com으로 접속하고 github 아이디로 로그인한다.
2. setting
상단의 계정명에 setting을 클릭, 활성화할 저장소를 클릭한다.

나는 모든 레포지터리가 필요한것이 아니기 때문에 단일 프로젝트를 선택하여 설치하였다.
3. plan 가입하기
책에는 나와있지않은데 plan을 가입하지않으면 진행이 되지 않았다.
다행이 free 요금제가 있어서 해당 요금제로 가입을 하면되는데
vat id 입력부분은 test로 넣었다.(사업자번호 넣는부분)
만약 비용이 발생하게 된다면 이부분이 문제가 될것이니 확인을 잘 해보자.

프로젝트에 Travis 설정

build.gradle과 같은 위치선상에 .travis.yml을 등록한다.
yml은 json에서 ()를 제거한 형태라고 보면된다.
짧게 넘어가자면 스프링부트를 사용하는데 있어서 설정은 yml이나 properties로 설정한다.
나는 아직은 properties에 익숙하고 좋아하는데 요즘 추세는 yml을 사용하는것이다.
장단점이 있지만 properties는 식별하기가 난 좀 더 편했던것 같다.
하지만 중복으로 등록이 불가능하니.. 여러개의 properties로 관리를 해야한다.
하지만 yml은 여러개를 등록가능하다. 하지만 줄맞춤이나 이런부분들이 까다로운 편이니 조심해야한다.


저장하고 push를한다.
push하면 travis에서 빌드를 진행한다.
빌드가 실패하였다. 원인은 gradlew의 권한이 없어서 이다.
이전 챕터에서도 얘기했지만 권한에 대한 문제가 많이 발생되어 권한을 처리해야 한다.

Travis CI와 AWS S3연동하기

S3 : 파일서버 - 이미지 파일이나 정적파일을 관리
travis에서는 배포파일을 관리하지 못하기 때문에 S3를 이용하여 배포를 진행한다.
그이유는 빌드되는 jar파일을 전달하기 위해서 이다.

실제 배포는 codedeploy에서 실행한다.
추천사항
codedeploy가 빌드와배포 둘다 가능하지만 빌드없이 배포만 필요할때 대응이 어렵다.
빌드와 배포가 분리되어 있으면 예전에 빌드되어 만들어진 jar를 재사용이 가능한데
둘다 하게 되면 항상 빌드를 해야되는 문제가 발생되기 떄문에 분리를 추천한다.

AWS Key 발급

AWS 서비스에 외부 서비스가 접근을 할 수 없다. 그러므로 접근 가능한 권한을 가진 Key를 생성해서 사용한다.
AWS에서 IAM(Identity and Acess managment)에서 관리를 해준다.
1. 사용자 추가

2. 세부설정





설정하면 사용자 등록이 된다.
3. 엑세스키 확인
권한최종확인하면 엑세스키 ID와 비밀번호가 나온다.
나는 .csv파일로 다운받아놨다.

TravisCI에 AWS키 등록

travis사이트에 접속하여 우측 상단에 setting를 누르고 발급받은 키를 등록하면된다.
나도 처음에 해깔렸는데

AWS_ACCESS_KEY가 ID를 입력하는 부분이고
AWS_SECRET_KEY가 비밀번호를 입력하는 부분이다.
나는 처음에 ID가 key고 패스워드가 vlaue로가서 셋팅을 하는줄 알았다.
이렇게 등록하면 .travis.yml에서 $AWS_ACCESS_KEY, $AWS_SECRET_KEY의 이름으로 사용가능하다.

S3버킷 생성

S3(simple storage service)에 관하여 설정을 진행한다.
순수하게 파일들을 저장하고 접근 권한을 관리, 검색 등을 지우너하는 파일 서버 역할이다.
1. S3접속 및 버킷만들기
AWS사이트에서 S3를 검색후에 버킷만들기를 클릭한다.

2.버킷 세부사항 설정


.travis.yml에 추가한다. 위의 코드는 이미 포함되어있는 코드이다.
설정이 다 완료되어 git에 push를 하면 S3에zip파일이 생성된다.

Travis CI와 AWS S3, CodeDeploy연동하기

1. EC2에 IAM 역할 추가하기
   IAM을 검색하고
   
   역할을 선택한다.
2. 역할을 만든다.
   역할 : AWS서비스에서만 할당 할 수있느 권한(EC2, CodeDeploy 등)
   사용자 : AWS서비스 외에 사용 할 수 있느 권한(로컬PC, IDC 서버등)
   
   
   
   해당 항목들을 차례대로 입력후 저장한다.
3. EC2에 인스턴스 설정
   
   책이에서와는 좀 바뀌었는데 인스턴스에서 마우스 우클릭 후에 보안 -> IAM역할 수정에서
   아까 생성한 역할을 선택해 주면된다.
4. 인스턴스 재부팅

CodeDeploy 에이전트 설치

EC2에 codedeploy를 설치해야한다.
1. EC2에 codedeploy 다운로드
aws s3 cp s3://aws-codedeploy-ap-northeast-2/latest/install . --region ap-northeast-2 명령어를 입력하면 다운로드가 이루어 진다.
완료가 되면 download: s3://aws-codedeploy-ap-northeast-2/latest/install tc ./install 실행된다.
2. codedeploy 설치
chmod +x ./install 로 권한을 부여 후 설치한다.
sudo ./install auto
install시 에러가 발생할 것이다. 루비가 없기 때문이다.
3. 루비설치
aws의 가이드에 나와있는데로 설치가 되지않았다.
이유는 내부에 루비가 없었기 때문이다.
amazon-linux-extras 입력한다. 입력하면 루비 목록이 나온다.
amazon-linux-extras install ruby2.5(해당버전에 맞게) 입력하면 설치가 된다.
yum list installed|grep ruby로 설치 유무를 확인 할 수 있다.
설치 후 2번을 다시 실행한다.
4. 설치 후 상태 검사
sudo service codedeploy-agent status를 입력하면
the aws codedeploy agent is running as PID xxx가 뜬다.

codedeploy를 위한 권한 생성

IAM에서 역할을 생성한다.
이번에는 서비스에서 codedeploy를 선택한다.

태그 추가까지 이전에 등록한 것과 마찬가지로 등록을 하면 된다.

codedeploy 생성

검색에 codedeploy를 검색하고 접속한다.
1. 애플리케이션 생성을 클릭한다.
2. 애플리케이션 구성을 설정한다.

3, 배포그룹을 생성한다.



해당 설정을 참고해서 셋팅하면 된다.

Travis CI, S3, CodeDeploy연동

1. 인스턴스에 접속해서 디렉토리를 설정한다.
   mkdir ~/app/step2 && mkdir ~/app/step2/zip
2. 프로젝트에 appsepc.yml을 생성한다.
   
   설정은 끝났다. 위에 .travis.yml을 보면 provider에 codedeploy를 가지고 있다.

배포 자동화 구성

최상단 폴더를 구성하고 deploy shell 파일을 만든다.
기존 인스턴스에서 생성한 deploy 와 유사하다.

우의 travis.yml에서 before_deploy가 이에 해당하는 부분이다.
그리고 추가로 appspec에서 hook을 추가한다.

자동화 구성은 종료 되었다.

codedeploy 로그 확인

cd /opt/codedeploy-agent/deployment-root 로 접속하여 확인 하면 된다.

이번 챕터의 나의 생각

실제로 CI를 구축해보니 정말 편리하였다.
이것저것 설정할 부분도 많았고 정말 도움이 많이 된것 같았다.
내가 회사에서 사용할 일은 없겠지만 지금 이 마인드를 가지고 혼자서 재미있게
개발을 해봐도 좋을 것 같다. 기존의 테스트하는 인스턴스를 삭제하고 또다른 프로젝트로
인스턴스를 구성해봐도 좋을 것 같다.
다시한번 다른 프로젝트로 구성하면서 정리를 해봐야 겠다. 굿잡