CI/CD & Jenkins

#개발자의도구들 #CI/CD #Jenkins

​

AI스쿨 msa기반 java 백엔드 코스 중에 공부한 내용을 작성하였습니다

\* 현재 Spring x 프로젝트를 진행하고 있습니다. 전체 목차를 보시려면 여기를 눌러주세요.

\* Devops stack: 여기

\* 리눅스 기본기: 여기

Build System

지금까지의 개발과정은 이렇습니다.

​

1. 코드를 작성한다.
2. 테스트 및 빌드를 직접 진행한다.
3. 수정사항을 git에 커밋한다. (업데이트)

​

이 큰 맥락에서 벗어나는 일이 거의 없는데요. 보통 로컬에서 개발을 진행하며 서버를 띄우고 테스트 하는 경우가 많은데, 실제 환경에서는 로컬이 아닌 다른 서버에 서버를 배포하고 실행하는 경우가 많습니다.

​

실제 VM을 통해서 해보면 아시겠지만, 로컬 VM에서 수정사항을 반영하여 서버를 실행하는 과정이 매우 귀찮습니다.

​

다음과 같은 플로우를 따르는데요.

                                    위의 수정사항을 커밋한다 이후로

1. VM에 접속한다.(원격으로 SSH)
2. github에서 새로운 패치 내역을 다운 받는다
-> 기존 파일은 삭제함

3. VM에서 build 한다.
4. build 이후 실행 한다.

막상 적으닌깐 별거 없어 보이긴 하는데, 실제로 해보면 매우 매우 귀찮은 것을 알 수 있습니다. 빌드 시스템은 이런 과정을 자동화 해줍니다.

​

CI/CD

현시점에서 실제 기업들이 대부분 CI/CD에 대한 역량을 요구하고 있습니다. 정의는 앞서 빌드 시스템에서 소개한 내용과 큰 차이가 없습니다.

​

👉 CI

• Continuous Integration
• 정의: 개발자들이 각자 작업한 코드들을 중앙 저장소에서 통합하는 프로세스
• 목표: 코드 변경사항들을 빠르게 병합하여, 자동화된 빌드 및 테스트 진행
• 효과: 통합시 발생하는 충돌을 빠르게 감지 및 대응

​

👉 CD

• Continuous Deployment
• 정의: 테스트 통과된 코드를 실제 서버 운영환경에 배포 하는 것

​

사실 정의만 놓고 보면 잘 이해가 안되실 수 있어서 CI/CD 이전의 빌드 및 배포 환경을 이해하는게 좋습니다.

​

CI/CD 이전의 build

물론 저는 실습때 혼자서 개발을 진행했다보니, 이 부분이 이해가 잘 안되는 것도 사실입니다. 그래도 조금만 생각해보면 CI/CD 이전의 빌드가 얼마나 혼란스러웠을지 예상해볼 수 있었습니다.

​

CI/CD 이전의 빌드는 다음과 같습니다.

​

• 개별 로컬 빌드
• 각 개발자가 자신의 환경에서 테스트 수 행후 결과를 저장
• 👉 내 환경에서는 안되는

​

• 수동 통합
• 중앙 저장소에 각각 개별 커밋을 진행
• 누군가는 수동으로 이를 통합하여 빌드 수행함
• 👉 통합 과정에서 충돌 및 빌드 오류 발생
• 이를 해결하기 위해 로컬로 돌아가 다시 수정을 진행

​

사실 이 환경을 직접 겪지 않았기 때문에 온전하게 이해하기는 어렵습니다. 그냥 "개발 코드를 통합하는데 정말 힘이 많이 들었겠구나" 정도만 이해하고 넘어가면 될 것 같습니다.

Jenkins

여러 빌드 시스템이 경쟁하다가 승기를 꽂은건 Jenkins 였습니다. Jenkins는 오픈 소스기반으로 현재 많은 업계에서 사용하고 있는 Ci/CD 플랫폼이 되겠습니다.

​

👷‍♂️Nodes

Jenkins는 기본적으로 두 종류의 노드를 사용합니다.

• Master: 전체 파이프라인 관리, 설정 관리, 스케쥴링, 빌드관리, 연결 노드 관리, 플러그인 관리 ..
• 실질적으로 Jenkins 서비스를 제공하는 노드
• Worker:
• Master Node를 통해 할당된 작업을 실제로 진행하는 노드

​

이렇게 중앙에서 작업 목록을 관리하고 master내 에서 worker 노드에게 일을 분배해두면 해당 작업을 작업 노드가 수행하는 방식입니다.

​

master는 나의 매니저, worker는 알바생이 되겠네요. 아 물론 워커들의 일은 제가 직접 지정해줘야 하지만, 어쨋든 비슷한 개념입니다.

​

👉 worker node

적절하게 VM을 구축하여 worker node로 지정할 수 있습니다. worker node를 따로 두는 이유는 크게 두가지로 정리할 수 있습니다.

​

1. build 리소스 : 실제 build 시에는 많은 리소스가 필요합니다. 만약 master노드가 build를 수행한다면, master의 일을 제대로 못할 가능성이 큽니다.

​

1. 여러가지 환경을 사용하기: worker 노드를 따로 지정할 수 있기 때문에, 시킬일도 커스텀하게 제공할 수 있습니다. 예를들어 어떤 프로젝트는 IOS, 어떤 프로젝트는 Window, 어떤 프로젝트는 Linux 환경에서 빌드가 진행되어야한다고 하면, Node를 맞춤형으로 설정해두면 됩니다.

​

​

                                    🚀 more ++
1. Master 노드는 뛰어난 웹 인터페이스를 제공합니다.
2. 여러 플러그인을 제공하여 다양한 도구들과 쉽게 연동이 가능합니다.
ex) git, k8s , docker, gradle ...

​