Docker에서 컨테이너와 이미지의 차이점은 무엇입니까?

이 글에서는 Docker에서 컨테이너와 이미지의 차이점을 소개합니다. 도움이 되길 바랍니다.

(추천 튜토리얼: docker 튜토리얼)

아직 Docker 기술에 대한 지식이 부족했을 때 Docker 명령을 이해하는 것이 매우 어려웠습니다. 그래서 몇 주 동안 Docker의 작동 방식, 더 구체적으로 통합 파일 시스템을 배우고 Docker 명령을 다시 살펴보면 모든 것이 매우 간단해졌습니다.

여담: 개인적으로 기술을 익히고 합리적으로 사용하는 가장 좋은 방법은 기술의 작동 원리를 깊이 이해하는 것입니다. 일반적으로 새로운 기술의 탄생은 언론의 과대광고와 과대광고를 동반하는 경우가 많아 사용자가 기술의 진정한 본질을 보기 어렵게 만듭니다. 오히려 새로운 기술은 항상 새로운 용어나 은유를 만들어내어 정보를 전달하는 데 도움을 줍니다. 이는 초기 단계에서는 매우 도움이 되지만, 기술 원리에 사포를 얹어 사용자가 이후 단계에서 기술의 진정한 의미를 익히는 데 도움이 되지 않습니다.

Git이 좋은 예입니다. 이전에는 Git을 잘 사용하지 못했기 때문에 Git의 원리를 익히는 데 시간을 투자한 후 비로소 Git의 사용법을 제대로 이해하게 되었습니다. 나는 Git의 내부를 진정으로 이해하는 사람만이 이 도구를 마스터할 수 있다고 굳게 믿습니다.

이미지 정의

이미지는 여러 읽기 전용 레이어의 통합된 관점일 수 있습니다. 아마도 이 정의는 독자가 이미지의 정의를 이해하는 데 도움이 될 것입니다.

왼쪽에는 겹치는 여러 개의 읽기 전용 레이어가 있습니다. 맨 아래 레이어를 제외한 다른 모든 레이어에는 다음 레이어를 가리키는 포인터가 있습니다. 이러한 레이어는 Docker 내부의 구현 세부 정보이며 호스트(번역자 참고 사항: Docker를 실행하는 머신)의 파일 시스템에서 액세스할 수 있습니다. 유니온 파일 시스템 기술은 다양한 계층을 하나의 파일 시스템으로 통합하여 이러한 계층에 대한 통합된 관점을 제공함으로써 사용자 관점에서 볼 때 여러 계층의 존재를 숨길 수 있습니다. 이미지의 오른쪽에서 이 관점이 어떻게 보이는지 확인할 수 있습니다.

호스트 파일 시스템에서 이러한 레이어에 대한 파일을 찾을 수 있습니다. 이러한 레이어는 실행 중인 컨테이너 내부에는 표시되지 않습니다. 내 호스트에서 /var/lib/docker/aufs 디렉토리에 존재하는 것을 발견했습니다.

sudo tree -L 1 /var/lib/docker/

/var/lib/docker/
├── aufs
├── containers
├── graph
├── init
├── linkgraph.db
├── repositories-aufs
├── tmp
├── trust
└── volumes
7 directories, 2 files

Container Definition

컨테이너의 정의는 이미지(image)의 정의와 거의 똑같습니다. 또한 묶음의 통일된 관점이기도 합니다. 유일한 차이점은 컨테이너가 읽기 및 쓰기가 가능한 상위 레이어가 가장 많다는 것입니다.

주의 깊은 독자라면 컨테이너 정의에 컨테이너가 실행 중인지 여부가 언급되어 있지 않다는 것을 알 수 있을 것입니다. 예, 이는 의도적인 것입니다. 나의 많은 혼란을 이해하는 데 도움이 된 것은 바로 이 발견이었습니다.

핵심 사항: 컨테이너 = 이미지 + 읽기 가능한 레이어. 그리고 컨테이너의 정의에는 컨테이너를 실행할지 여부가 언급되어 있지 않습니다.

다음으로 런타임 컨테이너에 대해 논의하겠습니다.

실행 중인 컨테이너 정의

실행 중인 컨테이너는 읽기 및 쓰기가 가능한 통합 파일 시스템과 격리된 프로세스 공간 및 여기에 포함된 프로세스로 정의됩니다. 아래 이미지는 실행 중인 컨테이너를 보여줍니다.

Docker를 유망 기술로 만드는 것은 파일 시스템 격리 기술입니다. 컨테이너의 프로세스는 파일을 수정, 삭제 또는 생성할 수 있으며 이러한 변경 사항은 읽기-쓰기 계층에 영향을 미칩니다. 아래 그림은 이 동작을 보여줍니다.

     

我们可以通过运行以下命令来验证我们上面所说的： 

docker run ubuntu touch happiness.txt

即便是这个ubuntu容器不再运行，我们依旧能够在主机的文件系统上找到这个新文件。 

find / -name happiness.txt

/var/lib/docker/aufs/diff/860a7b...889/happiness.txt

Image Layer Definition

为了将零星的数据整合起来，我们提出了镜像层（image layer）这个概念。下面的这张图描述了一个镜像层，通过图片我们能够发现一个层并不仅仅包含文件系统的改变，它还能包含了其他重要信息。 

     

元数据（metadata）就是关于这个层的额外信息，它不仅能够让Docker获取运行和构建时的信息，还包括父层的层次信息。需要注意，只读层和读写层都包含元数据。 

     

除此之外，每一层都包括了一个指向父层的指针。如果一个层没有这个指针，说明它处于最底层。 

     

Metadata Location: 
我发现在我自己的主机上，镜像层（image layer）的元数据被保存在名为”json”的文件中，比如说： 

/var/lib/docker/graph/e809f156dc985.../json

e809f156dc985...就是这层的id 

一个容器的元数据好像是被分成了很多文件，但或多或少能够在/var/lib/docker/containers/目录下找到，就是一个可读层的id。这个目录下的文件大多是运行时的数据，比如说网络，日志等等。 

全局理解（Tying It All Together）

现在，让我们结合上面提到的实现细节来理解Docker的命令。 

docker create

     

docker create 命令为指定的镜像（image）添加了一个可读写层，构成了一个新的容器。注意，这个容器并没有运行。 

     

docker start

     

Docker start命令为容器文件系统创建了一个进程隔离空间。注意，每一个容器只能够有一个进程隔离空间。 

docker run

     

看到这个命令，读者通常会有一个疑问：docker start 和 docker run命令有什么区别。 

그림에서 볼 수 있듯이 docker run 명령은 먼저 이미지를 사용하여 컨테이너를 생성한 후 컨테이너를 실행합니다. 이 명령은 매우 편리하고 두 명령의 세부 사항을 숨기는 반면, 사용자가 오해하기 쉽습니다.

여론: Git에 대한 이전 주제를 이어가면 docker run 명령은 git pull 명령과 비슷하다고 생각합니다. git pull 명령은 git fetch와 git merge의 조합입니다. 마찬가지로 docker run은 docker create와 docker start의 조합입니다.

docker ps

docker ps 명령은 실행 중인 모든 컨테이너를 나열합니다. 이렇게 하면 실행되지 않는 컨테이너의 존재가 숨겨집니다. 이러한 컨테이너를 찾으려면 다음 명령을 사용해야 합니다.

docker ps –a

docker ps –a 명령은 실행 중이거나 중지되었는지 여부에 관계없이 모든 컨테이너를 나열합니다.

docker Images

docker Images 명령은 모든 최상위 이미지를 나열합니다. 실제로 여기서는 미러와 읽기 전용 레이어를 구분할 방법이 없으므로 최상위 미러링을 제안합니다. 컨테이너를 생성할 때 사용한 이미지나 직접 끌어낸 이미지만 최상위 이미지라고 할 수 있으며, 각 최상위 이미지 아래에는 여러 개의 이미지 레이어가 숨겨져 있습니다.

docker 이미지 –a

docker 이미지 –a 명령은 모든 이미지를 나열하며, 읽을 수 있는 모든 레이어를 나열한다고 할 수도 있습니다. 특정 이미지 ID 아래의 모든 레이어를 보려면 docker History를 사용하여 볼 수 있습니다.

docker stop

docker stop 명령은 실행 중인 컨테이너에 SIGTERM 신호를 보낸 다음 모든 프로세스를 중지합니다.

docker kill

docker kill 명령은 컨테이너에서 실행 중인 모든 프로세스에 비우호적인 SIGKILL 신호를 보냅니다.

docker stop

docker stop 및 docker kill 명령은 실행 중인 프로세스에 UNIX 신호를 보냅니다. docker Pause 명령은 실행 중인 프로세스를 종료하기 위해 cgroups의 특성을 사용합니다. . 프로세스 공간이 일시 중지되었습니다. 구체적인 내부 원칙은 www.kernel.org/doc/Doc...에서 찾을 수 있지만 이 방법의 단점은 SIGTSTP 신호를 보내는 것이 프로세스가 이해할 만큼 간단하지 않아서 모든 것을 중지할 수 없다는 것입니다. 프로세스.

docker rm

docker rm 명령은 컨테이너를 구성하는 읽기 및 쓰기 가능한 레이어를 제거합니다. 이 명령은 실행되지 않는 컨테이너에서만 실행할 수 있습니다.

docker rmi

docker rmi 명령은 이미지를 구성하는 읽기 전용 레이어를 제거합니다. docker rmi 만 사용하여 최상위 계층(미러라고도 함)을 제거할 수 있습니다. 또한 -f 매개변수를 사용하여 중간 읽기 전용 계층을 강제로 제거할 수도 있습니다.

docker commit

docker commit 명령은 컨테이너의 읽기-쓰기 레이어를 읽기 전용 레이어로 변환하여 컨테이너를 변경할 수 없는 이미지로 변환합니다.

docker build

docker build 명령은 매우 흥미롭습니다. 여러 명령을 반복적으로 실행합니다.

위 그림에서 볼 수 있듯이 build 명령은 Dockerfile 파일의 FROM 명령어에 따라 이미지를 얻은 후 1) 실행(생성 및 시작), 2) 수정, 3)을 반복적으로 수행합니다. 저지르다. 루프의 각 단계는 새 레이어를 생성하므로 많은 새 레이어가 생성됩니다.

docker exec

docker exec 명령은 실행 중인 컨테이너에서 새 프로세스를 실행합니다.

docker Inspection 또는

dockerspec 명령은 컨테이너 또는 이미지의 최상위 메타데이터를 추출합니다.

docker save

docker save 명령은 다른 호스트의 Docker에서 사용할 수 있는 압축된 이미지 파일을 생성합니다. 내보내기 명령과 달리 이 명령은 각 레이어의 메타데이터를 저장합니다. 이 명령은 이미지에만 적용됩니다.

docker 내보내기

docker 내보내기 명령은 tar 파일을 생성하고, 메타데이터와 불필요한 레이어를 제거하고, 여러 레이어를 하나의 레이어로 통합하고, 통일된 관점에서 본 현재 콘텐츠만 저장합니다( 번역자 주: exoxt 이후의 컨테이너를 Docker로 가져오면 docker Images –tree 명령을 통해 하나의 이미지만 볼 수 있으며, 저장 후의 이미지는 다르므로 이 이미지 미러의 기록을 볼 수 있습니다.

docker History

docker History 명령은 지정된 이미지의 기록 이미지를 재귀적으로 출력합니다.

위 내용은 Docker에서 컨테이너와 이미지의 차이점은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!