이 기사는 공동 파일 시스템, 계층 구조 및 계층적 관행과 관련된 문제를 포함하여 공동 파일 시스템에 대한 관련 지식과 Docker 이미지 원칙에 대한 계층적 이해를 제공합니다.
UnionFS(Union File System)
UnionFS(Union File System): 유니온 파일 시스템(UnionFS)입니다. 계층화된 경량 고성능 파일 시스템은 단일 제출로 계층별로 겹쳐지는 파일 시스템 수정을 지원합니다. 동시에 여러 디렉터리를 동일한 가상 파일 시스템에 마운트할 수 있습니다. 단일 가상 파일 시스템). Union 파일 시스템은 Docker 이미지의 기초입니다. 레이어링을 통해 이미지를 상속할 수 있으며, 기본 이미지(상위 이미지 없이)를 기반으로 다양한 특정 애플리케이션 이미지를 생성할 수 있습니다.
또한 다양한 Docker 컨테이너는 일부 기본 파일 시스템 레이어를 공유하는 동시에 고유한 변경 레이어를 추가하여 스토리지 효율성을 크게 향상시킬 수 있습니다.
Docker에서 사용되는 AUFS(AnotherUnionFS)는 통합 파일 시스템입니다. AUFS는 각 구성원 디렉터리에 대한 읽기 전용, 읽기 쓰기 및 화이트아웃 가능 권한 설정을 지원합니다(Git 브랜치와 유사). 동시에 AUFS에는 읽기 전용 권한의 경우 논리적으로 점진적으로 수정할 수 있습니다( 읽기 전용 부분에는 영향을 주지 않습니다).
Docker는 현재 AUFS, btrfs, vfs 및 DeviceMapper를 포함한 공동 파일 시스템 유형을 지원합니다.
기능: 동시에 여러 파일 시스템을 로드하지만 외부에서는 하나의 파일 시스템만 볼 수 있습니다. 공동 로드는 파일 시스템의 각 레이어를 겹쳐서 최종 파일 시스템에 모든 기본 파일과 디렉터리가 포함됩니다. .
기본 이미지
기본 이미지는 단순히 다른 이미지에 의존하지 않고 완전히 처음부터 구축된다는 의미이며, 그 위에 다른 이미지가 구축된다는 의미는 건물의 기초와 원본에 비유될 수 있습니다. 도커 이미지.
기본 이미지에는 두 가지 의미가 있습니다. (1) 다른 이미지에 의존하지 않고 처음부터 작성됩니다. (2) 이를 기반으로 다른 이미지를 확장할 수 있습니다.
그래서 기본 이미지라고 할 수 있는 것은 일반적으로 Ubuntu, Debian, CentOS 등 다양한 Linux 배포판의 Docker 이미지입니다.
Docker 이미지 로딩 원리
Docker의 이미지는 실제로 파일 시스템 레이어로 구성되며, 이 파일 시스템 레이어는 UnionFS입니다.
일반적인 Linux에서는 bootfs + rootfs라는 두 개의 FS가 필요합니다.
bootfs(부팅 파일 시스템)에는 주로 bpotloader와 커널이 포함되어 있습니다. 부트로더는 처음에 bootfs 파일 시스템을 로드합니다. start. , Docker 이미지 하단에 bootfs가 있습니다. 이 계층은 부트로더 부트로더 및 커널 커널을 포함하여 일반적인 Linux/Unix 시스템과 동일합니다. 부팅 로딩이 완료되면 전체 커널이 메모리에 들어갑니다. 이때 메모리 사용 권한은 bootfs에서 커널로 이전됩니다. 이때 시스템은 bootfs도 제거합니다.
rootfs(루트 파일 시스템), bootfs 위에 위치. 일반적인 Linux 시스템의 /dev, /proc, /bin, /etc 등과 같은 표준 디렉터리 및 파일이 포함되어 있습니다. 루트는 Ubuntu, Centos 등과 같은 다양한 운영 체제 배포판입니다.
Docker 이미지에 커널이 없는 이유
이미지 크기로 보면 상대적으로 작은 이미지는 1KB 남짓, 즉 몇 MB에 불과한 반면, 커널 파일에는 수십 MB가 필요하므로 이미지 크기가 전혀 없습니다. 이미지의 커널 컨테이너로 시작된 후 호스트의 커널이 직접 사용되며 이미지 자체는 시스템의 정상적인 작동에 필요한 사용자 공간 파일 시스템인 해당 rootfs만 제공합니다. /dev/, /proc, /bin, /etc 디렉터리이므로 기본적으로 컨테이너에는 /boot 디렉터리가 없으며 /boot는 커널과 관련된 파일 및 디렉터리를 저장합니다.
컨테이너는 호스트의 커널을 사용하여 직접 시작하고 실행하기 때문에 물리적 하드웨어를 직접 호출하지 않으므로 하드웨어 드라이버를 포함하지 않으므로 커널과 드라이버를 사용하지 않습니다. 그리고 가상머신 기술이라면 각 가상머신은 자신만의 독립적인 커널을 가지고 있습니다
Docker 이미지는 계층적 구조로, 각 레이어는 다른 레이어 위에 구축되어 점진적인 증가를 달성합니다. Docker 이미지도 레이어로 다운로드됩니다. Redis 이미지 다운로드를 예로 들어보겠습니다.
새 이미지가 기본 이미지 레이어에서 레이어별로 생성되는 것을 볼 수 있습니다. 소프트웨어를 설치할 때마다 기존 이미지에 레이어를 추가합니다.
Docker 이미지가 이 계층 구조를 채택하는 이유는 무엇입니까?
가장 큰 장점은 리소스 공유입니다. 예를 들어, 동일한 기본 이미지에서 여러 이미지가 빌드된 경우 호스트는 디스크에 하나의 기본 이미지만 유지하면 되며, 모든 컨테이너를 제공할 수 있도록 하나의 기본 이미지만 메모리에 로드하면 됩니다. 이미지의 각 레이어를 공유할 수 있습니다.
쓰기 가능한 컨테이너 레이어
Docker 이미지는 읽기 전용입니다. 컨테이너가 시작되면 쓰기 가능한 새 레이어가 이미지 위에 로드됩니다.
이 새 레이어는 쓰기 가능한 컨테이너 레이어이며, 컨테이너 아래의 모든 항목을 미러 레이어라고 합니다.
Docker는 기록 중 복사 전략을 사용하여 기본 이미지의 보안은 물론 더 높은 성능과 공간 활용도를 보장합니다.
최상위 이미지 레이어에서 시작하여 아래쪽으로 검색한 후 메모리에 이미 있으면 직접 사용할 수 있습니다. 즉, 동일한 머신에서 실행되는 Docker 컨테이너는 런타임에 동일한 파일을 공유합니다.
위에서 아래로 검색하여 찾은 후 컨테이너 레이어에 복사합니다. 이미지 레이어를 선택한 다음 컨테이너 레이어에서 파일을 직접 수정합니다.
위에서 아래로 검색하여 찾은 후 컨테이너에 삭제 내용을 기록합니다. 실제 삭제가 아닌 소프트 삭제입니다. 이로 인해 이미지 크기가 줄어들지 않고 늘어나기만 합니다.
이미지 레이어에 영향을 주지 않고 최상위 컨테이너 쓰기 가능 레이어에 파일을 직접 추가하세요.
파일 추가, 삭제, 수정 등 컨테이너에 대한 모든 변경 사항은 컨테이너 레이어에서만 발생합니다. 컨테이너 레이어만 쓰기 가능하고, 컨테이너 레이어 아래의 모든 이미지 레이어는 읽기 전용이므로 여러 컨테이너에서 이미지를 공유할 수 있습니다.
이미지를 통해 컨테이너를 만든 다음 컨테이너 레이어를 작동하고 이미지 레이어를 변경하지 않은 다음 작동된 컨테이너 레이어와 이미지 레이어를 새로운 이미지로 패키징하여 제출합니다.
docker 커밋: 컨테이너를 사용하여 새 이미지를 만듭니다.
구문:
docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]
OPTIONS 설명:
1. 먼저 tomcat 이미지를 다운로드하세요
2. tomcat 이미지를 통해 tomcat 컨테이너를 생성하고 실행하세요:
docker run -d --name="tomcat01" tomcat
3 실행 중인 tomcat 컨테이너를 입력하세요:
docker exec -it tomcat01 /bin/bash
4. webapps 디렉터리에
cp -r webapps.dist/* webapps
5. Docker 커밋 이미지 제출
컨테이너 dc904437d987을 새 이미지로 저장하고 제출자 정보와 설명 정보를 추가합니다. 제출된 이미지 이름은 tomcatplus입니다. 1.0:
docker commit -a="wanli" -m="add webapps files" dc904437d987 tomcatplus:1.0
컨테이너 계층에 파일을 복사했기 때문에 커밋 후 새 Tomcat 이미지의 크기가 원본 Tomcat 이미지보다 약간 더 큰 것을 볼 수 있습니다.
추천 학습: "
위 내용은 Docker 이미지 원리: 공동 파일 시스템 및 계층적 이해(자세한 예)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
