도커

컨테이너 기반 가상화 플랫폼, 응용 프로그램과 그 종속성을 격리된 환경인 컨테이너로 패키징하여 실행하는 기술
컨테이너 환경에서 독립적으로 애플리케이션을 실행할 수 있도록 컨테이너를 만들고 관리하는 것을 도와주는 도구
환경에 구애받지 않고 애플리케이션 실행 가능

하나의 서버에 여러개의 프로그램을 설치하거나, 서로 사용하는 라이브러리의 버전이 다르거나 동일한 포트를 사용하는 경우 다양한 문제가 발생할 수 있다
→ 이러한 문제들을 해결하기 위해 App 구성, runtime 환경에서 필요한 요소들을 모아서 Packaging 하는 것을 도와줌

가상화

물리적 자원인 하드웨어를 효율적으로 활용하기 위해서 하드웨어 공간 위에 가상의 머신을 만드는 물리적 기술

Hypervisor 가상화

물리적인 서버에서 하나 혹은 그 이상의 독립적인 운영체제가 돌아가는 구조

물리적 서버의 OS 위에 여러 다른 독립적인 OS가 가상적으로 돌아감

• 하나의 물리적 서버에서 실행되고 있지만 가상적으로 완전한 독립적 OS로 운영

장점

• 물리적 서버의 리소스 효율적 사용
• CPU를 idle 상태로 두지 않고 필요한 OS나 서비스에 할당하여 효율적으로 사용

단점

• 기술적으로 너무 무거움
• 독립적인 OS를 실행시키는 것이기 때문에 부팅시간이 길고 리소스를 많이 차지함

Container 가상화

OS 커널 위의 유저공간(user space)에서 실행
완전히 독립적인 운영체제를 가상화 하는것이 아니라 독립적 user space 가상화

• 하나의 호스트 서버에서 여러 독립적인 user space 인스턴스들을 가상으로 실행

장점

• hypervisor 가상화보다 가볍기 때문에 빠르고 쉽게 독립적 가상 환경 실행
• docker image 만 있으면 어디서든 쉽고 빠르게 테스트 환경, 프로덕션 배포 가능

가상머신 VS 도커 컨테이너

가상머신(Virtual Machine)

기존의 가상화 기술인 가상 머신은 Hypervisor를 이용해 여러개의 운영체제를 하나의 호스트에서 생성해서 사용

여러개의 운영체제는 가상 머신이라는 단위로 구별, 각 가상 머신에는 운영체제가 설치되어 사용
Hypervisor에 의해 생성되고 관리되는 운영체제는 게스트 운영체제라고함 → 각 운영체제는 다른 게스트 운영체제와는 완전히 독립된 공간과 시스템 자원을 할당받아 사용 (VirtualBox, VMWare)

각종 시스템 자원을 가상화하고 독립된 공간을 생성하는 작업은 하이퍼바이저를 반드시 거치기 때문에 일반 호스트에 비해 성능 손실 발생, 게스트 운영체제를 사용하기 위한 라이브러리, 커널 등을 전부 포함하기 때문에 가상머신 이미지를 만들었을 때 이미지의 크기가 커짐

- Hypervisor를 통해 여러개의 운영체제를 생성하고 관리
- 시스템 자원을 가상화하고 독립된 공간을 생성하는 작업은 HyperVisor를 거쳐서 성능 손실이 큼
- 라이브러리, 커널 등을 포함해서 배포할 때 용량이 큼

도커 컨테이너

가상화된 공간을 생성하기 위해 리눅스 자체 기능인 chroot, 네임스페이스, cgroup을 사용하여 프로세스 단위의 격리 환경을 만들기 때문에 성능 손실이 거의 없음

커널을 공유해서 사용하고, 컨테이너 안에는 애플리케이션을 구동하는 데 필요한 라이브러리 및 실행 파일만 존재하기 때문에 컨테이너를 이미지로 만들었을 때 이미지의 용량이 적음

- 가상화된 공간을 생성할 때 리눅스의 기능을 사용해서 프로세스 단위의 격리환경을 만들어 성능 손실 없음
- 커널을 공유해서 사용하고, 라이브러리 및 실행파일만 있어서 용량이 작음
- 배포하는 시간이 가상 머신에 비해 빠르고, 사용할 때의 성능 손실이 거의 없음

도커의 3대 구성 요소

Dockerfile 만들기 → 빌드해서 이미지 만들기 → 컨테이너 구동

빌드된 이미지들은 Docker Hub에 저장되고 받아와서 컨테이너 생성

도커 파일

• 컨테이너를 어떻게 만들어야 하는지
• 필요한 파일, dependencies, 환경변수, 스크립트 포함
  

이미지

컨테이너 실행에 필요한 파일과 설정값 등을 포함하고 있는 것 → 상태값을 가지지 않고 변하지 않음
컨테이너를 실행하기 위한 모든 정보를 가지고 있기 때문에 의존성 파일을 관리할 필요가 없음

• Dockerfile을 빌드해서 이미지 생성
• 실행되고 있는 application의 상태를 스냅샷
• 컨테이너를 생성하고 실행할 때 읽기 전용으로 사용, 여러 계층으로 된 바이너리 파일로 존재

도커 이미지와 컨테이너는 1:N 관계

컨테이너

격리된 공간에서 프로세스가 동작하는 기술
이미지를 실행한 상태, 추가되거나 변하는 값은 컨테이너에 저장

다양한 프로그램, 실행환경을 컨테이너로 추상화하고 동일한 인터페이스를 제공하여 프로그램의 배포 및 관리를 단순하게 해준다

• 이미지를 고립된 환경에서 프로세스를 실행
• 이미지를 이용해서 구동
• 컨테이너에서 개별적 수정 가능 → 이미지에는 영향X, 컨테이너 내에서 변화

도커 사용 이유

• 환경 일치성 : 다양한 환경에서 동일한 실행 환경 보장
• 편리한 배포 : 도커 컨테이너는 이미지로 패키징되어 배포 → 어플리케이션 배포가 간단해짐
• 격리된 환경 : 각 컨테이너를 격리된 환경으로 실행, 하나의 컨테이너에서 발생한 문제가 다른 컨테이너에 영향 X
• 자원 효율성 : 가상 머신과 비교해 가볍고 빠름, 호스트 시스템의 리소스 효율적 활용
• 스케일링 : 컨테이너 기반 아키텍처는 쉬운 스케일링이 가능, 요구에 따라 응용 프로그램 확장

도커 스웜

도커에서 만든 컨테이너 오케스트레이션 툴
여러대의 도커 호스트에 컨테이너를 배포하고 관리하는 기능을 제공하여 애플리케이션의 가용성과 확장성 향상

컨테이너 오케스트레이션 : 여러 호스트의 컨테이너 배포 및 관리, 제어를 자동화하는 것

사용 이유

운영 중 서비스의 덩치가 커져 서버 자원이 부족할 경우 → 더 좋은 사양의 서버를 사면 되지만 서버의 구매, 교체 등은 부담이 됨

도커 스웜을 통해 여러 서버를 하나의 클러스터(군집)로 묶어 자원을 병렬로 확장 하게 도와주는 역할

다른 호스트의 여러 컨테이너를 하나로 묶어 하나의 호스트처럼 사용

구성

• 분산 코디네이터 : 여러 개의 도커 서버를 하나의 클러스터로 구성하기 위해 각종 정보를 저장 및 동기화

• 에이전트 : 각 서버 제어

• 매니저 노드 : 클러스터 내의 워커 노드 관리, 무조건 1개 이상 존재, 워커 노드 역할도 함
  - 클러스터의 상태 유지 : 뗏목 알고리즘 → 여러 서버 중 일부에 장애가 생겨도 나머지 서버가 정상적인 서비스를 할 수 있도록 해줌

  • 스케줄링 서비스 : 워커 노드에게 컨테이너 배포 → 특정 노드만 배포 가능
  • 스웜 모드 제공
  • 7개 이상의 노드는 성능 저하를 일으킬 수 있다고 함

• 워커 노드 : 컨테이너가 생성되고 관리되는 실제 도커 서버
  - 반드시 하나 이상의 매니저 노드를 가져야 함

• 노드 : 텍스트 클러스터에 속한 도커 서버 단위 → 보통 한 서버에 하나의 도커 데몬 실행(노드 = 서버)

스웜 클래식과 도커 스웜모드

스웜 클래식

• 여러 서버를 단일 접근점 제공
• 일반 도커 명령어 및 API로 서버 제어
• 분산 코디네이커/에이전트 별도 실행

도커 스웜모드

도커 엔진 자체 내장

• 마이크로 서비스 아키텍처 컨테이너를 다루기 위한 클러스터링
• 유동적 컨테이너 수 조절 가능
• 로드밸런싱 지원
• 확장성과 안전성 뛰어남

차이

스웜클래식은 여러대의 도커 서버를 하나의 지점에서 사용하도록 단일 접근점 제공
스웜모드는 마이크로서비스 아키텍처의 컨테이너를 다루기 위한 클러스터링 기능에 초점
공식문서에서도 도커 스웜모드를 권장함

쿠버네티스

도커 스웜과 같은 컨테이너 오케스트레이션 툴 중 하나

장점

1. 자동화 및 스케일링 : 클러스터의 리소스를 동적 확장/축소
2. 다양한 컨테이너 오케스트레이션 : 서비스 디스커버리, 로드 밸런싱, 롤링 업데이트, 롤백 등과 같은 기능 제공
3. 커뮤니티 에코시스템 : 큰 오픈소스 커뮤니티 기반
4. 유연한 아키텍처 : 다양한 환경에서 실행
5. 세밀한 컨트롤 및 구성 : 파드, 서비스, 볼륨 등과 같은 자세한 리소스 정의, 구성하는 세밀한 컨트롤 제공
6. 선언적 구성 : 높은 수준의 관리와 유지보수 용이성 제공
7. 다양한 배포 전략 : 롤링 업데이트, 블루-그린 배포, 카나리아 배포 등 다양한 배포 전략 지원
8. 서비스 디스커버리 및 로드 밸런싱

도커 스웜이 더 나은 경우

개인 개발 프로젝트를 운영하거나 소규모, 스타트업 기업에서 개발할 경우
도커 스웜은 쿠버네티스보가 학습곡선이 낮고 쉽게 채택 가능
세팅도 간편함

운영해야 할 컨테이너 개수가 적거나 컨테이너 관리에 익숙한, 향후 교육에 투자할만한 DevOps 전담 팀 혹은 인력이 없거나 부족한 경우, 개인 프로젝트를 운영하는데 DevOps를 도입해서 운영해보고 싶은 경우
→ 도커 스웜

반대의 경우 → 쿠버네티스