최초 Github actions를 통해 프로젝트를 빌드하고 WAS EC2 인스턴스에 빌드된 파일을 전송하는 구조를 구상했다.
그러나 프로젝트 제약사항으로 등록되지 않은 외부 IP를 통해 AWS EC2 SSH 접근이 불가능하다가 있었고,
Github actions 측에서 제공하는 서버로 빌드/배포 과정을 진행하는 방식으로는 완성된 빌드 파일을 보낼 수 있는 방법이 없었다.
코치님께서도 이 제약사항을 풀어줄 수 없다고 완강하게 말씀하셨다.
굳이 Github actions를 써야 겠다면, 몇가지 대안이 생각나긴 하네요.Github actions의 빌드 결과물을 도커로 빌드한후 도커 허브에 올린다. 서버에서는 이 이미지를 활용한다.github action를 self-hosted runner 방식으로 활용한다. 별도로 생성한 빌드서버(EC2, 혹은 로컬 서버)에서 운영서버로 ssh 연결이 가능하도록 구성한다.
어차피 WAS 프로그램도 도커 위에 구동시킬 것이라 1번 방법에도 메리트가 느껴졌으나, 얼마전 팀원 포츈이 Github actions 측에서 제공하는 서버로 빌드를 시도했을 때 알 수 없는 이유로 빌드가 수행되지 않아서(일시적으로 Github actions 측 서버가 멈추었던 것으로 추측) 2번 방법에 대한 메리트가 더 강하게 느껴졌다.
2번 방법을 통해 EC2상에 빌드서버를 구성할 경우 젠킨스를 이용하는 것 대비 장점이 무엇일까 고민해보았다.
아직 프로젝트의 규모도 크지 않고 팀원들도 Github actions의 간단함과 UI를 마음에 들어했기 때문에 쉽게 결정을 내릴 수 있었다. 이번 기회에 EC2서버 Github actions를 구성하면 추후 젠킨스로 교체하기도 용이할 터였다.
위 도식화에서 빨간 박스로 강조된 부분만 다룰 것이다. (다른 부분들이 궁금할 경우 여기를 참고할 것)
github actions self-hosted 서버를 구성하기 위해 EC2 인스턴스를 생성하자. 이 때 인스턴스의 public IP는 활성화로 고정한다. self-hosted runner가 CI/CD 작업중 저장소의 Actions 탭으로 진행상황과 결과를 지속적으로 전달하고, 저장소 Actions 탭에서 CI/CD 작업을 직접 요청할 수도 있기 때문에 인터넷 연결을 필요로 한다.
github actions를 통한 CI/CD가 진행되기 원하는 저장소에서 Settings - Actions - Runners - Add runner 메뉴로 접근한다.