저는 회사에서 두 개의 팀에 소속되어 서비스를 구축하고 개발하고 있습니다. 1팀(첫 번째 팀)은 Java".jar" 파일을 클라우드 가상 머신에 배포하는 방식으로 작업하고 있고, 2팀(두 번째 팀)은 쿠버네티스 환경에 Java 애플리케이션을 배포하는 방식을 사용하고 있습니다. 다양한 팀원들과 이야기를 나눈 결과, 2팀의 쿠버네티스 환경과 개발 플로우가 장기적으로 비용 효율적이고 개발 효율성을 높일 수 있다는 결론을 내리게 되어 1팀에도 쿠버네티스를 도입하기로 결정하였습니다. 제가 쿠버네티스 환경에서의 애플리케이션 개발 및 배포 경험이 있기 때문에 다른 팀원들이 쿠버네티스 환경에 쉽게 적응할 수 있도록 가이드를 제공하게 되었습니다. 다른 팀원들이 쿠버네티스에 애플리케이션을 배포하는데 참고할 수 있도록 쿠버네티스 환경 및 CI/CD 파이프라인을 구축하는 과정에서 겪은 경험에 대해 소개드리겠습니다.
1팀 개발 및 배포 과정(반자동)
첫 번째 팀에서 사용하는 개발 및 배포 플로우의 핵심은 젠킨스와 가상 머신을 사용하는 것입니다. 젠킨스를 이용하여 자동화된 테스트를 수행하고, 개발자는 사내 도구를 활용하여 직접 가상 머신에 java의 ".jar" 파일을 배포합니다.
- Pull Request의 요청 및 머지는 Github을 활용해 이뤄집니다.
- Pull Request 이벤트가 발생하면 Github의 event notification 기능을 활용해 Jenkins에 이벤트 정보를 전달합니다.
- Jenkins는 자동화 테스트를 수행합니다. 테스트 결과는 Github의 Pull Request 화면에서 확인할 수 있습니다.
- 개발자는 수동으로 VM에 java ".jar"을 배포합니다(사내 툴 활용).
2팀 개발 및 배포 과정(완전 자동화)
- Pull Request의 요청 및 머지는 Github을 활용해 이뤄집니다.
- Pull Request 이벤트가 발생하면 Github의 event notification 기능을 활용해 CircleCI에 이벤트 정보를 전달합니다.
- CircleCI는 소스코드에 정의된 테스트를 수행합니다. 테스트의 결과는 CircleCI의 UI 또는 Github의 Pull Request 화면에서 확인할 수 있습니다.
- CircleCI에 의해 빌드된 도커 이미지는 Harbor(도커 이미지 저장소)에 저장됩니다. 해당 이미지는 추후 쿠버네티스 환경에 배포될 때 사용됩니다.
- CircleCI는 도커 이미지를 새로 빌드하고, 이 정보를 Kustomize 설정 파일에 반영합니다. Kustomize 설정 파일은 Git repository로 관리됩니다. CircleCI는 Kustomize 파일의 변경 내역을 Git 커밋으로 이력에 추가합니다.
- 배치 및 스트림성 애플리케이션은 SCDF(Spring Cloud Data Flow)를 활용해 배포합니다. SCDF는 스프링 진영의 배치 및 스트림성 애플리케이션을 배포하는 데 사용하도록 특화된 플랫폼입니다. SCDF가 제공하는 API를 활용함으로써 새로 빌드된 도커 이미지와 관련된 애플리케이션을 배포할 수 있습니다.
- ArgoCD는 쿠버네티스에 배포된 애플리케이션을 관리(UI, 배포, 롤백, 설정 변경 등) 하기 위해 사용됩니다. 또한 Kustomize 파일을 저장하고 있는 Git repository에 새로운 커밋이 추가되는지를 지속적으로 관찰(polling)합니다.
- Kustomize 파일이 저장된 Git repository를 참조하여 애플리케이션을 배포합니다. 주된 역할은 CircleCI에 의해 새로 빌드된 도커 이미지를 사용해(새로 추가된 커밋을 참조) 쿠버네티스에 애플리케이션을 자동으로 배포하는 것입니다.
- ArgoCD는 Harbor으로부터 빌드된 이미지를 가져옵니다(pull).
- 쿠버네티스에서 실행되는 애플리케이션의 조작 및 모니터링을 위해 K9S라는 툴을 사용합니다.
- 쿠버네티스에서 실행되는 애플리케이션의 로그를 중앙 집중식으로 관리하기 위해 ElasticSearch를 활용합니다.
1팀 쿠버네티스 환경 도입
2팀의 구조를 그대로 가져왔다면 편했겠지만, 도입하는 과정에 장애물이 있었습니다. 사내에서 지원하는 CircleCI는 1팀이 사용중인 "git-dev.XXX.com" 도메인을 지원하지 않았습니다. 이에 따라 CircleCI를 사용할 수 없게 되었고, CI 툴을 고민하던 중 기존에 사용하고 있던 Jenkins를 사용해 보자는 아이디어가 떠올랐습니다. 기존에 Jenkins는 각 프로젝트마다 설정이 완료된 상태여서 큰 작업이 필요하지 않을 것으로 예상되었습니다. 따라서 2팀의 구조를 약간 변경하여 1팀에 도입하기로 결정하였습니다.
2팀과의 차이점은 CircleCI 대신 Jenkins를 사용한다는 것이 유일합니다. 그러나 CircleCI와 Jenkins의 스크립트 설정 방식에 차이가 있어 스크립트 작성을 위해 추가 작업이 필요했습니다.
셋업
1팀은 쿠버네티스와 관련된 인프라가 전혀 갖춰지지 않았기에 이번 도입 과정은 저에게 있어 전반적인 인프라 지식을 함양할 수 있는 기회였습니다. 도입하는 과정에서는 다음과 같은 경험을 할 수 있었습니다.
- 쿠버네티스 클러스터 셋업 (클러스터 할당 및 ArgoCD 연동)
- GitOps를 위한 셋업 (ArgoCD와 Github 연동, Kustomize 파일의 버전 관리를 위한 레포지토리 셋업)
- 도커 이미지 빌드 및 배포를 위한 Harbor 환경 셋업
- Jenkins를 활용한 쿠버네티스 배포 파이프라인 작성
- Spring Cloud Data Flow 플랫폼 셋업
직접 쿠버네티스 환경을 구축하는 과정에서 기존에 알고 있던 지식을 확장할 수 있었습니다. 무엇보다 좋았던 점은 제 스스로가 쿠버네티스에 대한 이해의 필요성과 관심이 생겼다는 점입니다. 팀에 가장 효율적인 방법으로 쿠버네티스 환경을 제공하고자 다양한 서적과 포스팅을 읽으며 저의 이해도도 향상할 수 있었습니다.
교육
사실, 혼자서만 쿠버네티스를 도입하겠다고 했다면 다른 팀원분들께서는 "굳이?"라고 생각했을 수 있습니다. 이미 서비스는 잘 운영되고 있었고 쿠버네티스라는 기술 장벽이 높은 플랫폼을 도입하겠다고 다른 누가 얘기한다면 심리적 장벽이 생기는 것이 당연합니다. 저는 팀원분들의 심리적 장벽을 조금이나마 낮추기 위해 쿠버네티스와 관련된 세션을 준비하였습니다. 팀에 쿠버네티스가 왜 필요하고 어떤 서비스에 적용할 수 있는지와, 비용을 어떻게 아낄 수 있는지 등을 설명드리니 쿠버네티스의 필요성에 대한 공감대가 조금씩 갖춰졌습니다. 물론 1팀에 쿠버네티스가 완전히 정착하기 위해서는 시간이 더 걸리겠지만, 시작이 반이라고 했듯이, 쿠버네티스 도입까지 절반은 진행했다고 생각합니다.
마무리
사실 이번 프로젝트는 제가 11월에 이직하는 회사로 가기 전 마지막 프로젝트입니다. 마지막 프로젝트인 만큼 다른 팀원분들께 도움 되는 작업을 최대한 수행하고 싶은 욕심이 있었습니다. 제 기준으로 충분히 만족스러운 결과를 냈지만 실제로 새로운 쿠버네티스 환경을 사용하실 다른 팀원분들이 어떻게 느낄지는 잘 모르겠습니다. 하지만 제 작업으로 인해 다른 팀원분들이 쿠버네티스를 도입하는 데 걸리는 시간을 조금이라도 낮출 수 있다면, 제 역할은 완수했다고 생각하겠습니다 😄
'Infrastructure > Kubernetes' 카테고리의 다른 글
| [Kubernetes] Rolling Update 이슈와 해결 과정 (0) | 2023.09.21 |
|---|