- 출처 : Jenkins를 이용한 CI/CD Pipeline 구축(인프런)
이후부터 배울 CI/CD의 흐름은 위 사진과 같다.
먼저 흐름에 대해 대략적으로 이해한 이후 단계별로 자세히 공부해보도록 하자.
1. Code Push
CI/CD 과정의 가장 핵심은 개인적으로는 "자동화"에 있다고 생각한다.
그렇다면 어떤 상황에서 CI/CD 과정이 자동으로 수행되는 것일까?
최소한 필자가 활용했던 Jenkins나 Travis CI는 Github의 특정 Branch에 Push(Merge) 작업이 수행되었을 때 CI/CD 과정이 시작되었다.
즉, Code Push는 Github의 Branch에 코드가 Push 되었을 때 자동으로 CI/CD 과정이 수행되는 Trigger에 해당하는 과정이다.
2. Continuous Build
여기서는 Build라고만 나와 있지만 이 과정에서 Build, Test, Packaging 전 과정이 수행된다.
즉, Jenkins 같은 CI/CD 툴이 자동화된 CI 과정을 수행하는 단계이다.
이전에 Packaging 과정을 Source Code를 바이너리 코드로 컴파일 한 뒤 이를 실행 파일로 바꾸는 과정이라고 설명했다.
정리하자면 Continuous Build라는 과정은 깃에 Push된 Source Code를 바이너리 코드로 변환한 이후 변환된 코드를 통해 Unit Test를 진행해보고 모든 테스트를 통과했을 경우 안정성 있는 코드라 판단하여 배포를 위한 실행파일을 만드는 과정이다.
2-1. Analysis Reports
이전에는 보지 못했던 SonarQube라는 툴이 나왔다.
Wikipedia에 나와있는 SonarQube에 대한 설명이다.
소나큐브(SonarQube, 이전 이름: 소나/Sonar)는 20개 이상의 프로그래밍 언어에서 버그, 코드 스멜, 보안 취약점을 발견할 목적으로 정적 코드 분석으로 자동 리뷰를 수행하기 위한 지속적인 코드 품질 검사용 오픈 소스 플랫폼이다.
소나소스(SonarSource)가 개발하였다.
소나큐브는 중복 코드, 코딩 표준, 유닛 테스트, 코드 커버리지, 코드 복잡도, 주석, 버그 및 보안 취약점의 보고서를 제공한다.
위 설명에서 가장 중요한 내용은 "정적 코드 분석"이라는 용어이다.
정적 코드 분석은 Source Code에 대해 수행하는 코드 검사 방법으로 메모리 누수나 Buffer Overflow, 보안 Issue 등 일반적으로 알려진 오류나 취약점을 파악할 수 있고 코딩이나 주석에 대한 Convention 적용도 가능해진다.
이렇게 설명하니 어려워 보일 수도 있는데 쉽게 말하자면 Source Code를 실행시키지 않고 오로지 코드만 분석하여 취약점이나 문제점 등을 파악하는 것이라고 할 수 있다.
CI Tool이 수행하는 Test는 Source Code를 실행시키고 기능들을 테스트하는 방식으로 동적 코드 검사라고 할 수 있다.
하지만 CI Tool들은 Source Code 자체를 분석하지는 않는다. 따라서 만약 코드 상 보안 이슈나 Buffer Overflow를 발생시킬 가능성이 있더라도 코드를 실행시켰을 때 정상적으로 동작한다면 이런 취약점을 걸러내지 못한다.
따라서 우리는 Jenkins에서 수행하는 동적인 코드 검사 이외에도 SonarQube에서 실행하는 정적인 코드 검사를 추가시킴으로써 코드 상 존재하는 취약점이나 문제점을 찾고 이를 시각화하는 과정을 추가하는 것이다.
당연히 이 과정도 자동화되어야 할 것이다.
3. Continuous Delivery
Jenkins를 통해 만들어진 실행 파일은 바로 Conatiner Image로 만들어지거나 운영 환경에 Deploy 되지 않는다.
IaC Tool에 코드를 배포하는 중간 단계를 두어 "실행 파일 생성 → IaC로 생성된 환경에 Application 배포 → Deployment"라는 Pipeline을 구축한다.
IaC는 Infrastrcutre as Code의 약어로써 인프라 구성을 프로그래밍(코드)을 통해 처리하는 방식이다.
IaC를 사용하기 이전에는 Code가 실행될 환경에 변경 사항이 생겼을 경우 직접 운영 환경이나 개발 환경에 접속하여 수동으로 설정을 변경시켜줘야 했다. 당연하겠지만 운영 환경 설정을 직접 수행해줘야 하므로 운영에 대한 배경지식이 풍부해야 했으며 수동으로 진행하기 때문에 Human Error의 가능성도 존재한다.
아마 (글을 기입하는 기준) 작년에 발생했던 KT 서버 다운 문제가 운영 환경의 Human Error에 대한 대표적인 예시가 아닐까 싶다.
(사실 엄밀히 따지자면 상황이 다르기는 하지만 결국 운영 서버에 대해 직접적인 수정을 수동으로 가하다가 발생한 Human Error라는 점때문에 예시로 사용했다)
IaC에서는 운영 설정에 대한 변경 사항을 코드로 처리할 수 있다.
따라서 운영 환경에 변경사항을 적용하기 위해 직접 접속하여 수정할 필요가 없어지며 이는 여러 가지 장점을 가지고 온다.
먼저 IaC Tool을 사용하여 코드를 통해 시스템이 올바르게 변경될 수 있도록 구성되어 있다면 자동화에 의해 운영 환경 설정을 빠르게 변경 및 구성할 수 있다.
두 번째로 자동화되어 있기 때문에 Human Error의 가능성을 매우 낮출 수 있다.
세 번째로 확장성 및 유지보수성이 뛰어나다는 점인데, 만약 운영 환경이 여러 개일 경우 기존에는 모든 운영 서버에 접속하여 일일히 환경 설정을 해주어야 했으나 IaC를 활용하면 모든 운영 환경에 대해 일괄적인 변경이 가능해진다.
마지막으로 IaC Tool을 활용하면 개발자는 코드를 통해 Infra 설정을 할 수 있으므로 운영에 대한 배경지식이 이전처럼 많이 필요하지는 않다는 것이다. 이는 개발과 운영 사이 경계가 줄어든다는 의미와 동일하고, 개발과 운영을 동시에 수행해야 하는 DevOps에 있어 매우 큰 장점으로 다가온다.
4. Deplyment(Image Pull)
CD의 마지막 단계이다. 3번 과정을 통해 IaC에서 Container Image를 만들었다면 생성된 이미지를 Kubernetes에서 같이 관리하게 됨으로써 실제로 개발하거나 수정한 기능을 운영 서버에 등록시키는 과정이다.
Kubernetes는 대표적인 Orchestration Tool인데 이전에도 배웠지만 Orchestartion이란 여러 기능을 합쳐 1개의 큰 기능을 만들어내는 것이다.
MSA에서는 이런 Orchestration 과정이 당연히 필수적인데, 작은 기능들이 Container Image라는 형태로 저장되어 있고 Image들을 적절하게 조화시켜 1개의 큰 Application을 만들어내는 Architecture이기 때문이다.
Kubernetes는 사용하는 Container Image들을 모두 관리하며 적절히 Orchestration 해주는 도구로써 사진에서 볼 수 있듯 cri-o라는 기술과 같이 사용할 수도 있지만 대부분 Docker와 같이 활용하기 때문에 우리는 Docker와 Kubernetes가 연결되어 있다고 많이 알고 있는 것이다.
이 과정을 통해 IaC에 의해 만들어진 환경에 배포된 Service를 실제로 활용할 수 있게 됨으로써 User가 개선되거나 추가된 서비스를 활용할 수 있게 되는 것이다.
