Oh My Algorithm
🐳인프라·DevOps

Docker 알고리즘

이미지와 컨테이너로 실행 환경을 통째로 포장. 아래 8개 항목을 인터랙티브 시각화로 단계별로 학습해 보세요.

🐳이미지 레이어 (Image Layers)

Docker 이미지는 하나의 통짜 파일이 아니라 읽기 전용 레이어를 겹겹이 쌓은 구조입니다. Dockerfile의 명령 하나가 레이어 하나를 만들고, 실행 시 그 위에 쓰기 가능한 컨테이너 레이어가 얹혀 하나의 파일시스템처럼 보입니다. 레이어는 내용이 같으면 이미지끼리 공유되고 캐시되기 때문에, 명령 순서가 곧 빌드 속도와 이미지 용량을 결정합니다.

Union FS · 레이어 캐시
🐳멀티스테이지 빌드 (Multi-stage Build)

빌드에 필요한 것과 실행에 필요한 것은 다릅니다. 컴파일러·빌드 도구·개발 의존성은 이미지를 만들 때만 쓰이는데, 한 스테이지로 빌드하면 이것들이 최종 이미지에 그대로 남습니다. 멀티스테이지 빌드는 빌더 스테이지에서 만든 결과물만 최종 스테이지로 복사하고 나머지는 통째로 버려, 같은 앱의 이미지를 1 GB대에서 100 MB대로 줄입니다.

빌드 스테이지 · 이미지 다이어트
🐳컨테이너 vs 가상머신 (Container vs VM)

가상머신은 하이퍼바이저 위에서 게스트 OS를 통째로 띄워 하드웨어 수준으로 격리하고, 컨테이너는 호스트 커널을 그대로 공유하면서 namespace와 cgroups로 프로세스를 격리합니다. 게스트 OS라는 한 층이 통째로 빠지기 때문에 컨테이너는 시작이 초 단위로 빠르고 이미지가 가볍지만, 격리 경계는 VM보다 얕습니다.

커널 공유 · 격리
🐳컨테이너 생명주기 (Container Lifecycle)

컨테이너는 만들어졌다가 사라지는 하나의 프로세스이고, 그 사이를 Created·Running·Paused·Exited 상태로 오갑니다. `docker run` 은 사실 create 와 start 를 합친 명령이고, `stop` 은 SIGTERM 을 먼저 보낸 뒤 기다렸다가 SIGKILL 로 강제 종료합니다. 어떤 명령이 어떤 전이를 일으키는지 알면 데이터가 언제 사라지는지도 함께 보입니다.

상태 전이 · create/start/stop
🐳볼륨과 데이터 (Volumes)

컨테이너의 쓰기 레이어는 컨테이너와 수명을 같이 합니다. 그래서 컨테이너를 지우면 그 안에 쌓인 데이터도 함께 사라집니다. 볼륨은 호스트 쪽 저장소를 컨테이너 경로에 얹어 데이터를 컨테이너 바깥에 두는 장치이고, 덕분에 컨테이너를 갈아치워도 데이터베이스 파일은 그대로 남습니다.

영속성 · 마운트
🐳네트워크와 포트 (Networking)

같은 브리지 네트워크에 속한 컨테이너들은 각자 사설 IP를 받고 서비스 이름만으로 서로를 찾습니다. 하지만 이 네트워크는 호스트 바깥에서 보이지 않기 때문에, 외부에서 접근하려면 `-p 8080:80` 처럼 호스트 포트를 컨테이너 포트에 연결해 줘야 합니다. 컨테이너끼리는 이름으로, 바깥에서는 포트 매핑으로 — 이 둘을 구분하는 것이 핵심입니다.

브리지 · 포트 매핑
🐳레지스트리 push·pull (Registry)

레지스트리는 이미지를 통째로 주고받지 않습니다. 이미지는 매니페스트(레이어 목록)와 레이어들로 나뉘어 있고, push·pull 은 상대가 갖고 있지 않은 레이어만 전송합니다. 각 레이어는 내용 해시(다이제스트)로 식별되므로 같은 베이스를 쓰는 이미지를 여러 개 올려도 베이스 레이어는 한 번만 저장됩니다.

레이어 전송 · 다이제스트
🐳멀티 컨테이너 (Docker Compose)

실제 앱은 컨테이너 하나로 끝나지 않습니다. 웹·API·데이터베이스를 각각 띄우고 네트워크로 잇고 볼륨을 붙이는 일을 `docker run` 여러 번으로 하면 재현이 어렵습니다. Compose 는 이 구성을 YAML 파일 하나에 선언해 두고 `docker compose up` 한 번으로 전체를 세우며, 서비스 이름이 곧 네트워크 상의 호스트 이름이 됩니다.

서비스 그래프 · 선언형