개인 프로젝트를 진행하면서, `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 파일)를 서버로 전송하는 방식을 사용하였다.

SCP 속도 개선하기
별도의 문제 없이 작동할 줄 알았는데, 꽤 불편한 문제가 발생했다.
docker 이미지를 SCP로 전송하는 방식을 사용하니 이미지 전송만 2분 정도로 꽤 큰 차이가 났다.
`Github actions`(미국 서버) -> `배포 서버`(한국 홈서버)로 연결되는 SCP의 속도가 너무 느려서 (대역폭 제한이 걸려 있는 것일까?), 배포 action이 훨씬 오래 걸리는 것 같다.
이미지를 전송하는 속도를 개선하기 위하여, 몇 가지 방법을 사용해 보았다.
1. SCP 대신 rsync로 이미지 전송

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 |