[Docker] 도커의 기본 아키텍처와 기능

도커(Docker)는 21세기 소프트웨어 개발 방식에 혁신을 가져온 대표적 플랫폼입니다.

컨테이너 기반 아키텍처와 클라이언트-서버 모델, 불변 인프라 원칙, 이미지 계층화 구조, 레지스트리를 통한 협업과 분산 실행 도구

이 요소들이 결합되어 현대 DevOps와 마이크로서비스 생태계에서 핵심 역할을 담당하게 만들었습니다.

Docker Architecture

도커 아키텍처의 핵심에는 도커 엔진(Docker Engine)이 있습니다. 도커 엔진은 다음과 같이 클라이언트-서버 구조를 채택하고 있습니다.

1) Server (Docker_HOST, dockerd)

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

2) REST API

• dockerd는 명확하게 정의된 REST API를 외부로 노출합니다.
• 이 API를 통해 커맨드라인 도구, 외부 프로그램, 오케스트레이터(예: 쿠버네티스) 등이 도커 데몬과 통신할 수 있습니다.

3) Client (CLI, docker 커맨드)

• 사용자가 터미널에 입력하는 docker run, docker build 등 모든 명령어는 사실상 REST API 요청의 추상화입니다.
• 도커 CLI는 유닉스 도메인 소켓(기본 경로 /var/run/docker.sock)이나 네트워크 인터페이스를 통해 HTTP 기반의 REST API로 동작합니다.
• 이 구조 덕분에, CLI와 데몬은 반드시 같은 시스템에 상주할 필요가 없습니다. 원격의 데몬을 CLI에서 제어할 수 있게 되어, 분산 환경과 클러스터링, 클라우드 오케스트레이션에 이상적인 설계가 완성됩니다.

---

Docker Images

도커 이미지는 실행 가능한 소프트웨어 환경의 완벽한 스냅샷(청사진, Blueprint)입니다.

• 읽기 전용(Read-Only) 파일로서, 실행에 필요한 코드, 라이브러리, 런타임, 의존성 등을 전부 내장하고 있습니다.
• 이미지마다 여러 개의 계층(Layer) 으로 구성되어 있습니다.

 

이미지 계층과 유니온 파일 시스템(Union FS)

• 각 Dockerfile 명령(예: FROM, RUN, COPY, CMD)마다 하나의 계층이 생성됩니다.
• 유니온 파일 시스템(UnionFS)은 이 계층들을 하나의 연속적인 파일시스템처럼 결합시켜줍니다.
• 공통 계층을 여러 이미지/컨테이너가 공유하는 구조로 인해, 저장 공간과 네트워크 대역폭 모두 극적으로 절약됩니다.
  • 예: Ubuntu 계층(1GB)을 10개 컨테이너가 공유할 때, 실제 1GB정도만 저장됨.

---

Docker Container

도커 컨테이너는 이미지를 바탕으로 생성된, "실행 중인 프로세스+파일시스템+격리 환경"을 모두 아우르는 단위를 의미합니다.

• 컨테이너는 이미지의 계층 위에 읽기-쓰기(read-write) 계층을 한 층 더 쌓아 올려 구동됩니다.
• 이 계층에 실행 중 생성되는 로그, 임시 파일 등이 쓰입니다.

비유: 클래스와 객체

• 이미지가 ‘클래스’라면, 컨테이너는 그 클래스를 실제로 띄운 ‘객체’입니다.
• 동일 이미지를 기반으로 무한히 많은 컨테이너를 찍어낼 수 있습니다.

실행 환경의 격리와 경량성

• 컨테이너마다 프로세스, 네트워크, 파일시스템이 격리되되, 커널(리눅스)를 공유하므로 가볍고 빠른 실행 환경이 제공됩니다.

컨테이너의 상태와 신규 이미지 생성

• 컨테이너에서 변경된 내용을 docker commit으로 새로운 이미지(청사진)로 만들 수도 있어, 실시간 변형을 손쉽게 관리할 수 있습니다.

---

도커파일(Dockerfile)

• 도커파일은 텍스트 기반의 설정 파일로, 도커 이미지 빌드에 필요한 모든 단계를 명령어 형태로 나열합니다.
• 빌드 자동화, 표준화
• 실행 환경의 이식성과 재현성 보장
• 개발-운영-테스트 간 환경 차이를 없앰

도커파일의 핵심 명령어와 구조

도커파일은 한 줄에 하나씩 "명령어 + 인자" 형태로 작성됩니다. 주요 명령어는 다음과 같습니다.

명령어	설명
FROM	베이스 이미지를 지정 (예: FROM ubuntu:22.04)
RUN	셸 명령을 실행해 소프트웨어 설치 등 처리(예: RUN apt-get update && apt-get install ...)
COPY	호스트의 파일/디렉터리를 이미지에 복사
ADD	COPY와 유사, 원격 URL/압축해제 지원
CMD	컨테이너 시작 시 기본 실행 명령을 지정 (단, docker run 명령어 인자에 의해 덮어쓸 수 있음)
ENTRYPOINT	컨테이너의 실행 진입점 지정 (CMD와 차이 있음)
ENV	환경변수 지정 (예: ENV NODE_ENV=production)
WORKDIR	이후 동작의 작업 디렉터리 지정
EXPOSE	컨테이너가 사용할 포트 번호 메타데이터(네트워크 공개 목적)
VOLUME	데이터 볼륨 마운트(영구 데이터 저장 목적)
ARG	빌드 시점에 사용되는 변수
USER	명령 실행 사용자 지정 (보안 강화 목적)
LABEL	이미지에 메타데이터(버전, 설명 등)

도커파일 빌드 프로세스

1. FROM에서 지정한 베이스 이미지를 다운 받아 루트 파일 시스템의 최하단 레이어로 삼음.
2. 위에서 아래로 한 줄씩 명령을 실행하며(예: RUN으로 패키지 설치), 각 단계(Instruction)별로 계층(layer)이 쌓임.
3. COPY/ADD 명령으로 애플리케이션 소스나 파일을 추가.
4. ENV/WORKDIR 등으로 환경을 세팅.
5. 마지막에 앱 실행 명령(CMD/ENTRYPOINT 등)을 지정.
6. 모든 단계가 다 끝나면, 중간 결과물이 읽기전용 레이어로 저장되어 최종 도커 이미지가 완성.

→ 이미지의 계층화(레이어스태킹)는 저장공간과 전송 효율성을 대폭 개선합니다.

도커파일 작성 예시

# 1. 베이스 이미지
FROM python:3.11-slim

# 2. 환경 변수 설정
ENV PYTHONUNBUFFERED=1

# 3. 종속성 설치
RUN apt-get update && apt-get install -y build-essential

# 4. 소스 코드 복사
COPY . /app

# 5. 작업 디렉터리 지정
WORKDIR /app

# 6. 패키지 설치
RUN pip install --no-cache-dir -r requirements.txt

# 7. 실행 명령(기본)
CMD ["python", "main.py"]

 

도커파일의 장점

• 불변 인프라/재현성: 같은 Dockerfile로 언제 어디서든 동일 이미지/환경 확보
• 자동화와 CI/CD: 소스 코드 변경→이미지 빌드→배포 플로우 자동화의 필수 요소
• 계층 활용 최적화: 변경이 잦은 단계(COPY 등)는 가능하면 하단이 아닌 상단에 두어 빌드 캐시 최대화
• 보안: 최소 권한 USER 설정, 필요 없는 파일은 .dockerignore로 빌드 제외
• 다중 스테이지 빌드: 빌드용 임시이미지/최소 배포이미지 분리로 용량과 보안 최적화

---

Docker Registry : docker hub

도커 레지스트리는 이미지 저장과 배포, 협업을 위한 핵심 인프라입니다.

• 이미지를 중앙에서 관리, 조직 내·팀 간·전 세계 개발자들 간에 손쉽게 이미지 배포 가능.
• 소스코드의 깃허브처럼, 이미지의 버전·배포·보안 정책을 통제하는 거점입니다.

---

Workflow: Build, Run, Push, Pull

위의 아키텍처 요소들은 개발팀과 운영팀, 혹은 머신 간 손쉬운 핸드오프를 가능케 합니다:

 

1. Build

• 개발자는 필요한 환경을 Dockerfile에 정의하고, docker build 명령어로 이미지를 생성합니다.
• 데몬이 실제 빌드 작업을 처리, 필요한 베이스 이미지는 없는 경우 자동으로 레지스트리에서 가져옵니다.
• 빌드 결과는 여러 계층(공유/불변)으로 저장됨.

2. Run

• docker run을 입력하면, CLI가 데몬에 REST API 요청을 보냅니다.
• 이미지를 바탕으로 RW 계층이 추가된 컨테이너가 생성 및 실행됩니다.
• 네트워크·스토리지 매핑 등은 데몬이 자동 할당.

3. Push

• 빌드한 이미지를 팀이나 생산 환경에 전달하기 위해 레지스트리에 push.
• 변경된 계층만 업로드하며, 디스크와 네트워크 효율성이 높음.

4. Pull

• 새로운 머신에서도 docker pull로 이미지를 받아 곧바로 컨테이너 실행.
• 운영자는 환경 설정이나 내부 코드를 알 필요 없이 이미지만으로 서비스 배포 가능.

---

아키텍처적 의미

도커의 아키텍처는 분리와 표준화, 불변성, 효율성, 확장성을 목표로 합니다.

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

이러한 아키텍처 덕분에 도커는 “한 번 빌드, 어디서나 실행”이라는 약속을 현실로 만들었으며, 전 세계 개발 문화와 소프트웨어 배포 방식을 새롭게 정의했습니다.

이는 곧 클라우드 네이티브, 마이크로서비스, CICD, DevOps의 핵심 기반이자, 일상적인 개발자와 운영자가 모두 사용하는 도구로 도약할 수 있었던 이유이기도 합니다.