영역 파괴의 주범 ConfigMap
<쿠버네티스 환경에서의 CI-CD>
1. 컨테이너는 도커 허브에서 모두 같은 이미지를 다운 받는다. 하지만 환경마다 다른 값을 주려고 이렇게 Configmap을 만듭니다.
2. 이렇게 스프링으로 개발을 하고 GitHub 소스를 Commit 하면 Jenkins에서 이 소스를 받아서 파이프라인이 돌아가는 구성
3. 소스 빌드와 컨테이너 빌드 과정에서 컨테이너 이미지가 도커업으로 올라가고 컨테이너 빌드 후 개발 환경(dev)에 배포한다.
4. QA나 운영은 필요할 때 배포 버튼을 따로 누르게 구성을 해놨다고 가정
<기존 인프라의 CI-CD>
1. 인프라 담당자가 환경별로 각 vm에 OpenJDK를 설치해 놓는다. 이때 VM의 환경변수 값을 바로 사용할 수 있는 인프라 담당자는 여러 서버에 똑같은 패턴으로 설치는 하되 필요할 때 마다 다른 값을 주기 위해 이런 내용들을 환경 변수로 관리할 수 있다. 여기서 환경변수(vm)는 ENV java_home, ENV volume_path, ENV log_path 이다.
2. 코드를 깃허브에 올리면 Jenkins에서 소스를 받아서 pipeline 돌리면 빌드되서 jar 패키지 파일을 VM 환경에 복사 해 놓고 실행 명령을 직접 날린다. 참고로 Jenkis와 개발자도 환경변수를 따로 관리를 해준다.
와 어렵다.....!!!
그러면 기존 인프라 환경에서는 이런 환경변수들을 각자 관리(Jenkins, Spinrg,VM) 했는데 쿠버네티스에서는 한꺼번에 관리가 가능하다.
위 자료는 쿠버네티스 어나더 클래스(지상편) - Sprint1의 강의를 듣고 정리한 자료입니다.
https://www.inflearn.com/course/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%96%B4%EB%82%98%EB%8D%94-%ED%81%B4%EB%9E%98%EC%8A%A4-%EC%A7%80%EC%83%81%ED%8E%B8-sprint1/dashboard