개발공부 기록지

deploy.yml 

- name: SSH로 EC2에 접속하기
  uses: appleboy/ssh-action@v1.0.3

아래의 코드를  위의 코드 앞에 입력

- name: GitHub Repository 파일 불러오기
  uses: actions/checkout@v4 # 라이브러리
  
- name: Node 설치
  uses: actions/setup-node@v4 # 라이브러리
  with:
   node-version: "20" # 원하는 버전 입력
   
- name: 의존성(라이블러리) 설치
  run: npm ci
  
- name: .env 파일 만들기
  run: |
    echo '${{secrets.ENV}}' > .env
    
- name: 테스트 코드 실행
  run: npm run test

이제 actions 에서 먼저 테스트를 하고 

테스트를 통과하면

코드를 배포하게 된다.

name: Deploy to EC2

on:
  push:
    branches:
      - main

jobs:
  Deploy:
    runs-on: ubuntu-latest
    steps:
      - name: SSH로 EC2에 접속하기
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USERNAME }}
          key: ${{ secrets.EC2_PRIVATE_KEY }}
          script_stop: true
          script: |
            cd /home/ubuntu/nestjs-gymlog
            git pull origin main
            npm i
            sudo npm run build
            sudo pm2 kill
            sudo npm run start:prod --name "backend-server"

uses: appleboy/ssh-action@v1.0.3 아래에  아래 코드를 추가

        uses: appleboy/ssh-action@v1.0.3
        env:
          ENV: ${{secrets.ENV}}
        with
          envs: ENV

   - git hub secrets 메뉴에서  ENV 생성후 필요한 값 입력하면 해당 값들이 불려져 온다.

   - envs: ENV 는 받아온 env 를 아래의 스크립트에서 ENV 로 사용하겠다는 의미

아래의 script: 에 아래 코드 추가

 rm -rf .env
 echo "$ENV" > .env

여기서  꼭 .env 를 안쓰고 자신이 설정한 .env 파일명을 쓰면 된다.

에러 메세지

ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

GitAction 마켓에 있는 "appleboy/ssh-action@v1.0.3" 

를 적용해서 EC2 에 ssh 로 접속하려는데

"인증 불가....."

EC2 보안그룹에 문제가 발생한 것인가 하여 확인

- 애플리케이션도 배포해보고 해당 ip 로 접속도 다된다.

Actions secret 에 입력한 값이 잘 못 되었나 하여 다시 수정하여 시도

-> 같은 에러 발생

구글링 해본 결과 : 패스워드 방식이 아니라 key 를 이용하는데 내가 사용하는 key 의 알고리즘이 EC2 에 있는 우분투 버전에 따라 지원하지 않을 수도 있다고 한다. 

-> appleboy/ssh-action git hub 에 있는 내용에 따라 

/etc/ssh/sshd_config 에 CASignatureAlgorithms +ssh-rsa 추가

-> 여전히 같은 에러

다시 CI/CD 를 위해 작성한 코드로 돌아가서 코드를 다시 확인
Actions secret  에 설정한 Repository secrets의 이름과 코드에 있는 이름이 다른 것이 있다...

회고

역시 에러는 에러가 발생한 위치 부근의 코드를 확인하거나

콘솔에 찍힌 로그를 잘 확인하면 해결이 가능한 것이였다.

또한 시스템 적인 에러보다 내가 몰라서 만들거나 실수가 많다....

CI/CD 를 구축할 수 있는 툴

• Github Actions
• Jenkins
• Circle CI
• Travis CI

→ Github Actinos 선택 이유

1. Github 과 하나로 통일된 환경에서 CI 수행 가능

2. 빌드용 서버가 따로 필요없다. → 비용절감, 시간 단축

3. 공개 레포지토리는 무료로 사용가능

Github Actions 개념 정리

GitHub Actions는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD(연속 통합 및 지속적인 업데이트) 플랫폼입니다. 리포지토리에 대한 모든 끌어오기 요청을 빌드 및 테스트하거나 병합된 끌어오기 요청을 프로덕션에 배포하는 워크플로를 만들 수 있습니다.

GitHub Actions은(는) 단순한 DevOps 수준을 넘어 리포지토리에서 다른 이벤트가 발생할 때 워크플로를 실행할 수 있도록 합니다. 예를 들어 누군가가 리포지토리에서 새 이슈를 만들 때마다 워크플로를 실행하여 적절한 레이블을 자동으로 추가할 수 있습니다.

docs.github.com

요약

• 리포지토리의 이벤트에 따라 정의된 로직을 자동으로 실행하는 자동화 도구
• 로직을 실행시킬 수 있는 일종의 컴퓨터

CI/CD 의 기본적인 흐름

1. 작성한 코드를 Commit 하여 GitHub 에 Push
2. Push를 감지하여 GitHub Actions에 작성한 로직이 실행
   • 로직 예) 프로젝트를 빌드 -  빌드된 프로젝트를 테스트 - 모든 테스트를 통과하면 서버로 배포
3. 서버에서 배포된 최신 코드로 서버를 재실행

참고 강의

[인프런 강의] 비전공자도 이해할 수 있는 CI/CD 입문 실전

Continuous Integration, Continuous Deployment

Test, Merge, Deploy 의 과정을 자동화 하는 걸 의미

필요성?

새로운 기능을 추가 후, commit -> merge  과정을 거친다.
그 후 배포를 할때  서버 컴퓨터에 접속을 해서 새로운 코드를 받아서 실행 시켜주어야 한다. 

매번 이 과정을 거치는 것이 귀찮은 일...

-> 이런 과정을 자동화시키기 위해 CI/CD가 필요하다.

CI/CD 과정

Test 를 작성하지 않은 서비스에서는 test 과정을 빼도 된다.