- 컨테이너는 샌드박스화 된 런타임 환경이다.
- 샌드박스화 : 프로세스가 보호된 영역에서 동작하여, 호스트 시스템 및 다른 프로세스에게 영향을 미치지 않는다는 것을 의미한다.
- 런타임 환경: 어플리케이션이 동작할 때 필요한 최소한의 실행환경
- 컨테이너는 호스트 OS를 공유한다. 따라서, 호스트 OS와 다른 OS 기반의 컨테이너 구동은 불가능하다.
- 즉, 컨테이너는 호스트 가상화처럼 게스트 OS를 호스트 OS와 분리하는 것이 아니라, 어플리케이션을 OS로부터 독립적으로 분리하는 역할을 한다.
- Docer는 컨테이너 가상화 기술 기반의 오픈소스 가상화 플랫폼이다.
- 프로세스를 격리하여 컨테이너와 같이 일정한 규격/인터페이스로 통일
- CPU/메모리는 필요한 만큼만 사용 (미리 일정량을 할당해 놓는 방식이 아니다)
- 단 CPU/메모리 사용량을 제한 할 수도 있다.
- 컨테이너는 서로 영향을 미치지 않고 독립적으로 실행되어 가상 머신을 사용하는 것과 같다
- 호스트의 특정 포트와 연결하거나, 호스트의 특정 디렉토리(볼륨 마운팅)를 공유할 수 있다.
도커 구동 방식
- 도커는 다양한 인터페이스를 사용해서 커널의 다양한 기능을 사용한다.
- 네임스페이스를 사용하여 네트워크, 사용자 ID, 파일시스템, 프로세스 트리와 같은 운영체제 환경을 어플리케이션 별로 격리하는 방식으로 어플리케이션이 독립적인 환경에서 수행될 수 있다.
- 버전 0.9부터는 자체적으로 개발한 libcontainer 엔진을 사용하여 커널이 제공하는 가상화 기능을 직접 호출하는방식으로 변경됨
- 도커 컨테이너를 실행하기 위해서는 도커 엔진이 필요하다.
- 도커 엔진은 서버-클라이언트 기반의 어플리케이션으로 Docker Deamon, REST API, CLI 3가지 컴포넌트로 구성된다.
- 도커 CLI를 통해서 도커 컨테이너, 도커 이미지, 네트워크, 데이터 볼륨 등을 관리한다
- 도커 CLI는 도커 Daemon과 REST API로 통신을 하는 구조로 동작한다.
도커 아키텍처
- 도커 클라이언트는 도커 Daemon과 통신하여 도커 컨테이너를 생성, 실행, 배포한다.
- 서버-클라이언트 아키텍처 기반이므로, 서버(Daemon)와 클라이언트가 동일한 시스템에 설치되거나, 다른 시스템에 설치될 수 있다.
- 서버-클라이언트 통신에서 REST API를 사용한다.
- 도커 호스트에서 수행하는 도커 데몬은 레지스트리로부터 도커 이미지를 호스트로 내려받아 인스턴스(컨테이너)를 생성한다.
- 도커를 사용할 때, 도커 이미지, 컨테이너, 네트워크, 볼륨 등을 생성하게 되는데, 이를 도커 객체라고 부른다.
도커 아키텍처의 주요 컴포넌트
- 도커 데몬
- 도커 호스트에서 동작하는 데몬 프로세스
- 데몬 프로세스란 백그라운드에서 계속 실행되는프로세스
- 클라이언트가 도커 API를 통해 요청하는 내용과 도커 오브젝트를 관리
- 도커 서비스를 위해서 도커 데몬은 도커 호스트의 다른 데몬과 통신한다.
- 도커 클라이언트
- 도커 사용자가 도커와 통신하는 방법 중의 하나로, 도커 관련 명령어를 도커 데몬에 요청하는 역할을 수행
- 도커 레지스트리
- 도커 이미지 저장소
- 도커는 로컬 파일시스템에 없는 이미지를 요청받으면 도커 허브에서 해당 이미지를 검색하여 다운
- 도커 이미지
- 개발 환경에 필요한 SW/라이브러리를 설치하여 이미지를 만들어 두면, 도커가 설치된 다른 컴퓨터에 옮겨서 동일한 환경 구성으로 사용할 수 있다.
- 이미지는 저장소에 등록된 이미지를 그대로 사용하거나, 등록된 이미지를 베이스로 하여 추가 SW/라이브러리를 추가 설치한 커스텀 이미지를 생성하여 사용가능
- 이미지 생성을 위해 Dockerfile이라는 파일을 사용한다.
- 도커 컨테이너
- 도커 이미지를 실행하면 도커 컨테이너가 생성된다. (프로그램 -> 프로세스 관계와 유사)
- 도커는 리눅스 커널이 제공하는 네임스페이스, 컨트롤 그룹, 유니온 파일 시스템 등의 기술을 활용한다.
- 네임스페이스
- 컨트롤 그룹
- 컨테이너가 사용할 CPU, MEM 등의 자원을 제어하는 역할
- 유니온 파일 시스템
- 물리적으로 서로 다른 파일 시스템으로 관리되더라도, 모두 하나의 디렉토리에 마운트 하여 사용자에게는 논리적으로 하나의 파일 시스템으로 통합해서 보여주는 기능
유니온 파일 시스템
도커의 기술적 소개
- 이미지
- 도커 이미지는 Read-Only Template으로, 컨테이너 실행에 필요한 파일과 설정 값 등을 포함한다.
- 컨테이너는 이미지를 실행한 상태로 볼 수 있으며, 컨테이너 구동 중 추가하거나 변경한 값/데이터는 컨테이너에 저장된다.
- 도커 이미지는 레이어 기반으로 구성됨
- 하나의 이미지는 다수의 Read-Only 레이어를 쌓는 형태로 구성됨
- 하나의 레이어는 다수의 이미지에 공통적으로 사용될 수 있음 (디스크 사용량 감소)
- 하나의 이미지로 여러 컨테이너 생성 가능
- 이미지와 레이어
- 상위 레이어는 하위 레이어에 의존성을 가지며, 각 레이어는 파일과 디렉토리로 구성되고 읽기 전용이다.
- 이미지를 실행하여 컨테이너가 생성되면 쓰기가 가능한 레이어가 최상위 계층에 추가된다.
- 컨테이너 구동 중에 발생하는 파일 쓰기/수정 등의 작업은 모두 최상위 계층에 저장된다.
- 최상위 계층에 저장된 내용과 하위 계층에 저장된 내용이 서로 다를 경우, 최상위 계층의 내용으로 덮어쓰게 된다.
- 도커 이미지가 빌드될 때, 하위 이미지와의 차이점(diff)을 새로운 레이어로 생성하고, 레이어를 순차적으로 쌓는 방식을 사용한다
- 만약 상위 계층이 하위 계층과 이름과 내용이 동일하면 상위 계층은 하위 계층과 차이점이 없으므로 비어있게 된다.
가장 최상위 Container layer에 쓰기가 가능하다 Image Later는 Read-Only이다.
- . 이미지와 레이어
- SHA256을 레이어 콘텐츠에 적용하여 생성된 16진수 해시 값을 게이어의 ID 값으로 사용한다.
- 각 도커 이미지는 이미지를 구성하는 레이어 리스트를 갖고 있어, 도커 엔진이 쉽게 해당 레이어를 참조하여 컨테이너의 파일시스템을 만들어 낼 수 있다.
- 이미지를 구성하는 레이어 리스트 확인하기 $ docker inspect nginx (nginx이미지 레이어 확인)
- 도커는 이미지를 구성하는 레이어를 관리하고, 컨테이너의 writable layer에 데이터를 저장하는 것을 관리하기 위해 storage driver를 사용한다
- 도커는 plug-in 방식으로 다양한 storage driver를 지원하기 때문에 plug-out하고 다른 storage drver를 plug-in할 수 있다.
- 컨테이너 실행 중에 생성/변경된 데이터는 container layer에 저장되며, 컨테이너가 삭제되면 container layer에 저장된 내용도 함께 삭제된다.
- 컨테이너가 삭제된 후에도 데이터를 유지하고 싶다면
- 볼륨 마운트를 통해 로컬 파일 시스템과 컨테이너의 파일 시스템을 동기화하기
- export 명령어를 사용해서 컨테이너의 이미지와 container layer의 내용을 새로운 이미지로 생성해야 한다.
- Container layer에서 발생한 수정내역 확인하기
- docker logs <컨테이너 이름> 명령어를 사용하여, 컨테이너 내부에서 어떤 활동이 있었는지에 대한 로그를 확인할 수 있다.