개발 환경에서 운영 환경으로, 사고를 확장하는 가장 빠른 방법

docker-compose.yml로 nginx + 앱 컨테이너를 함께 정의하고, 서비스 간 통신과 볼륨 마운트를 구성한다.

Docker Compose로 nginx + 백엔드 컨테이너를 띄우고 nginx.conf를 직접 작성해 리버스 프록시를 구성한다. verify.sh로 라우팅이 실제로 동작하는지 자동 검증한다.

배포 직후 React 앱이 백엔드 API를 못 찾고 있다. 두 컨테이너가 같은 서버에서 돌고 있는데 왜 통신이 안 될까? docker network를 해부하고 직접 연결 복구까지 마친다.

CI 빌드가 12분 걸리고 ECR 이미지가 1.2GB인 Node.js 앱을 해부한다. .dockerignore, 멀티스테이지 빌드, 레이어 캐시 최적화 3가지를 직접 적용해 200MB 이하로 줄이는 과정을 완주한다.

오픈소스 레퍼런스(docker/awesome-compose) 기반으로 Web·App·Data 3계층을 Docker Compose로 직접 설계하고 배선한다. 네트워크 격리, 헬스체크, 볼륨 영속성까지 프로덕션 패턴 그대로.

bridge, host, 커스텀 bridge 네트워크를 직접 생성하고 비교해 컨테이너 격리 vs 성능 트레이드오프와 드라이버 선택 기준을 이해한다.

컨테이너를 재생성했더니 데이터가 사라졌다. 컨테이너의 쓰기 레이어는 휘발성이고, 데이터를 지키려면 볼륨이 필요하다. named volume·bind mount·anonymous volume의 차이와 함정(익명 볼륨 누적, 마운트 경로 불일치, 바인드 권한)을 가르고, 데이터가 컨테이너 재생성에도 살아남도록 설계·검증한다.

"docker ps는 Up인데 503"의 정체는 "프로세스 생존 ≠ 서비스 정상"이다. HEALTHCHECK로 실제 서비스 상태를 판별하고, restart 정책으로 죽은 컨테이너를 자동 복구하며, compose의 depends_on condition으로 의존 서비스 준비를 기다린다. 얕은 헬스체크와 무한 재시작 폭주의 함정도 다룬다.

도커 호스트 디스크가 꽉 찼는데 큰 파일이 안 보인다. 범인은 보통 컨테이너의 json-file 로그가 무제한 쌓인 것이다. 로그가 어디 쌓이는지 찾고, 즉시 공간을 확보하고, 로그 드라이버에 회전(max-size/max-file)을 걸어 재발을 구조적으로 막는다.

자원 제한 없는 컨테이너가 호스트 메모리를 독식해 이웃을 죽인다. 컨테이너별 메모리/CPU 제한(--memory, --cpus)을 걸어 격리하고, OOMKilled(exit 137)를 cgroup·docker stats로 진단하고, 제한과 앱 실제 사용량의 균형을 잡는다. 제한이 너무 낮아 정상 앱이 OOM되는 함정도 다룬다.