[Node.js] 2. EC2 서버 CI/CD 구축하기

진욱·2025년 7월 1일
CI/CDCodeDeployawsec2expressnode.js

NodeJS

목록 보기
2/5
post-thumbnail

들어가며

1탄에 이어 이번에는 EC2에 배포한 Express 서버에 CI/CD 환경을 구축하는 과정을 소개해보려 한다.

약 이틀 간 여기에 매달려 수많은 실패를 맛 보았지만

그 고난의 과정을 기억하기 위해, 그리고 혹시라도 이 글을 보시는 분들은 같은 고난을 겪지 마시기를 바라며...

EC2 추가 설정

본격적으로 CI/CD를 구축하기에 앞서, 먼저 서버를 조금 손 보면 좋을 것 같다. 현재 서버에는 몇 가지 아쉬움이 존재한다.

1. 서버에 정해진 주소가 없다.
2. 인스턴스에서 계속 돌아가지 않는다.
3. 주소가 이상하다. http://13.125.13.246:3000

각각의 문제점(?)들을 3단계에 거쳐 하나씩 해결해보았다.

1️⃣ 탄력적 IP 할당

1탄에서 서버를 실행한 후 EC2의 퍼블릭 IP 주소를 이용해 접속했었는데, 이 주소에는 사실 함정이 있다. EC2 인스턴스를 재부팅 후 퍼블릭 IP 주소를 확인해보면 그 이유를 알 수 있을 것이다.

그렇다! EC2 인스턴스에 부여된 퍼블릭 IP 주소는 인스턴스가 재부팅될 때마다 변하는, 즉 동적으로 할당된 주소다. 따라서 기존에 접속했던 IP 주소로 서버에 접속을 시도해도 더 이상 접속이 불가능한 것이다. 따라서 우리는 인스턴스가 재부팅되더라도 변하지 않는 고정된 IP 주소, 탄력적 IP(Elastic IP) 를 부여해야 한다.

EC2의 네트워크 및 보안 탭에서 탄력적 IP 메뉴로 이동한다. 탄력적 IP 할당을 진행하면 다음과 같이 IPv4 주소가 하나 생성된다.

이 IP 주소를 EC2에 연결하면 이제 EC2 인스턴스가 고정된 IP 주소를 가질 수 있게 되는 것이다!

탄력적 IP를 생성할 때 "이 주소를 어디에도 연결하지 않으면 요금이 부과될 수 있습니다" 라는 무서운 문구가 써 있으니 탄력적 IP를 생성했으면 반드시 어디에라도 할당하여 요금 폭탄을 피하는 것이 좋을 것이다.

생성한 탄력적 IP 주소에서 탄력적 IP 주소 연결을 진행한다.

탄력적 IP 주소 연결

[탄력적 IP 주소 연결]

  • EC2에 연결할 것이므로 리소스 유형은 인스턴스를 선택한다.
  • 인스턴스에서 생성한 인스턴스를 선택한다.

이제 EC2에 고정된 IP 주소가 생성되었고, 이 주소를 이용해 서버에 접속할 수 있을 것이다!


2️⃣ PM2 설치

다음으로 서버가 인스턴스에서 계속 돌아가지 않는 문제를 해결한다.

현재 node app.js 명령어를 실행 중이라 서버에 접속이 원활하게 이루어지지만, Ctrl + C를 눌러 종료하고 나오면 다시 접속이 불가능하다. EC2 인스턴스에서 다른 작업을 하게 될 수도 있는데 그러면 그 때마다 서버를 직접 껐다가 다른 작업을 마친 후 서버를 직접 재시작해야하는 번거로움이 생길 것이다.

이를 방지하기 위해 pm2라는 프로세스 매니저를 설치하여 서버가 EC2의 백그라운드에서 지속적으로 실행될 수 있는 환경을 구현한다. pm2는 컴퓨터의 운영 체제 내의 백그라운드에서 프로세스를 관리하여 무중단 서비스를 제공할 수 있게 해주는 프로세스 매니저이다. pm2로 실행 중인 프로그램이 종료되면 자동으로 다시 실행하고, 코드가 변경되면 자동으로 프로세스를 재실행하여 리소스 수정을 반영할 수 있다.

pm2 설치 과정은 다음과 같다.

➀ pm2 설치

$ npm install pm2 -g

-g 키워드를 추가하여 EC2 전역에 pm2를 설치한다.

➁ package.json 수정 (옵션)

{
  ...
  
  "scripts": {
    "pm2": "pm2 start app.js",
    ...
  },
  
  ...
}

편집이 편리한 VSCode 등의 IDE를 활용해 package.json 파일에 scripts를 추가한다. "pm2"의 의미는 npm run pm2라는 명령어를 입력하면 pm2를 실행하는 pm2 start app.js 명령어를 실행하라는 의미이다.

이는 내가 편리하게 사용하기 위해 적용한 것일 뿐, 그냥 pm2 start app.js를 바로 입력해도 아무 문제 없다.

$ git pull origin main

변경사항을 원격 레포지토리에 반영하고, EC2에서도 원격 저장소의 변경사항을 동기화한다.

➂ pm2 실행

$ npm run pm2

위 명령어를 실행하고 서버에 접속해보면, node를 계속 실행하고 있지 않아도 백그라운드에서 서버가 돌아가고 있는 것을 확인할 수 있다.


3️⃣ nginx 설치

마지막으로 주소창에 계속 3000이라는 포트 번호가 남아있는 불편함을 해결한다.

EC2에 HTTP를 이용해 접근하면 80번 포트를 이용해 접근하게 된다. 주소창에 :80을 붙이지 않는 이유는, 80번 포트는 포트 번호 입력을 생략할 수 있기 때문이다. 다시 말해 아래 두 경우 모두 HTTP를 이용해 EC2에 접속한다는 동일한 의미인 것이다.

  • http://<EC2의 IP 주소>
  • http://<EC2의 IP 주소>:80

하지만 현재 Express 서버가 3000번 포트에 열려있기 때문에 우리가 구축한 서버에 접속하려면 http://<EC2의 IP 주소>:3000 이라고 주소창에 입력해야 하는 것이다.

이는 리버스 프록시(reverse proxy) 방식을 이용해 해결할 수 있다. nginx라는 웹 서버 프로그램을 이용해 HTTP의 80번 포트로 접속하더라도 3000번 포트에 있는 내용을 보여줄 수 있도록 하는 리버스 프록시를 적용한다.

➀ nginx 설치

$ sudo apt install nginx

nginx 프로그램을 설치한다.

➁ 환경변수 등록

이제 80번 포트로 들어온 클라이언트의 요청을 가로채 3000번 포트로 보내는 작업을 위해 환경 변수를 수정한다.

➁-1 nginx 디렉토리로 이동

$ cd /etc/nginx

cd (change directory) 명령어를 사용해 nginx가 위치한 디렉토리로 이동한다.

➁-2 sites-available 폴더로 이동

$ cd sites-available

nginx 폴더 내부에 있는 sites-available 폴더로 이동한다.

➁-3 default 파일 삭제 후 다시 생성

$ sudo rm default # default 삭제
$ sudo touch default # default 파일 생성
$ sudo nano default # default 파일 수정

ls 명령어를 사용해 sites-available 내부에 있는 파일을 살펴보면 default 파일이 존재할 것이다. 이 default 파일을 삭제 후 다시 생성한 후, nano 에디터를 이용해 내부에 코드를 작성한다.

server {
  listen 80 default;
  listen [::]:80 default;

  server_name <EC2의 퍼블릭 IP>;

  location / {
    proxy_pass http://<EC2의 퍼블릭 IP>:3000;
  }
}

위의 코드를 nano 에디터에 붙여 넣은 후, Ctrl + O를 이용해 변경 사항을 저장하고 Ctrl + X를 이용해 빠져나온다.

➂ nginx 재시작

$ sudo service nginx restart

nginx를 재시작한 후 3000번 포트를 지운 주소로 접속해보면 기존의 3000번 포트로 접속했을 때와 동일한 내용을 확인할 수 있어 Express 서버에 잘 접속했음을 확인할 수 있다.

CodeDeploy 설정

지금은 코드가 수정될 때마다 EC2에서 원격 레포지토리에서 백엔드 소스를 pull 받고 재실행 해야하는 번거로움이 있다. 따라서 GitHub 레포지토리의 코드가 변경되면 EC2 서버의 코드와 동기화하여 자동으로 변경 사항을 반영하고 배포할 수 있는 CI/CD 환경을 구축하기 위해 AWS의 CodeDeploy를 활용한다.

AWS CodeDeploy는 Amazon EC2 인스턴스, 온프레미스(On Premise) 인스턴스, 서버리스 Lambda 함수 또는 Amazon ECS 서비스로 애플리케이션 배포를 자동화하는 배포 서비스이다. CodeDeploy는 서버에서 실행되고 Amazon S3 버킷, GitHub 레포지토리 또는 Bitbucket 레포지토리에 저장되는 애플리케이션 콘텐츠를 배포할 수 있다.

이번에는 이 중에서 GitHub 레포지토리의 콘텐츠 배포를 자동화하는 방법을 구현한다.

1️⃣ CodeDeploy 에이전트 설치

AWS CodeDeploy 에이전트는 해당 인스턴스를 CodeDeploy 배포에 사용할 수 있게 해주는 소프트웨어 패키지이다. AWS에서 제공하는 Ubuntu Server용 CodeDeploy 에이전트 설치 문서를 참고하여 설치를 진행한다.

➀ apt 업데이트

$ sudo apt update

패키지 업데이트는 주기적으로 실행하는 것이 좋다.

➁ ruby 설치

$ sudo apt install ruby-full

➂ wget 설치

$ sudo apt install wget

➃ CodeDeploy 에이전트 설치 관리자 다운로드

$ cd /home/ubuntu
$ wget https://bucket-name.s3.region-identifier.amazonaws.com/latest/install

Ubuntu 기반 EC2의 홈 디렉토리로 이동한 후, CodeDeploy 에이전트 설치 관리자를 다운로드한다. 이 부분에서 주의할 점이 있는데, 나는 버킷 이름 대체와 리전 식별자 입력 과정에서 실수를 범해 한 번 더 시도했다. 내 버킷이 있어야 하는 줄 알고 버킷을 생성하고 버킷 이름을 붙여 넣고 난리 부르스를 떨었다는 것이다.

리전별 리소스 키트 버킷 이름을 반드시 확인하고, 적절한 버킷 이름 대체와 리전 식별자를 입력해야 한다.

아시아 태평양(서울)의 경우, bucket-name 자리에 aws-codedeploy-ap-northeast-2, region-identifier 자리에 ap-northeast-2를 입력한다.

**예시) 아시아 태평양(서울) 지역에서 작업 중이라면 이 코드를 복사하는 것을 추천!

$ wget https://aws-codedeploy-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/install

➄ install 파일에 대한 실행 권한 설정

$ chmod +x ./install

chmod 키워드를 사용해 install 파일에 대한 실행 권한을 설정한다. +x는 executable, 즉 실행 할 수 있는 권리를 부여한다는 의미이다.

➅ CodeDeploy 에이전트 설치

$ sudo ./install auto

최신 버전의 CodeDeploy 에이전트를 설치한다.

➆ CodeDeploy 에이전트 실행 여부 확인

$ systemctl status codedeploy-agent

# 또는

$ sudo service codedeploy-agent status

두 가지 명령어 중 하나를 통해 CodeDeploy 에이전트가 잘 실행 중인지 확인한다.

정상적으로 실행 중이라면 위 이미지처럼 active (running) 상태를 나타낼 것이다.


2️⃣ CodeDeploy 역할 생성

다음으로 IAM의 역할 탭으로 이동해 CodeDeploy 역할을 생성한다.

CodeDeploy 역할 생성

[CodeDeploy 역할 생성]

  • 사용 사례에서 CodeDeploy를 선택한다.
  • 나머지 설정은 기본값으로 두고 역할을 생성한다.

프로젝트에 script 파일 추가

프로젝트에 스크립트 파일들을 추가하여 CodeDeploy에 신규 배포가 생성되었을 때 수행해야 할 작업들을 정의한다. 이번 CI/CD 구축 과정에서는 총 세 단계에 거쳐 스크립트 파일을 구성하였다.

➀ appspec.yml 파일 추가

CodeDeploy에는 LifeCycle이 존재한다.

이 순서는 CodeDeploy에서 이미 정해 놓은 순서로, 각각을 Event Hook 이라고 한다. 일부 Event Hook은 사용자가 직접 스크립트 파일을 생성하여 사용할 수 있고, 위 이미지의 회색 처리 된 Event Hook은 이미 예약되어 있는 Event Hook이라 사용자의 스크립트 파일을 사용할 수 없다.

프로젝트 최상단에 appspec.yml 파일을 생성하여 어떤 Event Hook에서 어떤 스크립트 파일을 수행할 것인지 정의한다. 나는 AfterInstall 단계와 ApplicationStart 단계에 직접 생성한 스크립트 파일을 사용하였다.

version: 0.0
os: linux
files:
  - source: /
    destination: /home/ubuntu/Test-Server
hooks:
  AfterInstall:
    - location: scripts/after_install.sh
      timeout: 300
      runas: ubuntu
  ApplicationStart:
    - location: scripts/application_start.sh
      timeout: 300
      runas: ubuntu

[files]

  • source: 인스턴스에 복사할 수정된 파일 또는 디렉토리의 경로를 지정한다. GitHub 레포지토리의 모든 내용을 서버에 적용할 것이므로 /를 적용한다.
  • destination: 인스턴스에서 파일이 저장될 경로를 지정한다. /home/ubuntu 경로의 Test-Server 폴더 내에 저장한다.

[Event Hooks]

  • 공통
    • timeout: 스크립트 실행 시간이 timeout으로 지정한 시간을 넘어갈 경우 실패(fail)로 간주한다.
    • runas: 해당 스크립트를 실행할 사용자를 설정한다. Ubuntu의 기본 사용자는 ubuntu로 설정되어 있을 것이다.
  • AfterInstall: 프로그램이 시작되기 전에 업데이트된 내용으로 프로그램의 구성을 변경한다.
    • location: 실행할 after_install.sh 스크립트 파일의 경로를 입력한다.
  • ApplicationStart: 애플리케이션을 새로 업데이트된 내용을 적용해 재실행한다.
    • location: 실행할 application_start.sh 스크립트 파일의 경로를 입력한다.

참고

AWS 사용자 가이드 - CodeDeploy AppSpec 파일 참조

➁ after_install.sh 파일 추가

프로젝트의 최상단에 scripts 폴더를 생성하고 내부에 after_install.sh 파일을 추가한다. 스크립트 내부에는 애플리케이션이 성공적으로 Install 된 후 실행할 명령어들을 저장한다.

#!/bin/bash

echo 'run after_install.sh: ' >> /home/ubuntu/Test-Server/deploy.log

echo 'cd /home/ubuntu/Test-Server' >> /home/ubuntu/Test-Server/deploy.log
cd /home/ubuntu/Test-Server >> /home/ubuntu/Test-Server/deploy.log


echo 'Current directory: ' >> /home/ubuntu/Test-Server/deploy.log
pwd >> /home/ubuntu/Test-Server/deploy.log

echo 'check nvm version: ' >> /home/ubuntu/Test-Server/deploy.log 
npm -v

echo 'npm install' >> /home/ubuntu/Test-Server/deploy.log 
npm install >> /home/ubuntu/Test-Server/deploy.log

스크립트 파일을 제대로 추가했음에도 불구하고 이후 CodeDeploy에서 배포를 생성하면 계속해서 에러가 발생했다.

바로 이것.... 에러 로그를 살펴보면, npm을 찾을 수 없다는 npm command not found 때문이었다. 구글링과 ChatGPT를 찾아보니 npm이 nvm을 통해 설치되어 있는 경우 nvm이 활성화되지 않으면 npm 명령어를 찾을 수 없는데, 배포 스크립트가 실행될 때 nvm이 활성화되지 않아서 발생하는 문제라고 한다.

export NVM_DIR="/home/ubuntu/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

따라서 스크립트 파일의 #!/bin/bash 부분 아래에 위 코드를 추가해야 nvm을 로드하여, npm을 사용할 수 있도록 환경을 설정할 수 있다.

>> [path]

>>는 명령어의 실행 결과를 지정한 경로의 로그 파일에 추가(append)하는 리디렉션 연산자이다.

➂ application_start.sh 파일 추가

scripts 폴더를 내부에 application_start.sh 파일도 추가한다.

#!/bin/bash

echo 'run application_start.sh: ' >> /home/ubuntu/Test-Server/deploy.log

# pm2 버전 확인
echo 'check pm2 version: ' >> /home/ubuntu/Test-Server/deploy.log
pm2 -v >> /home/ubuntu/Test-Server/deploy.log

# pm2 restart 명령어 실행
echo 'pm2 restart nodejs-app' >> /home/ubuntu/Test-Server/deploy.log
pm2 restart nodejs-app >> /home/ubuntu/Test-Server/deploy.log

마찬가지로 pm2: command not found 에러가 발생했는데, 이 역시 pm2가 EC2 인스턴스에서 설치되지 않았거나, 설치된 경로가 PATH에 포함되지 않은 경우 발생할 수 있다고 한다. 위에서 pm2는 인스턴스에 설치했기 때문에 PATH에 pm2의 경로를 명시적으로 추가해야 한다.

export NVM_DIR="/home/ubuntu/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # nvm 로드
export PATH=$PATH:/home/ubuntu/.nvm/versions/node/v22.17.0/bin  # pm2 경로 추가

스크립트 파일의 #!/bin/bash 부분 아래에 위 코드를 추가하여 pm2 경로를 명시적으로 설정하고, pm2를 사용할 수 있도록 설정한다.


3️⃣ 애플리케이션 생성

AWS CodeDeploy의 애플리케이션 메뉴로 이동해 새로운 애플리케이션을 생성한다.

애플리케이션 생성

[애플리케이션 구성]

  • 컴퓨팅 플랫폼: EC2의 내용을 배포할 것이므로 EC2/온프레미스를 선택한다.

4️⃣ 배포 그룹 생성

생성한 애플리케이션 메뉴로 이동해 배포 그룹을 생성한다.

서비스 역할 선택환경 구성
배포 설정 및 로드 밸런서

[서비스 역할 선택]

[환경 구성]

  • Amazon EC2 인스턴스를 선택한다.
  • 키(Key)에는 Name, 값(Value)에는 인스턴스의 이름을 입력한다.

[배포 설정 및 로드 밸런서]

  • 배포 설정은 CodeDeployDefault.AllAtOnce로 설정한다. 현재 적용할 인스턴스가 1개라서 큰 의미는 없다.
  • 로드 밸런싱을 비활성화한다.

5️⃣ 테스트 배포 생성

CodeDeploy가 잘 설정되었는지 확인하기 위해 수동으로 배포를 생성해본다.

➀ 새로운 커밋 생성

GitHub 변경사항(커밋)을 이용해 배포를 생성할 예정이므로, 코드 에디터에서 눈으로 확인할 수 있는 변경 사항을 발생시켜 커밋 ID를 생성한다. 업데이트가 잘 일어났는지 확인하기 위해서 눈으로 확인할 수 있는 변경 사항을 추천한다.

예시)

app.get('/', (req, res) => {
  res.send('안녕하세요? 테스트 서버입니다.');
});

업데이트 후 해당 변경사항을 레포지토리에 push한다.

커밋 내역을 확인하고, 해당 커밋으로 이동한 후 URL에서 전체 해시값을 추출한다.

예시)

https://github.com/mygithubaccount/myrepo/commit/e6b0a736e8912f3097dc0cc42f0fc1906388343e

⇒ 전체 해시값: e6b0a736e8912f3097dc0cc42f0fc1906388343e

➁ 배포 생성

배포 설정레포지토리 입력
추가 배포 동작 설정

[배포 설정]

  • 개정 유형: 애플리케이션을 GitHub에 저장을 선택한다.
  • GitHub 토큰 이름: GitHub username을 입력한 후 GitHub에 연결한다. 경우에 따라 2차 인증이 필요할 수도 있다.

[레포지토리 입력]

GitHub 계정과 AWS가 연결되었다면 레포지토리 정보를 입력한다.

  • 레포지토리 이름: username/repo_name 형식으로 입력한다.
  • 커밋 ID: 위에서 추출한 커밋 ID를 입력한다.

[추가 배포 동작 설정]

  • 콘텐츠 옵션: 콘텐츠 덮어쓰기를 선택한다.

➂ 결과

여러 번의 시도 끝에... 드디어 배포 성공을 맛볼 수 있었다.

GitHub 연동 설정

1️⃣ GitHub ID 제공업체 추가

GitHub 연동을 위해 AWS IAM의 ID 제공업체로 이동해 GitHub를 추가해야 한다.

ID 제공업체 추가

[ID 제공업체 추가]

  • 공급자 유형: OpenID Connect를 선택한다.
  • 공급자 URL: https://token.actions.githubusercontent.com를 지정한다.
  • 대상: sts.amazonaws.com를 지정한다.

2️⃣ GitHub IAM 역할 생성

다음으로 IAM의 역할 메뉴로 이동해 IAM 역할을 생성한다.

신뢰할 수 있는 엔티티 유형웹 자격 증명
권한 추가정책 편집

[신뢰할 수 있는 엔티티 유형]

  • GitHub organization을 연동해야 하므로 웹 자격 증명을 선택한다.

[웹 자격 증명]

  • ID 제공업체: 이전에 추가한 https://token.actions.githubusercontent.com를 선택한다.
  • 대상: sts.amazonaws.com을 선택한다.
  • GitHub organization: GitHub username을 추가한다.
  • GitHub repository: 선택사항이지만 추후에 정책을 추가하게 된다면 다시 수정이 필요하다. 서버의 코드를 가진 GitHub 레포지토리 이름을 입력한다.
  • GitHub branch: 마찬가지로 선택사항이지만 추후에 정책을 추가하게 된다면 수정이 필요하다. 레포지토리의 모든 브랜치의 변경사항을 반영하려면 *를 유지하고, 특정 브랜치의 변경사항만 반영하려면 브랜치 이름을 지정한다.

[권한 추가]

  • AWSCodeDeployFullAcess 권한을 추가한다.

[정책 편집]
만약 웹 자격 증명에서 레포지토리와 브랜치를 지정하지 않았다면, 정책을 편집하고 레포지토리와 브랜치를 지정한다.

"StringLike": {
  "token.actions.githubusercontent.com:sub": [
    "repo:JWJung-99/Test-Server:ref:refs/heads/main"
  ]
}

아래와 같이 역할 생성을 완료했다.

⚠️ 역할은 나중에 수정이 불가하며, 수정하려면 ID를 삭제한 후 다시 생성해야 하므로 신중하게 결정해야 한다!


3️⃣ Workflows 스크립트 생성

프로젝트 최상위에 .github/workflows 폴더를 추가하고 deploy.yml 파일을 생성한다. deploy.yml 파일 내에는 GitHub 레포지토리에 동작이 발생했을 때 Github Actions로 실행할 작업들을 정의한다.

# This is a basic workflow to help you get started with Actions
# name:Connect to an AWS role from a GitHub repository

# Controls when the action will run. Invokes the workflow on push events but only for the main branch
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  AWS_REGION: 'ap-northeast-2' #Change to reflect your Region

# Permission can be added at job level or workflow level
permissions:
  id-token: write # This is required for requesting the JWT
  contents: read # This is required for actions/checkout
jobs:
  AssumeRoleAndCallIdentity:
    runs-on: ubuntu-latest
    steps:
      - name: Git clone the repository
        uses: actions/checkout@v3
      - name: configure aws credentials
        uses: aws-actions/configure-aws-credentials@v1.7.0
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }} #change to reflect your IAM role’s ARN
          role-session-name: GitHub_to_AWS_via_FederatedOIDC
          aws-region: ${{ env.AWS_REGION }}
      # Hello from AWS: WhoAmI
      - name: Sts GetCallerIdentity
        run: |
          aws sts get-caller-identity

      # Step 3 - check the application-name and deployment group name
      - name: Create CodeDeploy Deployment
        id: deploy
        run: |
          aws deploy create-deployment \
          --application-name [CodeDeploy 애플리케이션 이름] \
          --deployment-group-name [CodeDeploy 배포 그룹 이름] \
          --deployment-config-name [CodeDeploy 배포 설정 내용] \
          --github-location repository=${{ github.repository }},commitId=${{ github.sha }}

[on]
언제(= 어떤 이벤트가 일어났을 때) 해당 액션이 실행될 것인지 명시한다. 나는 main 브랜치에 push나 pull request가 발생했을 때 액션이 실행되도록 설정했다.

[jobs]
steps 안에 구체적인 액션의 실행 내용을 작성한다.

  • role-to-assume: 위에서 생성한 GitHub IAM 역할을 지정한다. 직접 입력해도 되지만 보안상 GitHub Repository Secret을 이용해 관리하는 것이 좋다.

  • CodeDeploy Deployment

    aws deploy create-deployment \
  --application-name [CodeDeploy 애플리케이션 이름] \
  --deployment-group-name [CodeDeploy 배포 그룹 이름] \
  --deployment-config-name [CodeDeploy 배포 설정 내용] \
  --github-location repository=${{ github.repository }},commitId=${{ github.sha }}
    • application-name: CodeDeploy 애플리케이션 이름을 입력한다. 예시) test-app
    • deployment-group-name: CodeDeploy 배포 그룹 이름을 입력한다. 예시) test-app-deploy-group
    • deployment-config-name: CodeDeploy 배포 설정 내용을 입력한다. 예시) CodeDeployDefault.AllAtOnce

⚠️ 입력 시에 줄바꿈 \ 뒤에 공백( )이 하나라도 있으면 Actions 실행 시 에러가 발생하므로 주의해야 한다!


4️⃣ 서버 접속

이제 서버에 접속해보면 위에서 적용한 변경사항을 확인할 수 있다.

마치며

이처럼 GitHub Actions를 활용해 EC2 서버의 CI/CD 환경 구축까지 완료했다. 다음에는 현재 퍼블릭 IP로 접속하고 있는 EC2 서버에 도메인을 연결하고, 데이터베이스 연결 등 서버의 기능을 추가해 api 문서 작성까지 시도해 볼 예정이다.

참고

profile
진욱
이전 포스트

[Node.js] 1. Express 서버 구성하기

다음 포스트

[Node.js] 3. EC2 서버에 HTTPS 연결하기

0개의 댓글