CI/CD 개념 , Gitops introduction

CI/CD

애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법

CI(Continuous Integration) - 지속적 통합

• 애플리케이션 코드의 새로운 변경 사항이 정기적으로 빌드 및 테스트를 거쳐 공유 리포지토리에 병합
  • 우리가 github action에 push or pull request를 올릴때마다 새롭게 build되고 이미지 레포에 추가되는 것처럼!

CD(Continuous Deployment) - 지속적 배포

• 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미

지속적인 제공

• 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리(예: GitHub 또는 컨테이너 레지스트리)에 자동으로 업로드되는 것
• 테스트 자동화와 코드 릴리스 자동화가 포함

지속적인 배포

• CI/CD 파이프라인의 마지막 단계
• 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것
• 실제 사례에서 지속적 배포란 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 클라우드 애플리케이션을 자동으로 실행할 수 있는 것을 의미

CI/CD 툴

Jenkins

Jenkins 바로가기

• 간단한 CI 서버에서 완전한 CD 허브에 이르는 모든 것을 처리할 수 있게 설계

Tekton Pipelines

Tekton Pipelines 바로가기

• 표준 클라우드 네이티브 CI/CD 경험과 컨테이너를 제공하는 쿠버네티스 플랫폼을 위한 CI/CD 프레임워크

CI/CD 오픈소스

• Spinnaker: 멀티클라우드 환경을 위해 구축된 CD 플랫폼.
• GoCD: 모델링 및 시각화에 중점을 둔 CI/CD 서버
• Concourse: "지속적인 오픈소스 작업 툴".
• Screwdriver: CD용으로 설계된 빌드 플랫폼.

벤더 제공 CI/CD 툴

• GitLab
• CircleCI
• Travis CI
• Atlassian Bamboo

CI/CD 전과 후 비교

CI/CD 적용 전

1. 개발자들이 개발하여 코드를 수정합니다.
2. 각자의 feature 브랜치에 코드를 push합니다. (but, 어느 한 부분에서 에러가 났지만 개발자들은 눈치채지 못합니다.)
3. 각자의 코드를 git에 올리고 통합(Intergration)합니다.
4. 에러가 발생했지만 어느 부분에서 에러가 났는지 모르므로 다시 어디부분에 에러가 있는지 디버깅하고 코드를 수정합니다.
5. (1) ~ (4)의 과정을 반복합니다.
6. 많은 시간을 할애하여 에러가 해결되었으면 배포를 시작합니다. 하지만 배포과정 또한, 개발자가 직접 배포과정을 거치므로 많은 시간을 소요합니다.

CI/CD 적용 후

1. 개발자들이 개발하여 feature브랜치에 코드를 push합니다.
2. git push를 통해 Trigger되어 CI서버에서 알아서 Build, Test, Lint를 실행하고 결과를 전송합니다.
3. 개발자들은 결과를 전송받고 에러가 난 부분이 있다면 에러부분을 수정하고 코드를 master 브랜치에 merge합니다.
4. master 브랜치에 코드를 merge하고 Build, Test가 정상적으로 수행이 되었다면 CI서버에서 알아서 Deploy 과정을 수행합니다.

GitOps

애플리케이션의 배포와 운영에 관련된 모든 요소를 코드화하여 **깃(Git)에서 관리(Ops)**하는 것

• 데브옵스를 적용하는 실천 방법 중 하나
• 핵심 아이디어
  • 배포에 관련된 모든 것을 선언형 기술서(Declarative Descriptions) 형태로 작성하여 Config Repository(혹은 Environment Repository)에서 관리한다.
  • Config Repository의 선언형 기술서와 운영 환경 간 상태 차이가 없도록 유지시켜주는 자동화 시스템을 구성한다.

깃옵스 핵심 개념

1️⃣ 선언형 모델

• 원격 서버에 디렉토리를 만들기 위해 가장 먼저 떠오르는 방법은?
  • 명령형 모델
    1. ssh로 접속
    2. cd로 이동
    3. mkdir로 디렉토리 생성
  • 명령형 모델의 단점
    • 이미 디렉토리가 존재한다면..?
    • 권한은..?
  • 선언형 모델
    • 디렉토리가 이미 존재하는지 확인하거나 OS에 따라 바뀌는 명령어를 사용자가 알아야 할 필요가 없음 → 선언형 모델 구현체의 몫
    • 선언형 모델의 장점
      • 인프라를 포함한 애플리케이션 배포와 운영에 관련된 모든 것을 코드로 관리할 수 있다는 점
      • 이 코드를 이용하여 언제든 똑같은 환경을 다시 만들어내거나 부분 소실 시 복원할 수 있다는 점
  • - name: Create a directory if it does not exist file: path: /etc/some_directory state: directory

2️⃣ 단일 진실 공급원

• 같은 데이터가 여러 곳에 있을 경우 발생하는 문제는?
  • 데이터의 중복과 비정합성
  • 때문에 한 곳에 두고 관리하고 다른곳에서 필요 시 참조하도록 해야함
• 깃옵스는 깃을 단일 진실 공급원으로 지정하고 오직 이 곳에서만 관리하도록 함
• 모든 운영 활동의 시작은 깃이므로 사람 혹은 시스템 간의 혼선을 최소화

깃옵스 구현

저장소 전략

• 최소 2개 이상의 Git 저장소 사용 권장
  1. 어플리케이션 저장소
     • 애플리케이션 소스 코드와 애플리케이션 배포를 위한 배포 매니페스트(예: kubernetes yaml)를 포함
     <aside> ❗ 이게 지니언니가 말한 매니페스트는 따로 깃 파라~ 이건가??
  2. </aside>
  3. 배포 환경 구성 저장소
     • 배포 환경에 대한 모든 매니페스트를 포함
     • 애플리케이션과 인프라 서비스(모니터링, 메시지 브로커 등)가 어떤 버전으로 어떻게 구성되어야 하는지에 대한 정보가 들어있음

배포 전략

• 두가지 배포 전략 → 푸시 타입(Push Type)과 풀 타입(Pull Type)
  • 무엇을 선택해도 상관없으나 깃옵스는 보안상의 이유로 풀 타입 배포 전략을 권장

푸시 타입

• 저장소에 있는 매니페스트가 변경되었을 때 배포 파이프라인을 실행시키는 구조
• 장점
  • 배포 환경의 개수에 영향을 받지 X
  • 접속 정보를 추가하거나 수정하는 것만으로도 간단하게 배포 환경을 추가하거나 변경 가능
• 단점
  • 항상 연결이 되어있는 상태가 아니기에 실제 배포 작업이 수행되는 시점에 실패할 수 있음
  • 배포 환경이 손상되어 배포 환경 구성 저장소의 내용과 다를 경우, 별도의 모니터링 시스템 필요
• 도구
  • 젠킨스(Jenkins)
  • 서클CI(CircleCI)

풀 타입

• 배포 환경에 위치한 별도의 오퍼레이터가 파이프라인을 대신
• 오퍼레이터 → 저장소의 매니페스트와 배포 환경을 지속적으로 비교하다가 차이가 발생할 경우 저장소의 매니페스트를 기준으로 배포 환경을 유지
• 배포 환경에 대한 모든 이력은 배포 환경 구성 저장소 즉, 깃에 존재한다는 것을 의미
• 도구
  • 아르고CD
  • 젠킨스X(JenkinsX)
  • 플럭스(Flux)

깃옵스 장점

1️⃣ 신뢰할 수 있는 정보의 공유

• 깃 이력을 보면 현재 상태는 물론 누가, 언제, 왜, 어느 곳을 수정했는지 쉽게 알 수 있음
• 에러 복구 시간 감소

2️⃣ 익숙한 절차

git commit → push → merge request → review → merge

 

References

 

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

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

https://seosh817.tistory.com/104

[CI/CD] CI/CD란? - 지속적 통합(Continuous Integration)/지속적 배포(Continuous Deployment) 기본개념

https://www.samsungsds.com/kr/insights/gitops.html

데브옵스의 확장 모델 – 깃옵스[GitOps] 이해하기