[CI/CD] Github Self Hosted Runner 도입 경험

도입 배경

GitHub Actions를 통해 EC2에 배포된 서버에 자동 배포를 진행하고 있었으나, EC2 인바운드 규칙 설정 이후에 자동배포가 동작하지 않는 문제를 확인하였다.

이전에는 Github Actions runnner의 IP 주소가 SSH 접속을 통해 자동 배포를 하고 있었지만, 이제는 인바운드 규칙에 걸려 차단당하기 때문이었다.

그럼 해당 runner의 IP만 인바운드 규칙에 추가해주면 되지않을까? 라는 생각을 했지만 Github Actions의 runner는 일정한 범위 내에서 매번 다른 IP 주소를 사용한다. 

해결 방법을 찾던중 Self Hosted Runner 방식에 대해 알게되었다.

Github Self Hosted Runner란?

- Github Actions 워크 플로우를 실행하기 위해 사용자가 직접 관리하는 서버나 머신

- Github이 제공하는 클라우드 기반 Runner 대신, 자신의 인프라에서 CI/CD 파이프라인을 실행할 수 있게 해줌

- 클라우드 VM(AWS EC2.. 등), 온프레미스 서버 등에 설치

 

인바운드 규칙이 문제이고 보안상 인바운드 규칙을 수정할 수도 없으니, EC2에 설치해서 아웃바운드로 보내는 방식을 활용하였다.

핵심은 연결방향을 반대로 설정한것.

적용

내 github 저장소 > Settings > Actions > Runners > New self-hosted runner

 

EC2의 운영체제와 아키텍처 선택 후 SSH 접속하여 아래 코드 실행

이렇게 하라고 친절히 가이드 해줌

 

적용하고나면 runner가 EC2 내부에서 active 상태가된다.

 

근데 터미널 조작도 같이 해야하니까 백그라운드에서 runner를 실행시켜보자

cd ~/actions-runner

# 서비스 등록
sudo ./svc.sh install ubuntu  # ubuntu는 현재 사용자명

# 서비스 시작
sudo ./svc.sh start

# 상태 확인
sudo ./svc.sh status

 

마지막으로 Github Actions에 Self hosted runner를 사용한다고 명시만해주면 된다.

jobs:
  deploy:
    runs-on: self-hosted  # 이 부분만 추가!
# ...

 

결과

- 결과적으로 어디서든 서버 자동 배포가 가능하게 하였음

- Long Polling 방식으로 러너가 요청

- 아웃바운드가 먼저이기때문에 이 요청에 관한 응답은 인바운드 체크하지 않음