DevOps/Docker

[Docker] Container vs Process

변역알림

아래 포스팅 내용은 google site의 techincal Collection 작성자가 이해하기 쉽게 번역하였음을 알립니다.



들어가기 앞서, Container vs VMs

container vs. VMs

가상머신에서 VM은 자체 메모리 관리, 장치 드라이버, 데몬 등이 포함 된 전체 OS로 구성됩니다. 반면 Container는 호스트의 OS를 공유하므로 무게가 더 가볍습니다.



Container vs Process

더 흥미로운 비교는 Container과 Process 간의 비교입니다.

  • Container는 실제로 전체 환경을 갖춘 프로세스입니다.

일반적으로 프로세스는 자체 주소 공간 + 프로그램 + CPU 상태 및 프로세스 테이블 항목을 가지고 있는 것으로 정의됩니다. 그러나 오늘날의 소프트웨어 환경에서는 이것이 더 이상 온전한 이야기가 아닙니다.

프로그램 텍스트(Program text)는 실제로 파일 시스템에서 프로세스 주소 공간으로 매핑 된 메모리이며, 종종 프로그램 자체에 추가하여 수십 개의 공유 라이브러리로 구성되므로 이러한 모든 파일은 실제로 프로세스의 일부입니다.

Containers vs. Processes

또한 실행중인 프로세스에는 일반적으로 환경 (일반적으로 Linux의 /etc 또는 /var/lib에 있음)의 여러 파일이 필요하며, 이는 구성 파일 또는 프로그램 데이터 저장을 위한 것이 아닙니다.
예를 들어, SSL 연결을 만드는 모든 프로그램에는 Root CA 인증서가 필요하고 대부분의 프로그램에는 Locale 정보 등이 필요합니다. 이러한 모든 공유 라이브러리와 파일은 프로세스를 파일 시스템 환경에 매우 의존적으로 만듭니다.

컨테이너가 하는 일은 기존 프로세스와 파일 시스템 환경을 캡슐화(encapsulation)하는 것입니다. 이 모든 것의 결로은은 컨테이너를 슬림화 된 VM보다 프로세스에 대한 더 나의 추상화로 생각하는 것이 훨씬 더 적절하다는 것입니다.



그럼 Docker는?

따라서 Docker에 대해 생각하는 올바른 방법은 각 컨테이너를 모든 종속성이 있는 하나의 프로그램 캡슐화로 보는 것입니다. 컨테이너는 (거의) 모든 호스트에 놓을 수 있으며 작동하는 데 필요한 모든 것이 있습니다. 컨테이너를 사용하는 이런 방식은 소형 및 모듈식 소프트웨어 스택으로 이어지며 컨테이너 당 하나의 관심사라는 Docker 원칙을 따릅니다.

많은 최초 사용자를 잘못 이끄는 Docker의 측면은 대부분의 컨테이너가 Ubuntu, CentOS 등과 같은 기본 OS 컨테이너에 소프트웨어를 설치하여 빌드된다는 것입니다. 따라서 컨테이가 실제로 "실행"될 것이라고 생각하기 쉽습니다. 그러나 그것은 사실이 아닙니다. 오히려 base OS 설치는 컨테이너에서 실행되는 프로그램이 의존할 수 있는 환경으로 표준 파일 시스템 콘텐츠로 시작하는 목적으로만 사용됩니다.(주: 컨테이너를 사용하는 주 목적은 애플리케이션을 실행하기 위해서이다. Ubuntu, CentOS는 애플리케이션이 컨테이너에서 실행되는 환경을 제공한것이라고 이해했다.)

프로그램에서 실제로 필요한 파일만 컨테이너에 설치할 수 있지만, 이러한 최소한의 컨테이너 콘텐츠를 대상으로하는 것은 종종 어렵우면서 번거롭고 유연하지 않습니다. 게다가 Docker가 Overlay File System을 사용하는 방식은 사용하지 않는 추가 파일의 비용을 최소화합니다.


Container 사용에 주의점(하나의 프로세스만)

컨테이너로 전체 OS 기본 설치로 시작하면 종종 사용자가 initd, syslogd, crond, sshd 등과 같은 컨테이너에서 시스템 데몬(System Daemon) 모음을 실행하기를 원하게됩니다. 하지만 컨테이너를 하나의 프로세스(혹은 프로세스 트리)만 실행하는 것으로 생각하는 것이 좋습니다. 그리고 모든 파일 시스템 종속성을 캡슐화합니다.