24、Docker 镜像手动发布与分发全解析

最新推荐文章于 2025-10-27 09:09:41 发布

算法笑匠

最新推荐文章于 2025-10-27 09:09:41 发布

阅读量30

点赞数

CC 4.0 BY-SA版权

分类专栏： Docker实战精髓文章标签： Docker 镜像分发手动发布

本文链接：https://blog.youkuaiyun.com/1a2s3d4f5g/article/details/152568479

Docker实战精髓专栏收录该内容

33 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

Docker 镜像手动发布与分发全解析

1. 手动镜像发布与分发概述

镜像本质上就是文件，因此可以像分发其他文件一样对其进行分发。常见的分发渠道包括网站、文件传输协议（FTP）服务器、企业存储网络或点对点网络等，甚至在知晓镜像接收方的情况下，还能使用电子邮件或 USB 密钥进行分发。

手动镜像分发的典型工作流程如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(Image origin computer):::process -->|docker build| B(Dockerfile):::process
    B -->|docker save/docker export| C(.tar):::process
    C -->|Upload| D(SFTP server / Blob storage / Web server / Email server / USB key):::process
    D -->|Download| E(Consuming computers):::process
    E -->|docker load/docker import| F(Local image cache):::process
    F -->|docker run| G(Container):::process

手动镜像分发的操作步骤如下：
1. 使用 docker build 创建镜像。
2. 使用 docker save 或 docker export 创建镜像文件。
3. 选择合适的文件传输方式进行镜像分发。
4. 客户端使用 docker load 或 docker import 完成镜像的导入。

手动镜像分发的性能评估如下表所示：
| 标准 | 评级 | 说明 |
| — | — | — |
| 成本 | 好 | 分发成本受带宽、存储和硬件需求驱动。托管分发解决方案会捆绑这些成本，且随着使用量增加，单位价格通常会降低，但也会包含人员成本和其他可能不需要的福利，相比自有机制价格更高。 |
| 可见性 | 好 | 与私有注册表类似，大多数手动分发方法较为特殊，比知名注册表更难推广。 |
| 传输速度/大小 | 好 | 传输速度取决于传输方式，文件大小取决于使用分层镜像还是扁平化镜像。分层镜像保留镜像历史、容器创建元数据和可能已删除或覆盖的旧文件，扁平化镜像仅包含文件系统上的当前文件集。 |
| 可用性控制 | 最佳 | 若可用性控制是重要因素，可使用自有传输机制。 |
| 长期控制 | 差 | 使用专有协议、工具或其他非开放且不受控制的技术会影响长期控制。例如，使用 Dropbox 等托管文件共享服务分发镜像文件将无法进行长期控制。 |
| 访问控制 | 差 | 可使用具有所需访问控制功能的传输方式或文件加密。 |
| 工件完整性 | 差 | 完整性验证在广泛分发中实现成本较高，至少需要一个可信的通信渠道来宣传加密文件签名。 |
| 保密性 | 好 | 可使用廉价加密工具实现内容保密。若需要元保密（交换本身保密）和内容保密，则应避免使用托管工具，确保传输方式提供保密功能（如 HTTPS、SFTP、SSH 或离线）。 |
| 所需经验 | 好 | 托管工具通常设计为易于使用，与工作流程集成所需经验较少，但在大多数情况下，也可轻松使用自有简单工具。 |

2. 使用文件传输协议的示例分发基础设施

2.1 FTP 作为分发工具的特点

FTP 虽不如以往流行，且该协议不提供保密功能，认证时需在网络上传输凭据，但软件免费，且大多数平台都有客户端，因此是构建自有分发基础设施的不错选择。

2.2 实验准备

首先，从 Docker Hub 拉取一个要分发的已知镜像，例如 registry:2 ：

docker pull registry:2

2.3 构建镜像分发基础设施

运行一个 FTP 服务器：

docker run -d --name ftp-transport -p 21:12 dockerinaction/ch9_ftpd

此命令将启动一个接受 TCP 端口 21（默认端口）上 FTP 连接的 FTP 服务器。该服务器配置为允许匿名连接在 pub/incoming 文件夹下进行写访问，此文件夹将作为镜像分发点。

2.4 导出镜像为文件格式

使用以下命令将 registry:2 镜像导出为结构化镜像文件：

docker save -o ./registry.2.tar registry:2

该文件将保留与镜像关联的所有元数据和历史记录。此时，可进行校验和生成或文件加密等操作，但此基础设施无此类要求，可直接进行分发。

2.5 上传镜像文件到 FTP 服务器

dockerinaction/ch9_ftp_client 镜像已安装 FTP 客户端，可用于将新镜像文件上传到 FTP 服务器。若在本地计算机上运行容器，可使用容器链接引用 FTP 服务器；否则，可使用主机名注入、服务器的 DNS 名称或 IP 地址：

docker run --rm --link ftp-transport:ftp_server \
    -v "$(pwd)":/data \
    dockerinaction/ch9_ftp_client \
    -e 'cd pub/incoming; put registry.2.tar; exit' ftp_server

可通过列出 FTP 服务器文件夹的内容来验证镜像是否上传成功：

docker run --rm --link ftp-transport:ftp_server \
    -v "$(pwd)":/data \
    dockerinaction/ch9_ftp_client \
    -e "cd pub/incoming; ls; exit" ftp_server

2.6 客户端消费镜像

在评估此分发方法之前，先模拟客户端消费镜像的过程：
1. 从本地镜像缓存和本地目录中删除 registry 镜像和文件：

rm registry.2.tar
docker rmi registry:2

从 FTP 服务器下载镜像文件：

docker run --rm --link ftp-transport:ftp_server \
    -v "$(pwd)":/data \
    dockerinaction/ch9_ftp_client \
    -e 'cd pub/incoming; get registry.2.tar; exit' ftp_server

使用 docker load 将镜像重新加载到本地缓存：

docker load -i registry.2.tar

2.7 FTP 分发基础设施的性能评估

标准	评级	说明
成本	好	这是一种低成本传输方式，相关软件免费，带宽和存储成本应与托管的镜像数量和客户端数量成线性比例。
可见性	最差	FTP 服务器在未宣传的位置运行，集成工作流程非标准，可见性极低。
传输速度/大小	差	此示例中，所有传输都在同一计算机上的容器之间进行，命令执行迅速。但如果客户端通过网络连接到 FTP 服务，速度将直接受上传速度影响，且该分发方法会下载冗余工件，不会并行下载镜像组件，整体带宽效率不高。
可用性控制	最佳	对 FTP 服务器有完全的可用性控制，若服务器不可用，只有自己能恢复服务。
长期控制	最佳	可按需使用为此示例创建的 FTP 服务器。
访问控制	最差	此配置不提供访问控制。
工件完整性	最差	网络传输层在端点之间提供文件完整性，但易受拦截攻击，且在文件创建和上传之间或下载和导入之间无完整性保护。
保密性	最差	此配置不提供保密功能。
所需经验	好	实现此解决方案所需的所有经验已提供，若要扩展此示例用于生产，需熟悉 `vsftpd` 配置选项和 SFTP。

总的来说，这种传输配置几乎不适用于任何实际场景，但有助于说明将镜像作为文件处理时的不同关注点和基本工作流程。唯一更灵活且可能更复杂的镜像发布和分发方法是分发镜像源。

3. 镜像源分发工作流程

3.1 概述

镜像源分发虽然可能最复杂，但却是最常见的方法之一，原因是流行的版本控制软件已经对扩展接口进行了标准化。

3.2 使用 GitHub 上的 Dockerfile 分发项目

使用 Dockerfile 和 GitHub 分发镜像源与在托管 Docker 镜像仓库上设置自动构建几乎相同。使用 Git 将本地 Git 仓库与 GitHub 上的仓库集成的所有步骤都是相同的，唯一的区别是不创建 Docker Hub 账户或仓库。相反，镜像消费者将直接克隆 GitHub 仓库并使用 docker build 在本地构建镜像。

生产者的分发工作流程

假设生产者有一个现有的项目、Dockerfile 和 GitHub 仓库，其分发工作流程如下：
1. 初始化 Git 仓库：

git init

配置全局用户信息：

git config --global user.email "you@example.com"
git config --global user.name "Your Name"

添加 Dockerfile 到仓库：

git add Dockerfile
# git add *whatever other files you need for the image*

提交更改：

git commit -m "first commit"

添加远程仓库：

git remote add origin https://github.com/<your username>/<your repo>.git

推送至远程仓库：

git push -u origin master

消费者的使用流程

消费者使用的通用命令集如下：
1. 克隆 GitHub 仓库：

git clone https://github.com/<your username>/<your repo>.git

cd <your-repo>

构建镜像：

docker build -t <your username>/<your repo> .

3.3 基于 GitHub 的镜像源分发性能评估

标准	评级	说明
成本	最佳	如果使用公共 GitHub 仓库，则无需成本。
可见性	最佳	GitHub 是开源工具的高可见性平台，提供出色的社交和搜索组件，使项目发现变得简单。
传输速度/大小	好	通过分发镜像源，可利用其他注册表获取基础层，从而减少传输和存储负担。GitHub 还提供内容分发网络（CDN），确保全球客户端能以低网络延迟访问项目。
可用性控制	最差	依赖 GitHub 或其他托管版本控制提供商将无法进行可用性控制。
长期控制	差	尽管 Git 是流行工具且会存在一段时间，但与 GitHub 或其他托管版本控制提供商集成将放弃长期控制。
访问控制	好	GitHub 或其他托管版本控制提供商为私有仓库提供访问控制工具。
工件完整性	好	此解决方案在构建过程中生成的镜像或源克隆到客户端机器后不提供完整性保护，但版本控制系统的核心就是保证完整性，任何完整性问题应通过标准 Git 流程明显体现并易于恢复。
保密性	最差	公共项目不提供源保密性。
所需经验	好	镜像生产者和消费者需要熟悉 Dockerfile、Docker 构建器和 Git 工具。

镜像源分发与所有 Docker 分发工具分离，仅依赖镜像构建器，因此可自由采用任何可用的分发工具集。如果在分发或源代码控制方面受限于特定工具集，这可能是唯一符合需求的选项。

4. 总结

4.1 分发机制总结

4.2 选择建议

在选择分发方式时，应遵循以下原则：
1. 要有多种选择的意识，了解不同分发方式的特点和适用场景。
2. 始终使用一致的选择标准来评估分发选项，以确定最适合的方法。
3. 对于需要高可见性和易于采用的项目，托管公共仓库是不错的选择。
4. 消费者对自动构建生成的镜像会有更高的信任度，因为是由可信的第三方构建的。
5. 若需要对分发过程有更多控制，如可用性控制、访问控制等，可考虑自有注册表或手动分发方式。
6. 若在分发或源代码控制方面受限于特定工具集，镜像源分发可能是唯一的选择。

总之，在进行软件分发时，需综合考虑各种因素，权衡不同分发方式的优缺点，以选择最适合自己的方案。