서론

Docker 아키텍처 목표
 - 분리   : 프로세스/네트워크/파일시스템이 모두 격리된 경량화된 실행 환경
 - 표준화 : 이미지와 REST API 기반 CLI로 어느 환경이든 표준화된 관리
 - 불변성 : 이미지는 절대 변하지 않아, 빌드와 실행, 배포의 일관성&재현성 보장
 - 효율성 : 계층화된 저장 및 전송 구조, 변경 분만 네트워크로 주고받는 방식
 - 확장성 : 원격 데몬 제어, 중앙 레지스트리를 통한 대규모 분산 시스템 구현 용이

Docker Arthitecture

Server(Docker_HOST, dockerd)

• dockerd는 백그라운드에서 상시 실행되는 데몬 프로세스
• 모든 도커 객체(이미지, 컨테이너, 네트워크, 볼륨 등)를 실제로 생성&관리하는 주체
• 일반적으로 DOCKER_HOST로 지정된 소켓에서 요청을 기다리며, 다음과 같은 방식으로 RestAPI를 받음
  • dockerd -H unix://var/run/docker.sock -H tcp://0.0.0.0:2375

REST API

• dockerd는 명확하게 정의된 REST API를 외부로 노출

• 이 API를 통해 커맨드라인 도구, 외부 프로그램, 오케스트레이터 등이 도커 데몬과 통신 가능

  추가
  ----
  - 여기서 오케스트레이터(k8s)가 "도커 데몬"과 통신 가능은 예전 "dockershim" 시절을 말함.
  - k8s v1.24부터는 보편적으로 "kubectl → apiserver → (노드) kubelet → CRI(gRPC) → containerd/CRI-O → runc → 컨테이너" 구조로 통신
  

Client(CLI, docker 커맨드)

• 사용자가 터미널에 입력하는 docker run&build 등 모든 명렁어는 사실상 REST API 요청의 추상화
• 도커 CLI는 유닉스 도메인 소켓(기본 경로 /var/run/docker.sock)이나 네트워크 인터페이스를 통해 HTTP 기반의 REST API로 동작