현재 Tiggle 프로젝트에서 NAS 서버에 도커를 통해 서버를 배포하고 있다.

배포자동화를 위해 Github Actions를 도입하였고 SSH 연결 부분에서 무지해서 발생한 일과 공부한 내용, 해결 방법을 적어보려한다.

---

문제상황

• NAS Server에는 server.sh 스크립트가 존재하여 docker-compose를 실행하고 있다.
• 갑자기 잘 되던 Github Actions에서 docker-compose.yml을 읽을 수 없었고, docker-compose.yml을 생성하여 docker의 컨테이너들이 실행되더라도 실서버에는 반영이 되지 않는 문제가 발생하였다.

not found: docker-compose.yml

• 분명 터미널을 통해 ssh 접속을 하면 docker-compose.yml이 정상적으로 확인이 된다.
• github actions 내부에서 ssh 접속 후 ls -al 명령어 실행 시 docker-compose.kafka.yml만 존재하는 문제가 있었다.

원인 & 코드

docker-compose.yml을 상위 util 폴더에 생성하고 Tiggle 프로젝트 폴더에서 심볼릭 링크를 생성해서 사용하여 Github Actions에서 동작할 때 정상적으로 불러오지 못하는 문제가 발생했다.

name: Deploy to NAS Server

on:
  push:
    branches: [ main ]

jobs:     
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    
    steps:
      - name: ssh connect
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USERNAME }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          port: ${{ secrets.PORT }}
      
      - name: Run server.sh
        run: |
          ls -al
          ./server.sh

공부한 내용

왜 심볼릭 링크를 사용한 파일을 읽어올 수 없는가?

정답은 가까운 곳에 있었지만 팀원이 공유해준 내용과 한참을 찾은 뒤 알 수 있었다.

• 위 이미지에서 runner라는 것이 존재하는데 우린 단 한번도 runner를 설정한 적이 없다.
• 분명 ssh 접속할 때 입력한 USERNAME이 존재하지만 해당 USERNAME은 없고 runner가 보이는 것은 문제가 있는게 아닐까?

그럼 왜 runner가 보이는 것일까?

• Github Actions 동작 원리
  • 자체적인 가상 환경에서 코드를 실행한다.
  • Github가 제공하는 임시 러너(virtual runner)에서 실행되며 가상 환경의 디렉토리 구조는 /home/runner/work/{repository}/{repository}와 같은 경로가 사용된다.

결론

• deploy를 보면 runs-on: ubuntu-latest가 있다.
  • ubuntu의 가상 환경에서 steps별 명령을 실행하게 되는데 이 때 ssh 접속 후 run 동작은 가상 환경에서 동작하게 된다.
• 가상 환경에서는 ssh 내부에 있는 심볼릭 링크가 존재하지 않아 docker-compose.yml이 없는 것으로 인식된다.

해결 방법

기존 util -> 프로젝트 폴더로 docker-compose.yml을 옮겨주면서 docker-compose.yml 인식은 정상적으로 해결 되었다.

---

배포 스크립트가 실서버에 반영되지 않는 문제

배포 성공과 Run server.sh 결과

배포가 성공적으로 이루어졌고, server.sh 스크립트도 제대로 실행된 것처럼 보이지만, 실제로는 실서버에 있는 Docker 컨테이너에 전혀 반영되지 않는 문제를 나타낸다.

수 많은 테스트

directory 체크

pwd와 cd로 Tiggle 폴더를 찾았으나 이상한게 보였다.
cd /home 실행 후 ls -al 실행하니 예상한 결과와 너무 달랐다.

• 어디에도 USERNAME은 없고 우리의 프로젝트 또한 없었다.
• 의문의 runner만 존재했다.

runner?

GitHub Actions 공식 문서에 따르면, runner는 jobs에서 실행할 동작들을 실제로 실행하는 서버를 의미
GitHub Actions는 워크플로우를 실행하기 위한 다양한 운영체제를 제공하며, 여기에는 Ubuntu Linux, Microsoft Windows, macOS 등이 포함된다.

jobs & runs-on

jobs를 통해 어떤 작업들을 어떤 환경에서 실행할 지 runs-on을 정해준다.

• runs-on: ubuntu-latest Ubuntu 서버에서 작업이 실행됨을 의미
  • GitHub Actions는 이 환경에서 명령을 실행하게 된다.

run과 script의 차이점

• run: GitHub Actions 가상 환경 내에서 명령어를 실행
  • run에서 실행된 명령은 GitHub Actions에서 제공하는 가상 머신에서 실행되며, 실서버와는 별개의 환경이다.
  • run을 사용하여 명령어를 실행하면 이는 GitHub Actions의 가상 환경에서 실행되며, 원격 서버에 반영되지 않는다.
  • run에서 ls -al은 가상 환경의 runner 디렉토리 구조를 보여준다.
• script: SSH를 통해 원격 서버에서 명령어를 실행
  • ssh-action을 사용하여 원격 서버에 접속한 후 script 필드에 작성한 명령어는 실제 서버에서 실행된다.
  • script: ls -al은 실서버의 디렉토리 구조를 보여준다.

SSH 연결 후 script 사용

• ssh-action을 통해 원격 서버에 접속한 후, script 필드를 사용하여 명령어를 실행하면, 실서버에서 직접 실행할 수 있다.
• 실제 서버에서 스크립트를 실행하거나, 서버의 상태를 변경할 때 사용

결론

• Github Actions에서 배포 스크립트가 실서버에 반영되지 않는 문제는 SSH를 통해 접속한 후 script 대신 run을 사용하여 명령을 실행했기 때문에 발생했다.
  • run은 GitHub Actions의 가상 환경에서 실행되므로, 실서버에 반영되지 않았다.

---

추가

• runner 방식에는 Github-hosted와 Self-hosted runner 2가지가 존재한다.
• 우리가 사용 중인 것이 Github-hosted runner로 Github 워크플로우를 실행하기 위해 가상 머신을 자동으로 생성하여 작업을 수행한다.
• Self-hosted runner는 사용자가 지정한 서바나 컴퓨터에서 워크플로우를 실행할 수 있는 환경이다.
  • Github-hosted runner의 경우 6시간의 타임아웃 제한, 작업 진행 전에 apt-get 등의 설치로 속도가 느린 부분이 있는데 이런 문제를 해결할 수 있다.
  • 커스터마이징이 필요한 프로젝트나 고성능, 보안 요구 사항이 있을 때 사용하기 적합하다.

대기업에서 Self-hosted runner를 이용한 CI/CD를 사용하고 있는 내용들이 있어 다음 내용으로 정리해봐야겠다.