개발을 하다 보면 "내 PC에서는 잘 되는데 서버에서는 왜 안 될까?"라는 고민을 한 번쯤은 하게 된다.
이 문제를 해결하기 위해 등장한 것이 Docker이고,
이를 자동으로 빌드하고 배포하는 것이 Jenkins,
그리고 실행된 서비스를 안정적으로 운영하는 것이 Kubernetes이다.
이 글에서는 Jenkins, Docker, Kubernetes를 하나의 흐름으로 연결해서 이해해보자
조금 더 쉽게 이해할 수 있도록 '도시락'이라는 비유를 활용해 전체 구조를 직관적으로 정리해보자
※ 핵심 개념
Image (이미지) = 포장된 도시락 (재료를 준비하고 요리까지 완료해, 꺼내서 바로 먹을 수 있는 상태)
- 실행에 필요한 코드 + 라이브러리 + 설정이 포함된 불변(immutable) 템플릿
- 읽기 전용이며, 컨테이너 생성을 위한 기준(설계도) 역할을 함
Container (컨테이너) = 포장된 도시락(Image)으로부터 도시락 하나를 꺼내서 식탁에 올려놓은 것 (올려져만 있을 수도 있고, 먹는 중일 수도 있음)
- 이미지를 기반으로 생성된 실행 가능한 인스턴스
- 격리된 환경에서 동작하는 프로세스 단위의 실행 환경
- 상태를 가지며(실행/종료), writable layer를 통해 변경 가능
containerd (컨테이너 런타임) = 꺼낸 도시락(Container)을 먹기 시작하게 하고, 먹는 동안 계속 관리해주는 도구
- 컨테이너의 생성, 실행, 중지 등을 담당하는 컨테이너 런타임
- 이미지 pull, 컨테이너 lifecycle 관리 등을 담당하는 내부(저수준) 실행 계층
Dockerfile (도커파일) = 포장된 도시락(Image)을 만드는 레시피
- 이미지를 생성하기 위한 명령어 집합(빌드 스크립트)
- 애플리케이션 실행 환경을 코드로 정의하여, 동일한 환경을 재현할 수 있게 해주는 Infrastructure as Code(IaC) 방식
Jenkins Pipeline (젠킨스 파이프라인) = 포장된 도시락(Image)을 언제, 어떻게 만들고 전달할지 정해진 자동화 흐름
- 빌드, 테스트, 배포 과정을 자동화하는 CI/CD 파이프라인 정의
- 코드 변경부터 배포까지의 과정을 일관되게 실행하는 자동화 프로세스
Kubernetes Pod (쿠버네티스 파드) = 꺼낸 도시락(Container)을 먹는 자리 (식탁)
- 하나 이상의 컨테이너를 포함하는 쿠버네티스의 최소 배포 단위
- 동일한 네트워크(IP, Port)와 스토리지를 공유하는 컨테이너 그룹
Deployment (디플로이먼트) = 꺼낸 도시락(Container)을 몇 개 유지할지 관리하는 정책
- Pod의 개수(Replica), 업데이트 전략 등을 정의하는 상태 관리 리소스
- 무중단 배포(Rolling Update) 및 자동 복구를 지원하는 배포 관리 객체
Service (서비스) = 사람들이 꺼낸 도시락(Container)에 쉽게 접근할 수 있게 해주는 창구
- Pod에 대한 고정된 접근 경로(IP/DNS)를 제공하는 네트워크 추상화 객체
- 로드밸런싱을 통해 여러 Pod에 트래픽을 분산하는 접근 인터페이스
Registry (레지스트리) = 포장된 도시락(Image)을 보관해두는 창고
- 도커 이미지를 저장하고 배포하는 이미지 저장소
- 버전 관리 및 공유를 위한 중앙 저장소 역할 수행※ Jenkins
코드 변경을 감지하여 빌드, 테스트, 배포 과정을 자동으로 수행하고,
전체 소프트웨어 개발 파이프라인을 관리하는 CI/CD 자동화 도구
주문이 들어오면 요리사(Docker 등 이미지 빌드 도구)를 통해 포장된 도시락(Image)이 자동으로 만들어지고, 정해진 곳으로 전달되도록 하는 자동화 시스템
※ 일반적으로 Git push와 같은 트리거가 '주문'에 해당
※ Docker
애플리케이션과 실행에 필요한 환경 및 설정을 Image로 패키징하고,
이 Image를 기반으로 어디서든 동일한 환경에서 Container를 생성 및 실행할 수 있게 해주는 플랫폼
포장된 도시락(Image)을 만드는 요리사이자, 도시락을 꺼내서(Container를 생성하고) 먹을 수 있게(실행할 수 있게) 해주는 시스템
※ Container는 docker run과 같은 명령을 통해 실행
※ Kubernetes
Container로 구성된 애플리케이션을 여러 서버에 자동으로 배포하고, 트래픽에 따라 확장하며,
장애 발생 시 복구하고 원하는 상태를 지속적으로 유지하는 Container 오케스트레이션 도구
꺼낸 도시락(Container)을 여러 곳에 배치하고, 필요한 만큼 유지하며, 문제가 발생하면 새로 꺼내서 다시 준비해주는 운영 관리자
※ kubectl apply와 같은 명령으로 배포 요청이 들어오면 동작하며, 이후에는 설정된 상태를 지속적으로 유지※ Jenkins 구조 (자동화 영역)
Jenkins는 "포장된 도시락(Image)이 만들어지고 전달되도록 자동화하는 흐름" 담당
Jenkins
└─ Jenkins Pipeline (자동화 흐름)
↓
Dockerfile(포장된 도시락 레시피) 기반으로 Image(포장된 도시락)가 빌드되도록 실행
↓
Docker(요리사)를 통해 Image(포장된 도시락) 생성
↓
Kubernetes Deployment로 배포 요청
※ Docker 구조 (Image 생성 및 Image 기반 Container 생성/실행 영역)
Docker는 "포장된 도시락(Image)을 만들고, 도시락을 꺼내서 먹을 수 있게(Container를 생성 및 실행할 수 있게) 하는 역할" 담당
Docker
├─ Dockerfile (포장된 도시락 레시피)
├─ Image (포장된 도시락)
├─ Container (꺼낸 도시락)
└─ containerd (꺼낸 도시락을 실제로 먹게 하는 실행 엔진)
※ Kubernetes 구조 (운영/관리 영역)
Kubernetes는 "꺼낸 도시락(Container)을 배치하고 유지하며 관리하는 역할" 담당
Kubernetes
├─ Deployment (수량 관리)
├─ Pod (실행 공간)
│ └─ Container(꺼낸 도시락) 실행
│ └─ containerd(꺼낸 도시락을 실제로 먹게 하는 실행 엔진) 사용
└─ Service (접근 창구)※ 도시락 비유로 흐름 이해
Jenkins Pipeline → 자동 생산 및 배포 (주문이 들어오면 포장된 도시락(Image)이 만들어지고 전달되도록 자동화 시작)
↓
Dockerfile → Image 생성 (도시락 레시피를 기반으로 포장된 도시락(Image)이 만들어짐)
↓
Image → 실행 대상 (완성된 포장된 도시락(Image))
↓
Deployment → 수량 관리 (꺼낸 도시락(Container) 개수 유지 및 조절)
↓
Pod → 실행 공간 (꺼낸 도시락(Container)을 먹는 자리)
↓
containerd → Container 실행 (꺼낸 도시락(Container)을 실제로 먹기 시작하게 하고, 먹는 동안 계속 관리)
↓
Service → 접근 창구 (꺼낸 도시락(Container)을 주문하고 접근할 수 있는 통로)※ PC방 사장의 입장에서 흐름 이해 (고전 게임 사례)
※ PC방 사장의 입장에서 흐름 이해 (고전 게임 사례)
고전 게임 A가 다시 유행했다고 가정해보자.
이 게임은 과거 환경에서만 실행 가능하기 때문에,
현재 PC 환경에서는 그대로 실행되지 않는다.
PC방 사장 입장에서는 모든 PC에서 이 게임이 문제없이 실행되도록 만들어야 한다.
이 상황에서 Jenkins, Docker, Kubernetes를 다음과 같이 이해할 수 있다.
--------------------------------------------------
Jenkins (자동 준비 & 배포)
고전 게임 A에 업데이트가 발생하거나 설정이 변경되면,
자동으로 게임 파일이 준비되고 모든 PC에 배포되도록 하는 역할
→ 게임이 바뀌면 모든 PC에 자동으로 설치되도록 하는 시스템
--------------------------------------------------
Docker (실행 환경 구성)
게임이 실행되던 환경을 동일하게 만들 수 있도록,
실행에 필요한 라이브러리, 런타임, 설정 등을 하나로 묶어
어떤 PC에서도 동일한 환경에서 실행되도록 하는 역할
※ 여기서 말하는 환경은 PC 전체 OS를 가져오는 것이 아니라,
게임 실행에 필요한 환경(OS 관련 라이브러리 등)을 포함하는 개념
--------------------------------------------------
Kubernetes (운영 & 관리)
게임이 여러 PC에서 안정적으로 실행되도록 관리하고,
사용자가 많아지면 게임을 실행하는 인스턴스를 자동으로 늘려
더 많은 사용자가 동시에 이용할 수 있도록 하며,
문제가 발생하면 자동으로 다시 실행되거나 다른 PC에서 실행되도록 하는 역할
→ 전체 PC를 관리하면서 게임이 항상 잘 돌아가도록 유지하는 시스템※ 조합별로 보는 구성
1. Jenkins만 사용했을 때
<편리한 부분>
- 코드 변경 시 자동 빌드 및 배포 과정 자동화 가능
- 반복 작업(빌드, 테스트, 배포) 자동화
- 배포 실수 감소
<사용자가 직접 해야 하는 부분>
- 서버 환경 세팅 (Java, Node 등)
- 실행 환경 맞추기
- 애플리케이션 실행/재시작
- 여러 서버 배포 시 직접 관리
<한 줄 요약>
자동으로 만들고 배포 과정은 자동화되지만, 실행 환경과 운영은 직접 해야 함
--------------------------------------------------
2. Docker만 사용했을 때
<편리한 부분>
- 실행 환경을 포함하여 어디서든 동일하게 실행 가능
- 컨테이너 실행이 간단 (docker run)
- 이미지 기반으로 버전 관리 용이
- 개발 및 테스트 환경 빠르게 구성 가능
<사용자가 직접 해야 하는 부분>
- 빌드 및 배포 자동화
- 컨테이너 실행 및 수동 관리
- 여러 서버 배포 및 운영
- 장애 대응 및 확장 처리
<한 줄 요약>
실행 환경은 편하게 만들 수 있지만, 자동화와 운영은 직접 해야 함
--------------------------------------------------
3. Kubernetes만 사용했을 때
<편리한 부분>
- 컨테이너 자동 배포 및 실행 관리
- 트래픽에 따른 자동 확장
- 장애 발생 시 자동 복구
- 여러 서버 환경에서 안정적인 운영 가능
<사용자가 직접 해야 하는 부분>
- 이미지 생성 (Docker, Kaniko 등)
- 배포 자동화 구성
- 초기 환경 설정 및 구성
- 애플리케이션 빌드 관리
<한 줄 요약>
운영과 실행 관리는 자동이지만, 이미지 생성과 배포 자동화는 직접 해야 함
※ Kubernetes는 Docker 없이도 containerd와 같은 런타임을 통해 컨테이너를 실행할 수 있다.
--------------------------------------------------
4. Jenkins + Docker 사용했을 때
<편리한 부분>
- 코드 변경 시 자동 빌드 및 이미지 생성
- 실행 환경 포함 배포 가능
- 반복 작업 자동화
- 배포 과정 안정성 향상
<사용자가 직접 해야 하는 부분>
- 컨테이너 실행 및 운영 관리
- 서버 확장 및 트래픽 대응
- 장애 복구 처리
- 서비스 운영 관리
<한 줄 요약>
자동으로 만들고 실행까지는 편하지만, 운영은 직접 해야 함
--------------------------------------------------
5. Jenkins + Kubernetes 사용했을 때
<편리한 부분>
- 코드 변경 시 자동 배포 가능 (이미지 준비 필요)
- 자동 확장 및 장애 복구
- 서버 운영 부담 감소
- 배포와 운영 자동화 가능
<사용자가 직접 해야 하는 부분>
- 이미지 생성 (Docker, Kaniko 등)
- 실행 환경 구성
- Kubernetes 설정 및 구조 관리
- 초기 환경 세팅
<한 줄 요약>
배포와 운영은 자동이지만, 실행 환경 준비는 직접 해야 함
--------------------------------------------------
6. Docker + Kubernetes 사용했을 때
<편리한 부분>
- 실행 환경 포함 배포 가능
- 컨테이너 기반 자동 운영 관리
- 자동 확장 및 장애 복구
- 안정적인 서비스 운영 가능
<사용자가 직접 해야 하는 부분>
- 빌드 및 배포 자동화
- 배포 과정 수동 관리
- CI/CD 파이프라인 구성
- 코드 변경 시 직접 반영
<한 줄 요약>
운영은 자동이지만, 배포 자동화는 직접 해야 함
--------------------------------------------------
7. Jenkins + Docker + Kubernetes 사용했을 때
<편리한 부분>
- 코드 변경 시 자동 빌드 및 배포
- 실행 환경 포함 배포 가능
- 자동 확장 및 장애 복구
- 개발부터 운영까지 전체 자동화 가능
<사용자가 직접 해야 하는 부분>
- 초기 환경 설정 (Pipeline, Dockerfile, Kubernetes)
- 모니터링 및 성능 튜닝
- 운영 정책 관리
<한 줄 요약>
개발부터 운영까지 거의 자동화된 DevOps 환경※ 헷갈리기 쉬운 개념 정리
Docker는 containerd를 내부에서 사용하는 올인원 도구이며,
이미지 생성부터 이미지 기반 컨테이너 생성 및 실행까지 지원한다.
Kubernetes는 containerd와 같은 컨테이너 런타임과 함께 동작하며,
이를 통해 컨테이너를 실행한다.
이미지(포장된 도시락)는 반드시 필요하며,
Docker, Kaniko, Buildah 같은 이미지 빌드 도구를 통해 생성할 수 있다.'DevOps' 카테고리의 다른 글
| [DevOps] 파이프라인(Pipeline) 이해하기 (GitHub/GitLab → Jenkins → Docker → Kubernetes) (0) | 2025.10.31 |
|---|---|
| [DevOps] Docker(도커) vs Kubernetes(쿠버네티스) (0) | 2025.10.31 |
