반응형
현재 fast api를 통해 개발 중인 코드가 있는데, 폐쇄망 내에서 빠른 적용 및 테스트를 위해, github action으로 배포를 자동화해 놓았다. 개발 환경은 nginx를 이용해 2개의 서버를 load balacing으로 묶어놓았고, 각각 서버에 github action runner를 돌려놓았다.
문제
- 아주 바보 같은 실수를 해버렸다. nginx restart를 한다는 것이 모르고 서버를 reboot 시켜버렸다.
- 하필이면, nginx가 구동 중인 서버를 종료시켰다. 서버가 reboot 된 후, nginx를 켜고, runner 동작을 위한 run.sh를 수행하였는데, 아래와 같은 문구가 뜨면서 runner가 동작하지 않았다.
The SSL connection could not be established, see inner exception.
해결 시도
- 우선 SSL 문구를 보고, 바로 인증서 or 방화벽을 의심했다. 하지만, git pull이 정상적으로 진행되었다. → 방화벽 문제 아님
- 그다음엔 인증서를 인식시키려 했다. 하지만, 동일 역할을 하는 다른 서버에는 인증서 관련해서 별도의 작업을 진행한 것이 없기 때문에, 인증서 문제도 아닌 것으로 생각되었다.
- 구글링 중, openssl의 버전 문제라는 글을 보았다. openssl 버전을 업그레이드했지만, 문제는 계속 발생했다.
- 그러다, github actions에서 사용을 위한 port를 찾아보게 되었다.
해결 방법
- 문제는 github actions가 사용할 port를 다른 서비스가 점유 중이어서 발생하는 문제였다. 나 같은 경우에는 nginx의 접근 port를 80으로 두었기 때문에, 충돌이 발생하여 꺼지는 문제였다.
- 이 문제는 nginx를 stop한 뒤, github actions runner를 돌리고, 다시 nginx를 start하니 해결되었다. (동일 port 사용)
- github actions config.sh나 run.sh 수행 당시에 해당 port가 점유되지 않으면 해결되는 문제이다. 만약, 사용 중인 port를 모른다면 netstat 명령어나, lsof 명령어를 이용하여 사용 중인 port를 확인 가능하다.
netstat -tuln
sudo lsof -i -P -n | grep LISTEN
- 라고 생각했으나, 다음날 동일 현상이 발생하였다. 구글링 결과, github action 홈페이지에서 해답을 찾게 되었다. 보안상에는 TLS 인증을 남겨놓는게 좋지만, 불가피한 상황에서 이슈가 발생한다면 아래 명령어로 TLS 인증을 꺼놓으면 해결된다.
export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1- 더 자세한 내용은 https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners?learn=hosting_your_own_runners&learnProduct=actions 을 참고 바란다.
- 당연히, 해당 명령어는 해당 터미널 세션에서만 유효하다. 추후 이슈 방지를 위해. bashrc(다른 shell을 사용한다면, shell 초기화 파일에)에 추가해 주는 것이 좋다.
echo 'export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1' >> ~/.bashrc
source ~/.bashrc