[스프링부트/AWS] 9장 코드가 푸시되면 자동으로 배포해보자

24시간 365일 운영되는 서비스에서 배포 환경 구축은 필수 과제 중 하나입니다. 여러 개발자의 코드가 실시간으로 병합되고, 테스트가 수행되는 환경, master 브랜치가 푸시되면 배포가 자동으로 이루어지는 환경을 구축하지 않으면 실수할 여지가 너무 많습니다. 그래서 이번 장에서는 24시간 365일 무중단 배포 환경을 구성하였습니다.

- CI & CD 소개

1) CI ( Continuous Integration - 지속적 통합 )

코드 버전 관리를 하는 VCS 시스템(Git, SVN 등)에 PUSH가 되면 자동으로 테스트와 빌드가 수행되어 안정적인 배포 파일을 만드는 과정

2) CD ( Continuous Deployment - 지속적인 배포 )

CI 배포 결과를 자동으로 운영 서버에 무중단 배포까지 진행되는 과정

일반적으로 CI만 구축되어 있지는 않고, CD도 함께 구축된 경우가 대부분이라고 합니다.

- CI/CD란 개념이 나오게된 배경

현대의 웹 서비스 개발에서는 하나의 프로젝트를 여러 개발자가 함께 개발을 진행합니다. 그러다 보니 매주 병합일(코드 Merge만 하는 날)을 정하여 수동으로 코드를 합치는 작업이 있었습니다. 이런 수작업 때문에 생산성이 좋을 수가 없었으며, 개발자들은 지속해서 코드가 통합되는 환경(CI)을 구축하게 되었습니다. 그 결과 더는 수동으로 코드를 통합할 필요가 없어지면서 자연스레 개발자들 역시 개발에만 집중할 수 있게 되었습니다.
CD 역시 마찬가지로 한두 대의 서버에 개발자가 수동으로 배포를 할 수 있지만, 수십 대 수백 대의 서버에 배포를 해야 하거나 긴박하게 당장 배포를 해야 하는 상황이 오면 수동으로 배포를 할 수 없습니다. 그래서 이 역시 자동화가 되었고, 개발자들은 개발에만 집중을 할 수 있게 되었습니다.
여기서 주의할 점은 단순히 CI 도구를 도입했다고 해서 CI를 하고 있는 것은 아닙니다. 마틴 파울러의 블로그를 참고해 보면 CI에 대해 다음과 같은 4가지 규칙을 이야기 합니다.

• 모든 소스 코드가 살아 있고(현재 실행되고) 누구든 현재의 소스에 접근할 수 있는 단일 지점을 유지할 것
• 빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용할 수 있게 할 것
• 테스팅을 자동화해서 단일 명령어로 언제든지 시스템에 대한 건전한 테스트 수트를 실행할 수 있게 할 것
• 누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것

여기서 특히 중요한 것은 테스팅 자동화라고 합니다. 지소적으로 통합하기 위해서는 무엇보다 이 프로젝트가 완전한 상태임을 보장하기 위해 테스트 코드가 구현되어 있어야만 합니다.

- Travis CI 연동하기

책 참고하여 진행 ...

※ 책에는 특정 프로젝트만 허용을 해서 진행을 했지만 저의 경우에는 모든 프로젝트에 대한 접근을 허용한 다음에 진행했습니다. 특정 프로젝트에 대한 권한만 허용시 Travis에서 제 프로젝트의 push를 인식하지 못했습니다.

※ YAML(야믈)
JSON에서 괄호를 제거한 것

- Travis CI 연동시 구조

사진 출처 : https://jojoldu.tistory.com/265

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

※ 빌드와 배포를 분리하는 이유

CodeDeploy가 빌드도 하고 배포도 할 수 있습니다. CodeDeploy에서는 깃허브 코드를 가져오는 기능을 지원하기 때문입니다. 하지만 이렇게 할 때 빌드 없이 배포만 필요할 때 대응하기 어렵습니다.
빌드와 배포가 분리되어 있으면 예전에 빌드되어 만들어진 Jar 를 재사용하면 되지만, CodeDeploy가 모든 것을 하게 될 땐 항상 빌드를 하게 되니 확장성이 많이 떨어집니다. 그래서 웬만하면 빌드와 배포를 분리하는 것을 이 책의 저자는 추천합니다.

- AWS IAM ( Identity and Access Management )

AWS에서 제공하는 서비스의 접근 방식과 권한을 관리합니다.

- AWS S3 ( Simple Storage Service )

순수하게 파일들을 저장하고 접근 권한을 관리, 검색 등을 지원하는 파일 서버의 역할을 합니다.

- CodeDeploy

AWS의 배포 삼형제 중 하나입니다. 배포 삼형제는 다음과 같습니다.

• Code Commit -> Git Hube
  • 깃허브와 같은 코드 저장소의 역할을 합니다.
  • 프라이빗 기능을 지원한다는 강점이 있지만, 현재 깃허브에서 무료로 프라이빗 지원을 하고 있어서 거의 사용되지 않습니다.
• Code Build -> Travis CI
  • Travis CI와 마찬가지로 빌드용 서비스 입니다.
  • 멀티 모듈을 배포해야 하는 경우 사용해 볼만하지만, 규모가 있는 서비스에서는 대부분 젠킨스/팀시티 등을 이용하니 이것 역시 사용할 일이 거의 없습니다.
• CodeDeploy
  • AWS의 배포 서비스입니다.
  • 앞에서 언급한 다른 서비스들은 대체재가 있고, 딱히 대체재보다 나은 점이 없지만, CodeDeploy는 대체재가 없습니다.
  • 오토 스케일링 그룹 배포, 블루 그린 배포, 롤링 배포, EC2 단독 배포 등 많은 기능을 지원합니다.

- 이슈사항들

1) 설정파일
저의 경우 프로젝트 명을 책에 있는 것과 다르게 해서 책에 있는 소스작성 시 고치는 부분이 좀 있었습니다. 저와 같이 프로젝트 명, 각 인스턴스 명 등을 다르게 했을 경우에는 .travis.yml과같은 설정 파일에 이름을 잘 보고 작성하도록 합니다.
https://github.com/oss0202/com.jordy.book/blob/master/.travis.yml

oss0202/com.jordy.book

2) CodeDeploy 에이전트 설치

# 루비 설치 후 CodeDeploy 설치 진행 sudo yum install ruby # CodeDeploy 에이전트 설치 aws s3 cp s3://aws-codedeploy-ap-northeast-2/latest/install . --region ap-northeast-2 # install 파일에 실행권한 추가 chmod +x ./install # install 파일로 설치 진행 sudo ./install auto # 설치 끝난 후 Agent 실행상태 확인 sudo service codedeploy-agent status # The AWS CodeDeploy agent is running as PID XXXX 노출 확인

책에 나오는 데로 스크립트 작성 후 이슈 없이 진행 완료하였습니다.
script의 경우에는 제 github에 올려놓았습니다.
https://github.com/oss0202/com.jordy.book/tree/master/scripts

이제 Master 브랜치에 푸시하면 자동으로 EC2에 배포가 됩니다. 하지만, 문제가 한 가지 남았습니다. 배포하는 동안 스프링 부트 프로젝트는 종료 상태가 되어 서비스를 이용할 수 없다는 것입니다. 그래서 다음 장(10장)에서는 서비스 중단 없는 배포 방법을 진행합니다.