본문 바로가기

docker10

Nginx 413 Request Entity Too Large 해결: 업로드 용량·프록시·Docker 점검 작은 파일은 올라가는데 큰 파일만 413 Request Entity Too Large로 실패한다면 요청 경로 어딘가의 본문 크기 제한을 넘은 것입니다. Nginx의 client_max_body_size가 대표 원인이지만 CDN, 로드밸런서, 두 번째 프록시, 애플리케이션 프레임워크에도 별도 제한이 있을 수 있습니다. 제한을 무작정 크게 만들기 전에 오류를 반환한 계층을 찾는 것이 먼저입니다.1. 실패 파일 크기와 413을 반환한 계층을 확인한다같은 형식의 작은 파일과 큰 파일을 각각 전송해 임계값을 좁히세요. 브라우저 개발자 도구의 응답 헤더, Nginx 접근·오류 로그, 애플리케이션 로그의 요청 도달 여부를 비교하면 어느 계층에서 차단됐는지 알 수 있습니다. 애플리케이션 로그에 요청이 없다면 앞단 프록.. 2026. 9. 23.
Docker 컨테이너가 Restarting을 반복할 때: exit code·로그·재시작 정책 점검 docker ps에서 컨테이너 상태가 Restarting으로 반복되면 애플리케이션이 종료되고 재시작 정책이 다시 실행하는 상황일 가능성이 큽니다. 무작정 restart를 반복하면 최초 오류가 로그에서 밀려 원인 파악이 더 어려워집니다. 종료 코드, 로그, 설정, 의존 서비스, 재시작 정책 순서로 확인하면 진단 시간을 줄일 수 있습니다.1. 재시작 횟수와 마지막 종료 상태를 먼저 기록한다컨테이너 이름을 확인한 뒤 상태, 종료 코드, OOM 여부, 시작·종료 시각, 재시작 횟수를 한 번에 남기세요. 컨테이너가 잠깐 실행되는 사이에 exec로 들어가려 하기보다 docker inspect로 종료 상태를 읽는 편이 안정적입니다.docker ps -a --filter status=restartingdocker in.. 2026. 9. 23.
Nginx 502 Bad Gateway 해결: Docker upstream·포트·헬스체크 점검 Nginx의 502 Bad Gateway는 브라우저 요청을 받은 Nginx가 뒤쪽 애플리케이션(upstream)에서 정상 응답을 얻지 못했다는 뜻입니다. 설정을 무작정 바꾸기 전에 오류 로그, 애플리케이션 상태, Docker 네트워크, 포트, 시간 제한 순서로 좁혀야 복구 시간을 줄일 수 있습니다.1. Nginx 오류 로그 한 줄부터 분류한다sudo nginx -tsudo tail -n 100 /var/log/nginx/error.logNginx 공식 upstream 문서는 여러 백엔드 서버를 정의하고 실패 처리와 시간 제한을 구성하는 방법을 설명합니다. 로그의 connection refused는 주소나 포트에서 프로세스가 수신하지 않는 경우, host not found in upstream은 이름 해석.. 2026. 9. 22.
Docker no space left on device 해결: 이미지·로그·볼륨 안전 정리 순서 Docker 빌드나 컨테이너 재시작 중 no space left on device가 나오면 무작정 docker system prune -a부터 실행하기 쉽습니다. 그러나 미사용 볼륨이나 이미지에 복구에 필요한 데이터가 있을 수 있습니다. 파일시스템 용량, inode, Docker 사용량을 차례로 확인한 뒤 영향이 작은 항목부터 정리해야 합니다.1. 디스크 용량과 inode를 먼저 구분한다df -hdf -idocker system dfdf -h는 바이트 기준 여유 공간, df -i는 파일 개수 한도인 inode를 보여줍니다. 작은 로그 파일이 매우 많으면 용량이 남아도 inode 부족으로 같은 오류가 날 수 있습니다. docker system df에서는 이미지, 컨테이너, 로컬 볼륨, 빌드 캐시가 차지한 .. 2026. 9. 22.
Docker 로그 확인과 용량 관리: compose logs부터 로그 로테이션까지 서비스에 오류가 생겼을 때 로그를 열면 너무 많은 내용이 쏟아지고, 정작 필요한 시간의 기록은 찾기 어려울 수 있습니다. 반대로 로그가 계속 쌓여 서버 디스크를 차지하는 문제도 있습니다. 로그를 읽는 방법과 얼마나 보관할지는 함께 정해야 합니다.이번 글에서는 Docker Compose에서 서비스와 시간 범위를 좁혀 로그를 확인하는 방법, 로그 드라이버의 역할, json-file 로테이션 예시를 살펴봅니다. 헬스체크와 시작 순서 글에서 확인한 오류를 더 자세히 추적할 때 이어서 사용할 수 있는 내용입니다.1. Docker logs는 어떤 로그를 보여줄까?일반적으로 Docker가 수집하는 로그는 컨테이너 프로세스의 표준 출력(stdout)과 표준 오류(stderr)에서 나옵니다. json-file 드라이버는.. 2026. 9. 8.
Docker Compose .env와 env_file 차이: 환경변수가 적용되지 않을 때 확인할 것 .env 파일에 값을 적었는데 컨테이너 안에서는 보이지 않거나, 파일을 수정했는데 프로그램이 계속 이전 설정을 사용하는 경우가 있습니다. 파일 이름보다 중요한 것은 그 값이 “Compose 설정을 만드는 데 쓰이는지”, “컨테이너의 환경변수로 전달되는지”입니다.앞서 헬스체크와 시작 순서 글에서 변수로 DB 설정을 표현했습니다. 이번에는 민감한 정보 없이 APP_MODE, LOG_LEVEL 같은 가상 설정으로 값이 전달되는 경로를 살펴봅니다.1. .env에 적으면 자동으로 컨테이너에 들어갈까?기본 .env 파일은 Compose 파일의 변수 치환에 사용할 값을 제공하는 역할을 합니다. 예를 들어 image: "myapp:${TAG}"의 TAG 부분을 채우는 데 쓸 수 있습니다. .env에 있는 모든 항목이 .. 2026. 9. 8.