Github actions으로 s3 배포 자동화 하기
Github 와 Github Actions을 이용한 CI/CD 구축
CI란?Continuous Integration지속적인 통합을 의미- 코드 등의 변경 사항이 정기적으로 빌드 및 테스트되어 통합 관리 하는 것을 뜻 한다.
CD란?Continuous Delivery와Continuous Depolyment지속적 서비스 / 지속적 배포를 의미- 개발자의 변경 사항이 고객의
Production환경 까지 지속적으로 배포 / 서비스 되는 것을 뜻 한다.
Github Actions란?- 코드 저장소인
Github의 이벤트가 발생하면 특정 작업을 정의해 수행시킬 수 있는 서비스이다. - 여기서는
CI/CD를 수행 하기 위해 작업을 진행 했고, 배포 이외에도 여러 작업을 수행할 수 있다.
- 코드 저장소인
CI/CD는프론트와API서버를 나누어 진행하였다.- 이번 글에서는
프론트배포 구성과 간단한GitHub Actions를 설명한다.
프론트의 CI/CD 구성
간단한 구성도
일단 S3는 CloudFront를 사용하여 CDN(Content Delivery Network)로 구성하였다.
글이 길어 지고 핵심을 놓칠 수 있기에 이 글에서 S3의구성 방법은 다루지 않는다.
프론트 환경에 맞춰 API의 URI 세팅
lcoal환경과 운영환경을 동일하게 유지할 것 이므로 API서버의 URI만 환경에 따라 수정해 준다.
Vite를 사용하는Vue프로젝트 이므로VITE_APP을 명시해 작성해 준다.import.meta.env.VITE_APP_API_URL와 같이 코드에서 환경변수를 불러와 사용할 수 있다.
.env는local환경에서 사용할 환경변수를 포함하고 있고npm run dev를 실행 했을 때 세팅된다.1
VITE_APP_API_URL=http://localhost:8080
.env.production는운영환경에서 사용할 환경변수를 포함하고 있고npm run build을 이용해 빌드할 때 세팅된다.1
VITE_APP_API_URL=https://api.yongjun.store
GitHub Actions를 이용한 CD 구성
해당 프로젝트의 GitHub Repository로 접속해 Actions 탭을 클릭
원하는 프로젝트 형식을 검색하면 그에 맞는 초기 틀을 제공해 준다.
사실, 아무거나 선택해서 들어가도 상관없다. 기본적으로 yml형식으로 작성만 하면 어떤걸 선택해도 상관 없기 때문.
node를 선택해서 들어가면 위와 같이 기본적인 틀을 제공해 준다.
작성법은 해당 문서에 자세히 나와 있다.
https://docs.github.com/ko/actions/examples/using-scripts-to-test-your-code-on-a-runner
GitHub Actions기본 구성요소
1 . Workflow
event를 기반으로 동작하며컨테이너이자 최상위 요소yml형식으로 작성하고 프로젝트의.github/workflows경로에yml로 생성된다.
2 . Job
- 작업을 시행하는 요소. 여러
step으로 구성되어 있다. - 다른 작업과 의존성관계를 나타낼 수 있고 병렬 실행도 가능하다.
3 . Step
Job을 구성하는 작업 단위 이며, 여러Tesk로 구성Shell이나Script로 명령을 입력할 수 있고action을 실행할 수도 있다.
4 . Action
marketplace에서 제공하는Action을 사용할 수 있고 직접 작성해서 사용할 수도 있다.재사용이 가능하다.
5 . Event
- 실행될
조건(Trigger)를 나타냄
6 . Runner(Enviroment)
- 환경을 정의 해준다.
직접 호스팅(self-hosted runner)을 해줄 수도, github에서 제공해 주는github-hosted runner를 사용할 수도 있다.
Actions yml 작성
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
name: main Build
on:
push:
branches:
- main # main브랜치 push할 이벤트 발생
jobs:
build:
runs-on: ubuntu-latest # ubuntu 최신 버전에서 구동
steps:
- name: Checkout source code. # repository에 있는 소스 코드를 체크아웃
uses: actions/checkout@v2
- name: Cache node modules # 노드를 설치 (package-lock.json에 있는 정보들도 같이 빌드)
uses: actions/cache@v1
with:
path: node_modules
key: ${{ runner.OS }}-build- ${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.OS }}-build-
${{ runner.OS }}-
- name: Install Dependencies # 의존성 패키지 설치
run: npm install
- name: Build # 프로젝트 빌드
run: npm run build
- name: Deploy # S3에 배포
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_S3_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_S3_SECRET_ACCESS_KEY_ID }}
run: |
aws s3 cp \
--recursive \
--region ap-northeast-2 \
dist s3://yongjun-store-web-page
간단한 흐름을 보자면
GitHub Actions에서 제공해 주는 ubuntu OS를 사용해서 node를 설치한 후, 프로젝트를 빌드해서 S3에 ACCESS하고 저장소를 초기화 한 후, 빌드된 dist를 업로드 한다.
steps:에서 - name:을 이용해서 어떤 행동의 대한 구분을 해주고 uses:를 사용해 특정데이터나 진행 상황을 Action하거나 run:을 사용해서 행동을 명령할 수 있다.
환경 변수
위 코드를 보면 {{ }} 감싸진 변수들을 볼 수 있는데, GitHub Actions에서 민감 정보를 관리할 수 있는 현경 변수를 세팅한 것이다.
${{ runner.OS }}:Workflow에서 사용되는 매크로 중 하나로, 현재 실행 중인러너(runner)의운영 체제(OS)를 나타낸다.- 별도 세팅이 필요 없는 기본 환경 변수.
${{ secrets.AWS_S3_ACCESS_KEY_ID }}${{ secrets.AWS_S3_SECRET_ACCESS_KEY_ID }}- 이 두개는
S3에 접근할 수 있는ACCESS KEY값 이므로 사용자가 따로 환경 변수 세팅을 해줘야 한다.
- 해당 프로젝트 탭에서
Settings를 클릭 - 좌측
Security탭에Secrets and variables-Actions로 이동 Repository secrets-New repository secrets클릭
Name : 사용할 환경 변수의 이름을 입력
Secret : 값 입력
Build 완료
작성을 완료하고, 내용을 Commit and Push해주면
빌드가 완료된걸 확인 할 수 있다.
그 후
S3에 간단하게 배포하는 CI/CD를 작성해 보았다.
Jenkins를 사용해서 배포하는 것보다 관리도 더 쉽고 CI/CD를 한 공간에서 처리할 수 있다는게 너무 매력적이었다.
하지만 Jenkins와는 달리 private 저장소는 부분 유료라는 점과 최근에 나와 참고 자료가 부족한 점이 힘들었다.
이 부분까지는 그렇게 어려운 점이나 막히는 부분이 없었지만, API서버를 배포할 때 EC2와 Docker에서 많이 막히고 힘들었다.
다음에는 EC2에 Dockerfile과 docker-compose를 이용해서 Spring boot프로젝트를 배포하는 글을 작성할 예정이다.