Github Action self-hosted-runner 도입기

1. 개요

mobile 에서는 CI-CD 로 TeamCity 를 사용하고 있었음. TeamCity 는 EC2에 띄워져 있고 로컬 빌드머신에서 커맨드를 수행하고 있었고, fastlane 으로 빌드/배포 작업이 진행되었음.

그런데 가끔 TeamCity 가 고장날때가 있었는데.. 히스토리 인프라쪽을 건드려야 하기 때문에 서버팀의 도움을 받아 고쳤었는데, 가끔 이렇게 유지보수에 신경 써야하기도 하고, mobile 팀에서 자체적으로 유지보수가 어렵다는 점에서 다른 방안이 필요하다고 팀원들과 공감대를 형성해왔고 그 대안은 Github Action 이 유력했음!

• iOS, Android 모두 Github 을 잘 활용하고 있었음
• 관련 자료들도 많음
• EC2 필요없음

그런데 Github Action 은 기본적으로 원격에서 돌아가는데, Android 와 iOS 의 빌드 시간이 무진장 길다는 것이다. 기존 팀시티 기준으로 Android 는 약 20분? iOS 는 30분 정도 걸렸는데, 이 시간은 Github Action 에서 돌린다고 줄어들 시간도 아니다.
그리고, iOS 빌드를 해야하는 macOS 운영체제 1분은 Github Action 세계에서 10분이다 ㅋㅋ? (

인터스텔라 밀러행성?

)

그래서 사실상 Github Action 을 원격으로 쓰는건 어렵겠다 싶어서 포기하고 있었는데, 자체 호스트형 실행기가 있다는 사실을 알게 되었고, 적용해 잘 사용중이다 !

2. Self-Hosted-Runner 특징

• Github Action 에서 커맨드를 받아서 작업을 실행하는 Runner 를 지정해서 사용할 수 있다.
  • 기존에 사용하던 TeamCity 도 EC2 에서 내려주는 커맨드를 빌드머신에서 받아서 사용했는데, 기존 방식과 동일하게 사용할 수 있다 !
  • Runner 는 원하는 머신, 즉 우리는 로컬 빌드머신을 사용할 예정이지만, 원하는 경우 EC2 나 집에 놀고있는 맥미니도 가능
• 무료로 사용 가능함! (우리 컴퓨터에서 돌리니깐)
• Runner 만 자체 hosting 해서 사용할 뿐, 나머지 trigger 나 workflow 등등 은 모두 동일하게 사용 가능
• Github Action 에는 다양한 플러그인 생태계가 있는데 그것들도 사용 가능

3. Self-Hosted-Runner 세팅

• Action - Management - New runner 로 새로운 러너를 추가할 수 있다.
• token 으로 러너를 validate 하고, actions-runner 프로세스를 띄우는 방식.
• 빌드머신에는 ios와 android 각각 별개의 runner 프로세스를 띄워둠
  • 1개의 runner는 1개의 job을 수행 가능한데, 별개의 프로세스로 띄워두면 병렬 처리가 가능함
• 호스팅한 각 러너마다 label 을 붙여서 구분할 수 있음
  • 아래처럼 구분해둠
    • iOS: ios-hosted
    • Android: android-hosted

      # Android Workflow Exmaple
      build:
      name: QA Build
      runs-on: android-hosted
      # iOS Workflow Example
      jobs:
      prepare:
      runs-on: ios-hosted

• 각 job 에 대해 어떤 runner 에서 실행해야 하는지 넣을 수 있음

• 만약 runner 가 이미 다른 작업을 수행중이라면?
  • Queue에 해당 job 이 enqueue 되어 다른 작업을 대기하게 됨

4. Fastlane 은 우짤까

TeamCity 를 사용할 때는 Fastlane 을 사용했었는데, Github Action 이라고 다르지 않다. Fastlane 을 그대로 사용할 수도 있고, 벗겨낼수도 있었다.
Fastlane 을 그대로 사용하면 기존 CI/CD 플로우를 그대로 사용할 수도 있고, 거기서 조금만 변경시켜줘도 되긴 한다. 그치만 유지보수 포인트가 하나 더 늘어나기도 하고, 에러 등의 처리도 그곳에서 해야 한다.
따라서 그냥 하는김에 Fastlane 을 벗겨내고 모두 Github Action 의 커맨드와 플러그인을 활용해 마이그레이션 하기로 했다. (슬랙, upload to testflight 등)

5. 결론

이럴 때 쓰면 좋을것같아요

• 개발 환경 설정이 복잡할 때
  • 이것저것 설치하는 개발 환경 설정을 미리 로컬에 해둘 수 있음
  • 새로 install 하는 시간이 없어지기 때문에 좀 짧아질 수 있겠다
    • ex) mise install tuist -> 이런거 필요없음
• 로컬 빌드가 필요할 때
  • 특히 iOS, Android 등 클라이언트에서 긴 빌드시간이 필요할 때 좋을 것 같음
• 빌드머신을 유지할 수 있을 때
  • 우리 같은 경우는 빌드 머신이 있어서 활용할 수 있는데, 빌드 머신이 없다면? :(
• 서버의 경우 보안 등의 사유로 Github Action 클라우드에서 우리 자원에 접근하지 못하도록 하고싶을 때? 직접 우리 서버에 runner 를 돌릴 수 있다 
  • https://tech.kakao.com/posts/516
  • https://devocean.sk.com/blog/techBoardDetail.do?ID=164362

이런 경우는 굳이?

• 빌드시간이 짧을 때
• 레포가 오픈소스일 때