my-blog: CI/배포 워크플로우를 raspiWorker1 셀프 호스트 러너로 이전

요약

이번 커밋은 my-blog 프로젝트의 CI 및 배포 워크플로우를 기존의 defunct 러너에서 새로운 raspiWorker1 셀프 호스트 러너로 전환하는 작업을 수행했습니다. 이를 통해 배포 과정의 복잡성을 줄이고 효율성을 높였습니다. 작업은 2026년 7월 15일에 이루어졌습니다.

배경 및 목적

기존에 사용하던 node2 및 node3 레이블이 붙은 셀프 호스트 러너가 더 이상 유효하지 않게 되었습니다. 실제 배포 대상 서버인 raspiWorker1 (IP 주소: 172.30.1.94)에서 새로운 러너가 설정되었기 때문에, CI/CD 파이프라인이 이 새로운 환경을 사용하도록 업데이트해야 했습니다. 목적은 더 이상 사용되지 않는 리소스에 대한 의존성을 제거하고, 실제 배포 환경에 맞춰 워크플로우를 최신화하는 것입니다.

구현 내용

이번 커밋에서는 GitHub Actions 워크플로우 파일 두 개를 수정하여 러너 설정을 변경했습니다.

• 변경된 파일 목록:

  • .github/workflows/ci.yml
  • .github/workflows/deploy.yml

• 총 변경 라인 수:

  • 추가: 11 라인
  • 삭제: 14 라인

.github/workflows/deploy.yml 변경 사항

이 파일은 배포 프로세스를 정의하는 핵심 파일입니다.

• 러너 변경: runs-on 설정을 [self-hosted, node3]에서 [self-hosted, raspiWorker1]로 변경하여 배포 작업이 raspiWorker1에서 실행되도록 했습니다.
• SSH 접속 제거: 기존에는 SSH를 통해 원격 서버에 접속하여 git pull 및 redeploy.sh를 실행했습니다. 하지만 이제 러너가 직접 배포 대상 서버에서 실행되므로, SSH 접속 관련 설정(ssh -i ~/.ssh/deploy_key -o StrictHostKeyChecking=yes -o ConnectTimeout=30 jcw@172.30.1.94)이 제거되었습니다.
• 직접 실행: redeploy.sh 스크립트가 ~/my-blog 디렉토리로 이동하여 git pull origin master를 실행한 후, bash deployment/redeploy.sh를 직접 실행하도록 변경되었습니다.
• 알림 메시지 업데이트: 배포 실패 시 출력되는 에러 메시지도 Node2 서버에서 raspiWorker1 서버로 업데이트되었습니다.

.github/workflows/ci.yml 변경 사항

이 파일은 Continuous Integration (CI) 프로세스를 정의합니다.

• 러너 변경: web-page-tests 작업의 runs-on 설정을 [self-hosted, node3]에서 [self-hosted, raspiWorker1]로 변경하여 Playwright 테스트가 raspiWorker1에서 실행되도록 했습니다.

기술적 의사결정

이 커밋에서 이루어진 주요 기술적 의사결정은 SSH 접속을 통한 원격 실행 방식에서 러너가 직접 실행되는 방식으로 변경한 것입니다.

선택 이유

• 단순성 및 효율성: 러너가 배포 대상 서버에 직접 존재하므로, SSH 연결 설정, 키 관리, 네트워크 문제 해결 등의 복잡성이 사라집니다. 이는 파이프라인을 더 간단하고 안정적으로 만듭니다.
• 보안 강화: SSH 키를 노출하거나 관리할 필요가 줄어들어 보안 측면에서도 이점이 있습니다.
• 직접성: 배포가 이루어지는 환경에서 직접 작업을 수행하므로, 실제 배포 환경과의 차이로 인한 문제를 줄일 수 있습니다.

다른 대안

• 기존 SSH 방식 유지: 가장 간단한 방법이었지만, 러너가 defunct 상태이기 때문에 불가능했습니다.
• 새로운 SSH 서버 설정: raspiWorker1에 별도의 SSH 서버를 구성하고 기존처럼 원격으로 접속하는 방식도 고려할 수 있었습니다. 하지만 이는 추가적인 설정 및 유지보수 부담을 야기합니다.

장단점 분석

• 직접 실행 방식 (선택):
  • 장점: 설정 및 유지보수 간편, 보안 강화, 파이프라인 단순화, 안정성 향상.
  • 단점: 러너가 배포 서버와 분리되지 않아, 만약 러너가 공격받을 경우 배포 서버까지 위험에 노출될 가능성이 있습니다 (물론 이는 셀프 호스트 러너 사용 시 항상 고려해야 할 부분입니다).

배운 점 및 개선점

배운 점

• GitHub Actions 워크플로우에서 runs-on 설정을 통해 특정 셀프 호스트 러너를 지정하는 방법을 명확히 이해했습니다.
• 기존의 배포 스크립트가 SSH 연결을 가정하고 작성되었으나, 러너가 직접 실행될 경우 해당 부분을 제거하고 간단한 명령으로 대체할 수 있다는 점을 알게 되었습니다.
• redeploy.sh와 같은 스크립트를 CI/CD 파이프라인에 통합하는 것이 프로젝트 배포를 자동화하는 효과적인 방법임을 다시 한번 확인했습니다.

개선점 및 다음 단계 계획

• 러너 격리: 현재 CI/CD 러너와 배포 대상 서버가 동일한 raspiWorker1 위에 있습니다. 보안 및 안정성을 위해, CI/CD 러너는 별도의 서버에 두고 배포 대상 서버에는 SSH로 접속하는 이전 방식을 고려하거나, 배포 서버 자체를 더 안전하게 격리하는 방안을 검토해야 합니다.
• 오류 처리 강화: redeploy.sh 스크립트 내에서 발생할 수 있는 다양한 오류 상황에 대한 처리를 더 견고하게 만들 필요가 있습니다. 현재는 간단한 echo 메시지만으로는 상세한 문제 파악이 어려울 수 있습니다.
• 파이프라인 모니터링: 배포 성공/실패 여부를 Slack 등 다른 알림 채널로 연동하는 것을 고려하여, 문제 발생 시 더 신속하게 인지하고 대응할 수 있도록 개선할 수 있습니다.