Docker镜像的知识归纳

docker镜像的知识总结归纳

---

一、镜像基础

1.镜像就是一个精简的操作系统

Docker镜像可以被看作是一个精简的操作系统。它包含了运行特定应用程序所需的一切，包括文件系统、库、依赖项和配置等。镜像是用于创建Docker容器的模板。

Docker镜像基于分层存储（Layered Storage）的概念。每个镜像都由一系列只读层组成，这些层相互叠加形成一个完整的镜像。每个层都包含了一个或多个文件系统的更改。这种分层结构使得镜像可以共享和重用公共部分，同时减少了存储空间和下载时间的需求。

当你从Docker镜像创建一个容器时，该容器会在镜像的基础上添加一个可写的层，用于保存容器运行时的状态和文件变更。这意味着你可以基于同一个镜像创建多个容器，并且每个容器都可以有自己独立的文件系统。

通过使用Docker镜像，你可以快速、可靠地部署应用程序，并且确保它们在不同环境中的一致性。镜像的轻量性和可移植性使得Docker成为了广泛应用于开发、测试和部署的技术之一。

2.三类主要的镜像仓库：Docker Hub、私有镜像仓库和第三方镜像仓库

在Docker生态系统中，有三类主要的镜像仓库：Docker Hub、私有镜像仓库和第三方镜像仓库。这些镜像仓库提供的镜像可以具备一定的质量保障，但具体情况还需要考虑以下几个因素：

1. Docker Hub：Docker Hub 是官方提供的公共镜像仓库，其中包含了大量的官方镜像和社区共享的镜像。官方镜像由Docker团队维护，通常具有高质量和可靠性。然而，社区共享的镜像质量参差不齐，可能存在质量较低、更新不及时或潜在的安全问题。在使用社区共享镜像时，应仔细检查镜像的源、维护者信誉度和镜像的使用量等指标。

2. 私有镜像仓库：私有镜像仓库是由个人或组织自行搭建和管理的镜像仓库，用于存储和共享自己的镜像。在私有镜像仓库中，镜像的质量取决于镜像的制作者和维护者。如果制作者严格遵循最佳实践、进行测试和验证，并保持镜像的更新和修复，那么私有镜像仓库中的镜像可以具备较高的质量保障。

3. 第三方镜像仓库：第三方镜像仓库是由第三方提供的镜像托管服务，例如Quay.io、GCR（Google Container Registry）、AWS ECR（Amazon Elastic Container Registry）等。这些镜像仓库提供了更多选择，包括一些官方镜像仓库所不具备的内容。在选择第三方镜像仓库时，建议了解提供商的信誉度、维护政策和社区支持，以确保镜像的质量和可信度。

总的来说，官方镜像通常具有较高的质量保障，而社区共享的镜像和第三方镜像仓库中的镜像质量可能会有所差异。在选择和使用镜像时，需要审查镜像的来源、维护者的信誉度，以及与社区的互动情况，以确保所使用的镜像是可信和具有一定质量保障的。此外，始终要保持镜像的及时更新和安全性，遵循最佳实践以降低潜在的风险。

二、镜像相关命令

1.基本命令

当涉及Docker镜像时，以下是一些基本的镜像相关命令及其用法：

1. docker pull：从镜像仓库下载镜像到本地

   docker pull <镜像名>
   

2. docker images：列出本地已下载的镜像

   docker images
   

3. docker rmi：删除本地的一个或多个镜像

   docker rmi <镜像ID 或 镜像名>
   

4. docker build：根据 Dockerfile 构建镜像

   docker build -t <镜像名:标签> <Dockerfile路径>
   

5. docker tag：给本地镜像打标签（重命名）

   docker tag <原镜像名:原标签> <新镜像名:新标签>
   

6. docker push：将本地镜像推送到镜像仓库

   docker push <镜像名>
   

7. docker inspect：查看镜像的详细信息

   docker inspect <镜像名 或 镜像ID>
   

8. docker history：查看镜像的历史记录（分层信息）

   docker history <镜像名 或 镜像ID>
   

9. docker save：将镜像保存为 tar 归档文件

   docker save -o <保存路径.tar> <镜像名>
   

10. docker load：从 tar 归档文件中加载镜像

    docker load -i <tar文件路径>
    

这些命令涵盖了镜像的基本操作，包括拉取、删除、构建、推送、查看详细信息等。通过这些命令，你可以管理本地镜像并与镜像仓库进行交互。请注意，在命令中的 <镜像名> 可以是镜像的名称或标签，或者使用镜像的 ID 进行引用。

2.自动化镜像

自动化镜像是指通过与 Docker Hub 连接的代码托管平台（如GitHub或Bitbucket）中的 Dockerfile，在Docker Hub上自动构建的镜像。这种自动化构建过程是由Docker Hub提供的功能实现的。

当你在Docker Hub上与GitHub或Bitbucket等代码托管平台进行连接并配置了适当的触发条件后，Docker Hub会监测与代码仓库相关联的镜像构建设置。当代码仓库中的Dockerfile文件发生变化时，Docker Hub会自动触发构建过程。它会根据Dockerfile的内容和相关配置，自动构建出镜像，并将构建出的镜像标记为"Automated Build"。

自动化构建提供了一种方便的方式来持续集成和持续部署（CI/CD）Docker镜像。通过将代码仓库与Docker Hub连接，你可以确保在代码更新或提交时，相应的镜像也会自动构建和更新。这种自动化构建的过程可以节省时间和工作量，使得镜像的构建和发布更加高效和一致。

此外，自动化构建还提供了与代码仓库的集成，允许开发人员将其应用程序代码和相关的Dockerfile存储在同一个代码仓库中，使代码和镜像的管理更加集中和方便。

总之，自动化镜像通过与代码托管平台连接，根据Dockerfile的变化自动构建镜像，并在Docker Hub上标记为"Automated Build"。这种自动化构建提供了持续集成和持续部署的能力，简化了镜像构建和发布的流程。

三、镜像分层

1.目的

为了实现在不同镜像之间的镜像层共享。Docker使用分层存储的概念，将镜像拆分为多个只读层，这些层可以在不同的镜像之间进行共享和重用。

通过将镜像拆分为多个层，可以带来以下几个好处：

1. 节省存储空间： 当多个镜像共享相同的基础层时，这些层只需要在存储中保存一次，减少了存储需求。因为镜像层是只读的，所以在创建新镜像时，只需要添加新的可写层，而不需要复制已存在的只读层。

2. 加速镜像构建和拉取： 如果某个基础层已经在本地存在，那么在构建新镜像时可以直接重用该层，而不需要重新下载和构建。这大大加快了镜像的构建速度和拉取速度。

3. 简化镜像管理： 分层存储使得镜像管理更加灵活和简化。可以基于同一个基础层创建多个不同的镜像，并且每个镜像都可以有自己独立的可写层。这样，当需要更新共享的基础层时，所有依赖于该基础层的镜像都可以受益，无需手动重新构建和部署。

总的来说，镜像分层的设计使得镜像可以高效地共享和重用已有的层，减少了存储需求、加速了构建和拉取过程，并简化了镜像管理。这为Docker提供了轻量、快速和灵活的镜像部署和交付机制。

2.镜像层的组成

Docker镜像的文件系统（Filesystem）由多个只读的镜像层（Image Layers）构成，以及一个镜像描述的JSON文件。这种分层的结构使得镜像的构建、存储和传输变得更加高效。

镜像的文件系统由一系列镜像层叠加而成，每个镜像层都是只读的，并包含了文件和目录的内容。每个镜像层都是前一个层的基础上所做的一系列文件系统更改。这些更改可以包括添加、修改或删除文件和目录。由于每个层都只记录了与前一层的差异，因此整个镜像的文件系统只需要存储这些差异，而不是重复存储相同的文件。这种共享和重用的机制大大节省了存储空间。

除了镜像层的文件系统外，每个Docker镜像还包含一个描述镜像信息的JSON文件，通常被称为镜像描述（Image Descriptor）。这个JSON文件包含了镜像的元数据，例如镜像ID、创建时间、作者、标签等。它还包含了指向每个镜像层的散列值（哈希值）以及与每个层相关的文件系统变更信息。这些信息用于构建镜像的完整文件系统。

通过将镜像的文件系统与镜像描述结合起来，Docker可以有效地管理和操作镜像。镜像描述文件允许Docker识别每个镜像层的内容和关系，实现镜像的高效存储、分发和版本控制。同时，通过只读的镜像层，Docker可以确保镜像的不可变性，提供可靠且可重复的构建和部署过程。

总结起来，Docker镜像的文件系统由多个只读的镜像层构成，这些层通过记录文件系统更改的差异来节省存储空间。镜像描述的JSON文件包含了镜像的元数据和与镜像层相关的信息，实现了镜像的高效管理和操作。

3.只读镜像层结构

Docker镜像的只读镜像层可以分为基础镜像层（Base Image Layer）和扩展镜像层（Additional Image Layer），而容器层（Container Layer）位于镜像层的最顶层，并且是可读写的。

1. 基础镜像层（Base Image Layer）：基础镜像层通常包含了操作系统的根文件系统，也被称为rootfs。它是构建镜像的基础，并提供了操作系统的基本文件和目录结构。基础镜像层是只读的，不可更改，通常由Docker官方或第三方提供，并作为其他镜像的基础。

2. 扩展镜像层（Additional Image Layer）：在基础镜像层之上，可以创建扩展镜像层，用于添加额外的文件、配置和应用程序。每个扩展镜像层都是只读的，并且记录了与前一层之间的文件系统更改。这种分层结构使得镜像的构建和更新更加高效和灵活。

3. 容器层（Container Layer）：容器层位于镜像层的最顶层，它是可读写的。当使用镜像创建容器时，Docker会在镜像层之上创建一个容器层，并将容器的文件系统挂载到该层上。在容器运行过程中，可以在容器层上进行文件操作、写入数据等，而不会影响底层的只读镜像层。

容器层的可读写性使得容器可以在运行时修改和保存数据，同时保持基础镜像层的不可变性，从而实现了容器的隔离性和可重复性。容器的修改不会影响基础镜像层和其他容器，每个容器都可以有自己独立的文件系统变动，不同容器之间的文件系统互相隔离。

总结起来，Docker镜像的只读镜像层分为基础镜像层和扩展镜像层，而容器层是可读写的。基础镜像层提供了操作系统的根文件系统（rootfs），扩展镜像层用于添加额外的文件和配置，而容器层用于运行时的文件操作和数据存储，实现了镜像和容器的隔离和可变性。

四、镜像摘要

1.digest 主要作用

Digest（摘要）在Docker中的主要作用是为了区分相同仓库（repository）和标签（tag）的不同镜像。

在Docker中，每个镜像都有一个唯一的摘要值，称为Digest。这个摘要值是通过SHA256算法计算得出的哈希值，它是镜像内容的唯一标识。摘要值由仓库名称、标签和镜像内容组成，保证了每个镜像的唯一性。

摘要值的作用在于：

1. 确保镜像的完整性和一致性：通过摘要值，可以验证镜像是否被篡改或损坏。如果镜像内容发生了任何改变，摘要值也会随之改变，从而确保镜像的完整性。
2. 避免重复下载和使用相同镜像：当使用相同仓库和标签拉取镜像时，Docker会首先检查本地是否已存在具有相同摘要值的镜像。如果存在，则可以直接使用本地镜像，避免重复下载和存储相同内容的镜像。

通过使用Digest，可以消除对镜像标签的依赖，因为标签可能会被重新打上或更新。相反，摘要值是基于镜像内容的计算结果，可以确保每个镜像的唯一性和一致性。

需要注意的是，摘要值是只读的，一旦镜像被创建，它的摘要值就不会再改变。因此，通过摘要值可以确定一个镜像的确切版本，避免了因标签的变动导致的混淆和误用。

总结起来，Digest在Docker中用于区分相同仓库和标签的不同镜像。它提供了镜像内容的唯一标识，确保了镜像的完整性和一致性，同时避免了重复下载和使用相同镜像的问题。

2.分发散列值 Distribution Hash 的作用

分发散列值（Distribution Hash）在Docker中的作用是为了解决在网络传输过程中，由于压缩等操作可能导致命令所携带的摘要（digest）与重新计算的镜像摘要不相符的问题。

在Docker中，当通过镜像仓库拉取镜像时，可以使用镜像的摘要值来验证镜像的完整性和一致性。摘要值是根据镜像内容计算得出的唯一哈希值，用于确保镜像在传输过程中没有被篡改或损坏。

然而，当使用Docker进行镜像的分发和传输时，通常会进行压缩等操作以减小传输的大小和带宽消耗。这种压缩操作会改变镜像的二进制表示形式，从而导致镜像的摘要值发生变化。这样，当接收方尝试验证镜像的摘要值时，发现计算得到的摘要值与传输过程中携带的摘要值不相符，就会产生验证失败的问题。

为了解决这个问题，引入了分发散列值（Distribution Hash）。分发散列值是在镜像上传到镜像仓库之前，针对压缩后的镜像数据计算得出的散列值。它并不受镜像传输过程中的压缩等操作的影响，因此可以用来验证镜像的完整性。

在进行镜像分发和传输时，分发散列值可以与镜像一起传输，并在接收方验证时使用。这样，即使镜像在传输过程中发生了压缩等操作，接收方仍然可以通过分发散列值来验证镜像的正确性。如果验证失败，接收方可以重新拉取镜像，确保获得完整和正确的镜像。

总结起来，分发散列值在Docker中的作用是为了解决在镜像传输过程中，由于压缩等操作导致命令携带的摘要与重新计算的镜像摘要不相符的问题。它提供了一种可靠的方式来验证镜像的完整性，确保镜像在传输过程中没有被篡改或损坏。

五、多架构镜像

1.为什么需要多架构镜像？

多架构镜像的存在是由于不同的操作系统（OS）和体系结构（ARCH）之间存在差异，包括所使用的类库和指令系统的不同。

1. 不同的操作系统（OS）：不同的操作系统具有各自特定的内核、系统调用接口和类库。例如，Windows和Linux在系统调用和类库方面存在差异，这意味着相同的应用程序在不同的操作系统上可能需要不同的镜像。

2. 不同的体系结构（ARCH）：不同的体系结构使用不同的指令集和硬件平台。常见的体系结构包括x86、ARM、PowerPC等。由于指令集的不同，相同的应用程序需要根据所部署的体系结构进行适配。

因此，为了支持不同的操作系统和体系结构，需要针对每个组合（OS/ARCH）设计和构建相应的镜像。这些多架构镜像通常被称为多平台镜像。

多架构镜像的好处包括：

• 跨平台兼容性：多架构镜像允许在不同的操作系统和体系结构上部署相同的应用程序，提供了更大的灵活性和可移植性。
• 资源优化：通过针对特定体系结构和操作系统进行优化，可以提高应用程序的性能和效率。
• 容器化的一致性：多架构镜像可以确保在不同的容器平台上具有一致的构建和部署体验。

需要注意的是，构建和维护多架构镜像可能需要额外的工作和资源投入。但它们提供了更广泛的应用部署选项，能够满足多样化的运行环境需求。

总结而言，多架构镜像的存在是为了适应不同的操作系统和体系结构之间的差异，以支持跨平台的部署和运行。通过提供针对不同OS/ARCH组合的镜像，可以确保应用程序在各种环境中的兼容性和性能优化。

2.为什么我pull之后会给我相应的镜像呢？

Docker Hub可以根据提交的Pull请求的Docker系统的操作系统（OS）和体系结构（ARCH）自动选择与其对应的镜像。

当你提交一个Pull请求到Docker Hub时，Docker Hub会检查Pull请求中的操作系统和体系结构信息。然后，Docker Hub会尝试匹配这些信息与可用的镜像标签进行匹配。

在Docker Hub上，每个镜像都可以标记为特定的操作系统和体系结构。这使得用户可以根据自己的需求选择适当的镜像。当你提交Pull请求时，Docker Hub会根据你请求中的操作系统和体系结构信息来自动选择合适的镜像。

这种自动选择镜像的机制使得用户可以更加方便地获取适用于特定操作系统和体系结构的镜像，从而简化了镜像选择和部署的过程。

需要注意的是，Docker Hub并不总是能够提供适用于所有操作系统和体系结构的镜像，因为不同的镜像仓库和镜像作者可能选择支持特定的平台。因此，在提交Pull请求之前，确保选择与你的操作系统和体系结构兼容的镜像仓库和镜像标签是很重要的。

总结起来，Docker Hub能够根据提交Pull请求的Docker系统的操作系统和体系结构自动选择与其对应的镜像。这个自动匹配机制简化了镜像选择和部署的过程，使用户能够更方便地获取适用于特定平台的镜像。

3.镜像信息是存放位置和实现原理。

多架构镜像的信息是存储在Docker Hub的Manifest文件中。多架构镜像的实现原理涉及两个主要概念：Manifest List和Manifest。

1. Manifest List（清单列表）：Manifest List是一个JSON文件，它包含了不同体系结构和操作系统的镜像Manifest的引用。一个Manifest List可以包含多个Manifest引用，每个引用对应一个特定的体系结构和操作系统。

2. Manifest（清单）：Manifest是描述一个具体镜像的JSON文件，它包含了镜像的配置信息和层（Layer）的摘要（Digest）等。每个Manifest对应一个特定的体系结构和操作系统，包含了该体系结构和操作系统所需的镜像信息。

多架构镜像的实现原理如下：

1. 构建镜像：对于多架构镜像，需要针对每个体系结构和操作系统分别构建对应的镜像，并为每个镜像生成独立的Manifest。

2. 生成Manifest List：在Docker Hub上，为了将多个Manifest组合成一个统一的镜像，使用Manifest List。Manifest List是一个JSON文件，其中包含了不同体系结构和操作系统的镜像Manifest的引用。通过Manifest List，可以将不同体系结构和操作系统的镜像关联在一起。

3. 镜像拉取和选择：当用户拉取多架构镜像时，Docker客户端会发送关于操作系统和体系结构的信息到Docker Hub。Docker Hub会根据这些信息选择合适的Manifest List，并返回该Manifest List给客户端。

4. 选择合适的Manifest：在接收到Manifest List后，Docker客户端会根据自身的操作系统和体系结构信息选择与之匹配的Manifest。然后，客户端会根据选定的Manifest获取镜像的配置信息和层的摘要，并使用这些信息来拉取和构建最终的镜像。

通过Manifest List和Manifest的结构，多架构镜像能够在Docker Hub中被管理和分发。Manifest List提供了一个集中的入口，使用户能够根据自身的操作系统和体系结构选择合适的镜像Manifest，从而实现了多架构镜像的灵活性和兼容性。

需要注意的是，Manifest List和Manifest的存储和管理可以使用不同的技术和工具，而具体的实现方式可能因不同的镜像仓库而有所差异。

总结起来，多架构镜像通过Manifest List和Manifest的结构实现。Manifest List是一个包含不同体系结构和操作系统的镜像Manifest引用的JSON文件，而Manifest是描述具体镜像的JSON文件。通过Manifest List和Manifest的结合，Docker Hub能够提供多

架构镜像的管理和分发功能，使用户能够根据自身的操作系统和体系结构选择合适的镜像。

---

ok，我已讲完。