[6주차] Jenkins에 대한 이해

[월간-CS][24년 4월] React, Next 배포와 배포 자동화 A부터 Z
이민석's avatar
May 13, 2024
[6주차] Jenkins에 대한 이해

이 문서는 [월간-CS][24년 4월] React, Next 배포와 배포 자동화 A부터 Z를 위해서 작성된 문서입니다. 이 문서에는 그 어떤 저작권이 없으며, 편하게 참고 및 사용하셔도 됩니다.

서론

본 문서에서는 GitHub Actions이 가진 한계와 문제점을 짚어보고 이에 따라서 Jenkins를 이용해서 이 문제를 해결해보겠습니다.

이 문서는 GitHub Actions의 한계를 Jenkins를 통해서 해결하는 것이 목적인 문서입니다. 따라서 “Jenkins가 무조건 좋다” 혹은 “그 외의 해결방법이 없다”를 의미하지 않습니다.

일반적으로

코드 형상 관리 툴인(e.g. GitHub, GitBucket, GitLab)을 통해서 협업을 할 때, 저희는 각종 지속적 통합(Continuous Deployment) 도구를 선택해서 사용하게 됩니다.

GitHub Action, Jenkins, Circle CI 등의 다양한 도구가 존재하며 최근에는 많은 사람들이 GitHub Action을 사용하고 있습니다.

따라서 이번에는 Unchaptered (Blog) | [월간-CS][24년 4월] React, Next 배포와 배포 자동화 A부터 Z (Blog) — [1주차] GitHub Action에서 React 지속적 전달 구현하기 (CF, S3) # GitHub Action 파일 작성하기를 통해서 취약점을 찾고 그 문제 해결 방법을 알아보겠습니다.

GitHub Action 장단점 비교

  1. GitHub Action의 보안 취약점

  2. GitHub Action의 장애 상황

  3. GitHub Action의 Runner 성능 이슈

  4. GitHub Action의 캐시 비효율성

  5. GitHub Action의 부족한 참고 자료

  6. GitHub Action의 장점들

GitHub Action의 보안 취약점

저희는 해당 주차에서 아래와 같은 GitHub Workflows 구문을 작성하였습니다.

      - name: Upload to S3 
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY  }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY  }}
        run:
          aws s3 cp --recursive --region us-east-1 ./build s3://${{ secrets.AWS_S3_BUCKET  }}

위에서 보면 GitHub Action의 환경변수는 누구나 꺼낼 수 있기 때문에 매우 취약합니다.

  1. AWS Credentials의 노출

    aws s3 cp ~~ ${{}} 아래에 이런 코드를 추가하면 환경 변수를 꺼낼 수 있습니다.

    echo ${{ secrets.AWS_ACCESS_KEY_ID }}
    echo ${{ secrets.AWS_SECRET_ACCESS_KEY }}

    만약 이 환경 변수에 AdministratorFullAccess와 같은 권한이 부여되어 있다면, 엄청난 요금을 청구받는 일이 일어날 수 있습니다.

    이런 CSP 업체의 Credentials의 경우 OIDC(OpenID Connect)를 이용해서 보완할 수 있습니다.

  2. S3 Bucket Name 노출

    AWS S3에서는 버킷에 요청이 들어오는 건 별로 비용이 나오는 항목이 있습니다. 따라서 S3 Bucket Name이 공유될 경우, 무작위 요청을 통해서 많은 요금이 과금될 수 있습니다.

    AWS S3 요금으로 한 놈 담궈버리는 방법, 코딩애플 (Youtube)

GitHub Action의 장애 상황

GitHub Action이 실행되는 환경인 runner는 결국 누군가가 개발하고 있는 도구입니다.

따라서 일년에 수차례 이상 장애가 발생을 하고 있으며, 이 경우 GitHub Action에 의존하고 있는 수많은 서비스(e.g. React, Next, Next, Spring, …)들을 배포할 수 없습니다.

이 모든 내용들을 수동으로 배포해야 합니다.

GitHub Action의 Runner 성능 이슈

GitHub Action은 저장소 유형이 Public인지 Private 인지에 따라서 다음과 같은 성능을 제공하고 있습니다.

일반적으로 사용하는 Linux를 비교하면 다음과 같습니다.
Standard GitHub-hosted runners for Public Repositories, GitHub Action (Docs)
Standard GitHub-hosted runners for Private Repositories, GitHub Action (Docs)

유형

CPU

MEM

SSD

Public Repository

4 GB

14 GB

14 GB

Private Repository

2 GB

7 GB

14 GB

따라서 복잡한 도커 이미지 배포와 같이 성능이 필요한 배포의 경우 오랜 시간이 소요될 수 있습니다.

GitHub Action의 캐시 비효율성

동일한 버전의 React 프로젝트들이 기록된 10개의 GitHub Repository가 있습니다.

GitHub Action은 개별 저장소 마다 작동하므로, GitHub Action Runner는 10개가 개별적으로 작동합니다.

따라서 react@18.3.1는 10개나 다운로드 받게됩니다.

모든 node_modules에 대해서 이런 일이 일어나면 배포 과정 전체가 비효율적으로 진행됩니다.

비교적 최신에 나온 기능들인 yarn berrypnpm은 단일 PC에서 N~NNN개의 프로젝트에 대한 node_modules를 캐싱하는 혁신적인 기능들을 제공해주고 있습니다.

하지만 GitHub Action은 사실상 복수 PC에서 작동하므로 이런 이점을 누릴 수 없습니다.

GitHub Action의 부족한 참고 자료

GitHub Action은 비교적 최신에 나온 툴입니다.

많은 사용 사례가 나오고 있지만 개인적으로 Jenkins 등에 비해 참고자료가 적은 편입니다.

GitHub Action의 부족한 호환성

코드 형상 관리 툴을 SVN, GitLab, GitBucket을 쓰는 경우 GitHub Action을 사용할 수 없습니다.

GitHub Action의 장점들

그럼에도 불구하고 초창기 스타트업에서 GitHub Action을 선택하는 데에는 아래와 같은 이유가 있습니다.

  1. 무료 👍👍👍

  2. 별도의 인프라 및 관리자 필요 없음 👍👍

  3. GitHub과의 강력한 통합 👍

해결 방법

대체재 선택

Jenkins, CircleCI, ArgoCD, CyclicSH 등의 다양한 도구가 존재합니다.

저희는 가장 많은 참고자료가 있고 역사가 깊은 Jenkins를 선택하는 것으로 결정하였습니다.

참고 자료

Share article
RSSPowered by inblog