인기포스트

ABOUT ME

도넛

Today
Yesterday
Total
  • CI-CD(Continuous Integration-Continuous Delivery)
    Infra 2023. 9. 28. 22:06
    728x90

    참고 블로그

    개념

    CI/CD (Continuous Integration/Continuous Delivery)는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법으로 CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포에있다.
    CI/CD는 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는 문제(일명 “통합 지옥(integration hell)”)를 해결하기 위한 솔루션이 될 수 있다.

    특히, CI/CD는 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공하는데 이러한 구축 사례를 일반적으로 “CI/CD 파이프라인”이라 부르며, 개발 및 운영팀의 애자일 방식 협력을 통해 DevOps 또는 SRE(사이트 신뢰성 엔지니어링) 방식으로 지원된다.

    CI/CD 차이

    CI - 지속적인 통합

    CI/CD의 "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미합니다. 지속적인 통합이 제대로 구현되면 애플리케이션 코드의 새로운 변경 사항이 정기적으로 빌드 및 테스트를 거쳐 공유 리포지토리에 병합된다. 따라서 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌하는 문제를 이 방법으로 해결할 수 있다.

    CD - 지속적인 서비스 제공 / 배포

    "CD"는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환하여 사용됩니다. 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.

    지속적인 서비스 제공

    지속적인 제공이란 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리(예: GitHub 또는 컨테이너 레지스트리)에 자동으로 업로드되는 것을 뜻하며, 운영팀은 이 리포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포할 수 있습니다. 이는 개발팀과 비즈니스팀 간의 가시성 및 커뮤니케이션 부족 문제를 해결해 줍니다. 그러므로 지속적인 서비스 제공은 최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 한다.

    CI의 빌드 자동화, 유닛 및 통합 테스트 수행 후, 이어지는 지속적 제공 프로세스에서는 유효한 코드를 리포지토리에 자동으로 릴리스하고, 효과적인 지속적 제공 프로세스를 실현하기 위해서는 개발 파이프라인에 CI가 먼저 구축되어 있어야 한다. 지속적 제공의 목표는 프로덕션 환경으로 배포할 준비가 되어 있는 코드베이스를 확보하는 것이다.

    지속적 제공의 경우, 코드 변경 사항 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계에는 테스트 자동화와 코드 릴리스 자동화가 포함되며 이 프로세스를 완료하면 운영팀이 더욱 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있다.

    지속적인 배포

    지속적인 배포(또 다른 의미의 “CD”: Continuous Deployment)란 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미하고 이는 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결한다. 지속적인 배포는 파이프라인의 다음 단계를 자동화함으로써 지속적인 서비스 제공의 장점을 활용한다.

    CI/CD는 지속적 통합 및 지속적 제공의 구축 사례만을 지칭할 때도 있고,
    지속적 통합, 지속적 제공, 지속적 배포라는 3가지 구축 사례 모두를 의미하는 것일 수도 있다.

    좀 더 복잡하게 설명하면 "지속적인 서비스 제공"은 때로 지속적인 배포의 과정까지 포함하는 방식으로 사용되기도 한다.

    결과적으로 CI/CD는 파이프라인으로 표현되는 실제 프로세스를 의미하고, 애플리케이션 개발에 지속적인 자동화 및 지속적인 모니터링을 추가하는 것을 의미한다.

    CI/CD 파이프라인에 구현된 자동화 수준 정도에 따라 그 의미가 달라진다. 대부분의 기업에서는 CI를 먼저 추가한 다음 클라우드 네이티브 애플리케이션의 일부로서 배포 및 개발 자동화를 구현해 나간다.

    Jenkins 과 GitHub Actions의 개념, 차이점

    젠킨스(Jenkins)는 거의 모든 언어의 조합과 소스코드 리포지토리(Repository)에 대한 지속적인 통합(CI)과 지속적인 배포(CD)를 무료로 제공한다.

    젠킨스는 다른 일상적인 개발 작업을 자동화할 뿐 아니라 파이프라인(Pipeline)을 사용해 거의 모든 언어의 조합과 소스코드 리포지토리에 대한 지속적인 통합과 지속적인 전달 환경을 구축하기 위한 간단한 방법을 제공해준다.

    젠킨스가 각각의 단계에 대한 스크립트 작성의 필요성을 없애주지는 않지만, 사용자가 쉽게 구축할 수 있는 것보다 더 빠르고 더 강력하게 빌드(Build), 테스트, 그리고 배포(deployment) 도구 등 체인 전체를 통합할 수 있는 방법이 될 수 있다.

    Github Actions은 Github 저장소를 기반으로 소프트웨어 개발 Workflow를 자동화 할 수 있는 도구로 간단하게 말하자면 Github에서 직접 제공하는 CI/CD 도구라고 할 수 있다.

    Workflow는 Github 저장소에서 발생하는 build, test, package, release, deploy 등 다양한 이벤트를 기반으로 직접 원하는 Workflow를 만들 수 있습니다.
    Workflow는 Runners라고 불리는 Github에서 호스팅 하는 Linux, macOS, Windows 환경에서 실행된다.

    그리고 이 Runners를 사용자가 직접 호스팅하는 환경에서 직접 구동시킬 수도 있으며(self-hosted runner) Github 마켓 플레이스에는 여러 사람이 공유한 Workflow는 찾을 수 있고, 자신이 직접 만들어서 공유할 수도 있습니다.

    사용료는 public 저장소는 무료이며, private저장소는 해당 계정에 부여된 무료 사용량 이후에 과금이 부과된다.
    Github 무료 계정의 전체 비공개 저장소를 기준으로 한달에 500MB 스토리지와 실행 시간 2,000분(minute)까지 제공된다.

    Github Actions Workflow는 저장소마다 최대 20개까지 등록할 수 있다.
    그리고 Workflow 안에 존재하는 Job이라는 단계마다 최대 6시간 동안 실행될 수 있고, 초과하게 되면 자동으로 중지된다.

    그리고 Github 계정 플랜에 따라 전체 Git 저장소를 통틀어 동시 실행할 수 있는 Job 개수가 정해져 있다.
    Job 안에서 Github API를 호출한다면 1시간 동안 최대 1,000번까지만 가능합니다.

    젠킨스 동작 방식

    젠킨스는 주요 운영체제용 자바 8 WAR 아카이브와 설치 패키지, 홈브루(Homebrew) 패키지, 도커 이미지, 그리고 소스코드 형태로 사용할 수 있다. 소스코드는 대부분 자바이며, 몇 개의 그루브(Groovy), 루비(Ruby), 그리고 앤틀러(Another Tool For Language Recognition, ANTLR) 파일이 들어 있다.

    젠킨스를 실행하면 웹 화면을 생성하며 REST API 호출로 구동 된다.

    젠키스 사용 장점

    • 프로젝트의 표준 컴파일 환경에서 컴파일 오류 검출
    • 자동화 테스트 수행
    • 코딩 규약 준수여부 체크
    • 프로파일링을 통해 소스 변경에 따른 성능의 변화 감시
    • 테스트 환경에 대한 배포작업
    • 개발 업무를 도와주는 많은 플러그인을 가지고 있음

    GitHub Actions 사용 장점

    • 기존의 Circle CI / Travis CI / Jenkins CI와 같은 서비스 또는 설치형 CI처럼 Github에서도 Actions이라는 CI툴을 선보였으며 별다른 복잡한 절차 없이 Github를 통해 사용할 수 있다는 장점이 있다.
    • 워크 플로우 복제 용이
    • GitHub와 통합
    • 라이브 로그
    • 다중 컨테이너 테스트
    • 리눅스, 맥, 윈도우, ARM 및 컨테이너를 쉽게 빌드, 테스트
    • 여러 운영체제 및 런타임 버전에서 동시 테스트 가능
    • 모든 언어 어플리케이션 빌드, 테스트 및 배포

    Jenkins 과 GitHub Actions 차이점

    요약

    • 설정에 자신이 있고 제어와 비용이 문제가 없으며 규모가 크다.
      Jekins
    • 그 외
      Github Actions

    Github Actions

    GitHub Actions는 DevOps를 넘어 리포지토리에서 다른 이벤트가 발생할 때 워크플로를 실행할 수 있다. 예를 들어 누군가 저장소에 새 문제를 생성할 때마다 적절한 레이블을 자동으로 추가하는 워크플로를 실행한다.

    GitHub는 Linux, Windows 및 macOS 가상 머신을 제공하여 워크플로를 실행하거나 자체 데이터 센터 또는 클라우드 인프라에서 자체 호스팅 러너를 호스팅할 수 있다.

    이 때 주의할 점으로 GitHub Actions은 CI/CD를 위한 자동화 도구일 뿐 그 외 컨테이너화된 서비스가 필요할 경우 Docker 컨테이너에서 직접 실행되도록 워크플로의 작업을 구성해야 한다.

    결국 AWS EC2와 S3같은 서버와 정적 파일을 담당하는 기관이 사용된다.

    Github에서 제공하는 Actions에 대한 가이드 목차는 다음과 같다.

    • GitHub Actions 이해
    • 작업 찾기 및 사용자 지정
    • Github Actions의 필수 기능
    • 워크플로 정보
    • 워크플로 재사용
    • GitHub Actions에 대한 보안 강화

    프론트: React, AWS S3 정적 웹 호스팅 백엔드: Spring Boot, MySQL, AWS EC2 인스턴스 CI/CD: Github Actions, AWS CodeDeploy

    참고 - onibmag

    CI/CD 개선 전략

    첫 번째 주변 사람들, 즉 개발자들의 이야기에 귀를 기울이는 것이다. 개발자가 그들의 관점에서 무심코 이야기하는 것 속에서 많은 피드백을 얻을 수 있다. 개발 문서, 회의록, 채팅방, 그리고 자리에 모여서 나누는 이야기 등 다양한 곳에서 들려오는 작은 목소리에도 호기심을 갖고 귀를 기울이는 것이 중요하다.

    두 번째는 CI/CD 작업에서 생산되는 데이터를 여러 사람들이 업무에 활용할 수 있도록 보여주는 것이다. 이 데이터를 통해 개발자들은 현재 상태를 정량적으로 파악하여 미래를 예측해 볼 수 있다.

    그렇게 되면 개발자도 자동화 업무에서 진행되는 개선 작업에 더 관심을 갖게 될 것이고, 이를 통해 자동화 업무를 수행하는 저와 의사소통할 수 있는 통로가 만들어진다.

    CI/CD 데이터 시각화

    어떤 것을 보여줄지 정하기 위해서는 먼저 무엇을 보여줄 수 있는지 알아야 한다.

    • 소스 코드 정보
      • 신규로 추가한 라인 수, 변경된 라인 수, 소스 코드 파일 개수, 커밋 개수 등
    • 소스 코드 정적 분석 데이터
    • 소스 코드 빌드 데이터
      • 작업별 빌드/테스트 시간
      • 빌드 성공/실패율, 빌드 로그
      • 빌드 테스트 리포트, 패키지(APK) 정보, 버전 정보
      • 빌드 옵션, 메모리 덤프 데이터
      • 빌드 태스크 의존성 정보
    • 빌드 시스템 정보
      • 사용자 시스템 정보(CPU, 메모리)
      • CPU 사용량, 메모리 사용량, 디스크 사용량
      • 빌드 대기 시간, 빌드 장비 활용 시간

    이 외에도 아직 목적이 부여되지 않은 데이터들이 CI/CD 시스템에 많이 쌓여 있다.

    데이터 시각화 목표 설정

    무엇을 보여줄 수 있는지 파악했으니 이제 보여주고 싶거나 해결해야 할 문제가 무엇인지 목표를 정의해야 한다. 목표를 설정하는 방법은 두 가지로

    스스로 업무의 개선점을 파악해 데이터와 연관해서 해결 가능한 문제를 정의하는 방법과 외부에서 피드백을 받아 문제를 정의하는 것이다.

    전자의 경우 이미 수립한 업무 목표를 정량적으로 파악하는 데 도움을 준다.
    예를 들어, 개발자가 코드를 올리면 자동으로 수행되는 코드 검증 시간을 줄이는 것(Pull Request 리드 타임 개선)과 실제 배포 대상 코드가 배포되는 시간을 줄이는 것(릴리스 리드 타임 개선)과 관련하여 지표를 수립하여 빌드 관련 리소스와 스크립트 개선 작업 결과를 숫자로 확인할 수 있다.

    후자의 사례로, 개발 과정에서 배포되는 패키지 크기가 갑작스럽게 커지는 문제가 발생할수있기 때문에 문제를 빨리 탐지할 수 있는 체계를 마련할 필요가 있다.

    즉, 데이터 시각화의 첫 번째 목표는 후자의 사례에서 도출된, 배포 패키지 데이터를 수집하면서 갑작스럽게 크기가 증가할 경우 알림이 발생하는 것으로 잡을 수 있다.

    데이터 시각화 방법 결정

    • 빠르게 구축할 수 있고 문제가 발생했을 때 참고할 만한 레퍼런스가 많은가?
    • 데이터를 유연하게 수집할 수 있는가?
    • 설정을 손쉽게 변경할 수 있는가?
    • 알림 기능이 있는가?
    • 다양한 차트를 사용할 수 있고 관련 생태계가 구축되어 있는가?
    • 시스템을 처음 접하는 동료와도 손쉽게 시작할 수 있는가?

    위와 같은 기준에 비추어 많이 사용되며 다양한 영역에 걸쳐 많은 레퍼런스를 보유한 데이터 수집, 저장, 조회용 오픈소스인 ELK Stack과 시각화를 위한 오픈소스인 Grafana를 활용할 수 있다.

    ELK를 선택한 이유는 다양한 장비에서 서로 상이한 데이터들을 수집할 수 있는 기능을 가지고 있고, Grafana는 ELK뿐만 아니라 다양한 데이터베이스나 데이터 저장소에 연결해 차트를 그릴 수 있는 기능을 제공하고 있다.

    그리고 한 가지 더, 사내 인프라 서비스인 Verda에서 ELK 관리형 서비스를 제공하고 있어서 간단하게 신청해서 안정적인 시스템을 확보할 수 있었고, Grafana와 같은 연관 시스템은 Docker를 이용해 빨리 확보할 수 있다.

    시각화할 데이터 수집

    필요한 데이터를 정의하고 Jenkins를 이용해서 배포할 패키지를 만듭니다.

    • OS 플랫폼
    • 빌드 번호
    • 빌드 Job URL
    • 패키지명
    • 버전 정보
    • 패키지 크기 정보

    중요한 것은 꼭 필요한 정보 이외의 다른 데이터를 추가하면 안 된다는 것이다.
    다양한 데이터를 살펴보다 보면, 정보를 조금 더 추가해서 다른 곳에 동일한 데이터 세트를 활용하고 싶은 욕심이 생길 수 있지만 그 욕심을 버리고 처음 설정해 놓은 목표만 바라보고 가야 한다.
    (앞으로 꾸준히 이 데이터를 개선해 나갈 것이기 때문에 데이터를 합치거나 변환하는 것은 나중에 해도 된다.)

    데이터를 정의한 뒤 Jenkins에서 패키지를 만드는 작업이 종료되는 시점에 정의한 데이터를 ELK에 전달할 수 있도록 스크립트 설정을 추가합니다. 설정에 관한 상세한 설명은 EKL 튜토리얼을 참고하시기 바랍니다.

Designed by Tistory.

티스토리툴바