개발블로그

Docker 본문

STUDY/Docker

Docker

devmel 2026. 8. 26. 15:45
Contents 접기
 

Docker은 왜 필요한가?

 

Application을 실행하려면 Source Code만 필요한 것이 아니라 해당 Application이 동작할 실행 환경도 필요

ex) PHP Web Application이라면 다음과 같은 환경이 필요 할 수 있다

: PHP 8.3, Nginx, MySQL 8, Redis 7, PHP Extension, 각종 Library 및 설정

 

여러 환경에서 동일한 Application을 실행하기 시작하면

Source Code가 동일하더라도 Runtime이나 Dependency의 Version, 설정 등이 다르면 동작 결과가 달라질 수 있음. 

ex) 특정 PHP Version에서만 지원되는 기능 사용, 필요한 PHP Extension이 설치되지 않음

 

Application이 실행되는 환경을 일정한 형태로 구성하고 재사용 할 수 있는 방법이 필요

 

Docker을 사용하면 Application과 실행에 필요한 환경을 Container라는 격리된 환경에서 실행할 수 있도록 관리.

=> Container가 실행에 필요한 요소를 자체적으로 포함할 수 있어 Host에 미리 설치된 Dependency에 대한 의존을 줄이고, 개발 환경이나 Server 등 여러 환경에서 동일한 Container를 실행할 수 있다. 

 

 


 

Docker란?

 

개념

Application을 Container라는 격리된 환경에서 개발하고, 배포하고, 실행할 수 있도록 지원하는 Platform

 

Docker를 사용하면 Application 실행에 필요한 환경을 Container 단위로 구성하고 관리할 수 있음. 

Application
+
Runtime / Library / Dependency
+
Configuration
        ↓
   Container
        ↓
 Docker가 실행 · 관리

 

역할

Container를 생성·실행·중지·관리하는 Platform

=> 각 Container뿐 아니라 Container 실행에 필요한 Image, Network, Volumn등의 Resource도 함께 관리.

 


 

Container란?

개념

Host에서 다른 Process와 격리된 상태로 실행되는 Process

Container마다 별도의 OS 전체를 실행하는 것이 아니라, Host의 Kernel을 공유하면서 필요한 실행 환경을 서로 분리

Host

├─ 일반 Process

├─ Container A
│    └─ Application

└─ Container B
     └─ Application

 

VM과의 차이

구분 VM Container
OS VM마다 Guest OS 존재 Host Kernel 공유
실행 단위 Virtual Machine 격리된 Process
크기 상대적으로 큼 상대적으로 작음
시작 속도 OS Boot 필요 Process 실행 중심이라 빠른 편
Resource 사용 Guest OS까지 필요 필요한 Process 중심
격리 수준 OS 단위 Process / Namespace 단위
용도 os 자체를 분리해야 하는 경우에 적합 Application 실행 환경을 빠르고 일관되게 구성하는 경우 

 

VM의 구조

VM은 하나의 물리적 장비 위에서 여러 개의 가상 Machine을 실행하는 방식

각 VM은 일반적으로 자신만의 Gueset OS를 가짐

=> Application을 실행하기 위해 VM마다 OS까지 함께 실행

Hardware
   ↓
Host OS
   ↓
Hypervisor
   ↓
┌───────────────┐
│ VM A                             
│ ├─ Guest OS                
│ └─ Application              
└───────────────┘

┌───────────────┐
│ VM B         
│ ├─ Guest OS   
│ └─ Application
└───────────────┘

 

Container의 구조

Host OS의 Kernel을 공유

Hardware
   ↓
Host OS / Kernel
   ↓
Container Runtime
   ↓
┌───────────────┐
│ Container A  
│ Application   
└───────────────┘

┌───────────────┐
│ Container B   
│ Application   
└───────────────┘

 

무엇이 격리되는가

영역 의미
Process Container마다 자신에게 속한 Process를 분리해서 관리
File System 각 Container가 사용할 File과 Directory 환경을 분리
Network Container별 Network 환경 구성 가능 (CPU/Memory 등)
Resource CPU, Memory 등의 사용량을 제한 가능

 

어떻게 격리할 수 있을까?

Linux환경에서 Container의 격리에는 대표적으로 Namespace와 cgroup같은 Kernel 기능 사용.

기능 역할
Namespace Process가 볼 수 있는 System Resource의 범위를 분리
cgroup CPU, Memory 등의 Resource 사용량을 관리·제한

 

주요 특징

  • 격리성 : 다른 Container 및 Host Process와 실행 환경을 분리
  • 독립성 : Container별로 생성·실행·중지·삭제 가능
  • 자체 실행 환경 : Application 실행에 필요한 File과 Dependency를 포함 가능
  • 경량성 : 별도의 Guest OS 전체를 실행하지 않고 Host Kernel을 공유 

 

 


 

Docker 구조

Client-Sever 구조

사용자
  │
  │ docker run nginx
  ▼
┌────────────────┐
│ Docker CLI                      │
└───────┬────────┘
        │ 요청 전달
        ▼
┌────────────────┐
│ Docker Daemon               │ -- nginx 이미지 있는지 확인, 없으면 Registry에서 이미지 받기. 
│                                          │    Docker 객체(이미지, 컨테이너, 네트워크 볼륨 등) 생성+관리  
│ dockerd                            │
└───────┬────────┘
        │
        ├─ Image 관리
        ├─ Container 관리
        ├─ Network 관리
        └─ Volume 관리

구성 요소 역할
Docker Client 사용자의 명령(terminal 명령)을 Docker Daemon에 전달
Docker Daemon Image, Container, Network, Volume 등을 실제로 생성·관리

- dockered라는 Background Process로 실행되며 Docker의 실제 작업을 담당

대표적인 역할]
- Image Download
- Image 관리
- Container 생성
- Container 실행/중지/삭제
- Network생성
- Volumn 관리
Docker API Client와 Daemon이 통신하는 Interface
Docker Registry Image를 저장하고 제공하는 저장소

Daemon이 Container를 생성하려면 먼저 필요한 Image가 있어야 함. 
Local에 Image가 없다면 Registry에서 Image를 가져올 수 있다. 

대표적인 Public Registry = Docker Hub
: Docker Registry → Image Pull → Local Image → Container 생성

 


 

Docker 활용

 

상황 Docker를 사용하는 이유
팀 개발 환경 개발자별 환경 차이를 줄이기 위해
여러 Project 개발 Project별 Runtime / Dependency 분리를 위해
테스트 환경 동일한 환경을 반복해서 생성하기 위해
CI/CD Build와 Test 환경을 일관되게 구성하기 위해
배포 만들어진 Image를 기반으로 Application을 실행하기 위해
개발용 DB / Redis Host에 직접 설치하지 않고 필요한 서비스만 실행하기 위해

 


 

Docker 사용 시 알아둘 점

 

실제 사용할 때는 데이터 저장, Network, 보안, Image 관리 등을 함께 고려해야 함. 

 

Container 내부 데이터는 영구 저장을 보장하지 않음

Container에서 생성하거나 변경한 File은 기본적으로 Container의 Writable Layer에 저장됨. 

Container가 삭제되면 이 Writeable Layter도 함께 제거된다. 

=> 따라서 MySQL같은 Database 데이터를 Container 내부에만 저장하는 것은 적절하지 않음. 

 

영구적으로 유지해야 하는 데이터는 Volumn 등의 별도 Storage를 사용해야 함. 

 

Container 간 통신 - Network 설정 필요

Docker Compose를 사용할 경우 기본적으로 Project Network가 만들어지고

같은 Network에 속한 Service끼리는 Service Name을 이용해 통신할 수 있다. 

 

Image Version 관리 필요

최신 Version을 가르키는 Tag에 의존하기보다, 

Project에서 사용하는 Image Version을 명확하게 지정하는 것이 환경 재현에 유리함. 

 

Container의 격리가 완전한 보안을 의미하지는 않음

Docker에서도 Container 권한, Docker Daemon 접근, Linux Capability, seccomp 등 여러 보안 요소를 함께 고려해야 함. 

 

Docker도 기본적으로 Container의 Capability를 제한하고 seccomp Profile등을 이용해 사용할 수 있는 System Call을 제한

특히, 필요 이상으로 높은 권한을 부여하는 설정은 주의 

 


 

Container 실행과 Lifecycle

 

Lifecycle

Container가 종료되는 기준

Container는 단순히 Docker가 켜져 있으닌까 계속 실행되는 것이 아님

Container 내부의 Main Process가 실행되고 있는 동안 Container도 Running 상태를 유지함. 

 

Dockerfile의 CMD, ENTRY POINT

=> 해당 하는 Process가 종료되면, Container도 종료될 수 있음 

 

Lifecycle 관련 명령어

실제로 Image로 만든 Container가 어떤 상태를 거치고, 어떤 명령으로 관리되는지

Image
  │
  │ docker create
  ▼
Created
  │
  │ docker start
  ▼
Running
  │
  ├─ docker stop
  │      ↓
  │    Exited
  │      │
  │      ├─ docker start → Running
  │      │
  │      └─ docker rm → 삭제
  │
  └─ docker restart
         ↓
      Running

명령어 설명
docker create Image를 기반으로 Container를 생성하지만 바로 실행하지는 않음
docker start 이미 생성되어 있는 Container를 실행함

※ 새 Container를 만드는 것이 아니라 기존 Container를 다시 실행함. 
docker run Image를 기반으로 새 Container를 생성하고 바로 실행함. 
docker stop 실행 중인 Container를 정상적으로 종료할 때 사용  
docker resetart Container를 중지한 뒤 다시 실행함
docker rm 더 이상 필요하지 않은 Container 삭제 

 

확인

docker ps -a
# docker ps : 현재 실행중인 Container
# docker ps -a : 실행 중 + 종료된 Container 전체 

# 결과
CONTAINER ID   IMAGE   COMMAND      STATUS          PORTS                  NAMES
a12bc34        nginx   "nginx..."   Up 5 minutes    0.0.0.0:8080->80/tcp   web
b56de78        mysql   "docker..."  Exited (0)                             mysql

 

항목 의미
CONTAINER ID Container를 식별하는 ID
IMAGE Container 생성에 사용된 Image
COMMAND Container에서 실행되는 Command
STATUS 현재 Container 상태 및 실행 시간
PORTS Host와 Container의 Port 연결 정보
NAMES Container 이름

 

 


 

Container 상태 확인 이후 실제로 내부 상태 점검방법

 

로그확인 → 상세 정보 확인 → 내부 접근

 

로그확인

# Container Log 전체 확인
docker logs web-server

# Log를 실시간으로 계속 확인
docker logs -f web-server

# 마지막 100줄만 확인
docker logs --tail 100 web-serve

 

상세 정보 확인

docker inspect web-server
# json 형태로 출력

 

확인 할 수 있는 정보 ] 

Container 상태, IP Address, Network 설정, Port Mapping, Mount 정보, 환경 변수, Image 정보, Restart 설정 

 

실행 중인 Container 내부에서 Command 실행

docker exec web-server ls

# container 내부 shell 접근 => -it 옵션
docker exec -it web-server bash 
# bash 없으면 sh

 

Container을 새로 만드는 게 아니라 이미 Running 상태인 Container에 추가 Command를 실행

 

'STUDY > Docker' 카테고리의 다른 글

Docker 명령어 모음  (0) 2026.08.26
Dockerfile  (0) 2026.08.26
Docker Volumn과 데이터 영속성  (0) 2026.08.26
Docker Container의 Port와 Network 통신 구조  (0) 2026.08.26
Docker Image  (0) 2026.08.26