직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 docker25 Docker daemon socket permission denied 해결: 권한·context·rootless 점검 permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock가 보이면 이미지나 컨테이너 문제라고 단정하지 마세요. 먼저 현재 CLI가 어느 Docker 데몬에 연결하려는지, 소켓이 존재하는지, 현재 사용자에게 접근 권한이 있는지를 분리해서 확인해야 합니다. 특히 단순히 소켓 권한을 모두에게 열면 로컬 보안 경계가 무너질 수 있습니다.1. 오류가 말하는 것은 무엇인가Linux Docker Engine의 기본 접속 경로는 Unix 소켓입니다. Docker 데몬 문서는 기본 소켓이 루트 또는 허용된 그룹의 접근을 받는다고 설명합니다. 이 오류는 데몬이 멈췄을 때 나오는 “Cannot conn.. 2026. 9. 29. Docker x509 인증서 오류 해결: unknown authority·사내 CA·프록시 점검 순서 AI로 제작한 개념 일러스트입니다. TLS 오류는 인증서를 검증하는 실행 환경과 신뢰 체인을 나누어 확인합니다.Docker에서 x509: certificate signed by unknown authority 오류가 나타나면 비밀번호부터 바꾸기보다 어느 실행 주체가 TLS 인증서를 검증하지 못하는지 확인하세요. docker pull 단계의 데몬, Docker Desktop의 호스트 환경, 컨테이너 안의 프로그램은 인증서를 신뢰하는 위치가 다를 수 있습니다. 같은 주소가 브라우저에서 열린다는 사실만으로 Docker에서도 신뢰된다고 판단하기는 어렵습니다.1. 오류가 발생한 위치부터 구분하기이미지 다운로드가 실패했는지, 이미 실행된 컨테이너에서 사내 API 호출이 실패했는지 기록합니다. 첫 번째는 레지스트리와.. 2026. 9. 28. Nginx 504 Gateway Timeout 해결: upstream 응답·proxy_read_timeout·Docker 점검 실제 재현 노트: 1초 제한인데 2.4초 응답은 성공한 이유2026년 10월 12일 별도 로컬 Docker의 Nginx 1.30.4·Node.js 24.21.0(Linux arm64)에서 실제 HTTP 요청을 시험했습니다. 운영 장애나 성능 벤치마크가 아니라, 응답을 언제 보내는지 통제한 예제 앱과 Nginx의 동작을 비교한 실험입니다. TLS·CDN·로드밸런서·실제 DB는 포함하지 않았습니다.요청 경로와 응답 시점을 통제했습니다같은 내부 네트워크의 app:3000을 직접 호출하거나 Nginx를 거쳤습니다. /slow는 1500ms 후 처음 응답하고, /heartbeat는 헤더와 첫 조각을 즉시 보낸 뒤 600ms마다 네 조각을 더 보냅니다. /gap은 헤더·첫 조각을 보낸 뒤 1500ms 동안 다음 조.. 2026. 9. 24. Nginx 413 Request Entity Too Large 해결: 업로드 용량·프록시·Docker 점검 실제 전송 노트: 413이 Nginx에서 났는지 앱에서 났는지 확인했습니다2026년 10월 12일 별도 Docker의 Nginx 1.30.4·Node.js 24.21.0(Linux arm64)에 비민감 A 바이트로 만든 본문을 실제 전송했습니다. 아래 기존 인코딩 계산과는 별개인 HTTP 재현 시험입니다. 실제 고객 파일·영상·운영 서버는 사용하지 않았습니다.작은 시험 한도로 경계와 차단 계층을 분리했습니다Nginx 시험 서버 두 곳의 client_max_body_size를 각각 3k(3072바이트), 6k(6144바이트)로 정했습니다. 같은 앱은 요청 본문을 실제로 센 뒤 4096바이트 초과이면 413을 반환하게 작성했습니다. 앱의 4096바이트는 이번 예제의 정책이지 Node.js나 모든 프레임워크의.. 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·포트·헬스체크 점검 실제 재현 노트: 같은 502라도 고칠 위치가 달랐습니다2026년 10월 12일 별도의 로컬 Docker 시험에서 Nginx 1.30.4와 Node.js 24.21.0(Linux arm64)을 실행했습니다. 아래는 운영 장애 경험이 아니라, 비민감 예제 앱에 실제 HTTP 요청을 보내고 Nginx 오류·접근 로그와 앱 수신 로그를 대조한 결과입니다. 시험 네트워크는 외부 연결을 막았고 호스트 포트는 공개하지 않았습니다.주소만 바꾼 세 요청과 앱이 반환한 502앱은 별도 컨테이너의 0.0.0.0:3000에서 수신하도록 했습니다. Nginx의 연결 제한은 1초, 읽기 제한도 1초였으며 자동 다음 upstream 재시도는 껐습니다. 아래 세 proxy_pass는 실제 시험에 사용한 설정의 핵심 부분입니다.# .. 2026. 9. 22. 이전 1 2 3 4 5 다음
