직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 전체 글195 systemd start-limit-hit 해결: 최초 실패를 고친 뒤 reset-failed로 복구 start-limit-hit나 Start request repeated too quickly가 보이면 먼저 제한에 도달하기 전의 최초 실패 로그를 찾으세요. reset-failed는 실패 상태와 시작 제한 카운터를 정리하지만 프로그램의 오류를 수정하지 않습니다. 원인을 고친 다음 대상 서비스만 재개하고 재발 여부를 확인해야 합니다.원인: 마지막 메시지는 시작을 막은 결과일 수 있다서비스가 짧은 시간에 여러 번 시작되면 systemd의 시작 횟수 제한에 걸릴 수 있습니다. 자동 재시작뿐 아니라 수동 시작도 해당 제한과 관계되므로 같은 start 명령을 연속 실행해 해결하려고 하면 진단이 더 어려워집니다. 마지막 제한 메시지 앞에 설정 누락, 실행 파일 오류, 의존 대상 접근 실패 같은 실제 원인이 있는지 .. 2026. 10. 18. Docker invalid reference format 해결: 이미지 이름과 셸 인수를 구분해 점검 invalid reference format은 먼저 Docker가 IMAGE 인수로 무엇을 받았는지 확인해야 하는 오류입니다. 저장소 이름 문법이 틀렸을 수도 있지만, 따옴표가 빠진 경로나 빈 변수 때문에 다른 문자열이 이미지로 해석될 수도 있습니다. 이미지 전체를 무조건 소문자로 바꾸거나 다시 빌드하기 전에 인수 경계를 확인하세요.원인: 이미지 참조의 문법 오류와 인수 위치 오류가 같은 메시지로 보일 수 있다docker run은 옵션 다음에 이미지 인수를 받고 그 뒤에 컨테이너 명령과 인수를 받습니다. 옵션 값이 공백에서 잘리면 예상하지 않은 조각이 IMAGE 자리에 놓일 수 있습니다. 이 단계에서 실패했다면 애플리케이션 로그나 컨테이너 네트워크부터 수정하는 것은 원인과 맞지 않을 수 있습니다.관찰먼저.. 2026. 10. 18. S3 Replication과 AWS Backup 비교: 복제본과 과거 시점 복구를 구분하기 다른 버킷에 객체를 전달하는 경로가 필요하면 S3 Replication을, 보존 정책과 복구 시점 중심의 운영이 필요하면 AWS Backup을 비교하세요. 복제 설정이 있다고 과거의 정상 상태를 원하는 시점으로 되돌릴 수 있는 것은 아닙니다. 삭제 전파·버전·복원 대상까지 실제로 확인해야 합니다.혼동의 원인: 사본이 있는 것과 정상 시점으로 돌아가는 것은 다르다운영자는 보통 “한 곳이 고장 나도 데이터를 읽을 수 있어야 한다”와 “잘못 수정하기 전 상태로 돌아가야 한다”를 동시에 원합니다. 앞의 요구는 사본의 위치·전달 지연과 관련되고, 뒤의 요구는 보존 기간과 복구 시점·버전 선택에 관련됩니다. 두 요구를 한 문장으로 묶으면 복제 완료 표시만 보고 복구 계획도 끝났다고 판단하기 쉽습니다.목적우선 확인성.. 2026. 10. 18. ALB와 NLB 선택: HTTP 경로 분기·고정 IP·TLS 종료 위치부터 확인 호스트·URL 경로에 따라 웹 요청을 나누려면 ALB를, TCP 연결이나 가용 영역별 고정 IP 요구가 중심이면 NLB를 먼저 검토하세요. 둘 다 TLS와 관련된 구성이 가능하므로 “HTTPS면 ALB, 나머지는 NLB”만으로 결정하지 말고 인증서가 어디에서 끝나야 하는지까지 적어야 합니다.선택을 헷갈리게 하는 원인: 연결 조건과 HTTP 조건을 섞는 것클라이언트가 요구하는 주소·포트와 애플리케이션이 요구하는 라우팅은 다른 항목입니다. 같은 443 포트를 사용하더라도 암호화된 연결을 서버까지 전달해야 하는 서비스와, 중간에서 HTTP 요청을 읽어 여러 API로 나눠야 하는 서비스의 설계는 달라집니다. 제품 이름을 먼저 정하면 인증서 관리와 방화벽 허용 목록을 뒤늦게 바꾸게 될 수 있습니다.요구우선 검토확.. 2026. 10. 18. SSH Too many authentication failures 해결: agent 키·IdentitiesOnly·실제 설정 확인 올바른 키가 있는데 Too many authentication failures로 연결이 끊기면, 먼저 ssh-agent가 제공하는 키 목록과 클라이언트의 실제 IdentityFile 설정을 확인하세요. 필요한 호스트에 IdentitiesOnly yes와 맞는 키를 지정하는 것이 출발점입니다. 이 오류를 해결하려고 서버의 인증 제한을 무조건 높이거나 호스트 키 검증을 끄지 않습니다.원인: 목적지 키에 도달하기 전에 다른 인증 후보가 시도될 수 있다ssh-agent에는 여러 서비스용 키가 등록될 수 있습니다. 클라이언트 설정·에이전트가 제시하는 후보와 서버의 접속당 인증 제한이 만나면 원하는 키로 인증하기 전에 연결이 종료될 수 있습니다. 다만 모든 동일 문구가 agent 때문이라고 단정하지 말고 실제 로그.. 2026. 10. 17. Docker COPY checksum not found 해결: 빌드 컨텍스트·dockerignore·스테이지 확인 COPY 단계의 failed to calculate checksum 또는 not found 오류는 먼저 빌더가 해당 소스 파일을 볼 수 있는지 확인해야 합니다. docker build의 마지막 경로인 컨텍스트, 그 안의 .dockerignore, COPY --from의 스테이지를 순서대로 대조하세요. Dockerfile이 있는 폴더와 COPY의 기준 폴더가 항상 같은 것은 아닙니다.원인 구분: 파일이 없음·범위 밖·제외됨·다른 스테이지이 글은 로컬 파일을 쓰는 Linux 컨테이너 빌드와 Compose V2를 기준으로 합니다. 예를 들어 저장소에 dist가 있어도 빌드 컨텍스트가 다른 폴더거나 ignore 패턴으로 제외되면 COPY 소스로 전달되지 않습니다. 로그에 checksum이라는 단어가 있다고 곧바.. 2026. 10. 17. 이전 1 2 3 4 ··· 33 다음
