[위클리페이퍼] 261006_Docker

Q. 컨테이너 기술과 Docker를 명확히 구분하여 설명하세요. 컨테이너 기술이 Docker 이전에도 존재했던 개념임을 언급하고, Docker가 컨테이너 기술을 구현한 하나의 도구라는 관점에서 설명해주세요. 또한, Docker 외에 컨테이너 기술을 구현한 다른 도구의 예시를 들어보세요.

 

A.

• 컨테이너는 도커를 통해 생겨난 것이 아닌 1970년도 chroot라는 기술로부터 시작되었고 2000년대는 LXC(Linux Containers) 같은 도구가 존재했으며 Docker는 이 러한 오래된 개념을 더 쉽게 쓸 수 있도록 만든 도구이다.
• 컨테이너 기술이란
  • 한개의 프로그램을 실행하기위한 작은 공간으로 내 컴퓨터 안에서는 여러개의 프로그램들이 있지만 컨테이너안에서는 현재 내컴퓨터와는 별개의 작은 컴퓨터처럼 독립적으로 실행할 수 있다.
• 컨테이너의 장점
  • 가벼움 → 운영체제 자체를 가상화하는 VM 보다는 훨씬 적은 자원을 사용함
  • 빠름 → 실행이 즉시 가능
  • 이식성이 높음 → 동일한 실행 환경을 제공하여 어디서나 실행 가능 
  • 확장성 뛰어남 → 서비스에 따라 다수의 컨테이너를 올릴 수 있음
• Docker 외에도 존재하는 컨테이너 도구들
  • PodMan → Docker와 비슷하지만 데몬이 필요없음 Rootless 실행 가능 → 보안 강점
  • LXC/LXD → Docker 이전부터 존재하는 리눅스 기반의 도구
  • containerd → 원래 Docker 내부 엔진이였지만 현재는 독립프로젝트로 Kubernetes에서 많이 사용된다.
• Docker를 왜 많이 사용하는가?
  • 위에를 보면 컨테이너를 사용할 수있는 많은 툴들이 있지만 Docker가 가장 사용하기 쉽고 자료도 풍부하고 기업에서도 많이 사용되기 때문에 Container를 사용할 수 있는 도구의 대명사가 되었다. 

• 컨테이너의 본질은 “애플리케이션 실행 환경을 격리하는 기술”이고,
• Docker는 그 기술을 쉽게 활용할 수 있돌고 만든 도구 이다.

 

 

Q. 컨테이너 오케스트레이션의 개념과 필요성을 설명하고, Docker 단독 사용 환경과 비교하여 컨테이너 오케스트레이션이 해결하는 주요 문제점 3가지(자동 확장, 자가 복구, 선언적 인프라)를 설명하세요.

 

A. 

• 컨테이너 오케스트레이션이란
  • 대규모 애플리케이션을 배포할 수 있도록 컨테이너의 네트워킹 및 관리를 자동화하는 프로세스이다. 대표적인 도구는 Kubernetes
• 왜 컨테이너 오케스트레이션이 필요한가
  • Docker만 사용하게된다면 컨테이너를 사람이 직접 띄우고, 확인하고 다시 띄우고를 반복해야한다. 서버가 1개 컨테이너 1개일때는 뭐 나쁘지않다! 하지만 서버가 N개로 늘어나고 각 서버마다 20개씩의컨테이가 있다면? 생각만해도 끔찍..! 오케스트레이션은 이러한 복잡성을 자동화하고 해결하여 수동 관리와 관련된 문제를 제거합니다. 
• 오케스트레이션을 해결하는 주요 문제점 3가지(자동확장, 자가 복구, 선언적 인프라) 

문제	Docker 만 사용	오케스트레이션
자동 확장	트래픽이 늘면 사람이 직접 추가적으로 계속 컨테이너를 생성 docker Run	CPU 사용량등 어떤 기준에 따라 컨테이너 수를 자동으로 늘려주고 줄여주고 한다.
자가 복구	컨테이너 죽으면 사람이 발견해서 다시 띄워주고 반복	죽은 컨테이너 바로 감지 자동으로 다시 띄워주고 서버 한대가 고장나면 다른 서버로 옮겨준다.
선언적 인프라	절차적으로 하나씩 지시해야함	원하는 상태를 YAML으로 미리 선언해놓으면 시스템이 그 상태를 계속 유지한다.

• 도구별 방식을 비교

도구	방식	예시
Docker CLI	명령형 (하나씩지시 )	docker run -d -p 8080:8080 project
Docker Compose	선언형(원하는 상태를 파일로 작성)	docker-compose.yml에 서비스, 포트, 볼륨을 작성하고 up 실행 시 한 번 적용 (이후 변경은 다시 실행해야 반영)
Kubernetes	선언형 + 지속 유지	YAML으로 선언하여 그 상태를 계속 유지한다.

• Docker Compose도 선언적이지만, 상태를 한 번 적용하느냐 계속 유지하느냐의 차이가 있다.
• 오케스트레이션의 문제점은?
  • 추가 관리 계층:오케스트레이터 자체를 설치·운영해야 한다.
  • 러닝 커브:  Pod, Deployment, Service 등 새로운 개념과 설정을 익혀야 한다.
  • 설정 파일 관리 부담: 서비스마다 여러 YAML 파일을 작성하고 관리해야 하며, 클러스터 버전 업그레이드와 호환성도 관리필요
  • 자원 비용: 관리 노드(컨트롤 플레인)가 CPU와 메모리를 사용해 서버 비용이 늘어난다.
  • 디버깅 복잡도: 컨테이너가 여러 서버에 흩어져 있어 장애 원인을 찾기 어렵다.
  • 작은 서비스에는 과함: 서버 한두 대 규모라면 Docker Compose로 충분하다.