230715 - [DevOps] Jenkins, Docker로 Spring Boot CI/CD 구축하기

오늘 한 일

CI/CD 개념과 구축

 

내가 이해한 CI

여러 branch로 작업한 것을 어떻게 잘 합칠까?

- test코드를 자동으로 실행시켜서 검증한 뒤 merge

 (자동화된 test code 구현)

지속적 통합(Continuous Integration, CI)
현대적인 애플리케이션 개발에서는 여러 개발자들이 동일한 애플리케이션의 각기 다른 기능을 동시에 작업할 수 있도록 하는 것을 목표로 합니다. 그러나 조직에서 특정한 날("병합의 날(merge day)")을 정해 모든 분기 소스 코드를 병합하는 경우, 결과적으로 반복적인 수작업에 많은 시간을 소모하게 됩니다. 이렇게 반복적인 수작업을 하는 이유는 독립적으로 작업하는 개발자가 애플리케이션에 변경 사항을 적용할 때 다른 개발자가 동시에 적용하는 변경 사항과 충돌할 가능성이 있기 때문입니다. 이는 팀이 하나의 클라우드기반 통합 개발 환경(Integrated Development Environment, IDE)사용에 동의하는 대신 각 개발자가 각자의 로컬 IDE를 커스터마이징하는 경우 더욱 복합적인 문제가 될 수 있습니다.CI(지속적 통합)를 통해 개발자들은 코드 변경 사항을 공유 브랜치 또는 "트렁크"로 다시 병합하는 작업을 더욱 수월하게 자주 수행할 수 있습니다. 개발자가 애플리케이션에 적용한 변경 사항이 병합되면 이러한 변경 사항이 애플리케이션을 손상시키지 않도록 자동으로 애플리케이션을 구축하고 각기 다른 레벨의 자동화된 테스트(일반적으로 단위 테스트 및 통합 테스트) 실행을 통해 변경 사항이 애플리케이션에 제대로 적용되었는지를 확인합니다. 다시 말해, 클래스와 기능에서부터 전체 애플리케이션을 구성하는 서로 다른 모듈에 이르기까지 모든 것에 대한 테스트를 수행합니다. 자동화된 테스트에서 기존 코드와 신규 코드 간의 충돌이 발견되면 CI를 통해 이러한 버그를 더욱 빠르게 자주 수정할 수 있습니다.

 

내가 이해한 CD

main에 branch 에 작성한 코드를 올리면 자동으로 변경을 감지해서 서버에 올려줌. (git과 서버를 연동해야함.)

이 과정을 처리해주는 것이 Jenkins 

Jenkins : 빌드, 테스트, 배포 프로세스를 자동화 할 수 있는 CI툴이고,웹 기반 콘솔로 편리하게 자동 배포 프로세스를 구축할 수 있다.

 

지속적 제공(Continuous Delivery, CD)
CI의 빌드 자동화, 유닛 및 통합 테스트 수행 후, 이어지는 지속적 제공 프로세스에서는 유효한 코드를 리포지토리에 자동으로 릴리스합니다. 그러므로 효과적인 지속적 제공 프로세스를 실현하기 위해서는 개발 파이프라인에 CI가 먼저 구축되어 있어야 합니다. 지속적 제공의 목표는 프로덕션 환경으로 배포할 준비가 되어 있는 코드베이스를 확보하는 것입니다.지속적 제공의 경우, 코드 변경 사항 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계에는 테스트 자동화와 코드 릴리스 자동화가 포함됩니다. 이 프로세스를 완료하면 운영팀이 더욱 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있게 됩니다.

지속적 배포(Continuous Deployment, CD)
CI/CD 파이프라인의 마지막 단계는 지속적 배포입니다. 프로덕션 준비가 완료된 빌드를 코드 리포지토리에 자동으로 릴리스하는 지속적 제공의 확장된 형태인 지속적 배포는 애플리케이션을 프로덕션으로 릴리스하는 작업을 자동화합니다. 프로덕션 이전의 파이프라인 단계에는 수동 작업 과정이 없으므로, 지속적 배포가 제대로 이루어지려면 테스트 자동화가 제대로 설계되어 있어야 합니다.실제 사례에서 지속적 배포란 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 클라우드 애플리케이션을 자동으로 실행할 수 있는 것을 의미합니다(자동화된 테스트를 통과한 것으로 간주). 이를 통해 사용자 피드백을 지속적으로 수신하고 통합하는 일이 훨씬 수월해집니다. 이러한 모든 CI/CD 적용 사례는 애플리케이션 배포의 위험성을 줄여주므로 애플리케이션 변경 사항을 한 번에 모두 릴리스하지 않고 작은 조각으로 세분화하여 더욱 손쉽게 릴리스할 수 있습니다. 그러나 자동화된 테스트는 CI/CD 파이프라인의 여러 테스트 및 릴리스 단계를 수행할 수 있어야 하기 때문에 많은 선행 투자가 필요합니다.

 

내가 이해한 docker

가상실행환경.서버마다 환경이 다르다. 그래서 각 was 서버마다 (예를 들어) jdk도 깔고 shell 파일도 만들고 log 폴더도 구성하고 이것 저것 해주어야하는 작업들이 많은데 도커를 이용하면 이런 반복적인 작업은 Dockerfile로 이미지라는 것을 만들어 OS를 통째로 띄워버림으로써 해결이 되는 것이다. jvm과 비슷하다.

 

CI는 일단 생략하고 CD 구축을 해보았다.

 

진행 순서

1. Jenkins Server에 Docker 설치
2. Jenkins Server에 Docker를 이용하여 Jenkins 실행
3. Jenkins 접속
4. Jenkins와 Github 연동
5. Jenkins와 Docker Hub 연결
6. Jenkins Server와 Spring Boot Server SSH 연결 설정
7. Jenkins와 Slack 연동
8. Jenkins Pipeline 구성

• Spring Boot Project Github Repository Clone
• Gradle Build
• Docker Build
• Docker Push
• Spring Boot Server SSH 연결
  • Docker Pull
  • Docker Run
• Slack Notification
  사전에 Jenkins Server, Spring Boot Server를 위한 AWS EC2 인스턴스 2개와 Spring Boot Project가 올라가있는 Github Repository와 Docker Hub Repository가 생성되어 있어야 한다. 대부분의 설정은 Jenkins Server에 접속하여 진행한다. Spring Boot Server는 SSH 연결 설정 시 public key를 등록할 때만 접속한다.

 

 

참고

https://velog.io/@hyeinisfree/Jenkins-Docker%EB%A1%9C-Spring-Boot-CICD-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0

[DevOps] Jenkins, Docker로 Spring Boot CI/CD 구축하기

https://www.redhat.com/ko/topics/devops/what-is-ci-cd

CI/CD(CI CD, 지속적 통합/지속적 배포): 개념, 툴, 구축, 차이