결국 데브옵스에게 중요한건 개발 > 빌드 > 실행이다.

시간이 흐름에 따라 툴들이 바뀌어도, 이 큰 흐름내의 작업이 될 것이기 때문이다.

이번주에는 cicd 서버가 띄워질 VM을 따로 띄웠고. 해당 서버에 젠킨스를 설치해, 자바로 만든 앱을 컨테이너에 올려 실제 서비스가 제공될 쿠버네티스 인프라 VM에 배포하는 환경을 만들었다.

소스코드 관리는 깃헙으로 했고, 도커를 통해 jar 가 들어간 이미지를 빌드하고 허브에 저장해둔다.
그리고 CICD 서버에서 kubectl 로 리모트 서버의 쿠버네티스 환경에서, kubectl apply 를 통해 리소스를 배포하면,
Deployment.yaml에 적혀있는, 우리가 막 빌드한 이미지를 허브로 부터 다운받아 리소스를 다시 띄우도록 했다.
이때 kubectl은 배포되는 환경의 인증서 정보가 필요해, .kube/config 파일을 scp로 받아와 설정해뒀다.

CICD 배포시 고려해야 포인트들이 있다.

• 소스 빌드, 컨테이너 빌드, 배포 ~ 의 책임소재에 따라 파이프라인을 어떻게 나눌지

• 깃헙액션과 같은 온라인 툴 또는 젠킨스같은 오프라인 툴 중 어떤 것으로 CICD 환경을 구축할지

• 배포툴을 하나만 두고 여러 배포환경에 대응하게해 관리적 이점을 살릴 것인지. 배포환경별 배포툴을 저마다 만들어 장애 격리등 운영 안정성을 높일 것인지

• 컨테이너 빌드에는 도커를 사용할지 다른 툴을 사용할지.

  • 도커는 여러 기능이 있고 친숙해 다루기 편하지만, 무겁고 도커 데몬이 SingleFailurePoint가 될 수 있다.

  • 실제로 같은 이미지를 도커와 containerd에 받으면, 도커는 추가 메타데이터들을 붙여 이미지를 재구성해 이미지 사이즈가 더 커짐. (도커에서 받은 이미지를 tar로 export > 다른 컨테이너 런타임에 import 해도 도커전용의 큰 사이즈 이미지를 그대로 받아와, 이런 이미지 복사에 주의해야함!)

• 쿠버네티스 배포에는 kubectl을 쓸지 아니면 Helm, Kustomize 처럼 패키지 관리 툴을 사용할지.

• 배포 전략 ~ 아래중 어떤 전략으로 서비스 배포를 진행할지.

  • 다운타임이 생기지만 리소스 변화가 없는 Recreate

  • 복수 버전의 서버가 공존하지만 서비스 다운타임이 없는 RollingUpdate

  • 자원 사용량이 최대 2배까지 늘어날 수 있지만, 서비스 다운타임이 없고 롤백이 용이한 BlueGreen

    • 민감 데이터를 가진 서비스에서 신규 배포를 전부 셋업해 놓고, 따로 서비스를 붙여 테스트 하는 환경을 만들수도.

       

  • 신규 배포환경을 세팅해, 트래픽을 적절히 늘려가며 배포할 수 있는 Canary

    • BlueGreen에서 일어날 수 있는 메모리디비, 디비 버퍼 등 콜드스타트에 따른 이슈들을 해소할 수 있고.

    • 헤더값을 통해 특정 트래픽만 v2로 보내, AB 테스트 / 배포전 QA 등을 처리할 수 있음.

쿠버네티스에서 BlueGreen 배포는 젠킨스 + kubectl, argoCD 등으로 가능한데.

• 기존 버전의 리소스들을 그대로 두고, 신규버전의 Deployment를 띄운 다음. 기존 리소스의 서비스 셀렉터를 바꿔줘 신규버전의 파드들에 트래픽을 보내는 식이다.

Helm vs Kustomize

• 둘다 복수 환경의 배포를 위한 다양한 Yaml 파일의 관리를 최적화 하는 목적에서 사용된다.

• Helm은 Kustomize 보다 배포 편의 기능이 많아 여러 케이스를 대응할 수 있지만 그만큼 복잡하다.

• Helm

  • Helm은 kubectl 과 같이 kube-apiserver에 직접 API 요청을 한다. (인증서 정보 필수)

  • 또한 ArtifactHub라는 패키지 저장소가 존재해, 오픈소스 패키지들을 가져다 쓸 수 있다.

  • 함수방식으로

    • 메인 차트(리소스 패키지)의 리소스 yaml 파일들을 templates 하위에 둔다.

      • 그리고 각 템플릿 (.yaml)에 변수 자리를 두고, 아래 파일 혹은 명령어로부터 값을 입력받을 수 있는데.

        • helm 명령어 (Release.X~)

        • Chart.yaml(Chart.X~) - 차트 기본 메타데이터 선언

        • Values.yaml(Values.x~) - 템플릿에 넣을 변수값 선언

        • _helpers.tpl({{ include~) - values로부터 값을 받아, 로직을 통해 가공한 값 선언

      • 이런 방식으로 환경에 맞는 변수를 입력받아 최종 리소스 yaml 파일을 만들어 배포하는 형식이다.

         

    • 헬름 템플릿은 go template 문법을 쓰기 때문에

      • yaml 파일의 주석도 go template에 맞춰 {/** */} 형식으로 써야하고.

      • {{-, nindent 등으로 우리가 보는 것과 같이 인덴트를 넣어 yaml 규격을 맞춰줘야 한다.

  • 위에 작성한 templates/xx, values.yaml, Chart.yaml 외에도 아래 파일 들이 있다.

    • .helmignore ~ 헬름 렌더링시 제외 파일 지정

    • NOTES.txt ~ 헬름 배포 후 출력되는 일종의 안내문구 파일

    • test ~ 앱의 통신상태 확인해주는 부가기능적 폴더

    • charts/xx ~ 메인 차트외에 서브 앱들을 활용할 때 쓰이는 폴더