Docker healthcheck·restart 정책 — "Up인데 죽은" 컨테이너 잡기 — 실습 Lab

INCIDENT RESPONSE

0 / 5 단계 완료

📚 PREREQUISITES

Labdocker-compose-multi-service

Theorydocker/healthcheck-restart

TRACK

DOCKER

SLA

40분

SEV

SEV-2

PHASES

3단계

ENV

local

INCOMING TICKET

“장애: "docker ps에는 Up이라고 나오는데 실제로는 503이 나요. 컨테이너가 살아있다는데 서비스는 죽어 있어요."”

YOUR ROLE

인프라/플랫폼 운영 엔지니어인 당신이

IMPACT IF UNRESOLVED

프로세스는 떠 있으나 실제 서비스 불능(좀비). 오케스트레이터·LB가 "정상"으로 오판해 죽은 컨테이너로 트래픽이 감.

🚨INCIDENT BRIEF

`docker ps`에는 컨테이너가 `Up 2 hours`로 멀쩡히 나옵니다. 그런데 사용자는 503을 받습니다.

"컨테이너가 살아있다는데 왜 서비스가 죽어 있죠?"

핵심은 "프로세스가 떠 있다 ≠ 서비스가 정상이다" 입니다. 앱이 데드락에 걸렸거나, DB 연결이 끊겼거나,

이벤트 루프가 멈춰도 프로세스(PID 1)는 살아 있어 docker는 Up으로 봅니다. 이 "좀비 Up"을 잡으려면

HEALTHCHECK로 실제 서비스 상태를 검사하고, restart 정책으로 죽은 걸 자동 복구해야 합니다.

⏱ 40분📊 중급🔧 3단계#docker#healthcheck#restart-policy#depends_on

MISSION

"Up인데 죽은" 상태 확인 — 프로세스 vs 서비스

docker ps의 Up과 실제 서비스 응답이 불일치하는지 확인하고, HEALTHCHECK 유무를 본다

HEALTHCHECK 정의 — 실제 서비스 상태 검사

프로세스가 아니라 실제 서비스(엔드포인트)를 검사하는 HEALTHCHECK를 정의한다

restart 정책 + depends_on으로 자동 복구

restart 정책으로 죽은 컨테이너를 자동 복구하고, depends_on condition으로 의존 준비를 기다린다

📌 선수 지식

ℹ️ 실습 환경

환경: local

필요 도구: docker, curl

🔒

실습 실행은 Pro 플랜 전용입니다

인시던트 브리프와 학습 자료는 지금 바로 확인할 수 있습니다. 실제 실습 진행 및 터미널 사용은 Pro 플랜에서 가능합니다.

>_ LAB TERMINAL↔ 너비 조절

NOTES