들어가기 전에
사실 CI/CD는 전부터 사용하고 있었는데, 뭔가 A to Z로 구축하는 가이드를 작성해두고 싶어서 강의를 듣고 이것저것 시도(라고 하고 삽질이라고 읽는다) 해보다가 드디어 글을 쓸 결심을 했다.
아무래도 스터디를 위한 글이나, 간단한 트러블 슈팅글보다는 캡처해야 할 내용도 많고 기억을 더듬어야 해서 작성할 때 시간이 오래 걸리는데... 어떻게 7월 초안에는 마무리를 했으면 좋겠다🥹 ... 힘을 내 나 자신아!
각설하고, 본 글에서는 CI/CD의 간단한 개념과 Jenkins, Ansible 을 통한 CI/CD구축 방법등을 담을 예정이다. 이 다음에는 k8s, AWS 환경까지 포함해서 파이프라인을 구축하는 글이 이어지지 않을까 싶다.
CI / CD 는 어디서 시작 되었을까?
소프트웨어 개발방법론에는 크게 폭포수모델과, 애자일이 있다. 폭포수 모델(waterfall)은 프로젝트 단계가 뚜렷하고, 각 단계가 완성되고 난 후 실행되는 특징을 가진다.
즉 다음과 같은 프로세스를 따른다.
- 요구사항 정의
- 분석/설계
- 구현
- 테스트
- 운영
이러한 폭포수 모델은 단계별 정의와 산출물이 명확하고 모형의 적용경험과 성공사례가 많지만, 신속한 대응이 어렵다는 단점을 가진다.
소프트웨어 개발 트렌드가 모바일 환경으로 변화하고 시장 적시성과 잦은 배포의 중요성이 부각되면서 이러한 폭포수 모델의 단점을 개선하기 위해 애자일 방법론(agile)이 등장하게 되었다.
애자일 방법론(agile)은 폭포수 모델의 효율성 저하를 보완하고, 프로젝트의 생명주기동안 반복적인 과정을 통해 프로젝트를 진행 시키며 사용자의 요구사항을 만족 시킨다. 개발과 함께 즉시 피드백을 받아서 유동적으로 개발이 가능하다.
애자일 방법론의 유형에는 XP(익스트림 프로그래밍), 스크럼, 린 등이 있으며 그 중에서 XP는 페어 프로그래밍, TDD, CI(지속적통합)등의 12가지 기본 원리를 가진다.
또한 On-Premise 에서 Cloud 환경으로 변화함에 따라 클라우드 네이티브 아키텍처의 중요성이 대두 되었다.
클라우드 네이티브 아키텍처란 클라우드에서 빌드 되고 클라우드 컴퓨팅 모델을 최대한 활용하는 워크로드를 디자인하고, 생성 및 운영하는 접근 방식을 의미한다. 클라우드 네이티브 아키텍처의 대표적인 키워드는 다음과 같다.
- MSA
- 컨테이너 가상화
- DevOps → 개발과 운영간에 협업하는 것을 의미함 ( Development + Operations ). 엔지니어가 프로그래밍, 빌드, 배포 및 서비스까지 실행시키고 사용자와 끊임없이 소통하면서 서비스를 개선해 나가는 일련의 과정과 문화
- CI/CD → 파이프라인에 의해서 자동화된 빌드/배포를 제공함
결론적으로, 소프트웨어 개발의 트렌드가 애자일 방식과 클라우드 네이티브 아키텍처로 변화함에 따라, CI/CD는 자연스럽게 따라오게 되었다고 볼 수 있다.
* CI ( Continous Integration )
지속적 통합은 코드 변경 사항을 공유 소스 리포지토리에 자동으로 자주 통합하는 것을 의미한다. 여기서 공유 소스 리포지토리는 일반적으로 협업시 사용하는 SCM(Git, SVN ...)에 해당한다.
* CD ( Continous Delivery 또는 Continous Deployment )
지속적 제공 및 지속적 배포를 의미한다. 지속적 제공은 CI에서 빌드와 단위테스트를 자동화 한 다음 검증된 코드를 리포지토리에 릴리즈 하는 것을 의미한다. 지속적 배포는 지속적 제공의 확장으로 개발자의 변경사항을 리포지토리에서 프로덕션으로 릴리즈하는 것을 자동화하여 고객이 사용할 수 있게 하는 것을 의미한다. 상황에 따라 지속적 제공과 지속적 배포를 알맞게 선택하여 사용할 수 있다.
Jenkins 와 Ansible
CI/CD 도구는 일반적으로 Jenkins, Travis, GitLab, CircleCI, Azure DevOps, Bamboo등이 있을 수 있겠으나 본 글에서는 Jenkins를 선택 했다. Jenkins를 선택한 이유는 현 시점 가장 인기있고 범용적으로 사용되는 오픈소스이기 때문이다. ( 실제 사용률 출처 )
곧 Github Actions에게 따라잡힐 것 같긴하지만... 4년차쯤되어서 감히 말해보건데 사실 도구 사용방법은 한 가지만 정확히 숙지하면 전반적인 흐름은 비슷하게 돌아가서 적응은 쉽게 할 수 있기 때문에 뭘 사용하든 본인이 개발하는 팀이 선호하는 방향에 가장 적절한 걸 선택하면 된다고 생각한다.
그리고 일단 무료다. Free!
이러한 CI/CD 도구를 사용해서 파이프 라인을 만드는 방식은 다양하다. 중간에 IaC를 두고 k8s/Docker 로 배포하거나, Iac 없이 WAS에 단독으로 올릴 수도 있다.
여기서 IaC는 Infrastructure as Code의 준말로 전통적인 인프라 관리 방식을 대체하는 방법을 의미한다. 즉, 인프라 구성 요소를 코드로 정의하고 관리할 수 있다. 이를 통해 서버, 네트워크, 데이터베이스 등의 인프라를 자동화하고 일관성있게 배포하는 것이 가능하다.
IaC는 주로 클라우드 환경에서 사용되며, 인프라 구성 파일을 버전 관리 시스템에 저장하여 변경 사항을 추적하고 협업할 수 있게 한다.
쉽게 말하면 docker image 다운로드하고, docker build 해서 컨테이너 생성하고, 실행하고 하는 것들을 IaC를 통해 작성할 수 있다는 소리다. IaC를 통해 인프라 세팅에 대한 설정을 미리 작성해 둘 수 있고, 한번에 설정한 서버 여러대에 동일한 작업을 수행하게 할 수 있게 때문에 일관성있는 배포가 가능한 것이다.
이전 회사에서 수동 배포할일이 있었는데, 다중화 서버가 걸리면 하나하나 했던 기록이 새삼 떠오른다. 서버실에서 찬바람 맞아가며 배포했던 나날들... 자동화는 참 좋은 것이다.
어쨌든 본 글에서는 IaC는 Ansible을 선택했다.
Ansible의 장점은 다음과 같다.
- 다른 서버를 관리할 때, Agent를 관리할 때 별도의 서버 설치가 불필요하다.
Ansible은 서버 간 통신시 python을 통해 ssh을 사용하여 통신하므로 별도의 Agent가 불필요하다. 따라서 Ansible 서버만 구축하면 Ansible 서버에서 보내는 요청을 받는 Agent 서버들에는 별도의 설정이 필요 없다. ( python을 통해 통신하므로 python만 설치되어 있으면 된다 )
결론적으로, Jenkins와 Ansible을 사용해서 다음과 같이 구성했다.
여기서 playbook이란 ansible에서 제공하는 모듈로, 각 agent 서버에 어떤 행동을 할지 관리하는 역할을 한다. 상세한 명령어 사용 방법은 다음 글에서 구체적인 실습 상황과 함께 작성하도록 하겠다.
ref.
'Dev > CI&CD' 카테고리의 다른 글
| Jenkins, Ansible로 CI/CD 구축하기 (3/3) (0) | 2024.07.15 |
|---|---|
| Jenkins, Ansible로 CI/CD 구축하기 (2/3) (0) | 2024.07.02 |