[AWS] 프리티어에 Github Action self hosted Runner설치해서 사용하기 : 스프링부트가 계속 죽는다고?

 

 

목차

 

• GitHub Action 주요 용어 정리
• 왜 self hosted를 이용했을까?
• Runner 설치 하는 방법
• 워크플로우(workflows) 작성
• 배포 쉘 스크립트
• 근데 왜 스프링이 계속 죽을까?
• 해결 방법

 

 

 

 

GitHub Action 주요 용어 정리

 

공식 문서 : https://docs.github.com/ko/actions/about-github-actions/understanding-github-actions

GitHub Actions 이해 - GitHub Docs

 

• Event (이벤트)
  워크플로우 Workflow를 실행하게 하는 트리거 활동 입니다.
  Pull, issue, Push, Pull Request 등 특정 활동을 요청 할 때 실행됩니다.
• Workflow(워크플로우)
  Job(작업)을 자동으로 처리하게 하는 작업의 설계도입니다.
  하나 이상의 Job(작업)을 실행하는 것을 구성 가능한 자동화된 프로세스입니다.
  깃허브 Repository에서 .github/workflows 폴더에 저장하게 됩니다.
• Job (작업)
  워크플로우 안에서 실행되는 작업 단위입니다.
  여러 개의 Job이 동시에 실행될 수 있고, 순서대로 실행될 수 있습니다.
• Runner (러너)
  Event(이벤트)가 트리거 될 때 Workflow(워크플로우)를 실행하는 서버 입니다.
  하나의 Job(작업)에는 하나의 Runner(러너)가 실행됩니다.
  Ubuntu Linux, Microsoft Windows, MacOS 실행기를 제공하며, 새로 프로비저닝된 새 가상 머신에서 실행됩니다.
• Action (액션)
  자주 사용하는 작업을 재사용 가능한 단위로 만든 것 입니다.
  Workflow(워크플로우)파일에서 작성하는 반복 코드의 양을 줄인 것 입니다.

[그림1] 깃허브 액션 구성요소

 

 

 

 

왜 self hosted를 이용했을까?

 

우선 저는 AWS 프리티어를 이용하고 있습니다. 즉, 서버 스펙이 CPU 1GB에, RAM 2GB 입니다..

깃허브 액션을 통하여 Spring Boot 프로젝트를 Build(빌드)를 하는 와중에 메모리가 부족하여 서버에 접근도 못하고 깃허브 액션이 무한 로딩되는 현상이 있었습니다.

 

여러가지 방법을 찾아보다가, 서버에 설치해서 사용하는 self hosted를 알게 되었고, 조끔 가난 할 떄 쓰는 방식(?)이라고 들은 것 같습니다.

또한, 프로젝트가 public 이면 무료인 것을 확인하여 이용하게 되었습니다.

 

 

 

 

Runner 설치 하는 방법

 

1. 여러분의 프로젝트 Repository → Settings → Actions → Runners 로 이동합니다.

[그림2] 깃허브 액션 러너 설치1

 

2.  New self-hosted runner를 클릭하여 러너를 생성해 줍니다.

[그림3] 깃허브 액션 러너 설치2

 

3. 각 개인의 서버에 접근하여 다운로드를 진행합니다.

1. Runner Image는 서버의 OS와 같은 것으로 설정해 주시면 됩니다.
2. Architecture도 AWS 서버 세팅할 때 했던 같은 Architecture로 설정해주시면 됩니다.
3. 서버에 진입했을 때 기준으로 Download 에 있는 코드를 복사하여 실행 해주시면 됩니다.
4. Configure에 있는 코드는 token 설정하는 것만 실행해주시면 됩니다.
5. 해당 Runner(러너)를 통해서 배포를 실행할 때 Runner(러너)가 active일 때만 실행가능 하므로 actions-runner 폴더에 있는 ./run.sh 명령어를 실행하여 Runner(러너)를 활성화 시킵니다.
6. Using your self-hosted runner에 있는 코드는 Workflow(워크플로우) 작성법에서 알려주겠습니다.

[그림4] 깃허브 액션 설치3

 

Tip) 서버를 재기동하여도 자동으로 Runner(러너)를 활성화 상태로 만들고 싶다면 

# 설치
sudo ./svc.sh install
# 시작
sudo ./svc.sh start

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

 

 

 

 

워크플로우(Workflows) 작성

 

빠르게 볼 수 있고, 이해 할 수 있도록 주석 처리로 작성하였습니다.

.github/workflows/[워크플로우이름].yml

name: CI/CD with Gradle # 워크플로우 이름 설정

on:
  push:
    branches: [ "dev", "main"] # dev와 main 브랜치로 푸시될 때 실행

jobs:
  test:
    runs-on: ubuntu-latest # GitHub 제공 최신 버전 Ubuntu 가상 머신 사용
    steps:
      - name: Checkout # GitHub Repository 코드 체크아웃
        uses: actions/checkout@v4
        
      - name: Set up JDK 17 # JDK 17 환경 설정
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
  
      - name: Run Test with Gradle # Gradle로 테스트 실행
        run: ./gradlew test
          
  deploy:
    if: github.ref == 'refs/heads/main' # main 브랜치에서만 실행
    runs-on: self-hosted # 우리 서버에 설치한 Self-hosted Runner 사용
    timeout-minutes: 5 # 타임아웃 설정 (5분)
    steps:
      - name: Checkout # GitHub Repository 코드 체크아웃
        uses: actions/checkout@v4

      - name: Set up JDK 17 # JDK 17 환경 설정
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
             
      - name: Run deploy script # 배포 스크립트 실행
        run: | 
          /home/ubuntu/deploy.sh
          # 여기서 직접 Spring Boot 기동하는 사람도 있었음.

 

 

 

 

배포 쉘 스크립트

 

아래와 같은 배포 순서를 가지고 있습니다.

 

1. 기존 Spring Boot 서버 죽이기
2. 코드 pull 해온 것 Build(빌드)
3. Build(빌드)한 jar 파일 내가 기동시키려는(관리하는) 디렉토리로 이동
4. jar로 서버 기동 (어떻게 기동했는지 맨 마지막 설명)

 

 

 

근데 왜 스프링이 계속 죽을까?

 

분명 쉘 스크립트(deploy.sh)에 백그라운드로 스프링을 실행했지만, 깃허브 액션이 끝나면 같이 죽는 문제가 발생하였습니다.

 

어떻게 발견했나?

• 스프링을 실행하고 sleep 60 을 두어 1분동안 서버 URL로 들어가 홈페이지, 스웨거등 열리는 것을 확인하여 기동되는 것을 확실하게 확인하였습니다. 하지만 깃허브 액션이 성공적으로 완료 되었다는 것과 함께 스프링이 기동되지 않고 있었습니다.
• 터미널을 한개 더 띄워서 서버에 새로 하나 진입하였고 ps aux | grep 'java -jar' 명령어를 이용해 jar로 기동된 것을 찾아 주었습니다. 하지만 깃허브 액션으로 성공적으로 스프링을 기동했을 때는 문제가 없었지만 깃허브 액션이 성공적으로 완료 되었다는 것과 함께 스프링이 기동되지 않아있었습니다.
• sleep을 주지 않고 바로 실행했을 때는 Spring이 기동하다가 로그가 끊겨 있는 것을 확인하였습니다.

[그림5] 문제 상황

 

이렇게는 하지 말아주세요 추가적 문제 발생합니다.

self hosted를 사용하여 root 계정이 실행시키는 것이 아니라 권한이 없는 계정이 Spring Boot를 기동 시켜서 계속 죽는 것으로 의심이 되었습니다.

배포 쉘 스크립트(deploy.sh)를 실행할 때 sudo를 주어 실행을 해봤지만, jar가 빌드가 안되는 문제가 발생하였습니다.

# 에러 내용
To honour the JVM settings for this build a single-use Daemon process will be forked. For more on this, please refer to https://docs.gradle.org/8.10.2/userguide/gradle_daemon.html#sec:disabling_the_daemon in the Gradle documentation.
Daemon will be stopped at the end of the build 

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':bootJar'.
> Could not resolve all dependencies for configuration ':runtimeClasspath'.
   > Failed to calculate the value of task ':compileJava' property 'javaCompiler'.
      > Cannot find a Java installation on your machine matching this tasks requirements: {languageVersion=17, vendor=any vendor, implementation=vendor-specific} for LINUX on x86_64.
         > No locally installed toolchains match and toolchain download repositories have not been configured.

 

 

 

 

해결 방법 : 시스템과 서비스를 관리하는 systemctl를 이용

 

배포 스크립트에 systemctl을 이용해 서비스를 시작하여 스프링을 기동하였을 때는 문제 없이 CI/CD가 구축되었습니다.

 

파일 열기

sudo vi /etc/systemd/system/[서비스 이름].service

 

작성

• 작성을 하기 위해서는 i 를 눌러 입력모드로 변환하여 작성해주시면 됩니다.
• ExecStart 할 때 jar를 기동할 때, 내 jar위치로 해주시면 됩니다.
• 항상 기동 ON 은 필요가 없어서 Restart는 Never로 두었습니다.
• 환경변수도 여기서 설정해주었습니다.
• 다 작성하였다면 ESC를 누르고 :wq 를 입력하여 빠져나옵니다.

##### 예시입니다~~

[Unit]
Description=[서비스 설명]
After=network.target

[Service]
User=ubuntu
WorkingDirectory=/home/ubuntu/project
ExecStart=/usr/bin/java -jar -Dspring.profiles.active=prod -Duser.timezone=Asia/Seoul /home/ubuntu/project/[프로젝트명]-0.0.1-SNAPSHOT.jar
Restart=never
Environment="KEY=VALUE"
Environment="DB_USERNAME=postgres"

[Install]
WantedBy=multi-user.target

 

서비스 시작

sudo systemctl start [서비스 이름].service

 

서비스 중지

sudo systemctl stop [서비스 이름].service

 

서비스 상태 확인

sudo systemctl status [서비스 이름].service

 

로그 확인

# 실시간 로그
journalctl -u [서비스 이름].service -f

# 최근 50줄
journalctl -u [서비스 이름].service --lines=50

# 특정 시간 로그
# 2024년 12월 1일 오전 10시부터 12시 사이의 로그만 표시
journalctl -u [서비스 이름].service --since "2024-12-01 10:00:00" --until "2024-12-01 12:00:00"

# 특정 키워드 
journalctl -u [서비스 이름].service --lines=100 | grep "ERROR"

 

 

 

 

 

 

후기

 

self-hosted를 이용한 사람은 있지만 스프링이 죽는 경험을 한사람이 별로 없어서 찾을 블로그가 없었습니다.....

다들 어떻게 바로 성공하셨는지.......

누군가 이글을 보고 도움이 된다면 너무 뿌듯할 것 같습니다.

2주동안 엄청 고생했거든요...

모두들 행복하세요 화이팅입니다.

 

 

감사합니다.