Kubernetes 여정 파트 1: 왜 Docker인가?
Source: Dev.to
Kubernetes 학습 시리즈의 첫 번째 포스트에 오신 것을 환영합니다! 복잡한 내용에 들어가기 전에, 모든 것을 가능하게 만든 기본 블록인 Docker에 대해 이야기해야 합니다.
소프트웨어 개발을 해본 적이 있다면 “하지만 내 머신에서는 동작해요!” 라는 말을 들어봤을 것입니다.
왜 Docker인가?
새로운 기능을 막 마무리하고 코드가 버전 관리 시스템(VCS)에 병합되었다고 가정해 보세요. 빌드 파이프라인이 아티팩트를 생성하고 이를 서버에 배포합니다.
- Dev Server: 완벽히 동작합니다. ✅
- Test Server: 기대대로 동작합니다. ✅
- Production: 배포했는데 빌드가 실패합니다. ❌
무슨 일이 일어났나요?
가장 흔한 원인은 환경 설정 오류 혹은 개발·테스트 환경에는 있었지만 프로덕션에는 없는 의존성 누락입니다. 전통적으로는 전체 환경이 아니라 아티팩트만을 배포할 수 있었습니다. 여기서 컨테이너가 등장합니다.
Docker가 해결한 방법
Docker는 코드 실행에 필요한 모든 것—라이브러리, 의존성, 설정, 심지어 기본 OS 바이너리까지—를 하나의 단위로 패키징합니다. 이 덕분에 환경 관련 오류가 거의 발생하지 않게 됩니다.
컨테이너란?
컨테이너는 애플리케이션 코드, 라이브러리, 런타임 의존성을 포함한 격리된 경량 샌드박스 환경이며, 호스트 운영 체제와 무관합니다.
- 핵심 차이점: 가상 머신(VM)과 달리 컨테이너는 전체 운영 체제를 패키징하지 않습니다. 최소한의 바이너리만 포함하고 호스트 OS 커널을 사용하므로 빠르고, 이식성이 뛰어나며, 자원 효율적입니다.
정의: Docker는 이러한 컨테이너를 어디서든 빌드하고, 배포하고, 실행할 수 있게 해 주는 플랫폼입니다.
작동 방식: Dockerfile → 런타임
애플리케이션을 컨테이너화하려면 Dockerfile, 이미지, 컨테이너라는 세 가지 주요 요소를 다룹니다.
Dockerfile
Dockerfile은 명령어 목록이 적힌 평문 파일입니다. docker build를 실행하면 이 명령어들을 읽어 이미지가 생성됩니다.
이미지
Docker 이미지란 애플리케이션의 스냅샷으로, 실행에 필요한 모든 것이 포함됩니다. 이미지는 레지스트리(버전 관리 시스템과 유사) 에 저장되어 모든 환경이 docker pull로 동일한 이미지를 가져올 수 있습니다.
컨테이너
docker run을 실행하면 이미지가 실제 실행 인스턴스로 변환되어 컨테이너가 생성됩니다.
Docker 아키텍처
Docker 아키텍처는 세 가지 주요 구성 요소로 이루어집니다.
- 클라이언트 – 코드를 작성하는 곳(예: 노트북).
- Docker 데몬(
dockerd) – API 요청을 듣고, 이미지 관리 및 컨테이너 실행을 담당하는 “두뇌”. - 레지스트리 – 이미지의 원격 저장소.
Docker 명령의 라이프사이클
# Dockerfile로부터 이미지 빌드 (클라이언트 → 데몬)
docker build -t myapp:latest .
# 로컬 이미지를 원격 레지스트리에 푸시
docker push myrepo/myapp:latest
# 대상 환경에서 이미지 풀
docker pull myrepo/myapp:latest
# 풀한 이미지로 컨테이너 실행
docker run -d -p 80:80 myrepo/myapp:latest요약
Docker를 사용하면 개발 환경과 프로덕션 환경이 동일해집니다. 내 머신에서 동작한다면 서버에서도 동작합니다. 왜냐하면 코드와 함께 “내 머신”(컨테이너)을 배포하기 때문입니다.
이제 컨테이너가 왜 필요한지 이해했으니, 다음 단계는 여러 컨테이너를 한 번에 관리하는 방법을 배우는 것입니다. 바로 여기서 Kubernetes가 등장합니다.
파트 2를 기대해 주세요!