나는 팔로우하고 있다처음부터 Kevin Boone 컨테이너 만들기
/mnt/container/ 아래에 알파인 미니 루트 파일 시스템이 있습니다.
chroot 및 unshare에서 마운트가 작동하는 방식이 약간 혼란스럽습니다.
공유를 해제하면 공유를 해제할 필요가 없습니다.
chroot /mnt/container /bin/sh -l
호스트 시스템에 "/"(루트)가 있는 컨테이너(일종의)를 얻습니다 /mnt/container.
컨테이너 내부에서 다음 명령을 실행하면;
mount -t proc proc /proc >& /dev/null
mount -t devtmpfs dev /dev/ >& /dev/null
호스트 시스템의 /proc 및 /dev를 마운트했음을 확인하므로 호스트에서 실행 중인 프로세스를 볼 수 있고 ps -ef호스트에서 생성될 /dev에 파일을 생성할 수도 있습니다. 아직 네임스페이스 격리가 없기 때문에 이는 예상된 결과입니다.
네임스페이스 격리를 생성하려면 다음을 수행합니다.
unshare -mpfu chroot /mnt/container /bin/sh -l
그런 다음 컨테이너 내부에서 실행하십시오.
mount -t proc proc /proc >& /dev/null
mount -t devtmpfs dev /dev/ >& /dev/null
이번에는 ps -ef컨테이너 내부의 두 프로세스만 표시됩니다. 내 이해(틀렸다면 정정해 주세요)는 mount -t proc proc /proc >& /dev/null호스트 시스템의 /proc가 마운트되지 않았지만 procfs 유형의 새 디렉토리 /proc가 생성되어 격리된다는 것입니다.
하지만 컨테이너 내부의 /dev는 여전히 호스트의 /dev와 동일합니다. 여전히 /dev에 파일을 생성할 수 있으며 호스트에 표시됩니다.
/dev가 /proc처럼 격리되지 않는 이유는 무엇입니까?
답변1
devtmpfs네임스페이스가 없습니다(참조컨텍스트 에 따라 shmem초기화됨), 사용자 네임스페이스 내에서 사용하기에도 적합하지 않습니다(참조:네임스페이스용 devtmpfs에 특별한 것이 있나요? 권한 문제).
이를 변경하려는 시도가 있었습니다.Seth Forshee가 제출한 2014 패치 시리즈. 그러나 커널 관리자, 특히 Greg KH는 devtmpfs호스트와 사용자 네임스페이스 간에 인스턴스 또는 네임스페이스 인식 인스턴스를 공유 하면쓸모 없는:
Loopdevfs 논의에서 devtmpfs 네임스페이스를 분리하는 것이 현명할 수 있습니다. 그러나 네임스페이스 devtmpfs를 방어하기 위해 사용자 공간의 경우 컨테이너가 시작될 때마다 장치의 전역 devtmpfs를 개인 tmpfs에 바인드 마운트해야 한다고 말하고 싶습니다(시스템 고려 사항의 경우 컨테이너 rootfs에만 있을 수는 없습니다). 피할 가치가 있는 것 같습니다.
컨테이너에서 원하는 장치 노드를 선택해야 하는 것은 좋은 일이라고 생각합니다. 사실, 어쨌든 커널에서 동일한 작업을 수행해야 합니다. 특히 사용자 공간이 커널보다 원하는 작업을 더 잘 알고 있기 때문에 여기서 결정을 내리는 데 문제가 있습니다.
기본적으로 사용자 네임스페이스 내에 있어야 하는 경우 /dev수동으로 채워야 합니다.
/proc는 PID 네임스페이스와 어떻게 상호 작용합니까?/proc이 동작은 설명되어 있습니다 .
답변2
Kevin Boone의 컨테이너 기술은 Docker 또는 가상 머신에서 가능한 컨테이너화 기술과 동일하지 않습니다.
Linux에서 /dev 및 /proc는 파일 시스템 디렉터리가 아닙니다. 이는 파일 시스템 개체(예: 개체)로 액세스할 수 있는 운영 체제의 특수 엔터티입니다.
많은 명령에서는 이러한 엔터티의 내용을 검사해야 합니다.
"dev" 및 "proc"이라는 이름의 디렉토리는 어디에서나 생성될 수 있지만 실제 /dev 및 /proc 의사 파일 시스템 디렉토리의 "덮개"로 나타날 수 있습니다.