컨테이너 이전 배포방식

컨테이너가 등장하기 전의 배포 방식은 비교적 단순한 구조였다.
애플리케이션을 빌드해서 나온 실행 파일을 서버에 복사하고 실행하는 방식이다.

개발 환경

• 개발자는 IntelliJ 같은 IDE를 사용해 코드를 작성한다.
• 개발이 완료되면 Gradle 같은 빌드 도구를 통해 빌드를 수행한다.
  빌드는 컴파일 후, 실행 가능한 형태로 패키징하는 과정이다.
• ex) Java로 개발한 경우, 빌드를 하면 .jar 파일이 생성된다.
• 이 .jar 파일은 사전에 설치된 JVM(Java Virtual Machine) 위에서 실행된다

많은 개발자들은 이러한 환경을 자신의 컴퓨터에 설치하고, 코딩하고 테스트하면서 개발을 진행한다.

• 각자 개발이 완료되면 소스를 GitHub에 커밋한다.
• GitHub에 코드가 통합된 이후,
  Jenkins 같은 CI 도구를 통해 빌드를 수행한다

CI/CD 환경

• Jenkins는 GitHub에서 소스를 내려받는다.
• Jenkins 서버에도 Gradle이 설치되어 있어 필요한 라이브러리를 내려받는다.
• 빌드를 통해 .jar 파일을 생성한다.
• 생성된 .jar 파일을 인프라 서버에 배포하면 배포가 완료된다.

(이 구조에서는 “서버에 JVM이 깔려 있고, 거기에 jar만 올리면 된다”
라는 전제가 항상 필요하다.)

컨테이너가 나온 후 배포방식

컨테이너 이전에는 .jar 파일을 서버에 복사하면 배포가 끝이었다.

하지만 컨테이너가 등장하면서 배포 방식에 중요한 변화가 생겼다.

가장 큰 변화는, 컨테이너 빌드 과정이 추가되었다는 점이다.

CI/CD 환경 (컨테이너 기반)

Jenkins에서 빌드 버튼을 눌렀을 때
다음과 같은 일이 순서대로 발생한다.

• 먼저 .jar 파일을 실행할 수 있는 OpenJDK 이미지를 DockerHub에서 가져온다.
• 이 OpenJDK 이미지는 애플리케이션을 실행하기 위한 베이스 이미지이다.
• 그 위에 빌드된 .jar 파일을 올린다.
• 이 과정을 통해 컨테이너 이미지가 생성된다.
  → MyApp 컨테이너 이미지
• 생성된 이미지를 다시 DockerHub 같은 이미지 레지스트리에 업로드한다.

즉, 이제 배포 대상은 jar 파일이 아니라 컨테이너 이미지가 된다.

배포 과정

컨테이너 이미지가 준비되면 배포가 진행된다.
Jenkins에서 쿠버네티스에 Pod 생성 명령을 전달한다.

인프라 환경 (Kubernetes)

이 명령을 받은 쿠버네티스는 다음과 같이 동작한다.

• Pod 정의 안에는 컨테이너 이미지 주소가 들어 있다.
• 쿠버네티스는 해당 주소를 보고 DockerHub에서 이미지를 다운로드한다.
• 그 다음, containerd에게 해당 이미지로 컨테이너를 생성하라고 요청한다.
• containerd는 이미지를 기반으로 실제 컨테이너를 실행한다.

이렇게 해서 애플리케이션이 실행된다.

핵심 차이

컨테이너 이전 :
-> jar 파일을 서버에 직접 배포
컨테이너 이후 :
-> jar 파일을 포함한 컨테이너 이미지를 빌드하고 배포.

컨테이너가 나온 덕분에

• 실행 환경이 이미지로 고정되고
• 서버마다 환경 차이로 인한 문제가 줄어들며
• 배포와 롤백이 훨씬 쉬워졌다.

위 포스팅은 인프런 강의 중 쿠버네티스 어나더 클래스-Sprint 1, 2를 참고하여 작성하였습니다.