본문 바로가기

개발기/Save The Bunnies

6편: SSH 배포가 계속 죽어서 러너를 직접 만들었다

반응형

셀프 호스티드 러너로 배포 성공

Docker 빌드 중간에 죽는 배포

기능 개발과 별개로, 배포 자동화도 필요했습니다. 처음엔 GitHub Actions에서 SSH로 서버에 접속해서 docker compose build를 실행하는 흔한 방식으로 시작했습니다.

문제는 admin 이미지 빌드가 오래 걸리면 SSH 세션이 아무 데이터도 안 오가는 상태(idle)로 몇 분씩 유지된다는 점이었습니다. 그러다 어느 순간 i/o timeout으로 세션이 끊기고 배포가 실패했습니다. 타임아웃 값을 늘려도 소용없었습니다. TCP 레벨에서 idle 세션을 끊는 문제라, 애플리케이션 타임아웃 설정으로는 손댈 수 없는 영역이었습니다.

SSH 기반 배포는 오래 걸리는 Docker 빌드에 근본적으로 취약하다. Idle TCP 세션이 네트워크 레벨에서 끊기는 건 타임아웃 설정으로 못 막는다.

Self-hosted 러너로 우회

결론은 "서버 안에서 직접 실행"으로 문제를 없애는 것이었습니다. GitHub Actions self-hosted 러너를 서버에 설치하면, 워크플로우가 SSH를 거치지 않고 서버 위에서 그대로 실행됩니다. 네트워크 idle 문제 자체가 성립하지 않게 되는 거죠.

admin 레포부터 먼저 적용했습니다.

name: Deploy Admin
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: self-hosted
    steps:
      - name: Deploy
        run: |
          cd ~/save-the-bunnies
          docker compose build admin --no-cache
          docker compose up -d admin

 

main에 push되면 서버가 스스로 이미지를 빌드하고 컨테이너를 올립니다. admin 하나로 먼저 안정성을 확인한 다음, backend와 frontend에도 같은 방식을 복제하기로 계획을 세워뒀습니다. (이 계획이 실제로 어떻게 끝나는지는 뒤에서 다시 나옵니다.)

이번 편 요약

  • SSH 배포 + 오래 걸리는 Docker 빌드 = idle TCP 타임아웃으로 배포 실패
  • Self-hosted 러너로 전환해 네트워크 경유 자체를 없앰
  • admin 레포에 먼저 적용, backend/frontend는 추후 복제 예정으로 남겨둠

다음 편에서는

배포 이야기는 잠시 미뤄두고, 다시 기능으로 돌아옵니다. 입양 관리와 육아노트라는, 지금까지 중 가장 큰 도메인 두 개를 몰아서 만든 2주 이야기입니다.

반응형