Github Action을 사용한 CI/CD

1. CI/CD

1.1 현업 개발 프로세스

Local

- 각자의 컴퓨터에서 개발

- 각자의 환경을 통일시키기 위해 Docker 등을 사용

Dev

- Local에서 개발한 기능을 테스트할 수 있는 환경

- Test 서버

Staging

- Production 환경에 배포하기 전에 운영하거나 보안, 성능 측정하는 환경

- Staging 서버

Production

- 실제 서비스를 운영하는 환경

- 운영 서버

 

1.2 CI/CD 개념

 

Continuous Integration, 지속적 통합

- 새롭게 작성한 코드 변경 사항이 Build, Test 진행한 후 Test Case에 통과했는지 확인

- 지속적으로 코드 품질 관리

- 10명의 개발자가 코드를 수정했다면 모두 CI 프로세스 진행

=>빌드 테스트 자동화

 

Continuous Deploy/Delivery, 지속적 배포

- 작성한 코드가 항상 신뢰 가능한 상태가 되면 자동으로 배포될 수 있도록 하는 과정

- CI 이후 CD를 진행

- dev / staging / main 브랜치에 Merge가 될 경우 코드가 자동으로 서버에 배포

=>배포자동화

 

 

 

2. Github Action

2.1 Github Action 소개

핵심 개념 : Workflow, Event, Job, Step, Action, Runner

Workflow

- 여러 Job으로 구성되고 Event로 Trigger(실행)되는 자동화된 Process

- 최상위 개념

- Workflow 파일은 YAML으로 작성되고, Github Repository의 .github/workflows 폴더에 저장

Event

- Workflow를 Trigger하는 특정 활동, 규칙

- 특정 Branch로 Push하는 경우

- 특정 Branch로 Pull Request하는 경우

- 특정 시간대에 반복(Cron)

Jobs

- Runner에서 실행되는 Steps의 조합

- 여러 Job이 있는 경우 병렬로 실행하며, 순차적으로 실행할 수도 있음

- 다른 Job에 의존 관계를 가질 수 있음(A Job Success 후 B Job 실행)

Step

- Step은 Job에서 실행되는 개별 작업

- Action을 실행하거나 쉘 커맨드 실행

- 하나의 Job에선 데이터를 공유할 수 있음

Actions

- Workflow의 제일 작은 단위

- Job을 생성하기 위해 여러 Step을 묶은 개념

- 재사용이 가능한 Component

- 개인적으로 Action을 만들 수도 있고, Marketplace의 Action을 사용할 수도 있음

Runner

- Github Action도 일종의 서버에서 실행되는 개념

- Workflow가 실행될 서버

- Github-hosted Runner : Github Action의 서버를 사용하는 방법

- 성능 : vCPU 2, Memory 7GB, Storage 14GB

- Self-hosted Runner : 직접 서버를 호스팅해서 사용하는 방법

 

 

 

2.2 Github Action을 사용한 배포

cloud computing을 사용 할 경우 해당 컴퓨팅에서 

 

1) 키생성

cd ~/.ssh/

ssh-keygen -t rsa -b 4096 -C “본인 이메일”

로 ssh key를 생성한다

2) 키등록

인스턴스에 public key등록

privatekey와 username ip를 github action의 secret에 등록하여사용