Github Action을 활용한 CI/CD

-·2022년 1월 12일
0

강의정리 - MLOps

목록 보기
8/18

Product Serving

목차

  • CI/CD
    -- 현업 개발 프로세스
    -- CI/CD개념
  • Github Action
    -- Github Action소개
    -- Github Action을 사용한 배포
  • Mask Classification Streamlit 배포하기
    -- Compute Engine에서 Streamlit 실행하기
    -- Github Action을 사용한 배포 자동화

CI/CD

개발 프로세스

개발 환경

Local

  • 각자의 컴퓨터에서 개발
  • 각자의 환경을 통일시키기 위해 Docker 등을 사용

Dev

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

Staging

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

Production -> 현재 내가 사용하는 앱

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

개발 환경을 나누는 이유

  • 실제 운영중인 서비스에 장애가 발생하면 안됨

Dev= Staging = Production인 경우

  • 소스코드를 저장하면 바로 반영
  • PyCharm이 SSH로 서버에 바로 붙어있고, 자리비운 상황에 만약 고양이가 코드를 치고 ctrl+s를 했다면?

Git Flow

main - staging - dev - feature/기능이름 <- branch

Prod Server - Staging Server - Dev Server <- Server

서버에 코드를 보내는 것과 반복적으로 진행할 Test를 어떻게 실행하는 방법은?

Dev Branch에서 Merge 되면 => Local에서 Git pull & Test 실행 후 괜찮으면 코드 배포(FTP로 파일 전송)
=> 번거로운 일

Continuous Integration(CI)

Continuous Integration, 지속적 통합

  • 새롭게 작성한 코드 변경 사항이 Build, Test 진행한 후 Test Case에 통과했는지 확인
  • 지속적으로 코드 품질 관리
  • 10명의 개발자가 코드를 수정했다면 모두 CI 프로세스 진행

Continuous Deploy/Delivery(CD)

Continuous Deploy/Delivery, 지속적 배포

  • 작성한 코드가 항상 신뢰 가능한 상태가 되면 자동으로 배포될 수 있도록 하는 과정
  • CI 이후 CD를 진행
  • Dev/ staging/ main 브랜치에 Merge가 될 경우 코드가 자동으로 서버에 배포

CI/CD

큰 개념을 생각하면

  • CI: 빌드, 테스트 자동화
  • CD: 배포 자동화

Voila, Streamlit 실습에 적용

  • Local에서 개발
  • Main으로 Merge시 Production Server에 코드 배포

개인 프로젝트에선 서버를 많이 두지 않는 경우도 존재

  • Dev/Staging/Prod 모두 비용

CI/CD를 활용할 수 있는 도구

많은 솔루션이 존재

Jenkins, CircleCI, Travis CI
AWS CodeDeploy, GCP Cloud Build, Github Action

Github Action

Github에서 출시한 기능으로, 소프트웨어 workflow 자동화를 도와주는 도구

Automate your workflow from idea to production

  • Test Code
    -- 특정 함수의 return값이 어떻게 나오는지 확인하는 test code
    -- 특정 변수의 타입이 int가 맞는가?
    -- Unit Test, End to End Test

  • 배포
    -- Prod, Staging, Dev서버에 코드 배포
    -- FTP로 파일 전송할 수도 있고, Docker Image를 Push하는 방법 등
    -- Node.js등 다양한 언어 배포도 지원

  • 파이썬, 쉘 스크립트 실행
    -- Github Repo에 저장된 스크립트를 일정 주기를 가지고 실행
    -- crontab의 대용
    -- 데이터 수집을 주기적으로 해야할 경우 활용할 수도 있음

  • Github Tag, Release자동으로 설정
    -- Main브랜치에 Merge될 경우에 특정 작업 실행
    -- 기존 버전에서 버전 UP하기
    -- 새로운 브랜치 생성시 특정 작업 실행도 가능

  • Github Action - Workflow 예시
    -- 그 외에도 다양한 Workflow를 만들 수 있음
    -- 사용자가 만들어서 Workflow 템플릿을 공유하기도 함
    -- 원하는 기능이 있는 경우<기능>github action 등으로 검색 !

Action Marketplace :
Awesome Github Action :

Github Action Pricing :(
Public Repo : 무료
Private Repo : 조건이 따로 있음

Github Action 제약 조건

  • 하나의 Github Repository 당 Workflow는 최대 20개까지 등록할 수 있음
  • Workflow에 존재하는 Job(실행)은 최대 6시간 실행할 수 있으며, 초과시 자동으로 중지됨
  • 동시에 실행할 수 있는 Job 제한 존재

Github Action 사용하는 방식

  • 코드작업
  • 코드작업후, Github Action으로 무엇을 할 것인지 생각
  • 사용할 Workflow 정의
  • Workflow 정의 후 정상 작동하는지 확인

핵심 개념 : Workflow, Event, Jobs, 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 실행)

Steps

  • 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 : 직접 서버를 호스팅해서 사용하는 방법

Github Action Hello World !

Github Repository 새로 생성 - public

Add file - Create new file

hello-world.py 를 생성한 후, Commit

Github Repository에서 Action 클릭

하단에 More Continuous integration workflows 클릭 - Python app

템플릿으로 파일이 생성 -> Test with pytest만 수정 (python hello-world.py)

Start commit으로 커밋

커밋한 후, 노란색 동그라미 클릭 ! (노란색 동그라미 -> action실행중)

Some checks haben't completed yet

초록색으로 바뀌면 Success를 의미

오른쪽 위에 re-run all jobs

정의한 Step 클릭시 로그를 확인할 수 있음

on : Event, 언제 Workflow가 실행될 것인가?!

jobs: jobs 정의, build는 job의 이름!

runs-on: ubuntu 환경에서 실행 (os 환경)

uses: 사용할 Github Action

name: Step의 이름

uses 없는 경우: run에 작성된 쉘 커맨드 실행

on:
	push:
    	branches: ~
       pull_request:
       branches: ~ 
jobs:
	build :

Mask Classification Streamlit 배포하기

진행순서

  • Compute Engine실행
  • SSH 키 생성 및 Github Secrets 설정
  • 터미널에서 최초로 서비스 실행
  • Github Action을 통한 배포 자동화

실습 깃헙

JODONG2

profile
-

0개의 댓글