현대 오토에버 SW 스쿨 - 클라우드/버전관리_Github

[Github] - Github page 로 Helm 패키지 이용 & CI/CD

yongyongMom 2024. 11. 7. 17:20
SMALL

1. Helm

1) 개요

  • kubenetes 를 이용해서 애플리케이션을 배포시
    • pod (Pod, ReplicaSet, Deployment, DaemonSet, StatfulSet 등 ) 을 만들기 위한 작업을 수행
    • 외부로 노출시키기 위해 Service (ClusterIP, NodeProt, LoadBalancer, Ingress, Controller, External IP 등) 
    • 데이터를 저장하기 위한 Volume 작업 수행
  • kubenetes 만을 이용하게 되면 여러 개의 작업을 별개로 수행하기 때문
    -> 오류 발생 or 일부분 업데이트 되지 않는 일 발생
  • 하나의 패키지로 묶어서 한번에 수행하기 위한 도구 -> Helm

2) Heml 설치

 

헬름 설치하기

헬름 설치하고 작동하는 방법 배우기.

helm.sh

  • 설치 확인 : helm version

3) 애플리케이션 설치

 

Learn Kubernetes in a Month of Lunches

Learn Kubernetes in a Month of Lunches

kiamol.net

  1. 레포지토리 추가
  2. 레포지토리의 캐시를 업데이트
  3. 애플리케이션 검색 및 설치
  4. 애플리케이션 다운로드 - 구조를 알아보기 위해서 압축 해제 진행 
    1. 환경 변수 확인
    2. 로컬에 nginx 설치 진행
    3. 원격 서버의 kiamol/web 설치

4) 패키징

  • helm creat 차트 이름 
  • 명령을 수행하면 Chart.yml, Valuse.yaml, charts 와 template 디렉터리가 생성되고 기본 코드 작성
helm create samplechart

 

5) 레지스트리를 만들어서 업로드

  • 레지스트리 만드는 방법
  1. Cloud 의 File Storage 이용 ( AWS 의 S3 등)
  2. Harbor 를 이용해서 구축
  3. git hub 같은 버전 관리 사이트를 이용
  4. 직접 웹 서버를 구축 ( S3 는 Front End Server 의 기능을 하는 것이 가능)

 

6) Github Page 로 Helm 패키지 저장 및 다운로드

  1. git hub 레포지토리와 배포할 데이터를 가진 디렉터리를 동기화
  2. git hub 레포지토리를 웹 사이트로 변경
    1. github 레포지토리 - [Settings] - [Pages] - [branch]
  3. 배포할 디렉터리 복사
  4. 압축파일을 생성
  5. index.yaml 파일 생성
  6. 푸시 수행
  7. 레포지토리 등록 후 설치

1. 지속적 통합/배포

1) 애자일 개발 모델

  • 개발 팀에 속한 모든 팀원이 동시에 같은 요구 사항에 대해서 작업하는 방식
  • RAD(Rapid Application Development) : 신속 애플리케이션 개발
    • 각자가 다른 업무를 수행 중 기획자가 작성한 요구 사항을 개발자가 구현
    • 개발자가 완료한 작업은 테스터가 수행하는 형태
  • 애자일 모델
    • 애플리케이션의 요구 사항을 우선 순위에 따라 분류 -> 요구 사항 별로 개발을 진행
    • 분류한 일정량의 작업을 분석하고 구현하는데 할당된 작업 기간을 Spring 
    • 애플리케이션은 Sprint 를 반복하면 완성됨
    • 기간은 보통 1주에서 3주로 짧은 기간 안에 많은 기능을 구현
    • 동일한 프로젝트에서 작업하는 개발자들이 각자 자신이 맡은 기능을 구현하고 구현과정에서 변경한 코드를 한꺼번에 Main Branch 에 Commit 
    • Git hub 에서는 main branch 라고 하고 Git Lab 에서는 master branch 라고 함
    • 회귀 결함 (이전에 제대로 작동한 기능에 문제가 발생) or 코드 충돌 같은 문제 발생 가능
  • 애자일 도입 초창기
    • 하루에 한 번만 통합하거나 sprint 가 끝날 떄 몰아서 통합 진행
    • 최근들어 지속적 통합 방식을 이용하는 형태로 변경
    • 지속적 통합에서는 개발자가 작업을 완료하는 즉시 main branch 에 통합 진행
    • -> 개발잔느 코드 충돌 문제를 좀 더 빠르게 발견 가능함
    • 회귀 결함이 발생해도 더 효율적으로 해결 가능함

2) 개발 워크플로

  • 로컬에서 단위 테스트 실행
    • 개발자는 중앙 레포지토리에서 최신 코드를 로컬로 가져온 후 요구 사항을 구현
    • 요구 사항을 구현할 때는 TDD 방식을 사용함
      TDD(Test-Driven Development) : 테스트 주도 개발
    • 구현된 코드는 단위 테스트를 모두 통과할 때까지 반복적으로 수정
    • TDD 
      • 코드를 구현하기 전에 테스트 케이스를 먼저 작성하는 개발 방식
      • 처음에는 테스트 케이스만 작성되어 있고 구현부는 없음
      • 테스트를 실행하면 모두 실패로 나옴
      • 구현부 코드를 작성해 나가면서 성공률이 올라가는 형식의 개발방식임
  • 중앙 레포지토리 코드 push 및 병합
    • 기능 구현을 완료한 후 중앙 레포지토리에 코드를 push 하면 main branch 에 merge
    • 코드 충돌이 발생할 수 있음
  • 병합 후 컴파일
    • 새로 병합된 코드로 인해 기존에 없던 컴파일 에러가 발생할 수 있음
  • 컴파일 된 코드에서 테스트 실행
    • 단위 테스트와 통합 테스트를 실행해서 회귀 결함이 있는지 확인
    • 정적 분석 (코딩 표준 준수 및 불필요한 코드의 존재 여부) 같은 작업이 추가되기도 함
  • 아티팩트 배포
    • 단계별 품질 점검이 끝나면 모든 코드를 패키징하고 최종 사용자가 사용할 수 있도록 배포
    • 자바의 경우 아티팩트는 jar 나 war

3) 지속적 제공 / 지속적 배포 

  • 지속적 통합 : 애플리케이션 코드가 변경될 때마다 개발 환경에서 테스트가 수행되며 빌드 결과가 공개됨
  • 정기 빌드외에 일상적인 코드 변경도 개발 환경에서 테스트와 확인 과정을 거치는 것이 중요함
  • 개발 환경에서는 잘 동작하던 애플리케이션이 production 환경에서 문제 발생
    -> 새로 변경한 항목이 기존 production 환경의 소프트웨어나 하드웨어와 호환되지 않아서 발생
  • production 에 자주 배포되지 않는 환경은 해당 문제를 디버깅하고 해결하는 것이 어려움

4) CI/CD 워크 플로우 과정 - 사칙연산 계산기 -> 덧셈을 추가 구현

# 1. 중앙 레포지토리에서 코드 가져오기

# 2. 단위 테스트 구현
{
	Result = Addition(10,20);
    Assert.assertEquals(Result, 30, "Addition Function Does Not work");
}
# 실행시 에러 발생 : Addition 구현 안됨

# 3. 코드 구현
Addition(a,b) {
	Result = a + b;
    return Result;
}

# 4. 단위테스트 다시 수행 : 통과

# 5. 코드 push 와 병합 
# 6. 컴파일 다시 수행
# 7. 병합된 코드에서 테스트 실행
# 8. 아티팩트 배포
# 9 배포 애플리케이션의 E-E(End to End : 실제 사용 환경에서 테스트) 테스트 수행
반응형
LIST