Docker에서 root·777인데도 Read-only file system이 나는 이유
root이고 파일 모드가 777이어도 읽기 전용 bind mount에는 쓸 수 없다. Mounts.RW로 마운트 정책을 확인하고, ro/rw의 호스트 파일 변화와 Permission denied 대조를 통해 수정할 컨테이너 생성 설정을 찾는다.
빌드노트
Docker·컨테이너
Docker·컨테이너 카테고리의 글입니다.
글 검색
글 목록
총 47개의 글
-
-
Docker 이미지의 설정 파일이 안 보이면 bind mount부터 확인한다
이미지에 넣은 설정 파일이 컨테이너에서 안 보일 때 bind mount의 목적지부터 확인한다. 같은 이미지에서 마운트 없음, 빈 폴더의 설정 경로 마운트, 데이터 경로 마운트를 실제 비교하고 마운트 범위를 줄일 기준을 설명한다.
-
Docker 포트를 publish했는데 서버가 응답하지 않는다
호스트에 포트를 publish해도 서버가 컨테이너의 127.0.0.1에서만 들으면 요청을 받지 못한다. 같은 호스트 포트에서 bind 주소만 바꿔 비교하고, 포트 매핑과 실제 listen 주소를 구분하는 확인 방법을 설명한다.
-
컨테이너 파일에 로그가 있는데 docker logs는 비어 있다
앱의 로그 파일은 docker logs가 자동으로 읽는 대상이 아니다. 실제 컨테이너의 LogConfig·Docker 로그·앱 파일을 비교해 stdout·stderr로 보낼지 별도 파일 수집 경로를 사용할지 판단한다.
-
옆 컨테이너가 떠 있는데 localhost 연결이 거절되는 이유
앱 컨테이너의 localhost는 옆 서버를 가리키지 않는다. 전용 bridge에서 DNS 해석과 HTTP 연결, 127.0.0.1·0.0.0.0 bind를 실제 비교하고, 상대 이름·컨테이너 포트·수신 주소를 확인하는 순서를 설명한다.
-
Compose down 후에도 데이터가 남으면 named volume을 확인한다
Compose down 후에도 데이터가 남는 이유를 컨테이너 layer와 named volume의 수명으로 구별한다. 같은 이미지에서 컨테이너 ID·Mounts·두 파일을 비교하고, 원래 데이터를 지우지 않은 채 새 빈 볼륨으로 확인하는 방법을 설명한다.
-
같은 컨테이너를 다시 시작했는데 tmpfs 파일이 없다
컨테이너를 삭제하지 않고 stop/start해도 tmpfs 파일은 사라진다. 같은 ID에서 tmpfs와 writable layer 파일을 비교하고, Mounts와 HostConfig.Tmpfs로 실제 저장 위치를 확인해 임시 데이터와 재시작 뒤 필요한 데이터를 나누는 기준을 설명한다.
-
compose exec 파이프 입력의 TTY 오류와 -T의 역할
compose exec의 -T는 stdin을 유지하고 TTY만 끈다. Compose v5.5.1에서 출력이 터미널일 때의 오류와 파이프로 수집할 때의 성공을 비교하고, --interactive=false로 입력까지 끄는 실수를 구분한다.
-
볼륨은 있는데 volume-subpath를 지정하면 시작에 실패한다
named volume이 있어도 volume-subpath로 지정한 하위 디렉터리가 없으면 시작이 실패한다. 별도 초기화 뒤 같은 컨테이너의 상태와 실제 읽힌 파일을 비교하고, Mounts 출력만으로 성공을 판단할 수 없었던 이유를 설명한다.
-
docker commit한 이미지에 볼륨 파일이 없는 이유
컨테이너에서 읽었던 파일이 docker commit 이미지에 없다면 Mounts와 파일 경로를 대조한다. 같은 경로의 일반 파일·볼륨 파일을 실제로 commit해 비교하고, 이미지와 마운트 데이터를 따로 보존해야 하는 이유를 설명한다.
-
Compose command가 컨테이너 값 대신 호스트 환경변수를 쓰는 이유
서비스 environment는 맞는데 command가 호스트 값을 쓰는 경우를 다룬다. 같은 APP_LABEL로 config와 단발 실행을 비교하고, $$로 Compose 보간을 피한 뒤 컨테이너 셸이 값을 확장하도록 고친다. 셸 없는 인자 대조와 config에 남는 $$ 표기도 실제 확인했다.