Docker 컨테이너 운영: 자원 제한, 보안, 로그, 장애 진단

컨테이너는 호스트 커널을 공유하는 프로세스다. 그래서 운영의 핵심 질문은 한 컨테이너가 이웃과 호스트에 얼마나 영향을 줄 수 있나(자원, 보안)와 문제가 났을 때 무엇을 보나(로그, 지표, 상태)다. 컨테이너를 격리하는 커널 기능(네임스페이스, cgroups)의 개요는 가상화와 하이퍼바이저에 있다.

자원 제한: cgroups

cgroups(control groups)는 프로세스 묶음이 쓰는 CPU·메모리·I/O·프로세스 수를 제한하고 측정하는 리눅스 커널 기능이다. 네임스페이스가 「무엇이 보이나」를 격리한다면 cgroups는 「얼마나 쓸 수 있나」를 제한한다. Docker는 컨테이너마다 cgroup을 만들고, 실행 옵션을 그 cgroup의 값(cgroup v2의 cpu.max, memory.max, io.max, pids.max)으로 옮긴다. 아무 옵션도 주지 않으면 제한이 없어 컨테이너 하나가 호스트 자원을 모두 쓸 수 있다.

docker run -d --name api \
  --cpus=1.5 \
  --memory=512m --memory-swap=512m \
  --pids-limit=256 \
  --device-write-bps /dev/nvme0n1:50mb \
  myapi:1.0

CPU

메모리와 OOM

메모리 상한을 넘으면 OOM killer가 cgroup 안에서 가장 큰 프로세스를 SIGKILL로 죽인다. 그것이 PID 1이면 컨테이너가 종료 코드 137로 끝나고 docker inspect의 State.OOMKilled가 true가 된다. 자식 프로세스만 죽으면 컨테이너는 살아 있고 일부 기능만 사라질 수 있다. JVM·Node.js처럼 힙 크기를 따로 정하는 런타임은 컨테이너 한도를 인식하게 하고(JVM의 -XX:MaxRAMPercentage), 힙 밖 메모리까지 고려해 한도를 잡는다.

I/O와 PID

포크 폭탄(:(){ :|:& };:처럼 자신을 끝없이 복제하는 프로세스)은 호스트의 PID를 고갈시켜 다른 컨테이너와 호스트까지 새 프로세스를 만들지 못하게 한다. --pids-limit을 두면 한도에서 fork가 실패하고 피해가 그 컨테이너에 그친다. --ulimit nproc은 호스트 전체에서 같은 UID의 프로세스를 세므로 컨테이너별 제한으로는 부정확하다.

CPU 스로틀링: 호스트가 한가한데 느린 이유

--cpus(쿠버네티스의 CPU limits)는 「코어 몇 개」가 아니라 주기마다 쓸 수 있는 CPU 시간이다. --cpus=1인 컨테이너에서 스레드 4개가 동시에 돌면 100ms 쿼터를 25ms 만에 다 쓰고, 나머지 75ms는 호스트 CPU가 놀고 있어도 멈춘다. 평균 CPU 사용률은 낮아 보이는데 응답 지연의 꼬리(p99)가 튄다.

cat /sys/fs/cgroup/cpu.stat          # 컨테이너 안에서 (cgroup v2)
# nr_periods 12000
# nr_throttled 3100                  ← 스로틀링된 주기 수
# throttled_usec 98000000            ← 멈춰 있던 총 시간

nr_throttled / nr_periods 비율이 높으면 스로틀링이 지연의 원인이다. 쿠버네티스에서는 container_cpu_cfs_throttled_periods_total 지표로 본다. 해결은 상한을 올리거나 없애고(경합 보호는 shares·requests로), 런타임의 스레드 수를 컨테이너 한도에 맞추는 것이다. Go는 1.25부터 GOMAXPROCS가 cgroup CPU 상한을 반영하고, JVM은 컨테이너 한도를 보고 GC·스레드 풀 크기를 정한다.

실시간 모니터링: docker stats

docker stats                          # 실행 중인 컨테이너 전체, 계속 갱신
docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.PIDs}}"

docker stats는 지금 값만 보여 준다. 추세와 알림은 아래 「지표 수집」의 도구가 맡는다.

보안

컨테이너의 위험 요소

컨테이너는 커널을 공유하므로 격리의 강도는 커널과 설정에 달려 있다. 같은 호스트의 컨테이너가 서로 간섭하는 길과 막는 방법을 정리하면 다음과 같다.

비root 실행

컨테이너 안 프로세스는 기본으로 root(UID 0)로 돈다. 사용자 네임스페이스를 쓰지 않으면 컨테이너 안 UID 0은 호스트의 UID 0과 같다. capability가 줄어 있어 바로 호스트를 장악하지는 못하지만, 런타임·커널 취약점으로 탈출하거나 실수로 호스트 경로가 마운트되면 호스트 root 권한으로 이어진다. 바인드 마운트에 쓴 파일도 root 소유가 된다.

• Dockerfile에서 USER 10001처럼 숫자 UID로 비root 사용자를 지정한다(Dockerfile 작성과 컨테이너의 PID 1). 실행 시 --user 10001:10001로도 덮을 수 있다.
• 1024 미만 포트가 필요하면 root 대신 높은 포트를 쓰고 매핑하거나 NET_BIND_SERVICE만 준다.
• 쿠버네티스의 Restricted 파드 보안 기준은 비root 실행을 요구한다(쿠버네티스 보안).

rootless 모드

rootless 모드는 사용자 네임스페이스 안에서 데몬과 컨테이너를 모두 일반 사용자로 실행한다. 데몬·런타임 취약점이 터져도 호스트 root가 되지 않는 것이 핵심 이점이다. 대신 1024 미만 포트 바인드에 별도 설정이 필요하고, 네트워크가 사용자 공간 구현을 거쳐 조금 느리며, cgroup 자원 제한은 cgroup v2와 systemd 위임이 있어야 동작한다. Podman은 처음부터 rootless를 기본으로 설계됐다.

capability, seccomp, LSM

리눅스는 root 권한을 40여 개의 capability로 쪼갠다. Docker는 기본으로 소수만 남긴다(CHOWN, NET_BIND_SERVICE, SETUID, KILL 등).

docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE \
  --security-opt no-new-privileges \
  --read-only --tmpfs /tmp \
  myapi:1.0

--privileged는 이 모든 제한을 풀고 호스트 장치까지 연다. 커널 접근 제어의 개념은 리눅스 접근 제어에 있다.

Docker 소켓 마운트의 위험

-v /var/run/docker.sock:/var/run/docker.sock은 컨테이너에 Docker API 전체를 준다. 그 컨테이너는 docker run --privileged -v /:/host로 호스트 루트 파일 시스템을 마운트한 새 컨테이너를 띄울 수 있으므로, 소켓 접근은 호스트 root 권한과 같다. 소켓을 :ro로 마운트해도 API 호출은 막히지 않는다. 같은 이유로 docker 그룹에 사용자를 넣는 것도 root를 주는 것이다.

데몬 API 노출

Docker 데몬(dockerd)은 root로 돌고, 데몬 API를 부를 수 있으면 호스트 root와 같다. 그래서 API는 기본값인 유닉스 소켓(/var/run/docker.sock)으로만 열고, 신뢰하는 사용자만 접근하게 한다.

같은 이유로 Docker 호스트에는 데몬과 컨테이너 외의 관리 도구·서비스를 되도록 올리지 않는다. 호스트에서 도는 것이 많을수록 데몬까지 닿는 길이 늘어난다.

Docker in Docker

Docker in Docker(DinD)는 컨테이너 안에서 또 하나의 Docker 데몬을 돌리는 것이다. 공식 docker:dind 이미지가 있어 CI에서 격리된 Docker 환경이 필요할 때 쓴다. 가상화와 달리 바깥 컨테이너와 안쪽 컨테이너가 같은 호스트 커널을 쓰므로 「Docker 위의 Docker」는 가능하지만 대가가 있다.

이미지 빌드가 목적이면 데몬 없이 빌드하는 도구가 더 안전하다. 진짜로 컨테이너를 중첩해야 하면 Sysbox처럼 특권 없이 중첩을 지원하는 런타임을 쓴다. CI에서의 쓰임은 CI/CD에 있다.

비밀 값 전달

앱은 환경 변수 대신 파일(DB_PASSWORD_FILE=/run/secrets/db_password)에서 읽게 만드는 것이 좋다. 비밀 관리 원칙은 DevSecOps에 있다.

이미지 공급망: 베이스 선택, 스캔, 서명

이미지 서명은 이미지가 정해진 빌드 파이프라인에서 나왔고 그 뒤로 바뀌지 않았음을 보장한다. 레지스트리가 뚫리거나 태그가 다른 이미지로 바뀌어도 서명 검증에서 걸린다. Docker의 옛 서명 기능 Docker Content Trust(DOCKER_CONTENT_TRUST=1, Notary v1 기반)는 2025년부터 폐기 절차에 들어갔고, 서명은 Cosign·Notation으로 옮겨 가고 있다. CI에서 스캔을 거는 방법은 CI/CD에 있다. 과거에는 Docker Cloud의 Docker Security Scanning이 레지스트리에 올린 이미지를 층별로 스캔했고, 그 역할은 Docker Scout로 넘어갔다.

호스트·설정 점검: CIS Docker Benchmark

CIS Docker Benchmark는 호스트 설정, 데몬 설정, 데몬 파일 권한, 이미지·빌드, 컨테이너 런타임, 운영 절차에 걸친 보안 권고를 항목별로 정리한 기준이다. 오픈소스 스크립트 docker-bench-security가 이 항목을 호스트에서 자동 점검해 PASS·WARN으로 보여 준다.

git clone https://github.com/docker/docker-bench-security.git
cd docker-bench-security && sudo sh docker-bench-security.sh

경고가 나오는 대표 항목은 TLS 없는 TCP 소켓, 비root가 아닌 컨테이너, --privileged, 자원 제한 없음, 호스트 네트워크·PID 네임스페이스 공유, 헬스체크 없음 같은 것으로, 이 노트의 위 항목들과 겹친다. 쿠버네티스는 같은 기관의 CIS Kubernetes Benchmark와 kube-bench가 대응한다.

로그

로깅 드라이버

컨테이너의 stdout·stderr는 로깅 드라이버가 받아 저장하거나 보낸다.

원격 드라이버를 써도 Docker가 로컬 캐시를 함께 남겨(dual logging) docker logs로 볼 수 있다. 드라이버가 느릴 때 앱이 로그 쓰기에서 막히지 않게 mode: non-blocking과 버퍼 크기를 줄 수 있다(버퍼가 차면 로그를 버린다).

중앙 수집은 두 길이 있다. 로깅 드라이버로 컨테이너마다 수집기에 바로 보내거나(--log-driver fluentd --log-opt fluentd-address=...), 노드마다 수집 에이전트(Fluent Bit, Vector, OpenTelemetry Collector)를 하나 띄워 /var/lib/docker/containers/*/*-json.log를 읽게 한다. 후자는 파일 이름의 컨테이너 ID로 태그를 붙이고 컨테이너 메타데이터를 덧붙인다. 파일에만 로그를 쓰는 앱(예: nginx의 /var/log/nginx)은 stdout·stderr로 심볼릭 링크를 걸거나(공식 nginx 이미지 방식), 로그 디렉터리를 볼륨으로 빼서 에이전트가 읽게 한다. 과거에는 로깅 드라이버가 없어(1.6에서 도입) 호스트의 logrotate(copytruncate)로 JSON 로그 파일을 잘랐다.

docker logs -f --tail 100 --since 30m -t api    # 따라가기, 마지막 100줄, 30분 전부터, 시각 표시

로그 회전과 디스크 포화 예방

기본 json-file은 회전하지 않아 오래 도는 컨테이너의 로그가 /var/lib/docker/containers/<id>/<id>-json.log에 무한히 쌓인다. 디스크가 차면 그 호스트의 모든 컨테이너와 데몬이 쓰기 실패로 멈춘다.

// /etc/docker/daemon.json: 이후 새로 만드는 컨테이너에 적용
{
  "log-driver": "local",
  "log-opts": { "max-size": "20m", "max-file": "5" }
}

docker run --log-opt max-size=10m --log-opt max-file=3 myapi:1.0   # 컨테이너별 지정

지표 수집과 이벤트

cAdvisor는 cgroup 통계를 읽어야 하므로 호스트 경로를 읽기 전용으로 마운트해 띄운다.

docker run -d --name cadvisor -p 8080:8080 \
  -v /:/rootfs:ro -v /var/run:/var/run:ro -v /sys:/sys:ro -v /var/lib/docker/:/var/lib/docker:ro \
  ghcr.io/google/cadvisor   # v0.53.0 이전 버전은 gcr.io/cadvisor/cadvisor

쿠버네티스에서는 kubelet에 cAdvisor가 들어 있어 따로 띄우지 않는다. 컨테이너 모니터링이 갖춰야 할 것은 정량 지표(CPU·메모리·I/O), 생명주기 이벤트(시작·종료·OOM), 임계치 알림의 세 가지다.

Prometheus가 이 대상들을 주기적으로 긁어 와 저장하고, Grafana로 대시보드를 만들고, Alertmanager로 「메모리가 한도의 90%」, 「재시작 반복」 같은 알림을 보낸다. 수집 구조는 관측 가능성에 있다.

docker events --since 1h --filter type=container --filter event=die --filter event=oom
docker events --format '{{.Time}} {{.Actor.Attributes.name}} {{.Action}}'

docker events는 데몬에서 일어나는 일(컨테이너 create·start·die·kill·oom·health_status, 이미지 pull, 네트워크·볼륨 변경)을 실시간으로 흘려 준다. OOM으로 죽은 시점 찾기, 재시작이 잦은 컨테이너 탐지, 누가 언제 컨테이너를 지웠나 같은 감사, 이벤트를 받아 알림·자동화를 거는 데 쓴다.

장애 진단

컨테이너가 시작되지 않을 때

docker ps -a --filter name=api                 # STATUS: Exited (1) 3 seconds ago
docker logs api                                # 앱이 남긴 마지막 말
docker inspect -f '{{.State.ExitCode}} {{.State.Error}} {{.State.OOMKilled}}' api
docker run -it --rm --entrypoint sh myapi:1.0  # 시작 명령을 셸로 바꿔 안을 살펴보기

종료 코드 읽기

137이 항상 OOM은 아니다. 137은 「SIGKILL로 죽었다」는 뜻일 뿐이다.

재시작 정책

재시작 사이에는 100ms부터 두 배씩 늘어나는 지연이 있고, 컨테이너가 10초 이상 돌아야 정책이 적용되기 시작한다. 재시작 정책은 한 호스트 안의 자동 복구일 뿐이라, 호스트가 죽으면 다른 호스트로 옮겨 주지 않는다. 그 일은 오케스트레이터가 한다.

실행 중인 컨테이너 들여다보기

docker exec -it api sh                     # 셸로 들어가기 (-u root, -e KEY=V, -w /dir 가능)
docker exec api env                        # 명령 하나만 실행
docker diff api                            # 이미지 대비 쓰기 층 변경: A 추가, C 변경, D 삭제
docker cp api:/app/logs/error.log ./       # 컨테이너 → 호스트 (멈춘 컨테이너에서도 된다)
docker cp ./fix.conf api:/etc/app/         # 호스트 → 컨테이너 (임시 확인용. 고친 것은 이미지에 반영)
docker top api                             # 컨테이너 안 프로세스 목록

• docker diff로 예상 밖의 파일 생성(침입 흔적, 컨테이너 안에 쌓이는 로그·캐시)을 찾는다.
• 셸이 없는 distroless 이미지는 도구 컨테이너를 같은 네임스페이스에 붙인다: docker run -it --rm --pid container:api --network container:api nicolaka/netshoot.
• exec로 고친 내용은 컨테이너를 다시 만들면 사라진다. 원인을 찾으면 Dockerfile이나 설정에 반영한다.

컨테이너에 SSH를 넣지 않는다

백업, 로그 보기, 재시작, 설정 변경, strace·gdb 디버깅은 모두 컨테이너 밖에서 할 수 있다. 컨테이너에 sshd를 넣으면 생기는 문제가 더 크다.

대신 docker exec(1.3에서 도입. 그 전에는 nsenter --target <PID> --mount --uts --ipc --net --pid로 네임스페이스에 들어갔다), 쿠버네티스의 kubectl exec·kubectl debug를 쓴다. 일회성 작업(DB 마이그레이션)은 같은 이미지로 docker run --rm ... bin/rake db:migrate처럼 별도 컨테이너를 띄운다(12요소 앱의 관리 프로세스). 컨테이너 자체가 SSH 서버인 경우만 예외다. 원칙은 「컨테이너 하나에 관심사 하나」다. 여러 프로세스가 꼭 필요하면 tini 같은 init을 PID 1로 두고(Dockerfile), 보조 기능은 사이드카 컨테이너로 나눈다.

디스크 정리

docker system df                           # 이미지·컨테이너·볼륨·빌드 캐시가 차지하는 공간
docker system prune                        # 멈춘 컨테이너, 안 쓰는 네트워크, 댕글링 이미지, 빌드 캐시
docker system prune -a --filter until=168h # 컨테이너가 쓰지 않는 모든 이미지까지 (일주일 이상 된 것)
docker system prune --volumes              # 안 쓰는 익명 볼륨까지
docker image prune; docker builder prune   # 항목별로

-a를 주면 다음 배포 때 이미지를 다시 받아야 하고, --volumes는 데이터를 지울 수 있으므로 운영 서버에서는 대상을 확인하고 쓴다. 댕글링 이미지는 Dockerfile 노트의 「이미지 관리」에 있다.

정리

• cgroups 옵션이 없으면 제한도 없다. CPU 상한은 스로틀링, 메모리 상한은 OOM kill(137)로 강제되고, --pids-limit이 포크 폭탄을 가둔다.
• 호스트가 한가해도 CFS 쿼터 때문에 스로틀링될 수 있다. cpu.stat의 nr_throttled로 확인한다.
• 커널을 공유하므로 비root·rootless, capability 축소, seccomp·LSM, 네트워크 분리로 격리를 보강한다. Docker 소켓 마운트와 --privileged는 호스트 root를 주는 것과 같다.
• 비밀은 이미지와 ENV에 넣지 않는다. 이미지는 스캔하고 Cosign 등으로 서명·검증한다.
• 기본 json-file 로그는 회전하지 않는다. 데몬 기본값에 회전을 두고 중앙으로 보낸다.
• 137은 SIGKILL일 뿐이다. OOMKilled, docker events, 커널 로그로 실제 원인을 가린다.

관련 노트: Dockerfile 작성과 컨테이너의 PID 1, Docker 네트워크와 볼륨, Docker Compose: 여러 컨테이너 묶어 띄우기, VM과 컨테이너, 가상화와 하이퍼바이저, 쿠버네티스 보안, DevSecOps, 서버 장애 진단 패턴