❗️ CI/CD란?
- CI: Continuous Integration(지속적 통합)
- 동일한 프로젝트에서 작업하는 모든 사람이 정기적으로 코드 변경 사항을 중앙 저장소에 병합하도록 하는 방식
- main 브랜치에 머지 -> CI Server에서 감지 -> 빌드/테스트를 진행하고 결과를 사용자에게 알려줌
- 개발 -> 빌드 -> 테스트 -> 통합을 빠르게 하는 것
- CD: Continuous Delivery(지속적 제공) & Continuous Deployment(지속적 배포)
1. Continous Delivery
- CI 이후 코드의 변경 사항을 프로덕션 환경으로 릴리즈 할 준비가 된 상태
- 여기서 QA 진행
2. Continuous Deployment
- Continous Delivery에 이어서 프로덕션 배포까지 자동화
- CI의 연장선에 있는 개념
- 빌드의 결과물을 프로덕션으로 지속적으로 배포하는 것
❗️ 파이프라인?
코드 구축 ~ 배포까지의 과정을 CI/CD 파이프라인이라고 하고, 총 3단계로 구성된다.
- Continuous Integration : 코드를 빌드하고 테스트하고 합친다.
- Continuous Delivery : 해당 레포지토리에 릴리즈한다.
- Continuous Deployment : 프로덕션, 즉 실제 서비스에 배포한다.
코드배포까지의 과정을 좀 더 체계적으로 만들고, 테스트를 강제할 수 있다.
ex) 파이프라인 내에 테스트가 존재하기 때문에 테스트가 없으면 코드가 머지되지 않도록
각 과정에 대해 알아보자.
- 빌드
웹브라우저는 js/css/html만 읽을 수 있기 때문에
.jsx/.tsx/.vue 파일을 브라우저가 읽을 수 있도록 만들어주는 과정이다.
- 테스트
작은 단위를 테스트하는 단위테스트, 모듈을 통합할 때 하는 통합테스트 등이 존재한다.
- 머지
git에서 코드 합치는 것으로 충돌을 최소화하는 것이 중요하다.
- 배포
사용자를 위한 서비스 배포 + 관리자 어민 페이지 배포, QA 엔지니어를 위한 배포 등이 있다.
- CI/CD 툴
github action, genkins, circle ci ..
❗️ 무중단 배포
배포 자동화를 통해 서비스를 운영 중이라면
새로운 서비스를 배포하기 위해서는 기존의 서비스를 종료하고 새로운 서비스를 배포해야 한다.
이 사이에 사용자들이 서비스를 이용하지 못하는 시간이 존재하게 되는데 이를 '다운 타임'이라고 한다.
다운 타임이 생기지 않도록 무중단 배포를 이용한다!
- AWS의 Blue-Green
- 도커
- L4, L7 스위치
- Nginx -> 가장 쉽고 저렴해서 많이 사용함
- 무중단 배포 방식
1. Rolling
가장 기본적인 방식으로 서버를 차례대로 업데이트한다.
3개의 서버가 있다고 가정해보자.
하나의 서버에는 로드밸런싱을 라우팅 하지 않도록 설정한 후, 해당 서버를 업데이트한다.
업데이트 후에 다시 로드밸런싱을 하도록 라우팅 설정을 해준다.
이를 다른 서버들에게도 차례대로 적용하는 방식이다.
장점 : 인스턴스 추가하지 않아도 돼서 관리가 간편하다.
단점 : 사용중인 인스턴스에 트래픽 몰릴 수 있고, 구버전과 신버전 공존으로 인해 호환성 문제 발생할 수 있다.
2. Canary
새로운 버전을 소수의 사용자에게만 배포하는 방식이다.
소수의 사용자에게 배포한 후, 문제가 없는게 확인되면 점진적으로 다른 서버에도 새로운 버전을 배포한다.
하나의 서버에는 로드밸런싱을 라우팅 하지 않도록 설정한 후, 해당 서버를 업데이트하고 다시 라우팅하도록 설정한다.
업데이트 된 서버가 문제없이 잘 작동되는게 확인되면 다른 서버에도 적용하는 방식이다.
장점 : 문제 상황을 빠르게 감지할 수 있고, A/B 테스트로 활용 가능하다.
단점 : 모니터링 관리 비용이 들고, 구버전과 신버전 공존으로 인해 호환성 문제 발생할 수 있다.
3. Blue / Green(Blue=구버전, Green=신버전)
구버전과 동일하게 신버전의 인스턴스를 구성한다.
신버전을 배포할 때, 로드 밸런서를 통해 신버전으로만 트래픽을 전환한다.
하나의 그룹을 신버전으로 업데이트 시키고, 로드밸런서를 업데이트한 그룹으로 라우팅한다.
구버전 그룹을 동일하게 신버전으로 업데이트 시키고 대기시켜뒀다가 이후에 업데이트 할 때 사용하는 방식이다.
장점 : 배포속도가 빠르고, 신속하게 롤백이 가능하고, 남아 있는 기존 버전의 환경을 다음 배포에 재사용한다.
단점 : 시스템 자원이 2배로 필요하다.
❗️ Jenkins vs Github Actions
- Jenkins
- 무료 오픈 소스
- 서버에 설치해야 됨
- 레퍼런스가 많은 안정적인 툴
- 다양한 플러그인이 존재해서 커스터마이징 가능
- 각 단계를 동기적으로 실행
- Github Actions
- Github와 연동
- 클라우드 환경에서 작동하기 때문에 설치할 필요 없음
- 각각의 Job은 Runners라는 VM에서 실행
- 직접 설정한 환경에서 구동시킬 수도 있음 -> Self-hosted Runner
- Workflow(파이프라인)를 .yml 소스코드로 관리
- 실제 Github Actions 적용
1. Github Repository에 .github/workflows 디렉토리 하위에 .yml 파일로 설정해준다.
2. 특정 Event가 발생하면 workflow가 실행된다.
ex) 특정 대상(브랜치, 경로 .. )에 특정 이벤트(push, PR ..)가 발생할 때 workflow 실행
=> develop 브랜치로 PR이 생성되면 실행
3. Jobs
workflow 안의 컨테이너 단위로, 병렬적으로 실행된다.
각 job은 순서와 돌아갈 환경을 정할 수 있다.
=> 우분투의 최신버전에서 job을 실행
4. Steps
Job내에서 step들을 수행한다.
이미 정의된 action을 수행시키거나 script나 command를 실행시킨다.
