CI(지속적 통합) - 테스트와 빌드가 자동 수행되어 안정적으로 배포 파일을 만드는 것
코드 수정 -> git push -> CI동작(테스트 및 빌드-Spring Boot의 경우 보통 Junit test 후 jar 빌드) -> 배포파일 생성!
CD(지속적 배포) - 빌드 결과물을 자동으로 운영서버에 무중단 배포
CI로 생성된 배포파일 -> 운영서버에 반영
1. 첫번째 실습
먼저 CI 개념을 익히기 위해 가장 간단하게 사용해보았다.
설치형인 젠킨스를 대신해 Git에서 제공하는 무료 CI인 Travis CI를 사용하면 더 간단하다.
위 구조의 문제점은
1. CI와 실제 서비스가 같은 인스턴스 내에 있다. 따라서 해당 인스턴스 문제 발생 시 둘다 영향을 받는다.
2. 빌드와 배포가 동시에 이루어진다. 기존 배포파일을 이용하지 못한다.
3. 배포 시 구동중인 서비스를 종료한 후 다시 구동시킨다. 즉, 서비스에 공백이 생긴다.
*번외
조사결과 Spring Boot의 경우 대부분 컨테이너로 많이 이용한다고 한다.
아직까지 왜 도커를 써야되는지 어떤 장점이 있는지 잘 모르겠지만 spring boot 2.3부터 이미지화도 편하게 변경되었기에 위 구조를 Docker로 변경해보았다.
위 구조에서 EC2에 도커를 설치 한 후 젠킨스 이미지를 설치하였다.
젠킨스에서 스프링 부트를 이미지화 해야되는데 문제가 발생하였다.
젠킨스 안에 도커가 없으므로 스프링 부트를 이미지로 만들 수 없었다!!!
찾아보니 도커 인 도커라는 구조가 있었는데 이미 젠킨스 안에 도커가 설치된 이미지를 누군가 배포중이였다.
이 이미지를 다시 내려받아 젠킨스를 구동 시킨 뒤 스프링 부트를 이미지화 한 후 구동 시켰다.
괜히 이상한거 해보겠다고 설치다가 몇일 날려먹었다 ㅠㅠ
왜 쓰는지 머가 장점인지도 모르면서....
2. 두번째 실습
첫 번째 실습의 1, 2번 문제점을 해결하기 위해 CI와 배포를 분리하였다.
젠킨스는 설치형 이기에 추가적인 EC2 인스턴스가 필요하다.
위와 달리 젠킨스에서 테스트 및 빌드 후 해당 파일을 S3에 업로드 한다.
업로드에 성공한 후 AWS의 CodeDeploy라는 서비스를 이용하여 EC2에 배포하게 된다.
이 역시 무중단배포가 이루어지지 않고 있기 때문에 서비스 공백이 생긴다.
3. 세번째 실습
무중단 배포 전 CI/CD를 사용하다보니 불편한 점이 하나 있었다.
Git commit - Test/Build - Deploy과정이 한눈에 안들어오고 로그 또한 따로 일일이 찾아봐야된다.
즉 관리가 너무 불편하다.
CodePipleline의 경우 이 문제를 해결해주는데
빌드부터 배포까지 모든 과정을 한번에 실시간으로 시각화된 모습을 볼수있고
로그 또한 바로바로 확인이 가능하다.
마침 Jenkins와 Github 또한 지원하여 사용해 보았는데 설정도 어렵지 않고 매우 편리했다.
3. 세번째 실습 - 무중단배포(ngix를 이용해보자!)
7) 스프링부트로 웹 서비스 출시하기 - 7. Nginx를 활용한 무중단 배포 구축하기
이번 시간엔 무중단 배포 환경을 구축하겠습니다. (모든 코드는 Github에 있습니다.) 7-1. 이전 시간의 문제점? 이전 시간에 저희는 스프링부트 프로젝트를 Travis CI를 활용하여 배포 자동화 환경을 �
jojoldu.tistory.com
참고할것!
4. 네번째 실습 - AWS를 이용하여 블루/그린 배포를 해보자!
5. gunsdevlog.blogspot.com/2017/07/scouter-apm-1.html스카우터
일단 무작정 따라는 해봤는데 현재 사용중인 서비스에 적용시켜보자..