CI/CD
DevOps
우선 DevOps를 먼저 살펴본다.
Dev + Ops 의 합성어로
Development(개발) + Operations(운영) 을 결합한 개발 방법론이다.
DevOps를 도입하게 되면 개발-배포-운영간 단절되어있던 과정을 하나의 과정으로 묶을 수 있게된다.
장점이라면 클라우드 환경 또는 서버 대수가 다수라면 배포 과정이 오래 걸리기 때문에
DevOps를 구축하여 개발과 배포를 자동화하고 배포 과정을 모터링 하는게 더 나을 수 있다.
다만 온프레미스 환경에서는 서버의 대수가 많지 않다면 배포하는데 어려움이 없기 때문에 DevOps를 구축 하는데 드는 비용이 더 클 수 있다.
CI/CD
CI/CD 는 Continuous Intergration(지속적인 통합) 과 Continuous Delivery(지속적인 배포) 의 준말이다.
말 그대로 지속적인 통합과 지속적인 배포를 위한 파이프라인을 얘기한다.
이 파이프라인을 구축하기 위한 대표적인 툴들이 있다.
CI 툴
- Jenkins :
가장 많이 사용되는 오픈소스 CI 도구로 다양한 플러그인을 제공하며, 유연하고 확장성이 높다.
다만 설정이 복잡하고, 자원 소모가 크다는 단점을 가진다.
실제로 메모리 사용량이 매우 큰 것 같다. - Travis CI :
GitHub과 연동하여 사용할 수 있는 CI 도구로 설정이 간단하고, 사용이 편리하다.
그러나 오픈소스 프로젝트에 대해서만 무료로 사용 가능하며 프라이빗 레포지토리에 사용하려면 유료로 사용해야한다. - CircleCI :
설정이 간단하고, 다양한 언어와 프레임워크를 지원한다.
프라이빗 레포지토리에도 무료로 사용할 수 있으며, 유료는 기능의 확장을 지원한다.
CD 툴
- Jenkins X :
kubernetes 위에서 동작하는 CI/CD 툴로 클라우드 환경의 어플리케이션 배포를 위한 기능이 매우 강력하나 설정이 복잡할 수 있다. - ArgoCD :
Jenkins X와 동일하게 Kubernetes 위에서 동작하는 CI/CD 툴
워크 플로우
- 개발자가 코드를 완성하여 Git에 Push한다.
- Git에 미리 해당 브런치(혹은 태그)에 Push 이벤트가 생길 경우 Jenkins에 Webhook 하도록 설정이 되어있기 때문에 브런치(혹은 태그)의 변경사항을 Jenkins에 알린다.
- Jenkins는 Git에서 소스를
clone → 해당 소스를 테스트(SornaQube 등 테스트 도구를 이용) → Build (maven 혹은 gradle 이용) → Docker Container 생성(이미지) → 생성된 컨테이너를 Docker Registry에 Push →
현재 Container 이미지 버전으로 k8s yaml 배포 파일 수정 및 Git Push 한다.
( 현재 윗줄, Jenkisn → Kubernetes yaml Repository Push 까지 완료)
⇒ CI의 과정이다. - Jenkins 혹은 개발자가 k8s 배포 파일(yaml) 을 수정 및 Push 하면 Argo는 현재 k8s 클러스터에 배포되어 있는 버전과 Git의 배포 파일에 차이가 있는지 주기적으로 확인하여 자동 배포, 혹은 수동 배포 하도록 한다.
⇒ CD의 과정이다. (ArgoCD)
전체적인 서버 구성을 보면 좀 더 이해가 쉽다
이미지 출처
봐야하는 초점은 Git, Jenkins, Docker Hub (또는 Docker Registry) 는 쿠버네티스 클러스터 밖에 존재하지만, Argo는 쿠버네티스 클러스터 안에 존재한다.
Argo는 쿠버네티스 배포를 명령하기 때문에 클러스터 내에서 실행되는 툴이다.
Git에서 배포 설정 파일(yaml)을 읽어 kubectl 명령을 대신 수행해주는 역할을 한다.
이로써 두루뭉실했던 CI/CD, DevOps 의 개념을 좀 더 구체적인 프로세스로 파악이 가능했다.