Docker Storage 드라이버에 대한 자세한 소개
나는 최근에 프로젝트에서 일 했고이 기간 동안 Docker Storage 드라이버를 사용하는 방법을 몰랐으므로 온라인으로 정보를 찾아 해결했습니다. 여기에 기록하겠습니다.
목적
Docker는 주로 Linux 커널 네임 스페이스를 사용하여 샌드 박스 분리를 달성하고 CGROUP를 사용하여 리소스 제한을 달성하는 오픈 소스 애플리케이션 컨테이너 엔진입니다. Docker는 통합 개발 및 배포에 사용되는 경량 Linux 컨테이너로, "의존성 지옥"문제를 해결하고, SHIPS에서 사용하는 컨테이너와 유사한 종속 서비스 및 구성 요소를 결합하고 빠른 설치 및 배치를 달성하려고합니다.
1. Docker의 기본 아키텍처 - 클라이언트와 데몬
먼저 Docker의 기본 아키텍처 및 시작 프로세스를 이해해 봅시다. 실제로 Docker는 클라이언트 및 서버를 포함한 C/S 아키텍처를 채택합니다. Docker Daemon은 고객의 요청을 서버로 받아들이고 이러한 요청을 처리합니다 (생성, 실행, 컨테이너 제출). 클라이언트와 서버는 RESTFUL API를 통해 동일한 시스템에서 통신합니다. 특정 사용 프로세스에서 서비스 Docker Start를 실행 한 후 Docker Deamon Daemon 프로세스는 호스트에서 생성되고, 백그라운드에서 실행되며, 클라이언트로부터 메시지 수신 (즉, Docker Pull XXX, Docker Run…, Docker Commit XXX와 같은 입력 Docker 명령)을 기다립니다. Docker 서비스를 시작한 후 Docker 프로세스를 볼 수 있습니다.
기본
[root@localhost ~]# ps -aux | Grep Dockerroot 11701 0.0 0.4 359208 16624? SSL 21:05 0:00/usr/bin/docker -d -h fd : // -selinux -enabled-insecure -registry 186.100.8.216:5000Root 11861 0.0 0.0 113004 2256 PTS/0 S+ 23:01 0 GREP -COLOR = AUTO DOCKER
이는 나중에 파일 시스템을 지정할 때/etc/sysconfig/docker (특별 블로그를 작성 함)에서 특정 스토리지 드라이버를 구성한 다음 Docker Daemon을 시작하고 실행 명령의 매개 변수를 통해 작동 할 수 없기 때문입니다. Docker d를 통해 호스트 명령 줄에서 직접 설정할 수도 있습니다.
2. Docker Storage Method- 스토리지 드라이버
Docker 모델의 핵심 부분은 계층 적 미러링 메커니즘을 효과적으로 활용하는 것입니다. 거울은 계층 구조를 통해 상속 될 수 있습니다. 기본 이미지 (부모 이미지없이)를 기반으로 다양한 특정 응용 프로그램 이미지를 만들 수 있습니다. 다른 Docker 컨테이너는 일부 기본 파일 시스템 계층을 공유 할 수 있으며 동시에 고유 한 변경 레이어와 결합하여 스토리지 효율을 크게 향상시킵니다. 주요 메커니즘은 계층 적 모델과 동일한 가상 파일 시스템에 다른 디렉토리를 장착하는 것입니다 (이 기사에서 여러 디렉토리를 단일 가상 파일 시스템으로 통합). AUFS, DeviceMapper, BTRFS 및 오버레이 (공식 웹 사이트에서)를 포함하여 여러 다른 스토리지 드라이버가 미러 스토리지 Docker에 사용됩니다. 다음은 다양한 스토리지 드라이버에 대한 간단한 소개입니다.
aufs
AUFS (다른 유오 ionfs)는 조인트 파일 시스템입니다. AUFS는 각 멤버 디렉토리 (GIT와 유사)에 대한 ReadOnly, ReadWrite 및 Whiteout 가능한 권한 설정을 지원합니다. 동시에, AUFS에는 비슷한 개념이 있으며, 여기서 읽기 전용 권한이있는 분기는 논리적으로 점진적으로 수정 될 수 있습니다 (읽기 전용 부분에 영향을 미치지 않음). AUFS의 유일한 스토리지 드라이버는 컨테이너간에 실행 파일 및 공유 가능한 런타임 라이브러리를 공유 할 수 있으므로 동일한 프로그램 코드 또는 런타임 라이브러리를 사용하여 수백 개의 런타임을 실행할 때 AUFS는 매우 좋습니다.
장치 매퍼
장치 매퍼는 논리 장치에서 Linux 2.6 커널에 제공된 물리적 장치에 이르기까지 매핑 프레임 워크 메커니즘입니다. 이 메커니즘 하에서 사용자는 요구에 따라 스토리지 리소스를 구현하기위한 관리 전략을 쉽게 공식화 할 수 있습니다 (세부 사항 참조). 장치 매퍼 드라이버는 이미지와 컨테이너가 포함 된 100G 간단한 파일을 만듭니다. 각 컨테이너는 10g 크기의 볼륨으로 제한됩니다 (참고 : 이는 루프백, 특히/var/lib/docker/devicemapper/devicemapper 아래의 메타 데이터를 사용하여 자동으로 생성되며 동적으로 확장 할 수 있습니다). 특정 참조를 위해 Docker 컨테이너의 크기를 조정할 수 있습니다.) 매개 변수 -S를 사용하여 Docker Daemon을 시작할 때 드라이버를 지정할 수 있습니다. 먼저 Docker Service를 닫고 명령을 실행하십시오.
기본
[root@localhost ~]# docker -d -s devicemapperInfo [0000] +job ServeApi (unix : //var/run/docker.sock) 정보 [0000] unix (/var/run/docker.sock) info [0000] +job inittdriver () 정보 [000] -000]에서 http를 듣습니다. (0) 정보 [0000] 컨테이너 로딩 : 시작. .... 정보 [0000] 컨테이너 로딩 : 완료. 정보 [0000] Docker 데몬 : 1.4.0 4595d4f/1.4.0; execdriver : Native-0.2; GraphDriver : devicemapper info [0000] +job acceptConnections () info [0000] -job acceptConnection () = OK (0)
또한 Docker는 컨테이너를 시작할 때 Storage-OPT 매개 변수를 지정할 수 있지만 이제 DeviceMapper 만 매개 변수 설정을 수락 할 수 있습니다. 나중에 대상 블로그 디스플레이가 있습니다.
Btrfs
BTRFS 드라이버는 Docker 빌드에서 매우 효율적일 수 있습니다. 그러나 DeviceMapper와 마찬가지로 장치 간의 공유 스토리지를 지원하지 않습니다 (공식 웹 사이트에 참여). BTRFS는 스냅 샷 및 클론을 지원하며 여러 물리적 장치를 쉽게 관리 할 수 있습니다. (자세한 내용은 IBM의 BTRFS 소개를 참조하십시오)
씌우다
오버레이는 AUF와 매우 유사하지만 성능은 AUF보다 낫고 메모리 활용이 우수합니다. 이제 Linux 커널 3.18로 병합되었습니다. 특정 사용 명령 : Docker DS 오버레이
공식 웹 사이트의 참고 사항 : 현재 BTRFS 또는 Writ
3 도커 디렉토리 구조
Docker의 가장 중요한 두 가지 개념은 거울과 용기입니다. 그렇다면 우리가 풀어 놓는 이미지는 어디에 저장되어 있습니까? 미러 실행 컨테이너가 시작된 후 작동의 내용은 어디에 수정됩니까? 특정 드라이버가 다르기 때문에 최종 구현 효과는 다릅니다. 장치 매퍼 스토리지 드라이버를 사용하여 Docker의 스토리지 구조를 분석하겠습니다.
1./var/lib/docker 디렉토리를 입력하고 내용을 나열하십시오.
기본
[root@localhost ~]# cd/var/lib/docker/[root@localhost docker]# lscontainers devicemapper execdriver 그래프 INT LINKGRAPH.DB Repositories-devicemapper TMP Trust Volumes
디렉토리의 내용에 따르면 Devicemapper 드라이버가 사용되는 것이 분명합니다.
참고 : 아래 표시된 폴더는 모두/var/lib/docker 아래에 있습니다.
2. 이미지 파일을 끌어 올리는 폴더가 있습니까? (참조)
풀의 이미지 정보는 그래프 폴더에 저장되며 이미지의 내용은 Devicemapper/ Devicemapper/ Data에 존재합니다.
3. 시작된 컨테이너는 어디에서 실행됩니까?
시작된 컨테이너 구성 정보는 컨테이너에 저장되며 execdriver/ Native/도 볼 수 있습니다.
컨테이너의 작동 내용은 Devicemapper/Devicemapper/Data에 저장됩니다.
4. 그래프의 역할
Docker Architecture에서는 다운로드 된 컨테이너 이미지의 관리인과 다운로드 된 컨테이너 이미지 간의 관계의 레코더를 재생합니다. 그래프의 로컬 디렉토리에서 각 컨테이너 이미지에 대해 저장된 특정 정보는 컨테이너 이미지의 메타 데이터 (JSON), 컨테이너 이미지의 레이어 크기 (계층화) 정보 및 컨테이너 이미지로 표시되는 특정 루프입니다.
5. 실험 테스트 :
- 처음에는 컨테이너가 활성화되지 않았습니다.
기본
[root@localhost docker]# ll 컨테이너/총 0
- 컨테이너 시작 :
기본
[root@localhost docker]# docker run -i -t --rm centos : 7 /bin /bash [root@187a8f9d2865 /]#
시작된 컨테이너의 uuid = 187a8f9d2865
- 컨테이너를 시작하기 전에/var/lib/docker/devicemapper/devicemapper/아래 파일의 실제 크기를 확인하십시오.
기본
[root@bhdocker216 docker]# du -h devicemapper/devicemapper/*2.1g devicemapper/devicemapper/data3.5m devicemapper/devicemapper/metadata
- 호스트에서보기
기본
[root@bhdocker216 docker]# ls 컨테이너/187a8f9d2865c2ac *** 91B981
UUID 폴더 아래에서 시작된 컨테이너의 내용을 확인하십시오.
기본
[root@bhdocker216 컨테이너]# ll 187A8F9D2865C2AC *** 91B981Total 24-RW -----. 1 루트 루트 273 3 월 5 23:59 187A8F9D2865 ***-JSON.LOG-RW-R-. 1 루트 루트 1683 Mar 5 23:58 config.json-rw-r-. 1 루트 루트 334 3 월 5 23:58 HostConfig.json-rw-r--. 1 루트 루트 13 3 월 5 23:58 Hostname-rw-r--. 1 루트 뿌리 174 3 월 53:58 호스트-rw-r--. 1 루트 루트 69 3 월 5 23:58 RESOLV.CONF- 시작 컨테이너에 파일을 추가하여 봅니다.
먼저 실행중인 컨테이너에서 파일을 만듭니다.
기본
[root@8a1e3ad05d9e/]# dd if =/dev/zero of = floppy.img bs = 512 count = 57605760+0 레코드 in5760+0 레코드 out2949120 바이트 (2.9 MB) 복사, 0.0126794 s, 233 MB/s
그런 다음/var/lib/docker/devicemapper/devicemapper/에서 파일을 봅니다.
기본
[root@bhdocker216 docker]# du -h devicemapper/devicemapper/*5.5g devicemapper/devicemapper/data4.6m devicemapper/devicemapper/metadata
8g 크기의 파일을 생성하기 위해 #dd if =/dev/zero of = tex.txt = 1m count = 8000을 처음 실행했기 때문에이 장소의 크기는 약간 다릅니다. 너무 느리기 때문에 종료했지만 달리는 컨테이너에서 작동 할 때 두 폴더가 변경되었음을 분명히 알 수 있습니다.
- 그래프를 확인하십시오. 하나의 이미지 (ubuntu14.10) 만 가져 오면 7 개의 긴 UUID 명명 된 디렉토리가 나타납니다. 이것이 어떻게 생겼습니까?
Docker Images 트리를 사용하여 거울 트리 구조를 나열하면 거울의 계층 적 저장 구조를 볼 수 있습니다. 최종 우분투 (레이어 7)는 계층 6 변경, 즉이 논리 트리의 N-th 층은 N-1 변경에 기초하고 N-Layer는 N-1 이미지에 따라 다릅니다. 0 층 크기는 0이며 기본 이미지라고합니다.
- 그래프/UUID 디렉토리의 내용은 무엇입니까?
기본
[root@localhost 그래프]# ll 01BF15A18638145EB *** -HTOTAL 8.0K-RW -----. 1 루트 루트 1.6K 3 월 5 18:02 JSON-RW -----. 1 루트 루트 9 3 월 5 18:02 계층 크기
계층화 내용 : 디지털 표현 계층의 크기 (단위 : B). Josn :이 이미지의 메타 데이터를 저장합니다 (예 : 크기, 아키텍처, 구성, 컨테이너, ** 부모의 uuid ** 등).
- devicemapper/devicemapper 폴더를 봅니다
두 개의 폴더, 데이터 및 메타 데이터가 있습니다. 실제로 장치 매퍼 드라이버는 미러 및 컨테이너 파일을 ** 데이터 ** 파일에 저장합니다. Docker Info를 통해 데이터 및 메타 데이터의 크기를 볼 수 있습니다. 또한 Du H (위의 사용)를 사용 하여이 두 스파 스 파일의 실제 크기를 볼 수 있습니다.
- execdriver
기본
[root@bhdocker216 docker]# ls execrdriver/avential/8a1e3ad05d9e66a455e683a2c *** 2437bdcccdfdfa // 내부 컨텐츠보기 : [root@bhdocker216 8a1e3ad05d9e6a455e ***]# lsconater.json.
- 볼륨
-v 매개 변수가없는 볼륨은 비어 있습니다. 테스트 후 컨테이너가 시작되면 -v 매개 변수를 추가하면 uuid가 볼륨 폴더에 표시됩니다. 글로벌 검색은 호스트에서 수행되며 볼륨에서만 발견됩니다. 그것은 컨테이너의 이미지와 uuid와 관련이 없습니다.
기본
[root@bhdocker216 docker]# find/-name 86eb77f9f5e25676f100 *** d5a/var/lib/docker/volumes/86eb77f9f5e25676f100 *** d5a // 내부의 내용보기 : [root@bhdocker216 Volumes]# ls]# ls. 86EB77F9F5E25676F100 *** d5aconfig.json [root@bhdocker216 볼륨]# cat 86eb77f9f5e25676f100 *** d5a /config.json { "ID": "86EB77F9F5E25676F100A89BA727BC15185303236AAE0DCF4C17223E37651D5A", "PATH": "/HOME/DATA", "ISBINDMOUNT": TRUE ": TRUE": TRUE} 폴더 기능의 표 설명
요약하고 테이블을 구성하고/var/lib/docker 아래에 다른 폴더의 기능을 설명하십시오.
읽어 주셔서 감사합니다. 도움이되기를 바랍니다. 이 사이트를 지원 해주셔서 감사합니다!