이미지 업데이트 후에야 컨테이너가 루트 소유 파일을 생성하기 시작하는 이유는 무엇인가요?

이미지 업데이트 후 새 이미지에서 런타임 사용자, 엔트리포인트 또는 시작 시 소유권 처리 방식이 변경되면 컨테이너가 root 소유 파일을 생성할 수 있습니다.

새 컨테이너가 다른 숫자 UID로 시작하거나 초기화 단계를 잠시 root 권한으로 실행하더라도 영구 볼륨 자체는 변경되지 않을 수 있습니다. 새로운 엔트리포인트가 누락된 디렉터리를 만들거나, 구성을 마이그레이션하거나, 권한을 다시 작성하거나, 이전 릴리스에서 사용하던 PUID 및 PGID 변수를 더 이상 적용하지 않을 수도 있습니다. 재귀적 소유권 변경을 적용하기 전에 업데이트 전 파일 하나, 시작 과정에서 생성된 파일 하나, 실행 중인 애플리케이션이 생성한 파일 하나를 비교하세요.

업데이트된 컨테이너가 시작된 후에만 소유권이 변경되는지 확인

스택을 중지하고 기존 파일 하나와 해당 상위 디렉터리의 숫자 UID, GID, 모드, ACL 및 타임스탬프를 기록하세요. 업데이트된 컨테이너를 로그가 표시되는 상태로 한 번 시작한 다음 같은 경로와 새로 생성된 파일 하나를 검사하세요.

Linux chown 시스템 호출은 숫자 소유권을 변경하므로, 결정적인 증거는 호스트에 표시되는 사용자 이름이 아니라 시작 전후의 UID와 GID입니다.

시작 전에 이미 소유자가 root라면 업데이트가 최초 원인이 아닙니다. 파일을 기록한 업데이트 복사, 압축 해제, 백업 복원 또는 관리자 명령을 조사하세요.

업데이트 전후 이미지 사용자 비교

이전 이미지와 새 이미지의 구성, 컨테이너에서 실제로 적용되는 사용자, 엔트리포인트, 명령 및 릴리스 노트를 확인하세요. 이미지가 이제 root, 이름이 지정된 계정 또는 다른 숫자 UID를 선언하는지 기록하세요.

Docker 문서에 따르면 USER 지시문은 런타임 ID를 설정하며, 런타임 재정의가 이를 대체하지 않는 한 이후 이미지 지시문과 컨테이너의 엔트리포인트 및 명령에 적용됩니다.

이미지에서 애플리케이션 사용자 이름이 같더라도 숫자 UID는 변경될 수 있습니다. 호스트에 마운트된 파일은 이미지의 사용자 이름 레이블이 아니라 숫자 소유권을 저장하므로 두 이미지 버전 내부의 숫자를 비교하세요.

새 엔트리포인트가 재귀적 chown을 실행하는지 확인

시작 로그, 릴리스 노트, 엔트리포인트 스크립트 및 프로세스 추적에서 chown, 권한 복구, PUID, PGID, 사용자 마이그레이션 또는 디렉터리 초기화를 검색하세요. 작은 스냅샷이나 임시 볼륨에서 테스트하세요.

GNU Coreutils는 재귀적 chown을 선택한 디렉터리 트리 전체의 소유권 재작성으로 정의합니다. 따라서 새 이미지가 시작된 직후 정상적인 기존 볼륨이 변경된 것처럼 보일 수 있습니다.

시작 시 복구 기능을 무작정 제거하지 마세요. 일부 이미지는 새로 생성된 디렉터리에 이 기능을 사용합니다. 이미지가 지원한다면 문서화된 비활성화 플래그, 고정된 애플리케이션 UID 또는 더 좁은 데이터 경로를 우선 사용하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Compose 사용자 재정의 및 제거된 PUID 또는 PGID 변수 감사

user:, 환경 변수, 추가 그룹, 프로필, 재정의 파일 및 스택 관리자가 저장한 설정을 포함해 업데이트 전후에 배포된 Compose 모델을 비교하세요.

Kubernetes는 명시적인 숫자 런타임 및 볼륨 ID를 사용합니다. 이는 동일한 컨테이너 경계를 보여주는 예로, 런타임 재정의와 볼륨 소유권 정책은 서로 다른 설정이며 계속 일치해야 합니다.

이전 이미지가 PUID 및 PGID 변수를 변환했지만 새 릴리스에서 해당 변수를 제거하거나 이름을 변경했다면 변수는 남아 있어도 더 이상 프로세스를 제어하지 않을 수 있습니다. 실행 중인 UID를 직접 확인하세요.

Rootless 및 사용자 네임스페이스 ID 매핑 고려

Docker가 rootful, rootless 또는 사용자 네임스페이스 재매핑 방식으로 실행되는지 기록하세요. 컨테이너에서 보이는 UID와 동일한 inode에 대해 호스트에서 보이는 소유자를 비교하세요.

Red Hat은 rootless 컨테이너가 보조 UID 및 GID 범위를 사용한다고 설명합니다. 따라서 컨테이너의 root가 호스트 UID 0으로 표시되지 않을 수 있으며, 업데이트 과정에서 매핑이나 런타임 모드의 변경이 드러날 수 있습니다.

매핑을 이해하지 않은 상태에서 rootless 볼륨을 호스트 root 소유로 재귀적으로 chown하지 마세요. 이렇게 하면 의도한 컨테이너 ID가 데이터에 접근하지 못할 수 있습니다.

Idmapped 또는 네트워크 마운트가 표시되는 소유자를 변경하는지 확인

애플리케이션 데이터가 로컬 파일 시스템, idmapped 마운트, NFS, SMB, FUSE 또는 NAS 공유에 있는지 확인하세요. 마운트 옵션을 기록하고 서버, 호스트 및 컨테이너에서 소유권을 비교하세요.

Linux 커널의 idmapped 마운트 모델은 파일 시스템 소유권과 마운트 소유권을 분리하므로, 실제로 재귀적 소유권 재작성 없이도 동일한 파일이 서로 다른 ID로 표시될 수 있습니다.

업데이트 후 표시되는 소유자만 변경되었다면 런타임이 다른 네임스페이스나 마운트 매핑에 진입하는지 확인하세요. 모든 inode를 다시 작성하지 말고 매핑을 수정하세요.

안정적인 런타임 ID 복원 및 다음 업데이트 확인

소유권 메타데이터를 백업하고, 애플리케이션을 중지한 다음, 의도한 숫자 UID와 GID를 정의하고, 애플리케이션이 소유한 경로만 수정한 뒤, 고정된 이미지와 문서화된 사용자 설정으로 재배포하세요.

ZimaSpace의 애플리케이션 데이터 복사 후 컨테이너 소유권 문서에서는 복사 및 마이그레이션 원인을 다룹니다. 이 문서에서는 교체된 이미지로 인해 발생한 변경만 다룹니다.

시작, 애플리케이션 쓰기, 컨테이너 재생성, 호스트 재부팅 및 통제된 이미지 업데이트를 모두 수행한 뒤 광범위한 권한 예외 없이 문서화된 ID로 파일이 생성되면 복구가 완료된 것입니다.

자주 묻는 질문

root 소유 파일이 있다고 해서 컨테이너 전체가 root로 실행된다는 뜻인가요?

아니요. 엔트리포인트가 볼륨을 초기화하기 위해 잠시 root로 실행된 후 애플리케이션이 시작되기 전에 권한을 낮출 수 있습니다.

볼륨 전체를 재귀적으로 chown해야 하나요?

의도한 UID, 공유 경로, ACL 및 네임스페이스 매핑을 확인하기 전에는 하지 마세요. 광범위한 재작성은 데이터베이스, 공유 미디어 또는 rootless 컨테이너의 소유권을 손상시킬 수 있습니다.

이미지 업데이트로 애플리케이션 UID가 변경될 수 있나요?

예. 유지 관리자는 이미지의 사용자 설정을 변경하거나, 계정 데이터베이스를 다시 빌드하거나, PUID 또는 PGID 설정의 이름을 변경하거나, 시작 시 소유권 마이그레이션을 추가할 수 있습니다.