개인 프로젝트 CI/CD 간소화하기

2025. 5. 29. 16:05·문제, 해결, 개선

개인 프로젝트를 진행하면서, `github actions`와 `dockerhub`를 통해 자동배포 파이프라인을 사용하고 있다. 이전에 해커톤을 하며 배웠던 보일러플레이트 코드를 가져다가 사용하고 있는데, 불필요한 부분이 있는 것 같아 개선해보고자 한다.

 

기존 자동배포 흐름

기존에는 `dockerhub`에 이미지를 push / pull 하는 과정이 있었다. (그림에서 빨간색 화살표 부분)

그렇기 때문에 github actions의 과정에서 dockerhub에 로그인하는 부분이 별도로 필요하였다.

docker login -u "$DOCKER_USERNAME" -p "$DOCKER_PASSWORD"

 

이전에 코드를 가져와서 사용할 때는 따로 의문을 가지지 않았으나, 이제 와서 보니 굳이 dockerhub가 없어도 될 것 같다고 생각하였다.

1. git을 통하여 버전관리를 하므로, 별도의 이미지 버전관리가 필요하지 않다.

2. 단일 서버 위주의 개발 및 배포이므로 한 번의 이미지 전송만으로 충분하다. dockerhub를 통해 이미지를 중앙화할 필요가 없다.

 

앞으로의 다른 프로젝트들을 고려해보았을 때도, dockerhub의 필요성이 느껴지지 않았다. 따라서 외부 서비스인 dockerhub를 제거하고, `scp`를 통하여 배포 서버로 이미지를 바로 전송하는 방법을 사용하려고 한다.

 

CI 서버에서 SCP를 이용하여 이미지 전송

dockerhub 대신, scp를 사용하여 이미지를 전송하였다. (빨간색 화살표 부분)

 

 `appleboy/scp-action`을 통해, 빌드한 도커 이미지(tar 파일)를 서버로 전송하는 방식을 사용하였다. 

.github/workflows/deploy.yml

 

SCP 속도 개선하기

별도의 문제 없이 작동할 줄 알았는데, 꽤 불편한 문제가 발생했다.

docker 이미지를 SCP로 전송하는 방식을 사용하니 이미지 전송만 2분 정도로 꽤 큰 차이가 났다.

`Github actions`(미국 서버) -> `배포 서버`(한국 홈서버)로 연결되는 SCP의 속도가 너무 느려서 (대역폭 제한이 걸려 있는 것일까?), 배포 action이 훨씬 오래 걸리는 것 같다.

 

이미지를 전송하는 속도를 개선하기 위하여, 몇 가지 방법을 사용해 보았다.

1.  SCP 대신 rsync로 이미지 전송

.github/workflows/deploy.yml

rsync의 `-z` 옵션으로, 이미지를 압축하여 전송할 수 있다.

 

Github actions 로그:

Run rsync -avz -e "ssh -i private_key -p $SSH_PORT" whenwhen.tar $SSH_USER@$SSH_HOST:~/
sending incremental file list
whenwhen.tar

sent 277,270,427 bytes  received 35 bytes  3,242,929.38 bytes/sec
total size is 504,345,600  speedup is 1.82

전체 이미지 사이즈 `504,345,600 bytes`에서, `277,270,427 bytes`로 약 1/2 정도까지 압축되어 전송되었다.

`speedup is 1.82` -> 무려 1.82배 더 효율적으로 전송했다고 한다.

 

 2. 더 가벼운 베이스 이미지 사용

현재는 베이스 이미지에 `openjdk:21-jdk-slim`를 사용하고 있다.

하지만 CI 서버에서 빌드를 진행하므로 도커 이미지에 JDK가 포함될 필요가 없다.

따라서 JRE만 포함된 실행용 경량 이미지를 사용하여 도커 이미지의 크기를 줄이고자 한다.

 

Dockerfile:

FROM openjdk:21-jdk-slim
->
FROM eclipse-temurin:21-jre-alpine

 

Github actions 로그:

Run rsync -avz -e "ssh -i private_key -p $SSH_PORT" whenwhen.tar $SSH_USER@$SSH_HOST:~/
  
sending incremental file list
whenwhen.tar
sent 118,839,370 bytes  received 35 bytes  1,760,583.78 bytes/sec
total size is 267,801,600  speedup is 2.25

전체 이미지 사이즈가  `504,345,600 bytes`에서 `267,801,600 bytes`로 2배 가량 줄어들었다.

 

rsync, 가벼운 베이스 이미지 두 가지 방법을 사용하여, 배포 시간을 기존 2분 이상에서 1분 정도로 개선하였다.

 

배포 서버에서 직접 git pull 하는 방법은 어떨까?

이전까지는 CI 도구 (github actions)에서 이미지를 빌드하고, 해당 이미지를 아티팩트로 올린 후 서버에 전송하여 실행하는 방법을 사용하였다.

만약 여러 서버에 배포하는 경우에는 하나의 이미지를 여러 번 배포하므로 의미가 있겠지만, 개인 프로젝트를 단일 서버에 배포하는 경우에는 '배포 서버에서 git 코드를 pull하고 이미지로 빌드하여 실행하는 방식'도 나쁘지 않을 것 같았다.

외부 서비스를 사용하지도 않고 불필요한 네트워크 전송 흐름도 없으므로 배포가 더 빨라지고 간소화될 것이라고 생각했다.

위와 같은 방법은 다른 방법들에 비해 간단하고 매우 빠르다.

 

하지만

1. 빌드/테스트 환경과 프로덕션 환경이 구분되지 않는다는 점

2. 배포 서버에서 빌드하므로 부하가 발생한다는 점

3. 배포 서버에 도커 관련 데이터가 많이 쌓이고, 커밋에 따른 도커 이미지 버전 추적이 어렵다는 점

 

`단일 책임 원칙`과 `확장성`을 고려해보았을 때, 이 방법보다는 'CI 서버에서 빌드하고, 이미지를 전송하여 배포 서버에서 실행하는 방법`이 적합하다고 생각하였다.

'문제, 해결, 개선' 카테고리의 다른 글

PPTX -> PDF 글씨체 깨짐 현상 해결  (0) 2025.10.14
Linux 홈 서버 네트워크 끊김 오류 해결하기 (2)  (3) 2025.08.13
Linux 홈 서버 네트워크 끊김 오류 해결하기 (1)  (0) 2025.01.31
우분투가 설치된 삼성 노트북에서 배터리 관리하기 (실패)  (0) 2025.01.26
Github Secrets 하나만으로 모든 환경변수 관리하기  (6) 2025.01.21
'문제, 해결, 개선' 카테고리의 다른 글
  • PPTX -> PDF 글씨체 깨짐 현상 해결
  • Linux 홈 서버 네트워크 끊김 오류 해결하기 (2)
  • Linux 홈 서버 네트워크 끊김 오류 해결하기 (1)
  • 우분투가 설치된 삼성 노트북에서 배터리 관리하기 (실패)
j30ngwoo
j30ngwoo
  • j30ngwoo
    Jeongwoo Dev Blog
    j30ngwoo
  • 전체
    오늘
    어제
  • 글쓰기 관리
    • 분류 전체보기 (17)
      • 탐구, 생각, 정리 (5)
      • Problem Solving (2)
      • 문제, 해결, 개선 (7)
      • Projects (3)
  • 인기 글

  • 태그

    kupc2023
    whenwhen
    티스토리챌린지
    backend
    오블완
    spring
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.1
j30ngwoo
개인 프로젝트 CI/CD 간소화하기
상단으로

티스토리툴바