MLOps - 11. CI/CD, Github Action

출처 : 변성윤님 블로그.
출처 : 부스트캠프 AI Tech.

1. CI/CD

1.1 현업 개발 프로세스

• Local
  • 각자의 컴퓨터에서 개발
  • 각자의 환경을 통일시키기 위해 Docker 등을 사용
• Dev
  • Local에서 개발한 기능을 테스트할 수 있는 환경
  • Test 서버
• Staging
  • Production 환경에 배포하기 전에 운영하거나 보안, 성능 측정하는 환경
  • Staging 서버
• Production
  • 실제 서비스를 운영하는 환경
  • 운영 서버
• 개발 환경을 나누는 이유
  • Dev = Staging = Production인 경우 - 소스 코드를 저장하면 바로 반영
  • PyCharm이 SSH로 서버에 바로 붙어있고, 자리비운 상황에 만약 고양이가 코드를 치고 ctrl + s를 했다면?

1.2 CI/CD 개념

• 서버에 코드를 보내는 것과 반복적으로 진행할 Test를 어떻게 실행하는 방법은?
• Dev Branch에 Merge되면 => Local에서 Git Pull & Test 실행 후 괜찮으면 코드 배포(FTP로 파일 전송) => 번거로운 일

1.2.1 CI

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

1.2.2 CD

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

1.2.3 CI/CD 실습

• Voila, Streamlit 실습에 적용
  • Local에서 개발
  • Main으로 Merge시 Production Server에 코드 배포
• 개인 프로젝트에선 서버를 많이 두지 않는 경우도 존재 => Dev / Staging / Prod 모두 비용

1.2.3 CI/CD 도구

2. Github Action

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

2.1 Github Action Workflow

2.1.1 Test Code

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

2.1.2 배포

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

2.1.3 파이썬, 쉘 스크립트 실행

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

2.1.4 Github Tag, Release 자동으로 설정

• Main 브랜치에 Merge 될 경우에 특정 작업 실행
• 기존 버전에서 버전 Up하기
• 새로운 브랜치 생성시 특정 작업 실행도 가능

2.1.4 다양한 Workflow

• 사용자가 만들어서 Workflow 템플릿을 공유하기도 함
• 원하는 기능이 있는 경우 <기능> github action 등으로 검색!
• Action Marketplace : https://github.com/marketplace?type=actions
• Awesome Github Action : https://github.com/sdras/awesome-actions

2.1.5 Github Action Pricing

• Public Repo : 무료
• Private Repo : 아래 조건을 따름
  

  

2.1.6 Github Action 제약 조건

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

2.1.7 Github Action 사용하는 방식

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

2.2 Github Action Core

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

2.2.1 Github Action Core - Workflow

• 여러 Job으로 구성되고 Event로 Trigger(실행)되는 자동화된 Process
• 최상위 개념
• Workflow 파일은 YAML으로 작성되고, Github Repository의 .github/workflows 폴더에 저장

2.2.2 Github Action Core - Event

• Workflow를 Trigger하는 특정 활동, 규칙
• 특정 Branch로 Push하는 경우
• 특정 Branch로 Pull Request하는 경우
• 특정 시간대에 반복(Cron)

2.2.3 Github Action Core - Jobs

• Runner에서 실행되는 Steps의 조합
• 여러 Job이 있는 경우 병렬로 실행하며, 순차적으로 실행할 수도 있음
• 다른 Job에 의존 관계를 가질 수 있음(A Job Success 후 B Job 실행)

2.2.4 Github Action Core - Steps

• Step은 Job에서 실행되는 개별 작업
• Action을 실행하거나 쉘 커맨드 실행
• 하나의 Job에선 데이터를 공유할 수 있음

2.2.5 Github Action Core - Actions

• Workflow의 제일 작은 단위
• Job을 생성하기 위해 여러 Step을 묶은 개념
• 재사용이 가능한 Component
• 개인적으로 Action을 만들 수도 있고, Marketplace의 Action을 사용할 수도 있음

2.2.6 Github Action Core - Runner

• Github Action도 일종의 서버에서 실행되는 개념
• Workflow가 실행될 서버
• Github-hosted Runner : Github Action의 서버를 사용하는 방법
• 성능 : vCPU 2, Memory 7GB, Storage 14GB
• Self-hosted Runner : 직접 서버를 호스팅해서 사용하는 방법

2.3 Github Action 실습

3. Deploy streamlit using Github Action

• Compute Engine 실행
  • GCP
• SSH 키 생성 및 Github Secrets 설정
  • 기본적으로 authorized_keys에 퍼블릭 키가 등록되면 외부에서 접근 가능
  • 단, GCP는 주기적으로 authorized_keys 파일을 삭제해서 외부에서 키파일 등록하는 과정이 필요

$ cd ~/.ssh/
$ ssh-keygen -t rsa -b 4096 -C "boostcamp.philhoon@gmail.com"

$ cat id\_rsa.pub >> authorized\_keys
$ cat id\_rsa.pub
# cat id\_rsa.pub을 실행한 후, 복사

• 터미널에서 최초로 서비스 실행
• Github Action을 통한 배포 자동화
• [Product Serving] 2-5. Github Action을 사용한 CI_CD.pdf 참고