- 컨테이너(도커)를 사용한 이유
컨테이너를 사용하여 구성한 환경을 이미지화 시켜서 항상 같은 환경으로 애플리케이션이 돌아가게 할 수 있습니다. 이로 인해 애플리케이션 환경을 구축할때 같은 과정을 반복하지 않고 해당 환경으로 일괄적으로 배포할 수 있다는 장점이 있습니다. 또한 컨테이너가 내려갈 경우 자동으로 재시작하게 만들어 가용성적인 측면에서도 뛰어난 환경을 만들 수 있다는 점에서 채택하게 되었습니다.
- 스프링 애플리케이션이 두 개 존재하는 이유
- nginx를 사용한 이유
프론트와의 이슈중에 프론트가 작업중에 배포중에 서버가 내려가면서 502에러가 발생하는 상황이 계속해서 발생하였고 이런 상황을 막기 위해 무중단 배포를 사용하여 현재 무중단 배포를 위해 블루-그린 배포 방법을 사용하여 하나를 active, 다른 하나를 standby 상태로 두어 배포중에 서비스가 중단되는 상황을 막기 위해서 두개가 존재하며, 실제 서비스 중에는 하나의 애플리케이션으로 동작하고 있습니다.
현재 무중단 배포를 사용하기 때문에 어떤 애플리케이션에 요청을 보낼지 계속해서 바뀌는 상황이 발생하고 현재 띄워져 있는 애플리케이션에 요청을 보내기 위해서 리버스 프록시 역할을 하는 nginx를 사용했습니다.
- github actions를 사용한 이유
서버에 배포하기 전에 미리 빌드를 해보고, 문제 없이 빌드가 되는지 확인하고 빌드된 파일을 컨테이너 이미지로 만들어 도커허브에 업로드하는 용도로 사용했습니다.
문법이 간단하고 레포지터리에서 바로 확인할 수 있다는점과 github actions를 사용하면 github에서 CI가 돌아가는 컨테이너를 무료로 제공해주기 때문에 추가적으로 비용을 쓰지 않아도 된다는 점에서 채택하게 되었습니다.
- jenkins를 사용한 이유
CI가 성공적으로 수행되어 빌드가 완료되면 운영서버에 자동으로 배포하기 위해 완료시점에 젠킨스에게 요청을 보내 서버에 배포스크립트를 실행하는 역할을 하기 위해 젠킨스를 사용했습니다.
- 사용자 시나리오
- 사용자는 서비스를 요청하기 위해 서버 URL을 DNS에 질의합니다.
- DNS는 freenom에 등록한 checkmoi.ga의 IP주소를 반환합니다.
- 사용자는 전달받은 IP를 가지고 http 또는 https로 서비스를 요청합니다(80포트, 443포트)
- 여기서 http로 요청을 보낼경우 자동으로 https로 리다이렉션 해준다.
- nginx는 현재 올라와있는 서버에 요청을 전달합니다.
- 서버는 요청을 받아 처리하고 다시 nginx에게 전달합니다.
- nginx는 사용자에게 응답을 전달합니다.
- 개발자 시나리오
- 작성한 코드를 github 레포지터리에 push 합니다.
- 개발자는 해당 코드를 develop 브랜치에 PR을 합니다.
- github actions workflows 파일에 정의한 작업을 수행합니다.
- 작성한 테스트 코드 실행
- 자코코로 테스트 커버리지 측정
- 소나큐브를 통한 코드 정적 분석
- 코드 리뷰를 실시합니다.
- 코드 리뷰에 문제가 없으면 merge를 실시합니다
- github actions workflows 파일에 정의된 작업을 수행합니다.
- 애플리케이션 빌드 후 컨테이너 화 작업
- CI가 성공적으로 완료되면 젠킨스에 배포 요청을 보냄
- 젠킨스는 미리 정의된 배포 스크립트를 운영 서버에 실행
- green에 도커 이미지를 최신화
- green 실행
- green이 정상적으로 올라올때 까지 대기 (서비스 가능한 상태가 될때까지)
- green이 정상적으로 올라왔으면 nginx가 green을 가르키도록 변경
- blue 종료
- 배포 완료
blue(active), green(standby) → 현재 실행중인 애플리케이션 blue, 대기중인 애플리케이션 green