같은 Docker 이미지를 운영 환경과 테스트 환경에 배포했는데 설정값을 바꾸려면 이미지를 다시 만들어야 할까요? 답은 설정이 저장된 위치와 애플리케이션이 값을 읽는 시점에 따라 달라집니다. 이미지 안에 포함된 파일과 컨테이너 생성 시 외부에서 전달한 설정을 구분하면 변경 범위와 확인 순서를 정하기 쉽습니다.이미지에 복사한 설정은 이미지 버전의 일부입니다Dockerfile의 COPY로 설정 파일을 넣으면 빌드 당시 파일이 이미지에 포함됩니다. 이후 원본 파일을 수정해도 이미 만들어진 이미지나 실행 중인 컨테이너가 자동으로 바뀌지는 않습니다. 변경된 파일을 이미지에 반영하려면 이미지를 다시 빌드하고, 새 이미지로 컨테이너를 교체해야 합니다.이 방식은 애플리케이션과 기본 설정을 함께 버전 관리하기 쉽습니다...

호스트 디스크가 가득 찼다는 이유만으로 Docker 로그가 원인이라고 단정할 수는 없습니다. 이미지, 볼륨, 애플리케이션 파일도 공간을 사용합니다. 이 글은 Linux Docker Engine과 Compose V2에서 표준 출력·표준 오류로 내보낸 컨테이너 로그를 점검하는 상황을 다룹니다.현재 컨테이너의 로그 설정부터 확인합니다Docker는 이 출력을 로깅 드라이버로 처리합니다. 기본 json-file 드라이버는 별도 제한이 없으면 로그가 계속 커질 수 있습니다. 반면 애플리케이션이 /app/logs 같은 경로에 직접 쓰는 파일에는 이 설정이 적용되지 않으므로, 먼저 어떤 로그가 증가하는지 구분해야 합니다. [1]아래 명령에서 app은 실제 컨테이너 이름이나 ID로 바꿉니다. Docker 명령을 실행할 ..

게시판을 새 이미지로 배포한 뒤 글 목록은 남아 있는데 첨부파일만 열리지 않는 상황을 가정해 보겠습니다. 데이터베이스에는 파일 경로가 남았지만, 파일 자체는 교체한 컨테이너 안에만 있었을 수 있습니다. 다만 파일이 보이지 않는다는 사실만으로 삭제를 확정해서는 안 됩니다. 파일의 위치를 기존 컨테이너에 있는건 아닌지, 배포는 정상적으로 됐는지 확인해봐야 합니다. 이 글은 Linux 컨테이너와 Docker Engine을 기준으로 실제 업로드 경로와 저장소 연결을 대조하는 순서를 설명합니다.재시작과 재생성은 파일에 미치는 영향이 다릅니다이미지는 실행에 필요한 파일의 바탕이고, 실행 중 생성한 파일은 기본적으로 해당 컨테이너의 쓰기 가능 계층에 저장됩니다. 마운트하지 않은 경로에 업로드했다면 파일의 수명은 그..

서비스가 잠깐 실행됐다가 종료되고 다시 실행되는 상황에서는 재시작 횟수만 늘려도 같은 오류가 반복될 수 있습니다. 프로세스가 끝난 이유와 systemd가 다시 실행한 조건을 나누어 봐야 합니다. 이 글은 systemd를 사용하는 Linux의 시스템 서비스에서 종료 기록, 재시작 간격, 의존 서비스의 상태를 확인하는 순서를 설명합니다. 예시의 app.service는 실제 점검할 서비스 이름으로 바꿉니다.마지막 실패 표시보다 먼저 발생한 종료 기록 확인우선 현재 상태와 이번 부팅의 서비스 로그를 함께 확인합니다. systemctl status는 최근 메시지 일부만 보여 주므로, 반복이 시작된 시점의 기록은 journalctl로 더 넓게 읽습니다. 옵션 중 -b는 이번 부팅으로 범위를 좁히며, 로그 접근 권한..

2026년 10월 30일 인천공항에서 일부 항공사의 체크인과 탑승권 발급이 지연됐습니다. 이 사건을 ‘예약불가’라고만 부르면 신규 항공권 구매 문제와 공항 현장 수속 문제가 섞입니다.와... 이때 제가 만약 현장에 있었다면 여행자로써 많이 당황스러웠을 것 같네요.확인한 보도의 중심은 출국 당일 수속 장애이며, 이 글은 공개된 경과와 기업 IT 운영에 적용할 복구 확인 기준을 구분해 살펴봅니다.최초 통신 이상과 발급 중단은 시작 시점이 상이언론 10월 30일 보도에 따르면 오전 4시 30분부터 일부 항공사 발권 네트워크에서 문제가 발생했고, 두 터미널의 항공사 13곳에서 간헐적인 통신 끊김이 나타났습니다. 낮 12시부터는 외국 항공사 일부의 일반 탑승권 발급이 사실상 중단됐습니다.언론 후속 보도는 공사 설..

관리자 접속은 확인되는데 뒤따른 작업 기록이 비어 있다면, 조사자는 어디까지 판단할 수 있을까요. 최근 발표된 VMware ESX의 CVE-2026-41709는 관리자 권한으로 수행한 일부 작업이 기록되지 않을 수 있는 취약점입니다. 로그가 없다는 사실을 행위가 없었다는 증거로 삼기 어려운 이유입니다.2026년 10월 31일 기준으로 10월 24~31일의 공식 대응 동향을 살펴보고, 해당 호스트의 패치 판단과 감사 증거의 확인 범위를 정리합니다. 제품 공지의 ESX 표기와 호스트 수정 빌드의 ESXi 표기를 구분해 읽어야 합니다.이번 주의 변화는 최초 공개가 아닌 실제 악용 목록 등록입니다Broadcom 공지의 최초 공개일은 2026년 7월 29일입니다. 해당 CVE의 최대 CVSSv3 기본 점수는 2...

터미널에서는 정상 실행되는 집계 스크립트가 cron에 등록한 뒤 결과 파일을 만들지 않는다고 가정해 보겠습니다. 같은 파일을 실행해도 계정, 명령어 검색 경로, 작업 디렉터리와 환경변수가 다르면 결과가 달라질 수 있습니다. cron에 등록해놓고 실행되는 쉘이 어떤것인지 확인하지 않는다면 설정한 cron은 정상적으로 동작하지 않아 다음날 작업 확인시 운영자를 당황스럽게 할 수 있습니다. 이 글은 Linux의 Cronie 계열 사용자 crontab과 Bash 스크립트를 예시로, 대화형 실행과 예약 실행의 차이를 좁혀 가는 순서를 설명합니다.예약 실행이 시작됐는지와 실행 계정을 먼저 확인결과 파일이 없다는 사실만으로 스크립트가 실패했다고 단정할 수는 없습니다. cron의 예약 자체가 실행되지 않았는지, 실행 ..

logrotate 실행 뒤 새 로그 파일은 생겼는데 크기가 늘지 않는다면, 파일 생성만으로 순환이 끝났다고 판단하기 어렵습니다. 애플리케이션이 이전 파일에 계속 기록하는지, 새 파일을 열지 못했는지부터 확인하고, 그 다음 log rotate 설정을 점검합니다. 이 점검을 소홀히 한다면 기존 로그파일에 적재되어 초반의 로그는 사라질 수도 있습니다.이 글은 Linux에서 일반 파일에 직접 기록하는 애플리케이션을 대상으로 파일 교체와 로그 재열기 사이의 점검 순서를 설명합니다.파일 이름이 바뀌어도 열린 파일은 유지가정해 보겠습니다. app.log를 app.log.1로 이름 변경하고 같은 경로에 새 app.log를 만들었지만, 서비스는 기존 파일을 계속 열고 있습니다. 프로세스가 사용하는 파일 디스크립터는 열린..

파일을 저장하려는데 “No space left on device”가 나왔지만 디스크에는 여유가 남아 있습니다. 이때 큰 파일부터 지우면 원인을 놓칠 수 있습니다. 파일시스템에는 데이터를 담을 공간과 파일 정보를 관리할 자원이 따로 있기 때문입니다. 이 글은 GNU 도구를 사용하는 Linux 환경에서 두 자원을 구별하는 점검 순서를 설명합니다.파일시스템에서 빈 공간과 inode는 서로 다른 객체inode는 소유자·권한·시간 정보와 데이터 위치 등 파일의 메타데이터를 담는 구조입니다. 파일명은 디렉터리 항목에 기록되고 해당 inode와 연결됩니다. Linux 커널의 ext4 문서도 이 구분을 설명합니다.새 파일이나 디렉터리를 만들려면 이를 위한 inode가 필요합니다. 따라서 작은 파일이 대량으로 쌓이면 데..

큰 로그 파일을 삭제했는데도 디스크 사용률이 그대로라면, 같은 경로에서 파일을 다시 찾는 것만으로는 원인을 확인하기 어렵습니다. 파일명은 사라졌지만 프로세스가 파일을 계속 열고 있을 수 있기 때문입니다. 이때는 삭제 명령의 성공 여부와 저장 공간이 회수되는 조건을 나누어 살펴봐야 합니다.파일명 삭제와 공간 회수의 타임스탬프 차이Linux에서 파일을 삭제하는 동작은 디렉터리에 있는 이름과 파일의 연결을 제거하는 것입니다. 파일을 가리키는 마지막 하드 링크가 없어져도 프로세스가 해당 파일을 열고 있다면, 마지막 파일 디스크립터가 닫힐 때까지 파일이 유지됩니다. 파일 디스크립터는 프로세스가 열린 파일을 다루는 데 사용하는 참조 번호입니다. Linux unlink 매뉴얼이 이 조건을 설명합니다.회사에서 시스템 ..