본문 바로가기

DevOps/Docker

[Docker] 도커 엔진(Docker Engine)에 대해서 - 컴도리돌이

728x90

 

회사에서 이제 카프카(kafka), 도커(docker), 엘라스티서치(elk), 등을 도입 얘기가 나오는데, 나는 아무것도 모릅니다. 😓 오늘은 도커 엔진에 대해 포스팅을 해볼 생각입니다. 아는 게 많고 해 봤던 것이 많은 개발자가 얼른 되고 싶네요 😭😭

 


도커(Docker)

도커는 클라이언트-서버 모델을 구현한 애플리케이션입니다. 

 

도커 엔진은 도커 컴포넌트(Docker Componets)와 서비스를 제공하는 컨테이너를 구축하고 실행하는 기본 핵심 소프트웨어이에요.  Docker Demon, Docker Client, Docker image, Docker Container, Docker Registry로 주요 구성되어 있으며, 개발자가 흔히 도커라고 할 때, 주로 Docker Engjine을 의미합니다. 

 


 

도커 클라이언트(Docker Client)

사용자가 도커와 상호 작용할 수 있는 명령행 인터페이스로, 클라이언트는 사용자가 컨테이너를 빌드, 실행, 중지, 삭제 등의 작업을 수행할 수 있도록 합니다. 클라이언트는 Docker Daemon과 통신하여 요청을 처리해요.

 

예를 들어, 다음과 같은 명령어를 사용하여 도커 클라이언트를 통해 컨테이너를 실행할 수 있어요.  

 

docker run -d nginx

 

Docker CLI에 명령어를 입력하면, 도커 클라이언트는 적절한 API Payload로 변환하여 Docker Daemon에게 REST API로 POST 요청을 합니다. 위에 예시에서는 Docker CLI에 명령어를 입력해서 도커 클라이언트에게 'nginx' 이미지를 사용하여 백그라운드에서 컨테이너를 실행하도록 요청하는 것입니다. 

 

도커 대몬(Docker Daemon) - dockerd

도커 데몬은 도커 엔진의 핵심 구성 요소로, 호스트 시스템에서 백그라운드로 실행됩니다. 도커 데몬은 클라이언트로부터 받은 요청을 처리하고, 컨테이너의 생성, 실행, 관리 등을 담당합니다. 예를 들어, 위에서 언급한 docker run 명령어는 도커 데몬에게 컨테이너를 실행하도록 요청하는 것입니다.

 

도커 클라이언트에서 요청받은 API는 도커 데몬으로 전달받습니다. 도커 데몬에서는 새 컨테이너를 시작할 때, 로컬 이미지가 있는지 확인하고, 존재하지 않으면 registry에서 해당 이미지를 가져옵니다. 

 

컨테이너 레지스트리(Container Registry)

도커 레지스트리는 도커 이미지를 저장하고 공유하는 중앙 집중식 저장소로, Docker Hub와 같은 공식적인 레지스트리 또는 사설 레지스트리가 사용됩니다. 사용자는 도커 레지스트리를 통해 이미지를 푸시하고 풀하여 이미지를 공유하고 관리할 수 있습니다. 또한 도커 데몬은 필요에 따라 레지스트리에서 이미지를 가져와서 로컬에 캐시 합니다. 

 

도커 CLI에서는 다음 코드처럼 도커 이미지를 빌드하여 레지스트리에 푸시합니다. 

 

# 도커 클라이언트를 사용하여 이미지를 빌드합니다.
docker build -t my_image .

# 빌드된 이미지를 도커 레지스트리에 푸시합니다.
docker push my_registry/my_image:latest

 

docker pull 명령을 사용하면, 도커 레지스트리에서 이미지를 풀하여 로컬에 가져오고, docker run 명령을 사용하여 해당 이미지를 사용하여 컨테이너를 실행시킬 수 있습니다. 다음 코드는 도커 이미지를 갖고 와서 실행시키는 명령어입니다. 

 

# 도커 레지스트리에서 이미지를 풀하여 로컬에 가져옵니다.
docker pull my_registry/my_image:latest

# 로컬에 가져온 이미지를 사용하여 컨테이너를 실행합니다.
docker run -d --name my_container my_registry/my_image:latest

 

 


 

 

containerd

도커 데몬에서 새로운 컨테이너를 생성할 때, containerd를 호출하는데, 이때 도커 데몬은 CRUD 스타일 API를 통해 gRPC로 containerd와 통신을 합니다.  containerd는 컨테이너의 생명주기 관리와 실행을 담당합니다. containerd는 도커 데몬의 하위 시스템으로, 더 낮은 수준의 컨테이너를 관리를 합니다. 컨테이너의 생성, 시작, 중지, 삭제와 같은 기본 작업을 수행할 뿐만 아니라 라이플 사이클 이벤트 처리도 관리를 합니다.  도커 데몬이 컨테이너 관리 작업을 수행할 때, containerd와 통신하여 이러한 작업을 수행합니다. 

 

예를 들면, 사용자가 도커 클라이언트를 통해 컨테이너를 실행하면, 도커 데몬은 containerd에게 해당 컨테이너의 실행을 요청하고, containerd는 이를 처리하여 컨테이너를 생성하고 실행하게 됩니다.

 

shim

shim은 컨테이너의 시작 및 종료를 관리하는 프로세스로, 도커 데몬이 컨테이너를 실행할 때마다 shim이 컨테이너 프로세스를 시작하고, 해당 프로세스를 모니터링합니다. 컨테이너가 시작될 때 컨테이너 프로세스를 생성하고, 컨테이너가 종료될 때 해당 프로세스를 정리하는데, 이는 도커 데몬과 containerd 간의 통신을 위한 프록시 역할을 수행하며, 컨테이너의 생명주기를 관리합니다. 

 

runc

OCI에 따라 구현된 컨테이너 실행 도구이며, 컨테이너를 위한 표준화된 인터페이스를 제공합니다. 컨테이너의 생성, 시작, 중지 삭제 등의 작업을 수행하며, 도커는 runc를 사용하여 컨테이너를 실행하고 관리를 합니다. 

 

실제로 도커는 컨테이너를 생성할 때, runc를 호출하여 컨테이너를 위한 격리된 환경을 설정하고 프로세스를 시작합니다. 

 


 

이제 도커 구조가 어떻게 구성되어 있고, 각각 어떤 역할을 갖고 있고 어느 부분과 상호작용하는지 맛만 봤네요 🥲

다음 포스팅에서는 조금 더 전문적인 내용으로 찾아오겠습니다. 😭

 


 

 

Docker Engine, 제대로 이해하기 (1)

📌 Docker Series > Docker Engine, 제대로 이해하기 (1) - docker engine deep dive Docker Engine, 제대로 이해하기 (2) - namespace, cgroup Docker Network, 제대로 이해하기 (1) - libnetwork Docker Network, 제대로 이해하기 (2) - brid

gngsn.tistory.com

 

 

Docker Architecture

도커 아키텍처

velog.io