Overview
CI
- Continuous Integration
- 간단히 설명하자면, 코드 - 빌드 - 테스트 로 이어지는 일련의 생명주기를 잦은 주기로 자동화
- 애자일 방법론 중 하나인 익스트림 프로그래밍에서 나온 개념
1. 코드 변경사항을 주기적으로 빈번하게 머지해야한다.
2. 통합을 위한 단계 (빌드, 테스트, 머지)의 자동화
- 최대한 작은 단위로 쪼개어 작업한다는 것이 전제됨
- 최대한 작은 단위로 나누지 않는다면 merge에 시간을 너무 많이 쓰게 된다.
- 동작
- A 개발자님 방금 Merge하는 과정에서 에러가 났습니다 확인하여주세요~~~~~
- 장점
- 주기적으로 짧은 단위로 머지하기 때문에 머지 충돌을 피할 수 있어서 개발 생산성이 향상됨
- 문제점을 빠르게 발견할 수 있음.
- 버그 수정이 용이
- CI를 잘 작성하기 위해서는, 모든 개발자들이 자신들이 작성하는 코드에 한해서 Unit Test를 포함해야하기 때문에 코드의 퀄리티 향상에 기여할 수 있다. (안정성이 높아진다.)
CD
- Continuous Delivery
- 코드 - 빌드 - 테스트 - 배포 in 개발환경
- 운영 환경으로 바로 넘기기에는 두려움
- 사람의 손 거치는 부분 없이 배포까지! (단, 운영환경으로 넘어갈 때는 수동으로)
- Continuous Deployment
- 코드 - 빌드 - 테스트 - 개발 환경에 배포 - 운영 환경 배포
- 사람의 손 거치는 부분 없이 운영 환경에 배포까지!
CI/CD Pipeline
- code → build → test → release →deploy
GitHub Actions?
- since 2018
- component
- Event
- ex1) main 브랜치로 머지
- ex2) 커밋을 푸쉬
- ex3) 이슈를 누군가 열면
- workflow
- 해당 이벤트에서 어떠한 일을 할 것인지
- Jobs
- Workflow에서는 하나 또는 하나 이상의 Job을 수행 가능
- ex1) Job “unit tests”
- ex2) Job “E2E tests”, …
- Job은 병렬적으로도, 순차적으로도 동작하겠끔 만들 수 있음.
- step
- Job을 수행하기 위한 단계
- Shell Script로 작성 가능
- Action을 활용 가능
- Action
- 흔하게 사용되는 다양한 명령어들이 actions로 정리되어있음.
- 잘만들어진 필요한 대부분의 actions들이 라이브러리처럼 작성되어있음.
- Runner
- VM or Container
- 각각의 Job들은 개별적인 각각의 Runner라는 컨테이너에서 실행
GitHub Actions
Path
- .github / workflows / workflow.yml (원하는 이름)
yml file
- name : workflow 이름
- on : event 명시
- [push] : commit이 push 될 때마다
- jobs:
- 첫째줄 : 어떠한 job인지
- runs-on : 어떤 VM 을 사용할 것인지 (Linux, macOS, Windows 환경, self-hosted runner)
- steps : Job을 실행하기 위한 순서
- checkout action 사용할꺼야
- node setup action 사용할꺼야
- with를 통해 node 버전 명시
- run : shell script 작성
얼마나 사용할 수 있을까
- 저장소마다 최대 20개 등록 가능
- Job은 Step마다 최대 6시간 실행, 초과하게되면 자동 중지
- Job 안에서 Github API를 호출한다면 1시간 동안 최대 1,000번 가능하다.
- 공개 저장소의 경우 사용료는 무료이다.
- 비공개 저장소의 경우, 한달에 500MB 스토리지, 실행 시간 2,000분까지 제공된다. ( 그 이후는 유료 )
대표적인 예
- Test Code
- ex) 특정 함수의 return 값이 어떻게 나오는지 확인하는 테스트 코드
- ex) df의 타입이 pd.DataFrame이 맞는가?
- ex) value1에 특정 값이 들어가는가?
- 쿼리를 날리고 데이터가 맞는지 정합성 체크하는 것도 일종의 테스트
- 배포
- 서버에 새로운 기능, 버전 등을 배포
- 기타 자동화하고 싶은 스크립트
- 주기적으로 데이터를 수집해 처리
- 다양한 파이썬 버전에서 실행되는지 확인
2022 카카오 엔터프라이즈 사례
Overview
- 러너 구성 시 액션 러너가 종료되면 환경을 초기화 해야 한다.
- 메모리 초과 등 빌드 실행 시 리소스 폭증을 제어할 수 있어야 한다.
- 빌드 스케일링이 가능해야 한다.
- 깃허브 액션 러너를 구축하기 위해 우분투 도커 이미지를 사용하고, 쿠버네티스 엔진을 이용해 오케스트레이션 한다.
Container
- build-and-test job
- 특정 컨테이너로 이미지 실행
- 서비스 빌드시 필요한 DB를 컨테이너로 구동
- Docker In Docker
- Runner Docker에서 띄운 Job Container가 Mount 된 File System에 접근이 안됨
- Action에서 보면 Docker In Docker에 대해 예외를 던지도록 처리해놓음. → 사용 불가
- Docker Out of Docker
- Runner Docker와 같은 레벨로 Job Contatiner을 구동하는 방식
exit code 137
- Job Container1과 2가 같은 인스턴스 레이블을 공유하게 되면서, Job Container1이 작업을 끝내고 초기화할 때, Job Container2도 같이 초기화 시키는 현상
- RUNNER_BINDIR 값을 pod 값으로 변경
- 쿠버네티스에서 아무리 많은 배포를 수행하여도, pod는 고유한 값을 지님.
Build Cash 적용
- GIT Action에서 Docker Out of Docker에 Build Cash가 적용 안되자 카카오에서 자체적으로 Action을 만들어 Out of Docker에도 적용될 수 있도록 수정
- 매번 initialize 되는 25분을 5분으로 단축
향후 계획
- 향후 계획으로는 깃허브 액션 러너의 자동 확장을 위해 오토 스케일링 기능을 개발할 예정이다.
- 또한, 빌드 로그 분석과 빌드 에러 원인 파악, 빌드 현황을 한 눈에 볼 수 있는 빌드 대시보드를 개발할 예정이다.
- 마지막으로, CI 빌드를 할 수 있는 전사 공통 빌드 시스템을 개발할 예정이다.
- 이를 통해 개발자들은 깃허브 액션 문법을 활용하여 백엔드, 프론트엔드부터 윈도우, 맥, 모바일까지 설정 없이 빌드할 수 있는 시스템을 개발할 것이다.
💡 이를 통해 개발자들은 깃허브 액션 문법을 활용하여 백엔드, 프론트엔드부터 윈도우, 맥, 모바일까지 설정 없이 빌드할 수 있는 시스템을 개발할 것이다.
추후 계획
앞으로의 발표 계획
대표적인 예 에서 본 것과 같이, MLOps와 관련된 GitAction 적용 사례를 살펴보고,
가능하다면 간단한 데모를 만들어서 발표해보고 싶습니다.
조사해보고 싶은 개념
- 모델 서빙 관련된 부분
레퍼런스
재밌어보이는 글
'MLOps 스터디' 카테고리의 다른 글
| [MLOps for MLE] Database 1 (1) | 2024.01.31 |
|---|---|
| Black formatter, Github Actions에 적용하기 (0) | 2024.01.26 |
