컨테이너 런타임

• 컨테이너 생성

• 이미지 안에 레이어로 이뤄져 있는 계층구조로 파일이 이뤄져 있음

• 이 위에 READ WRITE 레이어를 하나 더 올림

• 이 RW레이어를 통해 이미지의 파일을 읽고 쓰고 할수 있음.

• 이 상태가 컨테이너

• 이 RW 레이어를 통해 파일을 읽고 쓰도록 해주는 드라이버가

• AUFS나 OVERLAY2

• 도커 컨테이너의 성능은 그래서 이 스토리지 드라이버에 따라 차이가 남.

• 컨테이너 내부에 프로그램을 구동시켜야되는데

• 도커파일에 엔트리포인트에 정의된 실행파일 같은걸 실행시킴.

• 이 과정에서 namespace 격리 cgroup의 자원할당이 일어남.

• 일어나면서 외부와 격리됨.

• 위의 과정에서 cgroup와 namespace는 저수준 컨테이너 런타임이 실행과정에서 처리해줌.

• 저수준 컨테이너 런타임 = ( runc )

• /var/lib/docker/overlay2/에 이미지가 저장됨

Docker와 containerd

• 위의 runc로 cgroup namespace 일일히 다 oci 스펙에 맞게 config 작성하는것은 쉽지 않은 일.

• 이걸 쉽게 해주는게 containerd

• 도커는 continerd위에 올라가 있는 cli나 데몬 ( dockerd ) 임.

• 도커는 컨테이너를 다루기 위한 모든 동작이 포함되어있음.

• 그래서 자체 api나 자체 cli툴이 매우 강력함.

CRI-O

• 이름부터 container runtime interface - open container initative 이다.

• CRI 및 이미지가 OCI와 호환되는것에 중점을 둔 CR

• 오로지 컨테이너의 실행을 목적으로 경량화 했기 떄문에 도커가 제공하는 컨테이너 생성 및 이미지 빌드와 같은 과정이 없었음.

• 그래서 도커가 필요했음.

• CRI-O 팀은 도커를 대체하는 툴들을 개발함.

• Buildah, Podman, Skopeo

 

참고

https://www.samsungsds.com/kr/insights/docker.html

https://ssup2.github.io/theory_analysis/Docker_Component/

lugi 님